> C code can reuse existing header files for struct definitions instead
> of doing oid, pnm, psn = struct.unpack(">x2s5sxLxxx", data).On the other hand, C code risks having the same bug in tests and device models, and also endianness is less apparent in C. Overall I'd say it's a wash---if I were to start now I'd use Python but I agree with you that fragmenting the tests is not a good idea. For the purpose of testing the SD card code, I'd use the SD-over-SSI device. Unfortunately there is no board that uses bit-banging SSI, but STM32F405 is as close as it can get to it. Paolo > In general, Python's model for binary data is a marshalling (copy) model > rather than a type casting (in-place access) model. It's fine for some > things but programs that deal with a lot of raw data may use third-party > unboxed data primitives like numpy's instead. I definitely wouldn't say > that binary I/O is a strength of Python. > > > > and porting this to Python 3 will be extra work later (Python > > > 2 is set for End-of-Life in 2020, see https://pythonclock.org/). > > > > > > > You can write today code that work with both python 2 and 3. For binary > > io the key is using io.FileIO and io.BytesIO instead of open() and StringIO > > and CStringIO. > > Yes, it's possible to write the code carefully and test under both > Python 2 & 3. We have to do that for Python code in QEMU since the > world is currently transitioning and both Python versions are in use. > > So in this case, where it's questionable to start a new device-level > testing framework in the first place, the extra trouble of dealing with > Python 2 & 3 makes it even less appealing. > > Stefan >
