ARM and portability.. what's the real deal?

[JPortici]

Something that comes to my mind from time to time..
I don't use ARM a lot so please forgive and correct the inaccuracies. Neither on my projects nor on the job, i haven't had real need for 32 bit arithmetics so i try and find excuses to use them
I remember while i was taught ARM in school that one of the buzzwords in favour was "portability"
because, you know, several manufacturers use arm cores. you write your code one time and if you change manufacturers you don't have to re-do all the work.

Bullshit, i say. Every manufacturer has its conventions and most important of all it peripherals. Even if i ditch the HAL and access the registers the names change, the bits change, the positions in ram change.
So this might be that they are portable from one family to the other, inside the same manufacturer?
you mean just like i could do before?

One may argue that if you want to optimize an purely software algorithm with no connection to the hardware, random word in -> word out that you can do one time only.. just like CMSIS
but yeah... claiming that a microcontroller code is portable just for that reason...

thoughts? what am i missing?

[ataradov]

thoughts? what am i missing?

You are missing the fact that a big project will have most of its code hardware independent. And the code is portable in a sense that you get predictable behavior when moving your high level code between the devices.

The same applies to desktop software, while Linux is portable to many architectures, it does not mean that it will just work on something new or different without additional work, it just means that this work is going to be hugely reduced.

Also, ARM has established ecosystem of tools, so you don't have to buy super expensive tools (for no real reason) when moving to a different device vendor.

Plus ARM establishes a certain pattern in a way peripherals are designed, so it is way easier to understand the workings of a peripheral on a new MCU.

Same would apply to any other core, of course, but there is just no real ecosystem of MIPS devices.

And yes, porting big (but properly architected) projects between different ARM-based devices is really easy.

[legacy]

the code is portable in a sense that you get predictable behavior when moving your high level code between the devices

um, I believe it couldn't have been written better
*predictable behavior* is actually the concept key

[JPortici]

i think i can see what you mean. I should also mention that i never had *real* team experience in a workplace, i am mostly the only one in charge of the hardware, or the code or both. projects and jobs that aren't of course so large or complex that need a team.
I already thought that portability (and how you said predictability) was more important the more abstraction you had from the actual hardware.. so i would say the R and A series.. because i haven't seen much need of abstraction on microcontrollers yet

[nctnico]

It depends on what kind of pheripherals you are dealing with. I2C, SPI, timers, UARTs, etc are very similar. For ethernet and USB you use readily made protocol stacks which should offer a similar interface because their purpose is similar. I never had issues porting code between microcontrollers unless the architecture was too archaic to support a generic way of writing C.

[ataradov]

because i haven't seen much need of abstraction on microcontrollers yet

That's because you are looking at 8-bit MCUs. And that's exactly the problem - they are typically resource-limited, so they encourage poor design.

You say that you never had a need for 32-bit (and possibly floating point) arithmetic . I say, you have that need, but you just don't realize what a waste of time 8-bit micros are.

It is very liberating to not have to think if certain variable should be 8-bit or 16-bit, but with some performance impact, so you make it work as 8-bit. This very low-level thinking is very typical on 8-bit devices and leads to a very poor code.

[mikeselectricstuff]

The core doesn't really matter, the portability argument is mostly bullshit.
It would be much easier to port PIC24 to PIC32 than ARMs from different manufacturers, as it's mostly about the peripherals.
 
About the only factor that's core dependent is if you've invested in a profesisonal IDE liek IAR etc. then you'd probably want to move between parts with the same core so you can use the same devtools.
 

[legacy]

so, you will have a lot of fun with Infiineon XMC4500 

[dannyf]

you write your code one time and if you change manufacturers you don't have to re-do all the work.

only those who don't know embedded programming would say that.

With that said, the key to a large project is to isolate "hardware" from your software: your code would be about the logic of your application, not how the application is implemented.

If you take that approach, your code is far more portable, ARM or not.

[ebclr]

To all those that "guess" that port arm is hard

