Electronics > Beginners
Help a beginner get started with mcu's
rstofer:
If the subject moves to ARM, buy a copy of "Mastering the STM32" and follow along from installing the toolchain. An excellent book.
PIC assembly is awful, the chip architecture (of mid-range 16Fs) just sucks. The C compilers may hide the fact but look at the emitted code. About half the cycles are involved with banking and paging.
I started using AVRs with the ATmega128 and the GCC toolchain (and AVRDude). I like that chip and I like that toolchain. I was doing the work under Linux so I had all the normal Unix tools as well. A very nice way to get started.
The problem with starting out with bare iron and no libraries is you have to learn every single peripheral and write all your own drivers. That is a pretty easy task for someone with a bunch of experience. Maybe not so much for a newcomer. It might be worth taking a peek at the Arduino libraries to see how they did stuff. Not so much to copy and paste but rather to see how they set up the registers.
Once you get to interrupts, you soon get to queues and other data structures. That's another step up and not in a hardware direction. Pretty soon we get focused on computer science and less on hardware.
MCUs is a really big topic going from blinking LEDs to a full interrupt driven RTOS with networking. There's a lot to learn!
HB9EVI:
The AVR toolchain is really great; well I cannot speak for WinGCC a.s.o. but on Linux it just perfectly integrates in the system environment.
If you rely on the bare toolchain, you still have some basic functions for e.g. eeprom, progmem, interrupt aso. I don't know; Arduino aims to get the people coding, but actually what comes out is no real code; it might well do what it should, but we are still talking about a Mcu with maybe a few kB program memory - I see no sense in filling it with a bloated code like the one coming from the Arduino toolchain.
DrMag:
I'll chime in with some thoughts in another direction than has been suggested so far...
If you're serious about learning how mcu's work, I would suggest getting yourself a TI Launchpad. The MSP430 has an extremely clean architecture, and (arguably, I'll admit) is easier to understand than other architectures. You can use TI's IDE (eclipse based) for free as long as the code size is under 16kb.. which covers a very large portion of the selection of MCUs available. There's a gcc compiler for the MSP430 too. And if you want to move into ARM, they've got the new MSP432, which puts the MSP peripherals onto a 32-bit ARM core.
[shameless plug]
A few years ago, when the Launchpad was brand new, I wrote a series of articles about basic MCU topics. It seemed to be very well appreciated by the community, so it might be worth a look if you go this route. You'll find it at http://mspsci.blogspot.com.
[/shameless plug]
I've always been meaning to get back to doing that kind of writing. One of these days...
Doctorandus_P:
The Java contraption which some people claim to be an IDE in the "arduino" world is not more worth than @#$%^&*.
The AVR microcontrollers behind it are however as capable as any other microcontroller family. No matter which uC family you choose, they will all have UsARTS, SPI, I2C, Timers, Interrupts, watchdogs, etc.
One of the biggest advantages that the AVR's have over a lot of other uC families is full support from the high quality GCC compiler.The ARM processor core is also supported by GCC, but these are often more difficult to set up. "Just" GCC support is not enoug, you also need a linker script, startup code and the right way to glue this together with your own code.
As you say you have already done some stuff with arduino, I assume you have the hardware for it. "arduino nano" boards from Ebay / Ali / China / etc can be grabbed for the price of the postage stamp. Just put them in a Breadboard, apply power, and go from there.
My advice is to start with abandoning the arduino Java contraption (called ide), but still use the arduino framework for a while.
"Atmel Studio" is a capable IDE, based on M$ Visual studio and it can directly import arduino projects. You can also use Platformio to set up arduino projects.
Once you have an arduino project in Atmel Studio or in Atom (Default IDE for Platformio), you can see the whole code, and follow it through the "arduino" libraries and see what is actually happening behind the scenes. The arduino framework is divided over around 20 different source code files, and as many header files.
Assembly is a good tool for learning computer architecture, but not productive enough for almost any real work. C and C++ have become the default languages for small embedded microcontrollers. Assembly is still being used in some niche areas such as:
- Task switching in RTOS systems.
- Very time critical code (Bit banging low-speed USB on an AVR, search: "obdev").
- Intermediate step for the C compiler. (No compiler can be written without asm knowledge).
- Schools for Learning the basics of uC architecture.
Apart from these (and a few other) niches assembly has no real use anymore.
C and C++ are very much standarized langugages. I can take a library to control some external hardware in C / C++ from github written for any uC architecture and port it to AVR, even if the library was originally written for another uC architecture. You have to change how the uC's internal peripherals are handled, but apart from that the code is much the same. In assembly you can forget that. The whole thing has to be rewritten from scratch.
GCC can output listing files, which are human readable and they have both the original C / C++ source code and the by the compiler generated ASM instruction. This can be a valuable tool for understanding how asm is generated from C and the results of different ways of code writing and compiler optimastion settings. Reading asm is a lot easier than writing asm, especially if you already know what it does because the corresponding line of C code is above it.
https://www.avrfreaks.net/ is a very active and great forum for anything related to AVR's.
If you want to go this way, an interesting excersise is to examine why "digitalWrite()" is so horribly slow, and then replace it with some direct register manipulation where applicable.
"digitalWrite()" is acceptable for turning a relay on/of, but not for doing bitbanging of some serial protocol, or toggling the strobe signal of a TFT lcd.
Anyone starting with microcontrollers should buy a logic analyser together with their first uC board. Search Ali / Ebay / China / Etc, for "24m 8ch" and use that Salaea clone box with the excellent Sigrok / Pulseview combination.
https://sigrok.org/wiki/Supported_hardware
Other good resources are reading the dataseets of the uC's you are intested in (they are all on the 'net) and books about general programming in C or C++. I love these languages, but they can be abused in horrible ways. Writing code in a clear and comprehensible way is 80% of a good program. This can also easily be done on a PC. I often write and debug C functions on a PC before I recompile them for a uC. Stuff like CRC algorithms, button debounce code, Menu's string manipulation and lots of other stuff is easier on a PC than on a uC.
Have Fun.
Kleinstein:
The AVR µC used in the small Arduinos is a nice µC to start. It is reasonably easy to understand and has good C (GCC) support.
I don't know the ARduino software environment, but it's mainly a set of C++ libraries to give a supposed easier interface to the hardware. One can still use the Atmel Studio IDE with the Arduino hardware. It's even possible to use direct HW access within the Arduino environment. There is no need to use the C++ constructs. One can still use essentially normal (a few bad practices are no more allowed) C code with a C++ compiler.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version