4 ms·

I do bare metal C on modern ARM chips and nowadays it is near identical to anything you'd do on a desktop. We don't have to write portable code to compile most

by edoo 8y ago

I do bare metal C on modern ARM chips and nowadays it is near identical to anything you'd do on a desktop. We don't have to write portable code to compile most of the same libraries on real computers for proper unit testing. It is hilarious to think about the possibility of having to make your code portable to a 9 bit big endian system too.

jandrese 8y ago
I was thinking what a headache it must be to read a bitstream from one of those machines onto an 8 bit byte machine.
- SlowRobotAhead 8y ago
  I have a 32bit system that has a LIN connection to an 8bit system (or few or them). On the 8bit side I can still handle a 32bit address or hash for example. It’sslower but works fine in effect to what the user would experience. Before the great serialization options we have now (MessageBuffers, ProtoBuf, etc) there was a bit more ambiguity with what your data stream was. TLV (type-length-value) packing being pretty common... but I guess I’ve written plenty of domain specific ‘protocols’. If you mean a constant bitstream of never ending data, if you can use an established format like I2C or SPI the hardware on both sides really takes care of most the gritty stuff giving you a nice interrupt on both sides. Doesn’t really matter one side has the “preference” to look at in in 32bit chunks and the other in 8bit. Besides, even on ARM the physical transfer is typically in 8bit units anyhow. SPI can send 16s or 32s, but can also stop at 8s usually. It’s the ASIC/drivers/devices that are more rigid in their streaming requirements (this device MUST accept 8bit transfers, etc).
  - jandrese 8y ago
    I meant consuming a 9bit/byte bytestream on an 8bit/byte box.
SlowRobotAhead 8y ago
Agreed. I’m on ARM every day and it’s not nearly as foreign as people think. Here is the issue though, portability is a joke even between chips of the same series let alone chips of different mfgs and code for PC. In a PC I’m not stuffing every possible bit in a structure because I’m going to push this “object” over a 10kbps bus at some point or because on system still measures it’s ram with a K not a G. And typically it’s moot. Even if I have an RTOS, the majority of what a micro is doing is loading data in and out of peripherals. When it’s CPU heavy it’s typically (for me anyhow) just crunching some data in order to load a result into a peripheral. Well - those peripherals are never the same between mfgs. So portability it’s really as important to me as understanding how the mfg intended the peripheral to be used and doing so efficiency. I’ve been doing this for some time and while it’s a nice goal to write once use many, reality gets in the way.

by edoo 8y ago

jandrese 8y ago

I was thinking what a headache it must be to read a bitstream from one of those machines onto an 8 bit byte machine.

SlowRobotAhead 8y ago
I have a 32bit system that has a LIN connection to an 8bit system (or few or them). On the 8bit side I can still handle a 32bit address or hash for example. It’sslower but works fine in effect to what the user would experience. Before the great serialization options we have now (MessageBuffers, ProtoBuf, etc) there was a bit more ambiguity with what your data stream was. TLV (type-length-value) packing being pretty common... but I guess I’ve written plenty of domain specific ‘protocols’. If you mean a constant bitstream of never ending data, if you can use an established format like I2C or SPI the hardware on both sides really takes care of most the gritty stuff giving you a nice interrupt on both sides. Doesn’t really matter one side has the “preference” to look at in in 32bit chunks and the other in 8bit. Besides, even on ARM the physical transfer is typically in 8bit units anyhow. SPI can send 16s or 32s, but can also stop at 8s usually. It’s the ASIC/drivers/devices that are more rigid in their streaming requirements (this device MUST accept 8bit transfers, etc).
- jandrese 8y ago
  I meant consuming a 9bit/byte bytestream on an 8bit/byte box.

SlowRobotAhead 8y ago

Agreed. I’m on ARM every day and it’s not nearly as foreign as people think. Here is the issue though, portability is a joke even between chips of the same series let alone chips of different mfgs and code for PC. In a PC I’m not stuffing every possible bit in a structure because I’m going to push this “object” over a 10kbps bus at some point or because on system still measures it’s ram with a K not a G. And typically it’s moot. Even if I have an RTOS, the majority of what a micro is doing is loading data in and out of peripherals. When it’s CPU heavy it’s typically (for me anyhow) just crunching some data in order to load a result into a peripheral. Well - those peripherals are never the same between mfgs. So portability it’s really as important to me as understanding how the mfg intended the peripheral to be used and doing so efficiency. I’ve been doing this for some time and while it’s a nice goal to write once use many, reality gets in the way.