4 ms·

C is much better for this now, you are not tied to the processor architecture and thus can switch to a better/cheaper cpu easily. The cell modem he is using al

by alfor 4y ago

C is much better for this now, you are not tied to the processor architecture and thus can switch to a better/cheaper cpu easily. The cell modem he is using already has a 32 arm cpu maybe even multi-core. 32bit it the new 8bit. C is the new assembly for 99% of code. You can drop to assembly for the 1% where it matter.

tomhoward 4y ago
Yep, that's exactly what we've been talking about.
StillBored 4y ago
not tied to the processor architecture and thus can switch to a better/cheaper cpu easily. The core processor arch yes, but for many (most?) of these small embedded systems, a large part of the code is basically device drivers used to communicate with GPIO, a plethera of serial buses, and any number of other devices which vary from microcontroller to microcontroller. So unless you offload all that to a RTOS of some kind (which your then limited to devices the RTOS supports) switching devices isn't easy. And for many things, the RTOS overhead will be the largest consumer of CPU+RAM. That is sorta the beauty of the ardunio ecosystem were much of this has been abstracted into common libraries across a number of device families.
- alfor 4y ago
  State machines in C work great when you don’t want a preemptive RTOS. I did a embedded project on 8051 like that, we had the legacy code 100% in asm and we moved to C. In the end I think we had about 10-20 lines of asm and everything else in C. You are right switching cpu and thus all the peripheral is major headache, not something to take lightly.
  - deleted 4y ago
    [deleted]
  - Johnythree 4y ago
    Is relatively trivial. Have done it countless times since the early '80's. In fact I find that learning new high level packages much harder.
adhesive_wombat 4y ago
This is pretty important right now, since there's tons of micros you literally cannot buy, some venerable 8-bitter lines are being cut off entirely and there's a whole new RISC-V panoply coming down the tracks. With C, you just need to rewrite the device drivers (because your business logic is portable and unit tested, right?!). In assembly, it's time to throw it all away and start again. For a trivial programme like read the ADC and do something like alert on a UART, that's not so bad. But some products are a lot more complex than that.
- ddingus 4y ago
  One could emulate those 8 bit CPU's and get good performance too. The bonus being able to continue using well tuned, mature routines. An emulation done once, would bring the whole works onto a new CPU.
  - adhesive_wombat 4y ago
    Maybe, but a well-tested routine running in a new emulator is no longer well-tested. There's a careful value judgement to be made there. For example, if you have many products all in some dying 8-bit architecture, and it's easier to write the emulator once and then all the products are rescued, then good. If you spend 6 months writing the emulator to save yourself from 6 weeks of porting one simple program, less good. This is when "hey wouldn't it be really cool if" meets the cold realities of commercial engineering.
    - ddingus 4y ago
      I have seen all sorts of stuff done small scale commercial. I agree with you. I took this particular case to mean there are lots of products. Could also just put the CPU into an FPGA, which would be a choice I would look hard at personally. Many 8 bitters are out there, some cycle exact. Then one has a hardware solution to build. Could go quicker.
      - adhesive_wombat 4y ago

by alfor 4y ago

tomhoward 4y ago

Yep, that's exactly what we've been talking about.

StillBored 4y ago

not tied to the processor architecture and thus can switch to a better/cheaper cpu easily. The core processor arch yes, but for many (most?) of these small embedded systems, a large part of the code is basically device drivers used to communicate with GPIO, a plethera of serial buses, and any number of other devices which vary from microcontroller to microcontroller. So unless you offload all that to a RTOS of some kind (which your then limited to devices the RTOS supports) switching devices isn't easy. And for many things, the RTOS overhead will be the largest consumer of CPU+RAM. That is sorta the beauty of the ardunio ecosystem were much of this has been abstracted into common libraries across a number of device families.

alfor 4y ago
State machines in C work great when you don’t want a preemptive RTOS. I did a embedded project on 8051 like that, we had the legacy code 100% in asm and we moved to C. In the end I think we had about 10-20 lines of asm and everything else in C. You are right switching cpu and thus all the peripheral is major headache, not something to take lightly.
- deleted 4y ago
  [deleted]
- Johnythree 4y ago
  Is relatively trivial. Have done it countless times since the early '80's. In fact I find that learning new high level packages much harder.

adhesive_wombat 4y ago

This is pretty important right now, since there's tons of micros you literally cannot buy, some venerable 8-bitter lines are being cut off entirely and there's a whole new RISC-V panoply coming down the tracks. With C, you just need to rewrite the device drivers (because your business logic is portable and unit tested, right?!). In assembly, it's time to throw it all away and start again. For a trivial programme like read the ADC and do something like alert on a UART, that's not so bad. But some products are a lot more complex than that.

ddingus 4y ago
One could emulate those 8 bit CPU's and get good performance too. The bonus being able to continue using well tuned, mature routines. An emulation done once, would bring the whole works onto a new CPU.
- adhesive_wombat 4y ago
  Maybe, but a well-tested routine running in a new emulator is no longer well-tested. There's a careful value judgement to be made there. For example, if you have many products all in some dying 8-bit architecture, and it's easier to write the emulator once and then all the products are rescued, then good. If you spend 6 months writing the emulator to save yourself from 6 weeks of porting one simple program, less good. This is when "hey wouldn't it be really cool if" meets the cold realities of commercial engineering.
  - ddingus 4y ago
    I have seen all sorts of stuff done small scale commercial. I agree with you. I took this particular case to mean there are lots of products. Could also just put the CPU into an FPGA, which would be a choice I would look hard at personally. Many 8 bitters are out there, some cycle exact. Then one has a hardware solution to build. Could go quicker.
    - adhesive_wombat 4y ago