Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
tiny rhetoric question...
#1
If you guys are forking and considering a major overhaul of the firmware, have you considered starting from scratch with a new hardware platform?

16 bits just does not seem right for 2014. There is stm32 (not automotive - that's an issue) and MPC56xxx/SPC56xxx. 32 bit, faster, FPU. Overall, that's the next level of performance, meaning a new level of features and/or the new level of code quality simply by reducing the need to kink in order to get the job done in time.

Just saying Smile
Reply
#2
Hi,

Yes I have considered it. Right now I just don't have to time for a ground up effort. The s12x is essentially a 16-bit core, but there are tons of other metrics that should be considered. IMO the s12x is on the weak side of the spectrum, but it is pretty rich in modules. Some of typical the things that make a 16-bit chip "slow" have been mitigated with 32-bit instructions(32 bit hardware divide for example). We have made available gcc patches that allow the compiler to take advantage of such improvements. Unfortunately codewarrior can still run circles around gcc. Really the only thing saving it in terms of rt latency, is the xgate Co processor.

If I have the time/drive/need for a clean slate, I would likely chose an arm based chip. I like gcc and the code generated for arm targets is respectable. I think an arm + small fpga could solve just about anything. But for the time being a fork serves well enough.

As far as how much time other guys may have, I can't speak on that subject Smile I like you comment about a hal, I will comment on that post soon. Thanks.
Reply
#3
(02-10-2014, 10:35 AM)seank Wrote: Hi,

Yes I have considered it. Right now I just don't have to time for a ground up effort. .......Unfortunately codewarrior can still run circles around gcc.

If only there were an existing project 5634 project using CW..... hmmmm



Tongue
Reply
#4
My (Newbie) $0.02 is to stick with the current Freescale devices.
Not only are they already 'automotive rated' by design. (eg: Temp range and available peripherals), but they're also far more 'deterministic' than ANY ARM chip I've played with.
As a microcontroller, I've found most ARM based offerings are truly lacking. When I write code to command a change of state of any given pin, I want it to happen when I tell it to and not have the pin toggle being 'buffered' until such time as the crossbar has an available microcycle to actually bother getting around to flipping the state of the ^%$&^%$ pin!
I suspect there are many 'suitable' ARM based micros out there without the pin I/O pipeline... I've just not played with any of them... YET...
(That reminds me... I must 'upgrade' the RepRap sometime soon. A _WHOLE_ different topic there)

(02-10-2014, 10:35 AM)seank Wrote: Hi,

Yes I have considered it. Right now I just don't have to time for a ground up effort. The s12x is essentially a 16-bit core, but there are tons of other metrics that should be considered. IMO the s12x is on the weak side of the spectrum, but it is pretty rich in modules. Some of typical the things that make a 16-bit chip "slow" have been mitigated with 32-bit instructions(32 bit hardware divide for example). We have made available gcc patches that allow the compiler to take advantage of such improvements. Unfortunately codewarrior can still run circles around gcc. Really the only thing saving it in terms of rt latency, is the xgate Co processor.

If I have the time/drive/need for a clean slate, I would likely chose an arm based chip. I like gcc and the code generated for arm targets is respectable. I think an arm + small fpga could solve just about anything. But for the time being a fork serves well enough.

As far as how much time other guys may have, I can't speak on that subject Smile I like you comment about a hal, I will comment on that post soon. Thanks.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)