One unique platform that handles

 ARM
 Atmel
 BBC Make it Digital Campaign
 CQ Publishing Co.,Ltd.
 Delta
 Embedded Artists
 Espotel
 JKSoft
 Maxim Integrated
 MultiTech
 NXP Semiconductors
 Nordic Semiconductor ASA
 Nuvoton
 Outrageous Circuits
 RedBearLab
 Renesas
 STMicroelectronics
 SeeedStudio
 Semtech
 Silicon Labs
 Switch Science Inc.
 WIZnet
 communitycontributors
 u-blox AG

https://developer.mbed.org/platforms/

Even a 9 year kid can port

[ataradov]

Even a 9 yuear kid can port

Only 9 year old will want to. Don't do embed, it is a toy, just like Arduino for grownups. You get least common denominator of all platforms, that's not what you want.

[janoc]

Even a 9 yuear kid can port

Only 9 year old will want to. Don't do embed, it is a toy, just like Arduino for grownups. You get least common denominator of all platforms, that's not what you want.

Actually it is worse than Arduino - Arduino at least works ...

mBed is joke, especially when you talk about portability - how many of those chips by those manufacturers are actually supported by mBed libraries beyond basic "comes out of reset, can blink a LED"?

It is really the lowest common denominator - i.e. in most cases completely useless and you have to resort to vendor libraries or coding to the hw for almost everything, but you still pay for the mBed bloat and overhead with code size.

[ebclr]

