Slashdot Mirror

You do realize that this isn't the kind of ARM that you run Linux on, right? This is a Cortex-M microcontroller, and it's meant to do the kind of stuff that AVR does, only with a 32-bit processor and a single address space that doesn't confuse C compilers. There's plenty of sizes of Cortex-M from 2K-128K RAM and 4K-1M flash, and they run the gamut from low power to hardware floating point. As for cost, you're talking about a buck or two per chip average (the big number-crunching monsters might cost as much as ten bucks), with lots of low-end ones under a dollar.

The main disadvantage for hobbyists is that the one in TFA is the only ARM chip you can get in a DIP package. But these days the Arduino form factor is pretty common in typical ARM boards, and it sure beats trying to rig up the chip like in TFA every time. Such boards usually cost from $10-$25, literally as much or less than a genuine (non-bootleg) Arduino.

As an actual embedded systems programmer, I can tell you that most of them use C because they can't grok (or even actively hate) C++. Sure, you don't want to go nuts with dynamic allocation (a bad thing in the small-system embedded systems world), but a subset of C++ * can be quite effecitvely used for embedded systems programming. Just limiting yourself to C99+classes+virtual method functions and static/auto scope objects can really improve the quality of your code over C.

* Yes, EC++ as a specific C++ dialect may be defunct, but IMHO it was created more for the benefit of compiler vendors who were having trouble getting templates and exceptions working properly back in 2002 or so.

http://www.st.com/web/catalog/... Cost: 10 Euro. That gives you an ARM Cortex with plenty of resources, Arduino compatible headers, debugger on board, and the tools are free and you can use http://www.mbed.org/ with it. And yes, the pins are labeled.

http://www.st.com/web/catalog/... Cost: 10 Euro. That gives you an ARM Cortex with plenty of resources, Arduino compatible headers, debugger on board, and the tools are free and you can use http://mbed.org/ with it.

This new thing is based on mbed, which uses an online web-based cloud IDE and compiler, nothing to install. I've seen indications that they may want to run their own back-end on a different domain than the usual mbed compiler, but it should be the same principle. Once you hit compile, all your code (stored remotely, but you can get it exported as a zip file) is compiled, and it creates the .bin file as a Save As, which you save to the (usually fake) file system presented by the USB interface, which then programs the target CPU.

I've read a few things about it today, and it's going to be mbed based, which has me chuffed because I'm a big mbed fan, and that means that the USB port will obviously be for programming and power. And once it's programmed, the battery means it won't have to stay plugged into a computer to flash its blinkenlights.

The CPU they're using not only has a Bluetooth module, it even supports programming over Bluetooth. At that point you'll probably want a battery to make up for the lack of a USB connection.

What I don't know is if the USB can be used as a regular USB device port, to make little HID devices and such. But in my experience, a USB port used for programming usually can't be used that way, and boards will have a second USB port just for this.

I've read a few things about it today, and it's going to be mbed based, which has me chuffed because I'm a big mbed fan, and that means that the USB port will obviously be for programming and power. And once it's programmed, the battery means it won't have to stay plugged into a computer to flash its blinkenlights.

The CPU they're using not only has a Bluetooth module, it even supports programming over Bluetooth. At that point you'll probably want a battery to make up for the lack of a USB connection.

What I don't know is if the USB can be used as a regular USB device port, to make little HID devices and such. But in my experience, a USB port used for programming usually can't be used that way, and boards will have a second USB port just for this.

Every software developer, please stop using OpenSSL. It was crap then, it is crap now and it will be crap tomorrow. And LibreSSL is not the solution. You can't turn crap into something nice. You want a decent SSL library, try mbed TLS. Unlike OpenSSL, this library has good documentation (example programs included), has a logical and sane API (no ugly callback shit) and its code is clean and secure.

I switched from OpenSSL to mbed TLS (named PolarSSL back then) in my open source project some time ago. I should have done it more early! The migration was easy and only cost me a few days. So, stop punishing yourself and give mbed TLS a try. You won't regret it!!

Disclaimer:
No, I'm in no way connected to mbed TLS. Just a happy mbed TLS user who doesn't understand why people keep on torturing themselves and their users.

