Important changes to forums and questions
All forums and questions are now archived. To start a new conversation or read the latest updates go to forums.mbed.com.
4 years, 5 months ago.
Why mbed isn't taken seriously
I used to program 8752 microcontrollers using a device burner with code I wrote using an assembler on a old 386 machine. It was great. Imagine how excited I was when I discovered the ARM. And then the mbed platform that not only provides an amazing library, but a cool online IDE, and the final offer to download the code directly to your flash-drive-like target! I told everyone how cool it is...for a while.
The fact is that I want it to continue to be that good. The reality is that the mbed team needs to wake up and smell the coffee or become irrelevant in the not too distant future. Here are the most basic issues that cannot be tolerated:
1. The online IDE cannot go down, ever. If it does, there must be some notification or a very short duration downtime. The pain is agonizing when you're trying to get the code working and the site is down just as you're on a hot debugging path.
2. The toolset must support devices, not just modules. It is infuriating that I cannot compile my code with the the by-design LPC11U37 when the only chips that are allowed are the ones that happen to be on some vendor's module. When I compile the code for the 24 when the memory of the 37 is needed, there is no complaint by the tool but the code won't run on the target.
3. The exporting tool must work. Note that this option should rarely be pursued but the failures noted above make this a far-too-often activity. Sure, it causes a lot of uncontrolled possibilities but if the online tool would allow an LPC11U37 like it ought to, this would not be an issue. However, it does not so I download the LPCXpresso development environment because I have a deadline. Mbed allows me to export the project for the LPC11U24 but not for LCPXpresso! So I choose the LPC11U35 to allow the LPCXpresso option and load it into the project but it won't compile, not even close. Oh, there are posts about how the known bugs with the exporting feature. Sorry.
4. The platform is so good in many ways that I want to keep loving it. I have a hard time recommending this methodology when my colleagues keep reminding me of the items above. "We'll never use mbed here b/c..." Ouch.
5. Developers need map files. They need finer control over compiler and linker options. Pleeease!
I'm dead in the water right now. I have a target with plenty of memory to meet my needs but I can't compile the code. If I remove some of data tables, or disable just one of the features (SD card support, for example) at a time, the code will compile and fit but I need it all in the chip at the same time.
How can I get the code to compile for the LPC11U37? I've read posts about faking the compiler to use 37-type params when compiling for a 24 but they don't work.