Embedded platforms for beginners?

to:

mbed.org.

They have cheap hardware, an online IDE (bleah), tutorials, demo, etc. IMHO it's better if you choose the hardware, and then download the official IDE from the producer.

Bye Jack

Elof Huang wrote on 9/1/2017 2:07 AM:

"Embedded systems" is a pretty general term. I would recommend any of the many ARM eval boards. TI has a few that are pretty cheap with free tools. Their MSP430 boards are pretty interesting as well.

Do you have any particular goals?

If you're really a beginner, there is really nothing better than the Arduino system. So much code, blogs, forums, etc, no matter what you want to do, someone will have done it... ... mostly badly, but they will have done it, and it'll give you time to learn how to do better.

I suggested the following shopping list for my son (the only one why didn't major in computer programing!) to start just recently:

As discussed, the best tutorial ecosystem for learning this stuff is Arduino, and the easiest "getting started" because of the huge number of projects you can just copy from. The C language is close to the machine, so you'll learn things that you can apply to other CPU types, not just the AVR, without hiding what's really going on. The downside is that before you go too far you should read an introductory book on C. If you can borrow a not-ancient version of this it'd be good:

I tried to find everything from the same AliExpress store to make the ordering easier. This stuff runs off USB or a power pack. I don't think you should buy Chinese power packs, they are often unsafe. Start with just USB power.

The Arduino I started with is this "Uno" (the name refers to the CPU type and connection layout). Get two or three. You'll need a USB cable, which is included in the second link here (from the same store) (one of those and one or two of the others, unless you already have the right cable):

To wire up projects in a similar way to many you'll see online, get a couple of each proto-board and jumper wires.

They make bigger ones too:

This board seems to provide a lot for very little money and no soldering. It plugs directly on top of the UNO and gives you buttons, lights, a numeric display, buzzer, infrared receiver (for a TV remote), and a servo interface for controlling hobby servos:

Clifford Heath.

Thank you for so much information, I have saved it

I manage to learn C, but I want to know which should I start, C or Embedded C?

Having checked Arduino site several times, its forum says it uses C++, I don't know how to program in C while the libraries are not C.

Still looking for it, but I am interested in making an open source hardware correspond to close source hardware like OBD.

C is C. Embedded C is a small set of mostly unnecessary extensions to C, which in any case are not well-supported by tools. Ignore it. The things you might eventually need (like fixed-point arithmetic) can be handled in regular C through libraries, with no need of language extensions.

Although C++ is a fairly large set of (mostly) compatible extensions to C, very little of the Arduino API uses the features. Arduino is mostly C, with just a few C++ features used mostly to manage namespaces.

If you know C at all, you'll quickly get to grips with the C++ features that are used in Arduino standard APIs and most projects.

Clifford Heath.

Unless you actually want to learn to build systems. Arduino is sort of embedded-Python-lite, and (last time I looked) has horribly archaic development tools. I've had source-level debugging since Microsoft 5.2 for DOS, circa 1989. Arduino? Not last time I checked.

If they have the time and the discipline. The percentage of code I see that is stitched together from sample code and snippets of stackexchange is mind-boggling. For instance, my son and I are in the midst of fixing one of those right now, re-doing a customer's instrument that the contract engineering firm botched. The customer paid us to demonstrate the concept and write the HDL but had the board and firmware done for cheap overseas. (That was nearly three years ago--an expensive mistake.)

I'm a big fan of the LPCxpresso ecosystem myself.

Cheers

Phil Hobbs

C has so little resemblance to Python that I can't understand why you said that. I know that you know both languages.

I must agree with that. But is there another simple architecture with such a broad supportive beginner community? I'm not counting cases where you never need to see the machine, like RPi, the various micro-Python or Node things; they're just desktop-lite.

Yes, but there is some quite nice stuff too. It's worth being exposed to both good and bad practices, and learning to distinguish them.

That's pretty sad. However, the error was not because the contractor chose Arduino, but because the customer chose that contractor.

Clifford Heath

It's not the language I mean, it's the ethos of bolting stuff together from giant libraries made of code you couldn't write yourself.

Obviously there are limits--I'm not going to try reimplementing the C++ standard library any time soon--but one of the good things about learning on embedded systems is that you're closer to the metal. It's sort of like Montessori schools--the children learn that glass things break if you drop them, for instance. Reality obtrudes into the process a bit more.

Agreed. Rubbing a puppy's nose in its mistakes, and all that. ;)

It wasn't Arduino--they actually cloned the LPCxpresso board for the LPC1769. That isn't a bad start at all except that it's massive overkill for the job. But then they didn't use the 12-MHz crystal oscillator they specified--in fact they didn't set up the clock at all, so this nice 120 MHz MCU is running at its default 4 MHz on the internal RC oscillator. We'll probably use an LPC1764 running at 96 MHz on the RC, which is way better than good enough.

(We, or at least I, don't do enough embedded stuff to get good at more than one or two MCU families. I can find my way round ATmegas and NXP ARMs, but that's about it these days. My son Simon does big-ass FPGAs and manly stuff like that, whereas I've done exactly one Verilog project on a CPLD.)

Cheers

Phil Hobbs

Ahh, I see. Well, that's not my practice. I detest many aspects of the standard Arduino APIs, and have a plan to completely rewrite them and all the other libraries I use, from the GPIO pin level up. But for a newb, I think it's an acceptable approach.

I've always used as little as possible of the C++ stdlib, even when writing million-line products. It encodes and hides too many assumptions about what might be "good for me". I'll be the judge of what is good for me, thanks all the same! We used libraries we wrote ourselves, in almost all cases.

Exactly. And for a beginner, it needs to be as little metal as possible, consistent with running an HLL. STM32 is great, but you couldn't expect a beginner to configure the clock chains, for example. I don't imagine that many ARM chips are as simple as an AVR (talking peripherals here; the instruction set is the domain of the compiler). I really liked the MSP430, but it doesn't have the support that AVR has. I tried to build an Arduino-style platform for it once - big job though. I had also tried the same thing earlier with the 68HC11 - got a good toolchain going using gcc and my own debugger DL11, but never packaged it for newbs. Insufficient RAM and no hardware breakpoints were its downfall, but the MSP430 solved that.

Clifford Heath.

Circuit Python?

I haven't tried it yet but it doesn't look that desktop-ish.

• No need to allocate or manage memory (it's GC'd)

• API access to all port pins, audio, touch, etc

• No need to touch a peripheral device directly

• No need to initialize the chip or devices

In other words, it's fairly highly-managed. That's a fine thing, but the skills are not easily transferable to other MCUs.

Clifford Heath.

What is GC?

I'm not sure that is really true. There are many other skills that are learned in this process which *are* transferable. Just learning to use the tools and debug a program is the most important skill of all I think. The rest is just details that differ largely between targets.

All I need to do is learning C, and do not need to worry about Embedded part and Arduino?

Garbage collection. Make new objects and just lose them, the GC will pick them up. You never know when the GC will run, and you need a *lot* more memory, so it's not a good way to get the most out of an MCU.

Yes. But all those skills can also be learned in a desktop environment. If you actually want to learn embedded, the primary need is to learn how to control hardware, especially to deal with fine-grained real-world timing constraints (timer/capture hardware, etc).

Clifford Heath.

Arduino is a development platform and a set of C/C++ libraries to talk to the hardware. If you use an Arduino device, you'll want to start with the Arduino platform. You might move beyond it, but not soon.

You don't need to worry about Embedded C. I've been writing embedded C for over 20 years, and until you mentioned it, never even knew that "Embedded C" existed.

Clifford Heath.

Elof Huang wrote on 9/3/2017 3:37 AM:

Then use C tools on your computer or phone and play away! Nothing is simpler (in terms of getting the tools up and running) and 90% of what you learn will be useful no matter what your target is.

I actually recommend that you learn Forth though. It is *much* easier to ramp up with and runs on nearly any target. MPE in Europe and Forth Inc in the US supply eval versions you can learn with and there are many open source versions. I used Win32Forth for a commercially used test fixture which has made me a lot of money for very little hassle.

Why didn't you write garbage collection? It's not like "GC'd" is a commonly used abbreviation.

Those are misconceptions: there are systems that are completely deterministic, others that are very predictable (e.g., GC is schedulable in particular time slots, won't exceed given percentage of CPU time, etc.), and systems that don't need much additional memory.

There even are systems that combine predictability with low memory overhead.

It is absolutely true that GC requires *some* extra room and *some* extra CPU cycles wrt a non-GC system ... but the notion that GC is something unpredictable is a misconceived generalization of behavior that is implementation dependent.

You may dislike GC and that is fine, but please don't go spreading FUD. Many GC runtimes are intended for desktop/server use, and those are inappropriate for small or RT systems - but that doesn't mean all of them are.

I would say it it depends on the system. My position is that GC has no place in a small system. OTOH, if you're talking about a complex system with 32-bit controller and 100s of KB (or more) of RAM ...

George

All that is true. None of it invalidates what I said.

Thanks for confirming my position.

Then you have resources in such excess that *you don't need* to get the best out of it. Exactly what I said, in other words.