In that case, you better try mbed TLS (former PolarSSL). Has been tested and audited more times than this untested new comer. And it has full support for everything that is needed. mbed TLS makes every new attempt to implement an SSL / TLS library obsolete immediately.

IO ports. The Beeb had millions of them

The are a good modern alternative (and cheaper than a BBC was, back in the day!). The LPC1768 has the same amount of RAM as the BBC and a bit more flash than the BBC had space on a floppy disk, and has analogue and digital I/O pins, as well as serial (which the BBC had with RS-423), and a few things the BBC lacked (Ethernet and USB).

Yes

It works really well for embedded programming, especially when you don't have a heap. And anywhere you would consider using a bunch of function pointers, using virtual methods instead will make for a lot cleaner code. Also, classes can be used as an API for hardware devices, something I learned after being introduced to mbed.

It is salvageable if you throw away most of it. Using it as "C with classes" has a lot of potential. C++ does have a few problems that made templates necessary, but that doesn't mean that I don't think templates aren't a fucking mess, or that you even need to use them.

Look at mbed as an example of using C++ without templates or iostreams. Classes are treated as an API to hardware, with a single object representing one instance of a hardware device, containing the port/unit number and state. For instance, to use Timer 3 in a microcontroller, you would create an timer class object and initialize it with the number 3, like a declaration of "Timer t3(3);" then do things with it like "t3.SetMode(Timer::MODE_PWM); t3.SetCount(1000); t3.Start();".

Just remember that the only difference between a struct and a class is that a class's members are private by default, and a struct's members are public by default. So all you're doing is adding function calls to a struct, with the struct's address being an implicit pointer called "this", and whose elements don't need extra syntax to access them, just like locals and globals.

Like others have said, "It depends." But, having plunked $50-ish for an mbed - https://mbed.org/ - I'm having a blast with it. It even has usable threads so you can do a form of *nix-like parent-child intercommunication and multi-processing. Like the Arduino, there are a lot of libraries available so you can just drop in a module and off you go. The LPC1768 is powerful enough that when you find you want to do a "real" project, you don't have to change MCUs.

I've read their guidelines, and they're doing much like I've been doing recently with moving from C to C++ for embedded systems programming, which is to avoid the really crazy shit that you can do in C++. In particular, exceptions and RTTI are absolutely verboten. They're even planning a compiler switch that turns off the features that will be outlawed in the compiler source. Any templates outside of STL are also forbidden ("template hell" sucks), and I won't even use STL myself because I can't count on having a heap. Even iostreams are being frowned on except maybe possibly in debug dump code where no text language translations are needed.

C++ can really tidy up C code that uses any sort of function pointer hooks or object dispatch style switch statements with virtual methods. A class can become a mini-API, and even used as a sort of device-driver, as in the mbed libraries. Doing this has really helped improve encapsulation in my own code.

I'd rather have one of these: http://www.mbed.org/ I've been using these for personal projects and various tasks at work, and they've been a dream to work with, especially coming from the world of closed-source, proprietary PIC microcontrollers and the expensive compilers they require to get a decent high-level language working.

The Mbed is another board to consider to get a microcontroller project up and running quickly. It has a ARM processor, 512k flash, 64k RAM, and it plugs into a breadboard.
A C compiler is available online "in the cloud" to build your application with free libraries for the peripherals. It also has ethernet and USB, so it is quite a bit more capable than the Arduino.
See http://www.mbed.org/ for details.

You can do this with an mbed and not need to etch your own PCB or solder SMT components. I got one when they first shipped and let me say they are a pleasure to work with. Ethernet, USB, serial (rs232, SPI, i2c), PWM, Analog in and out as well as digital in and out. Small compact foot print that is DIP compatible. The best pat is it is programed with c++ instead of assembly. You don't need a programmer either as you plug it into any PC (Works with Linux, OSX and Win) via usb and shows up as a 2mb flash disk and you drag and drop the binary to the disk and hit the reset button. The only down side is the compiler is online so its sorta cloud based but there are third party compilers for the ARM Cortex that will work with the mbed.

No I am not paid to plug this device, its just been a while since I had this much fun playing with embedded hardware. http://www.mbed.org/