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

[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.