Need help starting with embedded programming

[avogadro]

So Im currently in the second year in uni studying EE. We recently started learning about digital electronics and vhdl and Im starting to really like it. I was plaining on buying an fpga board to do projects at home. Anyway I stumbled upon fpga and arm interfacing stuff so now I want to get more into embedded in particular arm microprocessors but I dont know where to start. Im okay in C but I lack knowledge in the workings of an mcu. I would also like to buy a cheapish arm dev board. So if anyone could point me in the right direction, suggest books, online courses and dev boards Id really appreciate it.

[pyroesp]

STM Discovery boards are pretty cheap.

[newbrain]

If I could have a nickel for every time this topic came up and I gave MHO...well, maybe I could buy me an ice cream 

Of course this question has as many answers as thre are forum members, so here's some link to older discussions.
https://www.eevblog.com/forum/microcontrollers/microchip-or-atmel-arm_s/
https://www.eevblog.com/forum/microcontrollers/starting-with-arm-cortex-m/
https://www.eevblog.com/forum/microcontrollers/best-way-to-start-moving-away-from-arduino/
https://www.eevblog.com/forum/microcontrollers/which-board-to-buy/

To the above I would add this: since you are interested in programmable logic, have a look at the PSoC 5 Prototyping kit.
The MCU is a Cortex-M3, and it has some programmable logic on it (enough to build a VGA like video adapter!).

Pros:
- Extra cheap
- 5V if you need to interface 5V stuff, plus some IOs can be set to a reference voltage of your choice
- The peripheral libraries are clear, well documented, no-nonsense and not bloated.
- The FPGAish part can be programmed in verilog
- It has also some analog capabilities (comparators, op-amps, mux, mixers, PGA, ADCs and DACs)
- The provided IDE is decent both for the C and the schematic entry parts