Mbed is nothing more than keil, with a layer of libraries ( you can simple don't use the libraries ), I simple don't know any thing that you can do with arm that you can't do using a Keil compiler, Even arduino is also a layer of libraries and the c compiler behind the scene is there if you want to do anything , Mbed is a pretty useful and valuable tool on the right hands a toy on the wrong hands

[ataradov]

you can simple don't use the libraries

Then you can extend your list with all other ARM device manufacturers. You can program all of them without using mbed libraries.

Now, you also don't have to pay any money and be locked to a crappy online tool, by using GCC

So yeah, mbed is totally cool, as long and you don't use it.

[ebclr]

As i wrote the thing behind the keyboard make the difference.......

[westfw]

So although that is just the core and some integrated peripheral functions that ARM specifies and provides, that is still a lot of compatibility.

In particular, everything that a compiler vendor needs to write, including startup code, critical sections and access to the core registers, is standardized.  And then there are "strong hints" on how to lay out peripherals as well, so those are frequently "similar to access" even when the peripherals themselves are different.  This is in contrast with a bunch of 8bit CPUs, where going from one compiler to another ON THE SAME CHIP can require significant effort.

This is underappreciated, even if the overall claims of portability are overstated...
(Personally, I'm find the limitations of the CM0, with it's "16bit thumb instructions only", to be a bit gross...)

[zapta]

So yeah, mbed is totally cool, as long and you don't use it.

I use mbed with lpcxpresso and it works great for me. For example the Ticker class, usb/serial stack, digital I/O pin classes, and pwm outputs.

[Boomerang]

So yeah, mbed is totally cool, as long and you don't use it.

I use mbed with lpcxpresso and it works great for me. For example the Ticker class, usb/serial stack, digital I/O pin classes, and pwm outputs.

This is interesting - can you download the mbed source code and compile it with LPCXpresso?

[zapta]

This is interesting - can you download the mbed source code and compile it with LPCXpresso?

In the mbed online project you can export it in various project formats including lpcxpresso.

[coppice]

The core doesn't really matter, the portability argument is mostly bullshit.
It would be much easier to port PIC24 to PIC32 than ARMs from different manufacturers, as it's mostly about the peripherals.
 
About the only factor that's core dependent is if you've invested in a profesisonal IDE liek IAR etc. then you'd probably want to move between parts with the same core so you can use the same devtools.

Spot on. The core of my C code (i.e. the bit that don't touch the peripherals) for embedded applications builds without change for a variety of processors, and I usually do most of the development and debug on a desktop machine, before the code ever touches an actual MCU. You have to write pretty poor code these days to have more than trivial issues moving it to a new core - except for some of the really basic 8 bit cores, for which C doesn't work awfully well, and you need to write in a subset of C. Power management is typically the biggest issue. ULP devices, like the MSP430, only get good power results if the code operates in sympathy with their power management features.

When you get to interacting with the MCU's peripherals and DMA the fun really starts. If your needs are pretty basic you might be able to use the peripherals in a fairly generic way, and only produce small amounts of peripheral specific code. If you are using the full power of sophisticated peripherals you might not even be able to get the functionality you want from the peripherals after considerable effort customising your code. As you say, moving between PICs, with similar peripherals, is a lot easier than moving between different manufacturers who all use ARM cores. If you have MSP430 code, you'll get it running on an ARM based MSP432 with very little effort, because of peripheral compatibility. Try to move from another ARM based device to an MSP432 and you'll have considerable work.

[tggzzz]

Something that comes to my mind from time to time..
I don't use ARM a lot so please forgive and correct the inaccuracies. Neither on my projects nor on the job, i haven't had real need for 32 bit arithmetics so i try and find excuses to use them
I remember while i was taught ARM in school that one of the buzzwords in favour was "portability"
because, you know, several manufacturers use arm cores. you write your code one time and if you change manufacturers you don't have to re-do all the work.

Bullshit, i say. Every manufacturer has its conventions and most important of all it peripherals. Even if i ditch the HAL and access the registers the names change, the bits change, the positions in ram change.
So this might be that they are portable from one family to the other, inside the same manufacturer?
you mean just like i could do before?

One may argue that if you want to optimize an purely software algorithm with no connection to the hardware, random word in -> word out that you can do one time only.. just like CMSIS
but yeah... claiming that a microcontroller code is portable just for that reason...

thoughts? what am i missing?

You are missing how to structure a design to allow

• a simple correspondance between behaviour specified in the requirements documents and your code. That greatly simplifies your implementation task, and also getting through design reviews, and also handing your work over to another person
• multiple people to work on the project simultaneously
• you to write and debug the application before the hardware is available
• to make it easy to make changes/enhancements reliably, i.e. in a way minimises the chances of introducing new faults
• you to demonstrate that a fault is in the other person's (or company's) code

If you structure your design in terms of events + algorithms + actions, often in the form of an FSM, then:

• the algorithms and FSM are independent of the hardware, and can be debugged on a PC using a test harness. Very helpful and convenient
• the events and actions are dependent on the peripherals; a small amount of device-specific code translates actions into peripheral output, and peripheral inputs into events
• when you have a possible problem with the hardware, you determine
  
  • whether the inputs triggered the events correctly
  • whether the actions caused the outputs correctly
  • whether the event/actions were in the sequence you expected

And you will note that some degree of portability automatically falls out of that.

I've used those design techniques on life-critical code, and also to demonstrate that another company's code wasn't working properly.

[tszaboo]

I had projects where the boss said the code is portable. It took 2 years to iron out all the bugs which were introduced by this compatibility, and the guy working on it quit. The other project, they moved the code from a 16 bit xc130 to ARM, and it was working in a few weeks. It is really project and coding dependent. If programmers make stupid things (they tend to), nobody can help. This is not just using int16 instead of int, this is deeper than that.

so, you will have a lot of fun with Infiineon XMC4500 

I'm not touching Infineon ever, period.

[dannyf]

mbed can be quite useful.

The attitude exhibited towards mbed is quite similar to that exhibited towards arduino: an "elitist" attitude. those people judge others not by what they can do with their tools but what tools they use.

Superficial to say the least.

[legacy]

I'm not touching Infineon ever

lucky man 

my boss requested us to use Infineon because …. never understood why 

ah, yes, it was because a customer had requested to use it
but this is not the real *cause*, even if it adds more sense in the causality cause-effect
so, the effect is … we are digging every day in these data sheet and application notes
which claims "32-bit-industrial-microcontroller-based-on-arm-registered-cortex-registered"
etc etc etc on their yellowish things on their PDFs about their ARM (supported by their DAVE RAD)

but WHY? on the WHY? are we doing so? nobody (including my boss) knows @____@

[legacy]

a work colleague made us happy like kids under the xmas three
when they get their gifts, and with his effort we had success
in switching from DAVE RAD to Keil/C (happiness)

that dude, DAVE-dude has the RAD suffix which should stand for
something like "rapid? applications development"
but it's almost a lie for the marketing, I guess 

[tszaboo]

but WHY? on the WHY? are we doing so? nobody (including my boss) knows @____@

I believe, the only reason to use Infineon, SAP, DHL, Oracle and all these big bad companies, is simple. They build swimming pools and give car keys or money to the managers. Or brainwash them. I cannot really think of any logical reason to choose them, but there must be something.

[nctnico]

I'm not touching Infineon ever

lucky man 

my boss requested us to use Infineon because …. never understood why 

I didn't know Infineon hopped onto the ARM bandwagon. Infineon makes great semiconductors but they completely suck at producing coherent datasheets and user manuals. Back in my telecom days Mitel (now Zarlink) could describe a chip fully on 5 pages where Infineon needed 30 pages and fill it with contradictions as well.

[JPortici]

because i haven't seen much need of abstraction on microcontrollers yet

That's because you are looking at 8-bit MCUs. And that's exactly the problem - they are typically resource-limited, so they encourage poor design.

You say that you never had a need for 32-bit (and possibly floating point) arithmetic . I say, you have that need, but you just don't realize what a waste of time 8-bit micros are.

It is very liberating to not have to think if certain variable should be 8-bit or 16-bit, but with some performance impact, so you make it work as 8-bit. This very low-level thinking is very typical on 8-bit devices and leads to a very poor code.

Spot on. Basically i should "stop worrying and learn to love the ARM"

After all, my high school education was on Programmable Logic, PLC, pic assembly.. that sort of things.
The course i took on microcontroller programming while i was in uni was a total joke. The tutors had no idea of what they were doing almost all the time and the result was more like yet another arduino tutorial. Every time i had a problem i had to do the hard work myself, which of course is not a bad thing, quite the opposite, but you get the idea.

Been doing this professionally not for a long time time, just quite recently i started trusting the compiler for producing code that can be as clever as i would write it if not better (understandable for 8 bitters) and, most important, i accepted that i don't always have to squeeze every instruction.. i even started using divisions but not for time critical things.

and of course, routines to talk to external chips, as a sanity check. those routines have inside them a for example "SPI_SEND" routine that will be changed if i have to port the code to another micro... i guess i'm improving a step at a time.
But again, i never worked on something high level or so complex that needed a team bigger than two persons.. and what i do is low level anyway, the user interface if present is a computer application that talks with UART
but i want/have/need to broaden my view.

[technix]

ARM does have some portability, but the portability is limited. So far I have only touched different variants of Cortex-M3, and here is my (pretty limited) conclusion: Cortex-M3 from different vendors share the same ISA, basic architecture and basic peripherals, as those are defined by ARM. And portability stops there.

It is good that ARM provided CMSIS which virtually all vendors of ARM-based MCU sticks to, making interrupt management and one of the timers fairly easy to port. I have written a single SysTick.h/SysTick.c that implements the Arduino-style timing functions on STM32F103 using only CMSIS-defined library functions, and those files can be copied into an ATSAM3X8E project and work correctly without any modification. However for virtually any other function to work device- or vendor-specific have to be written.

About HAL, I do feel the need of a HAL but those implemented by vendors are often poor and non-portable. I have once tried ASF from Atmel and STCubeMX, but both HAL generates ugly code that cannot be ported (or understood) in any way. (Even the startup code in STM32 StdPeriph can be hard to understand or extend.) For most platforms I have worked on I usually end up implementing an Arduino-like HAL (implementing the Arduino interface for my specific device and board, so I can cut one corner or two by using existing Arduino libraries in my project during prototype stage)

[Sal Ammoniac]

I didn't know Infineon hopped onto the ARM bandwagon. Infineon makes great semiconductors but they completely suck at producing coherent datasheets and user manuals. Back in my telecom days Mitel (now Zarlink) could describe a chip fully on 5 pages where Infineon needed 30 pages and fill it with contradictions as well.

My company uses Infineon XMC series ARM MCUs and we have not had any problems with the user manuals or the chips themselves. They do what the data sheet and user manuals say they do and we get excellent support from the company when we have questions.

[legacy]

I didn't know Infineon hopped onto the ARM bandwagon. Infineon makes great semiconductors but they completely suck at producing coherent datasheets and user manuals. Back in my telecom days Mitel (now Zarlink) could describe a chip fully on 5 pages where Infineon needed 30 pages and fill it with contradictions as well.

My company uses Infineon XMC series ARM MCUs and we have not had any problems with the user manuals or the chips themselves. They do what the data sheet and user manuals say they do and we get excellent support from the company when we have questions.

with Keil or with DAVE RAD ?

[janoc]

mbed can be quite useful.

The attitude exhibited towards mbed is quite similar to that exhibited towards arduino: an "elitist" attitude. those people judge others not by what they can do with their tools but what tools they use.

Superficial to say the least.

Danny, I know you are trolling, but try to actually use mBed on anything else but the original NXP-based (LPC1768 if I am not wrong) boards. Even if the boards are officially "mBed supported" - like the ST's Nucleos and Discoveries.

Then you can talk.

It has nothing to do with elitism but a simple fact that basic peripherals, like timers or USB aren't supported on many boards, most libraries and APIs work only on certain boards (of course not the one you have), etc. What is the point of such tool?

[Sal Ammoniac]

I didn't know Infineon hopped onto the ARM bandwagon. Infineon makes great semiconductors but they completely suck at producing coherent datasheets and user manuals. Back in my telecom days Mitel (now Zarlink) could describe a chip fully on 5 pages where Infineon needed 30 pages and fill it with contradictions as well.

My company uses Infineon XMC series ARM MCUs and we have not had any problems with the user manuals or the chips themselves. They do what the data sheet and user manuals say they do and we get excellent support from the company when we have questions.

with Keil or with DAVE RAD ?

IAR

[nctnico]

mbed can be quite useful.

The attitude exhibited towards mbed is quite similar to that exhibited towards arduino: an "elitist" attitude. those people judge others not by what they can do with their tools but what tools they use.

Superficial to say the least.

Danny, I know you are trolling, but try to actually use mBed on anything else but the original NXP-based (LPC1768 if I am not wrong) boards. Even if the boards are officially "mBed supported" - like the ST's Nucleos and Discoveries.

Then you can talk.

It has nothing to do with elitism but a simple fact that basic peripherals, like timers or USB aren't supported on many boards, most libraries and APIs work only on certain boards (of course not the one you have), etc. What is the point of such tool?

That it works for the LPC1768 and probably can be made to work for related microcontrollers with little effort. I do agree though that there are too many tools out there claiming to be a one-size-fits-all solution while they are not. For some reason they still make money from marketing BS or just think they got the perfect solution.

[jancumps]

but WHY? on the WHY? are we doing so? nobody (including my boss) knows @____@

I believe, the only reason to use Infineon, SAP, DHL, Oracle and all these big bad companies, is simple. They build swimming pools and give car keys or money to the managers. Or brainwash them. I cannot really think of any logical reason to choose them, but there must be something.

with SAP and Oracle Apps you can actually run a big business. For real.

[zapta]

Danny, I know you are trolling, but try to actually use mBed on anything else but the original NXP-based (LPC1768 if I am not wrong) boards....

I used it with LPC11U35 boards and it works like charm.

Even if some of the APIs are not supported on some CPUs, the API spec still provide a clear path for convergence.

[dannyf]

I used it with LPC11U35 boards and it works like charm.

The whole LPC11xx family is nice, with LPC1114 being my favorite.

[rstofer]

mbed can be quite useful.

The attitude exhibited towards mbed is quite similar to that exhibited towards arduino: an "elitist" attitude. those people judge others not by what they can do with their tools but what tools they use.

Superficial to say the least.

Danny, I know you are trolling, but try to actually use mBed on anything else but the original NXP-based (LPC1768 if I am not wrong) boards. Even if the boards are officially "mBed supported" - like the ST's Nucleos and Discoveries.

Then you can talk.

It has nothing to do with elitism but a simple fact that basic peripherals, like timers or USB aren't supported on many boards, most libraries and APIs work only on certain boards (of course not the one you have), etc. What is the point of such tool?

So, buy a board that is supported!  I use the original mbed all the time for toy projects and one real project.  I noted that the mbed toolchain supports the ST boards but I don't know the state of the libraries.  If the boards, or more specifically their peripherals, aren't supported, well, you are no worse off than starting with bare iron.  You can pick what works from the existing BSPs and write the rest.  Some boards will be better supported than others.  This isn't a new problem!  But the hobbyist always has a choice of boards.  Choose wisely!

I'm not actually using the mbed toolchain for my ST projects but that doesn't mean I won't use it for my LPC1768 mbed projects.  If nothing else, I got the network stack with zero effort.  That's a BIG deal!  And, yes, I ported the entire code base to Rowley Crossworks and it all worked fine.

Disclaimer:  All of my projects are for my personal amusement.  I don't have a team of programmers so I can't invest man-years in writing protocol stacks.  It's amusement, not ordeal!

[janoc]

So, buy a board that is supported! 

Yes, like any of the ST boards sporting the blue mBed enabled logo, you mean? Like this one?
http://www.st.com/content/st_com/en/products/evaluation-tools/product-evaluation-tools/mcu-eval-tools/stm32-mcu-eval-tools/stm32-mcu-nucleo/nucleo-f042k6.html

And then swear when you discover that stuff like USB isn't supported on them or mBed's online compiler doesn't even have support for them yet, despite the boards being sold for a few months already (like the STM32F030 and 042 Nucleos had until recently ...)

I thought that the point of this thread was portability. If I only want a well supported library for a specific chip family, then I will likely go to the vendor's libraries instead, there is little point in using mBed there.

If the boards, or more specifically their peripherals, aren't supported, well, you are no worse off than starting with bare iron.  You can pick what works from the existing BSPs and write the rest.  Some boards will be better supported than others.  This isn't a new problem!  But the hobbyist always has a choice of boards.  Choose wisely!

Exactly - which is why I am not choosing anything with mBed anymore after wasting way too much time on it. There are better libraries around supporting more peripherals and hardware and you certainly don't have to start from bare iron.

E.g. libopencm3 is very good, stm32plus is excellent, ChibiOS is also excellent. And all produce code sizes that are often half of what comes out of mBed, at least for STM32 targets where mBed uses the horrible ST's HAL as a foundation. Actually the enormous code size even for trivial programs was another reason I have rapidly abandoned the idea of using mBed - if a loop reading some data over I2C and doing math on it produces almost a 64kB binary with mBed (making the code not fit in the 32kB MCU) and 20kB with libopencm3, the choice is obvious.

I'm not actually using the mbed toolchain for my ST projects but that doesn't mean I won't use it for my LPC1768 mbed projects.  If nothing else, I got the network stack with zero effort.  That's a BIG deal!  And, yes, I ported the entire code base to Rowley Crossworks and it all worked fine.

By all means, use it. LPC1768 is the originally supported chip by mBed and boards with these are the best supported ones. However, again, the thread is about portability between different chips, not that mBed actually works OK on LPC1768.

BTW, stm32plus and ChibiOS also include networking support if you need it. There are several free TCP/IP stacks available, usually you only need to write/connect the low level drivers for sending/receiving packets (e.g. ethernet).

[rstofer]

BTW, stm32plus and ChibiOS also include networking support if you need it. There are several free TCP/IP stacks available, usually you only need to write/connect the low level drivers for sending/receiving packets (e.g. ethernet).

\
Yes, the mbed TCP/IP stack is based on LWIP.  Nothing original to mbed but they did provide the low level drivers for the LPC1768.

As far as I can tell, the ST compatible boards are compatible only in that they implement the mbed download process. I wouldn't expect any of the peripheral code to be portable if, for no other reason, than the register names are changed.  And i wouldn't make any assumptions on how the peripherals are actually implemented.  There must be a way to research that kind of thing.

For the LPC1768 I don't find code size to be excessive.  My plotter project has 30 kB of source text and generates 67kB of flash code and this includes the network stack, interrupt driven SPI slave (tiny code) and managing a couple of 16k queues and some conversion between step-by-step plotter output and LaserJet HPGL connected through a TCP connection.  Not a big project but one that has been running for a few years.  The neat thing about this project is that the only time I had to get down to the hardware was to deal with the SPI gadget and the NVIC.  Everything else came out of the mbed library.

I have certainly seen some massive code files for the STM32F stuff using the supplied code base (mostly from STM32CubeMX).

[westfw]

This is underappreciated

Y'all are spoiled, and not remembering the bad old days when there would be a LONG wait for SOMEONE to make a compiler for a vendor's new CPU, and then end up stuck with something buggy, non-standard, and expensive.   (oh, better yet - several different buggy and non-standard expensive compilers, all MUTUALLY INCOMPATIBLE!)

[technix]

but WHY? on the WHY? are we doing so? nobody (including my boss) knows @____@

I believe, the only reason to use Infineon, SAP, DHL, Oracle and all these big bad companies, is simple. They build swimming pools and give car keys or money to the managers. Or brainwash them. I cannot really think of any logical reason to choose them, but there must be something.

with SAP and Oracle Apps you can actually run a big business. For real.

You can also run them on MariaDB and PHP.

[janoc]

Yes, the mbed TCP/IP stack is based on LWIP.  Nothing original to mbed but they did provide the low level drivers for the LPC1768.

Yes, that is one I had in mind too.

As far as I can tell, the ST compatible boards are compatible only in that they implement the mbed download process. I wouldn't expect any of the peripheral code to be portable if, for no other reason, than the register names are changed.  And i wouldn't make any assumptions on how the peripherals are actually implemented.  There must be a way to research that kind of thing.

Actually, that is not correct. mBed does support some of the peripherals and you can actually write code for STM32 with it (otherwise it would be completely useless). They use the ST's HAL libraries to connect into their own hardware abstractions. The "download process" is simply a matter of the bootloader on the boards, nothing to do with the architecture itself.

The problem, however, is that mBed support for things like timers, interrupts, uarts and many other peripherals is sketchy at best, with many features not supported or even drivers for the peripheral completely missing. It is also  not consistent between the different boards. E.g. STM32F303 Discovery has USB supported, the STM32F042 Nucleo which has an essentially identical USB hw doesn't. And so on.

This is why I made the comment about Arduino earlier - Arduino at least works and when the board is supported, it really *is* supported - the same code will work with only minimal modifications across all supported boards (modulo obvious things like memory sizes or missing peripherals), because their hardware abstractions are actually implemented for each of them.

For the LPC1768 I don't find code size to be excessive.  My plotter project has 30 kB of source text and generates 67kB of flash code and this includes the network stack ...
...
I have certainly seen some massive code files for the STM32F stuff using the supplied code base (mostly from STM32CubeMX).

Yes and that is the reason why mBed for STM32 is almost useless when code size is concerned - it uses the same code as what CubeMX uses - the ST's new HAL frameworks.

[Bruce Abbott]

This is underappreciated

Y'all are spoiled, and not remembering the bad old days when there would be a LONG wait for SOMEONE to make a compiler for a vendor's new CPU,

I remember when compilers practically didn't exist for the platforms I was interested in, and if they did would have been a joke anyway. Porting consisted of learning the new CPU's opcodes and rewriting my assembler to handle them. Back then peripheral hardware differences were the biggest hurdle. Now we also have to deal with bloated software frameworks and hardware abstraction libraries that are inefficient, poorly documented, incompatible with each other, and don't even work on some of the vendor's own chips!

For me the biggest attraction of 'portability' is being able to use code that someone wrote for a different platform. Nowadays there is a reasonable C compiler available for practically every chip, so basic code compatibility isn't an issue. But a lot of that code is built on top of things like Embed or Arduino, which often often makes it harder to port, not easier. All the critical bits are buried in libraries and stuff that is tied to that platform, so it ends up being easier to just start from scratch.

     

[autobot]

The problem, however, is that mBed support for things like timers, interrupts, uarts and many other peripherals is sketchy at best, with many features not supported or even drivers for the peripheral completely missing. It is also  not consistent between the different boards. E.g. STM32F303 Discovery has USB supported, the STM32F042 Nucleo which has an essentially identical USB hw doesn't. And so on.

The mBed has a test suite you can run on your board which can tell you what stuff work and what isn't. but i haven't seen all this information collected to help us with selection.

[legacy]

Y'all are spoiled

in Air Space Defense, we still use the old DSP M560001
programs, applications, everything is written in assembly
mainly used for radars 

[janoc]

The mBed has a test suite you can run on your board which can tell you what stuff work and what isn't. but i haven't seen all this information collected to help us with selection.

Right. But when you look in the documentation, there is, for example, no documentation at all for timers. Only "software" (virtual RTOS) timers seem to be supported. Even basic stuff like input capture isn't there. Forget about anything more advanced as well.

Oh and documentation - clicked I2C, there is a short trivial example writing few bytes somewhere and when you  open API documentation, you get a copy of the C++ header file. That's all. "Reference" sends you to a Wikipedia article on I2C.  Seriously? How do I configure the I2C peripheral? Use 8 or 10 bit addressing? Use SMBus functions? None of it is documented and the header files seems to imply that the API actually isn't there. Great 

USBHID - cool that they include this ready to go, but how do I set things like the device descriptors?? At least being able to set the polling frequency, the power requirements and whether the device is self/bus powered would be really nice. Only vendor/product ID can be set and a single report type is hardwired. Yay! What is the point of a library like that?

And then there is the issue that nobody really knows what is supported on which board, as you said. Why that cannot be directly in the documentation? Are they afraid that people would see that the majority of the code doesn't actually work on anything else but the original LPC chips?

To me mBed feels like an attempt to make a competition to Arduino for semi-beginners, but after the original company behind it got acquired by ARM directly, it went totally downhill. Enormous feature creep and it is a basically unusable marketing gimmick trying to give an impression of a functioning multi-vendor ecosystem.

[tszaboo]

but WHY? on the WHY? are we doing so? nobody (including my boss) knows @____@

I believe, the only reason to use Infineon, SAP, DHL, Oracle and all these big bad companies, is simple. They build swimming pools and give car keys or money to the managers. Or brainwash them. I cannot really think of any logical reason to choose them, but there must be something.

with SAP and Oracle Apps you can actually run a big business. For real.

You can also run them on MariaDB and PHP.

Or on toilet paper and stones strategically placed in the sand.

[westfw]

Currently working on some code that reads the CMSIS-mandated .SVD files for a chip, and outputs... I dunno.  StuffL  .h files, string tables for use by a parser (your choice of language.)  Forth words.  Lists of peripherals present on the chip, in a much abbreviated form compared to a datasheet.  All that sort of thing. 

Once done, it should work on any ARM chip from any vendor (assuming that a .SVD file is available.)  That's pretty neat!

(it turns out that this is pretty easy, once you use a language with native stings and an XML library - a good excuse to learn some python.)

[ataradov]

(it turns out that this is pretty easy, once you use a language with native stings and an XML library - a good excuse to learn some python.)

It is pretty easy until you go into "advanced" things, like alternative versions of registers layout that depend on some bits set in other registers. And also, documentation of the format is different from what official ARM SVD to header files tool understands.