Cons:
- Cheap construction and packaging
- No VHDL (well, for me that's one of the pros  )
- The proprietary IDE is more or less the only way to use it, and it's Windows only.

If you want a FPGA only board, I have the older version of this one, not bad for the price.

[NorthGuy]

IMHO, from the learning viewpoint, if you have time, it's better to get a grip and understanding on logic circuits, FPGAs, and HDL, and only then move to MCUs. This is because the MCUs are made mostly of logic circuits (both CPU and peripherals), and you will understand them better if you already know their inner workings. And the best way of moving from FPGA to MCU is to design a small soft core on FPGA.

If you're more interested in practical side of things instead of learning, then get Zynq.

Shortly after you graduate, the quantum computers will mature, or something of that sort will happen. Everything you do now will become obsolete. Keep that in mind when you choose things to do.

[rstofer]

Embedded programming and hardware design with VHDL are worlds apart.  In fact, they have essentially nothing in common.

For embedded programming, I would start simple with the Arduino.  Everything that can be built with an Arduino has been built and the projects are all over the internet.  But Arduino programming is a long way from bare iron embedded programming.  You can skip over all the Arduino libraries and get right down in the dirt.  The only thing you want to save is the bootloader.  You will be using the same IDE/toolchain, just omitting the library stuff.  You will need to understand avr-gcc and avr-libc, both of which the Arduino system is already using.

The STM boards are a big step up but there is a tendency to use the factory provided bloatware libraries.  I haven't tried to get around this on STM boards.  Then there is the original mbed LPC1768 board which is my personal favorite.  You can get right down in the weeds with interrupt handlers and all the hardware gadgets.  Getting the NVIC (interrupt controller) set up is an interesting learning experience.  Stop by mbed.org.  BTW, their toolchain works for many 'mbed compatible' STM boards.  This allows use of the online toolchain (work on your project from any browser in the world) plus drag and drop device programming.  There are mixed opinions on using this toolchain.  I like it!  If you're going to buy an STM board, it might as wel be 'mbed compatible' whether you intend to use those tools or not.

OR...

There's a project out in the Google-verse called LC3B (or the earlier version LC3) which is a hardware design project.  The given state diagram can be coded up in VHDL (or whatever) to form a functional CPU with nothing more than an interrupt driven serial port.  It has separate system and user privileges and while the instruction set is clearly RISC, there is a C compiler for the LC3 version.  I don't know if it has been upgraded for the byte oriented LC3B.  There is also an assembler for the LC3 version.

This is a pretty nice project because first you build the CPU, then you add peripherals (PWM, more serial, <whatever>) then you write bare metal code in assembly language.  In the end, you will have a pretty good handle on both hardware and embedded programming.

There's a book: "Introduction to Computing Systems" by by Patt and Patel.

I am having fun playing with the PSoC 6 and the video series with the end result of creating a robotic arm controlled by a cell phone.  This is a most interesting way to create projects but 90% of the code is toolchain created.  The entire infrastructure is provided, all you do is add a few lines of specific code.  You'll see what I'm talking about.  PSoC Creator is the toolchain.

OR, if you like command line work, consider installing the AVR-GCC toolchain under Linux and using a simple editor (I use gedit) and connecting to a simple chip like the ATmega128.  Now you're as close to the iron as you can get.  I did quite a bit of work with this setup a long time back and I really enjoyed it.  The '128 is a great chip with lots of peripherals and pins.

http://maxembedded.com/2015/06/setting-up-avr-gcc-toolchain-on-linux-and-mac-os-x/
https://www.mouser.com/ProductDetail/Olimex-Ltd/AVR-H128-C
https://www.digikey.com/product-detail/en/olimex-ltd/AVR-ISP-MK2/1188-1008-ND/3471448

As to the ICSP programmer, expect to have to play with udev rules to get the USB working under Linux.  According to Google, it works just fine under Windows.

What you are looking for is an ICSP programmer that will work with avr-dude.

It's a pretty large sandbox, you need to decide where you want to play.

[legacy]

There's a project out in the Google-verse called LC3B (or the earlier version LC3) which is a hardware design project.

The MIPS R2K is covered by the 99% of university courses since it is the first examination in computer science. Supported by H&P books, plus slides.

[rstofer]

There's a project out in the Google-verse called LC3B (or the earlier version LC3) which is a hardware design project.

The MIPS R2K is covered by the 99% of university courses since it is the first examination in computer science. Supported by H&P books, plus slides.

I don't know that I buy into the 99% considering the number of university references the LC3 on Google.  Nevertheless, Hennessy and Patterson is required reading (and studying) for anybody who plans to go very far with hardware design.

https://www.csl.cornell.edu/courses/ece4750/handouts/ece4750-T02-proc-uarch.pdf

This paper starts out simple and works through several iterations to get to a fully pipelined CPU - unlike LC3 where no attempt was made to optimize throughput.

Due to the scaled nature of the processors in the paper above, it might be interesting to play with.  However, the paper doesn't hand feed the information in the way that Patt & Patel do.  I think it matters where you are coming from.  If this is for a hobby and a person is just starting out with FPGAs, LC3 is much more approachable whereas R2K is a good deal more advanced.

[rstofer]

If you like Pascal (which I do), take the output of Wirth's P4 compiler and create a stack machine in an FPGA to execute it directly rather than interpreting it as was done with the UCSD compiler.  There are MANY advantages to interpreting stack code but speed isn't one of them.  But it did make the system portable.  All that was necessary to host Pascal was an interpreter for the given host and it wasn't all that complex.

So, I basically got the CPU to work but I stumbled when it came time for system calls.  I'm not working on the idea any longer but I think I would now just implement them as traps.  It's really only the lowest level calls that are problematic.  Everything else (OS and friends) would be written in Pascal.  Exactly what was done for UCSD Pascal.

Given the speed of the modern FPGA, it should be very easy to outrun the original P4 system on the CDC 6400 mainframe.

[hamster_nz]

If you want an inexpensive ARM dev board that has a well documented learning path, the Texas Instruments Launchpad boards are reasonably good, and are used by this free edX course that will walk you though using it:

https://www.edx.org/course/embedded-systems-shape-the-world-microcontroller-inputoutput

If you did want something more feature-rich, then the Cyress PSoC 5 kits are pretty compelling (and have some programmable logic hardware features):
http://www.cypress.com/documentation/development-kitsboards/cy8ckit-059-psoc-5lp-prototyping-kit-onboard-programmer-and

if you just want a microcontroller board for experimenting/learning/tinkering with in your spare time, then the ESP32 board might be of interest. They are inexpensive, have WiFi, and quite a few have battery management for a LiPo pack. The WEMOS boards are usually a good place top start:

https://www.aliexpress.com/item/LOLIN-D32-Pro-V2-0-0-wifi-bluetooth-board-based-ESP-32-esp32-Rev1-ESP32-WROVER/32883116057.html

[brucehoult]

So Im currently in the second year in uni studying EE. We recently started learning about digital electronics and vhdl and Im starting to really like it. I was plaining on buying an fpga board to do projects at home. Anyway I stumbled upon fpga and arm interfacing stuff so now I want to get more into embedded in particular arm microprocessors but I dont know where to start. Im okay in C but I lack knowledge in the workings of an mcu. I would also like to buy a cheapish arm dev board. So if anyone could point me in the right direction, suggest books, online courses and dev boards Id really appreciate it.

TinyFPGA BX is on special at the moment for $28

https://www.tindie.com/stores/tinyfpga/

With 7680 LUT4s it's got a ton of space for anything you'd design yourself, and even enough to use maybe a third of it for a soft-core CPU (typically RISC-V such as PicoRV32) while still leaving room for your own circuits.

It uses a fully-Open Source tool chain from Verilog or VDHL (or Chisel, or ...) to the bitstream. No obscure hard to set-up toolchains. No licenses to fight with.

[rstofer]

So Im currently in the second year in uni studying EE. We recently started learning about digital electronics and vhdl and Im starting to really like it. I was plaining on buying an fpga board to do projects at home. Anyway I stumbled upon fpga and arm interfacing stuff so now I want to get more into embedded in particular arm microprocessors but I dont know where to start. Im okay in C but I lack knowledge in the workings of an mcu. I would also like to buy a cheapish arm dev board. So if anyone could point me in the right direction, suggest books, online courses and dev boards Id really appreciate it.

TinyFPGA BX is on special at the moment for $28

https://www.tindie.com/stores/tinyfpga/

With 7680 LUT4s it's got a ton of space for anything you'd design yourself, and even enough to use maybe a third of it for a soft-core CPU (typically RISC-V such as PicoRV32) while still leaving room for your own circuits.

It uses a fully-Open Source tool chain from Verilog or VDHL (or Chisel, or ...) to the bitstream. No obscure hard to set-up toolchains. No licenses to fight with.

At first I was thinking that 7680 LUT4s wasn't very much but it turns out that the LC3 RISC CPU project (all over Google) only takes 611 LUTs on an Artix 7, even with my sloppy approach to VHDL.  LUTs don't always equal LUTs but, even so, the project would fit several times over.

However, the TinyFPGA BX is limited on BlockRAM such that it can only implement 8k x 16b but that may be just fine for a learning project.

[JackJones]

I know this isn't ARM, but here's an excellent basic tutorial for PICs: https://www.gooligum.com.au/PIC-tutorials/baseline-PIC-tutorial

It might be worth a read through even if you don't want to use PICs. It explains the most basic things very clearly.

[NorthGuy]

At first I was thinking that 7680 LUT4s wasn't very much but it turns out that the LC3 RISC CPU project (all over Google) only takes 611 LUTs on an Artix 7, even with my sloppy approach to VHDL.  LUTs don't always equal LUTs but, even so, the project would fit several times over.

Yes, not always equal. Artix-7's LUTs are 6-input LUTs, each of which is roughly equivalent to four 4-input LUTs, not to mention their flexibility - they can be converted to memory or to shift registers. Also Artix-7 has other things such as muxes and carry chains, which don't count as used LUTs but they do help.

[shangaoren]

I'm working with cortex M4 every day, i think you shouldn't try to mix FPGAs and microcontrollers at the beginning, it will be too much complex.

If you want to know how Arm Cortex works you can read "the definitive guide to Arm cortex-m3 and cortex-m4" by joseph yiu, this book explain very well how the core works.
If you plan to work in electronics i suggest you to avoid arduino, this is an easy plateform to create some things but many of microcontrolers useful features are not used (DMA, Interrupts) as far as i know.
The cheapest Arm boards i know are ST's Nucleos, you just have everything to start on board for about 20 bucks for the biggest chips, and ST's documentation is not bad.

[rstofer]

I'm working with cortex M4 every day, i think you shouldn't try to mix FPGAs and microcontrollers at the beginning, it will be too much complex.

Absolutely correct.  The budding engineer or hobbyist needs to decide whether they want to create hardware or software (firmware, I suppose).  There's a huge difference!

If you want to know how Arm Cortex works you can read "the definitive guide to Arm cortex-m3 and cortex-m4" by joseph yiu, this book explain very well how the core works.
If you plan to work in electronics i suggest you to avoid arduino, this is an easy plateform to create some things but many of microcontrolers useful features are not used (DMA, Interrupts) as far as i know.
The cheapest Arm boards i know are ST's Nucleos, you just have everything to start on board for about 20 bucks for the biggest chips, and ST's documentation is not bad.

The ATmega328 is not a very sophisticated chip but it is adequate for a number of projects, with or without the Arduino infrastructure.  Any of the ATmegas will be more approachable than an ARM for the beginner.  That the ATmegas lack the sophistication of the 'be-all, do-all' ARMs is a blessing, not a curse.

I started playing with ARMs using the ARM7-TDMI chips like the LPC2148 and LPC2106.  There was a sense of 'bare iron' because the only given file was 'startup.S' and it was pretty much a skeleton when it came to the interrupt handlers and such.  It was a great introduction.  The LPC2148, especially, is a great chip.  The 'stamp' form factor of some LPC2106 boards make it easy to plug into a daughter card.

As I see the STM boards and even the PSoCs, the amount of tool generated code once again takes the programmer away from bare iron.  It's debatable whether this is good or bad and that debate revolves around whether the developer wants a project complete in a hurry or whether they are on a training mission.  In the case of the PSoCs, the tool generated code is pretty comprehensive, leaving the programmer to just add a few lines to get an app to work.

In the middle is where I see the LPC1768 mbed.  There are libraries for things like TCP/IP (and that's a good thing!) but you can still get down in the dirt with things like the NVIC and interrupt driven SPI slave.  That's also a good thing.

But the original question is "where to start" and there's no more fully documented platform than Arduino and there is no easier platform to get started with.  There's time later to take on more complex chips or even take a complete left turn and play with FPGAs.

My only interest, really, is hardware design.  I like playing with FPGAs.  Still, playing with the PSoC 6 has been quite a lot of fun.  Today?  I'm playing with an Arduino for temperature controller experiments.

http://apmonitor.com/pdc/index.php/Main/ArduinoTemperatureControl

[HB9EVI]

The ATmega328 is not a very sophisticated chip but it is adequate for a number of projects, with or without the Arduino infrastructure.  Any of the ATmegas will be more approachable than an ARM for the beginner.  That the ATmegas lack the sophistication of the 'be-all, do-all' ARMs is a blessing, not a curse.

+1

Imho it's an ideal mcu prototype for many (but certainly not all) purposes; compared to the PICs, the smaller diversity in the AVR family makes it much easier to choose the right for a particular project; and compared to ARM, the less complex hardware offers less pitfalls and makes a start into programming much smoother

it's hard to say, if to recommend ARM or AVR for start into embedded; my sole advise would be to never get attached to Arduino, HALs or whatever crippled library set

[shangaoren]

HAL for ST's, i don't know for others, is crap it's just good to make a proof of concept but not a definitive code.
Bare Registers can be scary but the names are pretty clear and documentation is readable, you don't have to fear of them.

I began with PICs but i feel more confortable with ARM architecture and peripherals, but maybe it's the experience

[langwadt]

As I see the STM boards and even the PSoCs, the amount of tool generated code once again takes the programmer away from bare iron. 
...
In the middle is where I see the LPC1768 mbed.  There are libraries for things like TCP/IP (and that's a good thing!) but you can still get down in the dirt with things like the NVIC and interrupt driven SPI slave.  That's also a good thing.

there is not thing that forces you to use tool generated code for STM if you are felling masochistic you can program it in assembler using notepad and the usermanual

isn't MBED that "internet of things" buzzword powered browser only abomination ?

[rstofer]

I began with PICs but i feel more confortable with ARM architecture and peripherals, but maybe it's the experience

Yes, but you started with PICs (I played with them years ago), not ARM.  And that's the point!  For a beginner, the ARM can be a stretch.  Not that I would wish the mid-range PIC on my worst enemy.

I like the AVR architecture, I like the infrastructure (avr-gcc, avr-dude, avr-libc) and I really like the ATmega128.  And I can get along with the ATmega328 as used in Arduinos.

The question at hand is "where to start" and maybe ARM isn't it.

[rstofer]

isn't MBED that "internet of things" buzzword powered browser only abomination ?

I guess that would be one way of looking at it!  OTOH, I like the 'stamp' form factor of the original LPC1768 because I can plug it into a daughtercard with a MagJack and have networking in a heartbeat.

The great misunderstanding is the 'browser only' bit.  That is a nice feature if you want to be able to work from anywhere in the world, using anything with a browser.  But it isn't required!

You can download the libraries and use them with Rowley CrossWorks for example.  In fact, you can use them with arm-gcc of any flavor.  Or you can write to the bare iron.  What is important is the 'drag and drop' programming of the device.  That's just neat!

The flip side is also true of the mbed model.  I can develop code on any toolchain that will compile to a binary image.  Then I download the image via USB to the board and I'm up and running.

It is curious to see 'abomination' used when STM is doing everything in their power to accommodate the idea by making their boards 'mbed compatible'.  I was happy with the arrangement long before STM got involved.

I was even happier before ARM bought out the operation.  I don't know if it lives or dies depending on the mood of ARM at some point in time.  Independence was a good thing.  OTOH, financing is another good thing.

I have toolchains on multiple machines all over my office.  Sometimes Linux, sometimes Windows 7, sometimes Windows 10, I don't care which.  I don't much care how many different tools are required or how much horsepower they take to run.  It all works out.  But I still like the online approach!  I don't have to install or maintain anything.  That's all taken care of by others.

[HB9EVI]

Maybe ARM isn't it... after using AVR for a long time, it was a challenge getting into STM32 the bare metal way

success that way likely depends how stubburn and frustration resistant someone is

after being familiar with STM32F1, I newly had to break my head and rewrite functions for I2C on STM32F0 - I didn't try yet other ARM, but ST doesn't make the things easier

wouldn't recommend any mid range PICs to anybody either

[rstofer]

success that way likely depends how stubburn and frustration resistant someone is

More than any other trait, stubborn is the most important to get anywhere in this field.  The chips don't work (read the errata, you'll see!), the documentation sucks, the sample code is bloatware and totally obtuse, and the list goes on...

In the end, only stubborn gets it done!

Sometimes even the simplest things take an inordinate amount of time.  You just have to keep beating on things until they work.

[Bassman59]

success that way likely depends how stubburn and frustration resistant someone is

More than any other trait, stubborn is the most important to get anywhere in this field.  The chips don't work (read the errata, you'll see!), the documentation sucks, the sample code is bloatware and totally obtuse, and the list goes on...

You forgot:
"Vendor tech support is worthless."

[nctnico]

Maybe ARM isn't it... after using AVR for a long time, it was a challenge getting into STM32 the bare metal way

after being familiar with STM32F1, I newly had to break my head and rewrite functions for I2C on STM32F0 - I didn't try yet other ARM, but ST doesn't make the things easier

That is your punishment for buying the cheap crap everyone is using. The LPC series ARM controllers from NXP are much easier to use. And since the peripherals are 99% the same across the entire range you don't need to rewrite stuff you already wrote.

[rstofer]

Maybe ARM isn't it... after using AVR for a long time, it was a challenge getting into STM32 the bare metal way

after being familiar with STM32F1, I newly had to break my head and rewrite functions for I2C on STM32F0 - I didn't try yet other ARM, but ST doesn't make the things easier

That is your punishment for buying the cheap crap everyone is using. The LPC series ARM controllers from NXP are much easier to use. And since the peripherals are 99% the same across the entire range you don't need to rewrite stuff you already wrote.

I LIKE the LPC series.  The device drivers are easy to write, NXP produces good documentation and there are library archives all over the place.

If somebody was going to use something like the NXP LPC2148, I would direct them to the superb code at www.jcwren.com/arm  Yes, the code is long in the tooth but so is the chip.  I have several development boards from Olimex.

The LPC2106 in stamp form factor was the basis of a music player I built as a demo.  The codec was connected to the 2106 as was an ethernet gadget.  The 2106 would make a connection to my music library on a Linux box (NFS as I recall), grab the MP3 file and play it.  There was quite a bit going on in the code so it was a great learning project.

Super easy to program with ICSP or JTAG and I was writing the code on a Linux box with arm-gcc and gedit.  Good times!