Where do I start if I want to learn larger architecthre "C" uC programming?

[DaveHardy]

I'm interested in learning how to program 32 bit microcontrollers or perhaps a PIC18 if it is a better place to start.  I've programmed 8 bit microcontrollers in ASM for a while and feel that I'm ready to start learning the C language and bigger architectures.

A visit to the Microchip website is total chaos.  There's links everywhere and I don't think that half of the Microchip staff knows what the other half is doing.  I did a search for the Hi-Tec C compiler and it appears that Microchip absorbed them somehow.  Whatever happened to the Hi-Tec C kinda reminds me of the movie the blob.

Atmel confuses me too.  They have some sort of open source thing going on but I can't figure out how to get started.  I guess that I'm scared because Dave did a video saying that I need to be the Linux penguin to figure out how to set up the workspace properly.   Also, Atmel stuff is getting a lot more expensive.

What do you guys think of the mikroC free or starter compiler?  It looks like a good place to start and it appears straightforward enough. 

-Dave

[westfw]

Get an Arduino, ignore the extensive easy-to-use libraries and numerous examples of neat applications, and start writing away.  Arduino uses gcc (C and C++) "under it's hood", and you won't find an easier to download and install environment, or a cheaper development board.
Your choice of 8bit (Atmel AVR: Uno, MEGA, Leonardo), 16bit (MSP430 using "Energia"), or 32bit (Due, Teensy 3, Tiva Launchpad (using Energia), PIC32 (ChipKit - using MPIDE))
The editor is minimalist to the point of being primitive and annoying, but the "use external editor" preference works surprisingly well.
And you won't get a debugger or simulator.  When you get to the point where you need those, you can upgrade to the next level of tool.

[Kremmen]

I'm interested in learning how to program 32 bit microcontrollers or perhaps a PIC18 if it is a better place to start.  I've programmed 8 bit microcontrollers in ASM for a while and feel that I'm ready to start learning the C language and bigger architectures.
[...]
Atmel confuses me too.  They have some sort of open source thing going on but I can't figure out how to get started.  I guess that I'm scared because Dave did a video saying that I need to be the Linux penguin to figure out how to set up the workspace properly.   Also, Atmel stuff is getting a lot more expensive.
[...]
-Dave

Linux penguin for Atmel? Naah. I do Atmel stuff all the time and while i have nothing against Linux and have several boxes around running stuff, i do all my Atmel development on Windoze. That includes the lowly Arduinos, a bunch of 8 bit and 16 bit stuff (the XMega), and Atmel's SAM series Cortex ARMs.
You just download the Atmel Studio 6.2 (free) and start hacking away. Mind you, you do need some way of downloading the binaries and eventually for debugging your brain children, but that applies for all environments. The JTAGICE 3 from Atmel is not terribly expensive, or you could go for the Segger J-link debugger. Works like a charm for the ARMs (not only Atmel's) and there is a more reasonably priced non-commercially licensed version of the thing. Those tools will get you a _long_ way; in fact all the way for Atmel chips.

[AndyC_772]

All you need to know about Microchip for now is this:

- the current, supported IDE is MPLABX. Download it here.

- the C compilers are XC8 for 8 bit devices, XC16 for 16 bit, and XC32 for 32 bit. Download the free versions of any of them here, and install after you've installed MPLABX.

- ignore everybody who bitches and whines that the free compilers don't optimise. So what? You're learning the language, not trying to squeeze every last bit of performance out of a device. I've only needed optimisation for one design out of a dozen or so I've done over the last few years.

- my current favourite range of devices is the PIC18FxxK22 family. All you need to get started is a breadboard with a PIC18F26K22, programming header (6 pin 0.1in), a decoupling capacitor and a pull-up resistor on MCLR.

- Once you've started a new project in MPLABX, go to Window > PIC Memory Views > Configuration bits. Here you can set all the configuration bits for the device from a series of drop-down menus, then click 'Generate source code to output'. Copy and paste this code into your project, and all the chip's configuration bits are done. (I always put this lot into a header file called config.h and then #include it).

Other things you need to do in your project are:

- #include <xc.h> at the start of your main.c file, and any others which refer to device registers

- Set OSCCON to specify the clock source and speed that you want the chip to run at

- Set the ANSEL and TRIS bits for any pins you want to use as digital I/O

- Read inputs from PORT registers, but write outputs to LAT registers.

- You can access individual bits in registers by name, rather than having to write the whole register at a time. So, for example, you can turn on an LED connected to pin RA6 by writing LATAbits.LATA6 = 1. This register naming convention is used throughout.

- READ THE ERRATA for any PIC you're considering using. There are some absolute howlers which you really, really do need to know about.

[Monkeh]

Get an Arduino, ignore the extensive easy-to-use libraries and numerous examples of neat applications, and start writing away.  Arduino uses gcc (C and C++) "under it's hood", and you won't find an easier to download and install environment, or a cheaper development board.

Sure you will: A Launchpad is cheaper than a cloned Arduino, and arrives faster. Or a Cypress PSoC4 at the moment.

And you won't get a debugger or simulator.  When you get to the point where you need those, you can upgrade to the next level of tool.

Start with the Launchpad and you get the debugger in the bargain!

[gocemk]

If you go with MPLABX, it has excellent templates for creating a new project. When you create new project, just go to Samples->Microchip Embedded, and there you will find templates for all PIC families + the Explorer and PICDEM boards. It will create all the necessary files like main.c, interrupts.c ... all with comments where to put the code and etc. It will also create "getting_started.txt" file in your project tree which will get you started step by step on how to set the config bits and etc... If you are using different chip from the one in the template (e.g the template is for PIC18F45K22 and you are using PIC18F4550), just right click on the project->Properties. Then in the upper right corner under "Device:" choose the PIC that you are using from the drop-down menu, click Apply or OK, and you are good to go.

Hope this helps getting you started with programming PIC's in C.

[hans]

I believe the mikroC compiler Free has a size limitation. That can get annoying, because suddenly you run out of luck.

Personally I would pick optimize constraints > size constraints - so I would pick the XC8/16/32 compiler. They work well and integrate into MPLAB X or MPLAB IDE. In that case you just need 1 IDE ranging from 8-pin PIC10s to 100 pin PIC32s.
Here are all the downloads grouped together : http://www.microchip.com/pagehandler/en-us/family/mplabx/
(Design Support -> MPLAB X -> Download)

As for a chip, the PIC18 K series are nice to start with.
If you're looking for a bit more C-optimized platform you could look at the PIC24 or PIC32 series (16/32-bit chips). If it matters; they have chips in DIP packages, but the biggest are only "only" 28-PDIP size. For example; PIC32MX1xx and PIC32MX2xx chips have some DIP versions, and the PIC24 has some DIP versions scattered around.

[dannyf]

For 32bit devices, I use coide: free and excellent wizard. Limited support for new chips. Other options are keil for its rte, or iar for its ui.

between avr or pic I would go with avr. Code blocks plus gcc avr is a great combination.

[AndyC_772]

If you want to learn an ARM based family - and that's certainly a good idea IMHO - then I'd also suggest Rowley CrossWorks for ARM, which is a commercial package but with a deeply discounted 'personal' licence option.

[nctnico]

IMHO the best way to learn C is to start programming simple stuff on a PC. Whether you use Eclipse or Visual Studio personal edition you'll have an excellent debugger to trace what your code is doing. I still write a lot of microcontroller code on the PC first just to be able to debug & test it quickly.

edit: typo

[Paul Price]

I used to use the legacy Microsoft Visual C+ Ver 6.0 for debugging pieces of code. Can be simple to use for this purpose.

[Lukas]

The STM32F4 series eval boards (STM32F4DISCOVERY and STM32F429I-DISCO) provide really good bang-per-buck. Full-featured debugger on board, very good support from the gnu toolchain (arm-none-eabi target)

[DaveHardy]

Wow, thanks for the help guys.  There's lots of stuff to digest here.  I'm going to get started now and report back.

[dannyf]

Depending on your knowledge of the chips and your approach, going from 8-bit to a 32-bit chip can be quite challenging for a new comer, and in my view, requires a different way to programming.

[IanB]

Depending on your knowledge of the chips and your approach, going from 8-bit to a 32-bit chip can be quite challenging for a new comer, and in my view, requires a different way to programming.

Can you elaborate? What kind of challenges does a 32 bit chip introduce?

In a historical context, the move from 8/16 bit processors to 32 bit processors removed many impediments and made programming much easier.

[true]

Depending on your knowledge of the chips and your approach, going from 8-bit to a 32-bit chip can be quite challenging for a new comer, and in my view, requires a different way to programming.

Can you elaborate? What kind of challenges does a 32 bit chip introduce?

In a historical context, the move from 8/16 bit processors to 32 bit processors removed many impediments and made programming much easier.

It's not so much 32-bitness of the chips, but rather the complexity and connectivity of the peripherals and setting up the core.

Compare setting up standard GPIOs on an attiny with setting up GPIOs on an STM32 using ST's libraries. Neither is hard, but ST is certainly more involved, though much more powerful. Get to more involved things, like setting up i2c or other peripherals, and it isn't necessarily "easier"

[westfw]

For example, on an 8-bit AVR, for a GPIO port you have the Data-direction register, the PIN register (for input), and the PORT register (for output.)
On a Tiva CortexM4 chip, you have about 40 registers for each GPIO port  :-) (Not counting the 256 addresses used to achieve bitwise access.  Which is separate than bit-banding, which does single-bit access.  Obviously!)

(no, that's not a fair comparison, because the 40 registers include things like alternate function select and interrupt control that are handled "differently" on the AVR.  But that's how it will feel.
A better comparison is probably that the Atmega1280 manual is about 500 pages, while the Tiva TMC123GH6PM is about 1500 pages (i'd rate the manuals as "comparable" as to completeness of content.))

(Oh, and don't forget that the TI GPIO ports are completely different from the ST GPIO ports!)

(And did I mention that you'll be encouraged to implement things through a series of library calls that are pretty good at preventing you from ever figuring out how things actually work.

    MAP_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOA);
    MAP_GPIOPinTypeGPIOOutput(GPIO_PORTA_BASE, GPIO_PIN_1);

(pretty much as bad as Arduino libraries, IMO. (only the names are worse!)))

(Not that this sort of "peripheral complexity" isn't slipping down into 8bit parts as well.)

[westfw]

   you won't find an easier to download and install environment, or a cheaper development board.

Sure you will: A Launchpad is cheaper than a cloned Arduino, and arrives faster. Or a Cypress PSoC4 at the moment. [and they come with debuggers!]

Well, I'll give you "cheaper", if you neglect Arduino clones (and you probably should.)  But I was one of the people who waiting months for my first launchpad :-) (yes, they've gotten better.)  And I'll stand by "easier download/install": the Tiva launchpad tutorial has you downloading and installing stuff from all over the place, with "Open your launchpad box" being somewhere around step 25. (http://software-dl.ti.com/trainingTTO/trainingTTO_public_sw/GSW-TM4C123G-LaunchPad/TM4C123G_LaunchPad_Workshop_Workbook.pdf )  (You can avoid this by using the Arduino-compatable Energia IDE instead, but you're back to no debugger.)

[janoc]

I'm interested in learning how to program 32 bit microcontrollers or perhaps a PIC18 if it is a better place to start.  I've programmed 8 bit microcontrollers in ASM for a while and feel that I'm ready to start learning the C language and bigger architectures.

If you have never programmed in C before, then, please, do yourself a big favour and forget the micros for a while. Go, get a book on C and a desktop compiler (Visual C++, gcc, mingw, what have you) and learn the language there first.

Learning C and debugging code on a microcontroller is way harder - e.g. if you mess up (and you will mess up, trust me) with pointers and overwrite stack, on the PC the application will most often simply crash, with the debugger pointing you to the place where the problem happened. A micro will happily overwrite its RAM and good luck trying to figure out what is going on there, even if you have debugger connected. Not to mention the various idiosyncrasies like linker scripts, memory layout and what not that you have on the microcontrollers.

Microcontrollers are not the best place to learn a new programming language.

[dannyf]

learn the language there first.

Agreed. It makes sense to have a good mastery of C if you want to program in it.

Not to mention the various idiosyncrasies like linker scripts, memory layout and what not that you have on the microcontrollers.

Mostly transparent for you. I wouldn't worry about any of them for now.

Microcontrollers are not the best place to learn a new programming language.

Agreed.

[nctnico]

I disagree. One of the major improvements of C++ is that you can pass variables by reference. This reduces the chance on making errors with pointers.

[Monkeh]

   you won't find an easier to download and install environment, or a cheaper development board.

Sure you will: A Launchpad is cheaper than a cloned Arduino, and arrives faster. Or a Cypress PSoC4 at the moment. [and they come with debuggers!]

Well, I'll give you "cheaper", if you neglect Arduino clones (and you probably should.)  But I was one of the people who waiting months for my first launchpad :-) (yes, they've gotten better.)

Well, a full size Uno clone is much the same price as a basic Launchpad, with so much less to offer (we'll ignore the wide range of badly designed 'shields') Once you look at the F5529 you never look back. Much nicer hardware documentation IMO, too.

And I'll stand by "easier download/install": the Tiva launchpad tutorial has you downloading and installing stuff from all over the place, with "Open your launchpad box" being somewhere around step 25. (http://software-dl.ti.com/trainingTTO/trainingTTO_public_sw/GSW-TM4C123G-LaunchPad/TM4C123G_LaunchPad_Workshop_Workbook.pdf )  (You can avoid this by using the Arduino-compatable Energia IDE instead, but you're back to no debugger.)

I'll give you that, installing and learning a real IDE is more involved than the click and go approach of the Wiring framework.

[Gall]

C first, C++ later.

Probably the best way to learn C is to learn C on a PC first. The uC is exactly the same, just smaller and without printf(). Usually no malloc() as well.

C++ is a good thing even for microcontrollers provided that you deeply inderstand templates and know how to avoid useless copies of variables. This is of course not in C++ 101. Learn C++ on a PC and go to uC later.

[nctnico]

C first, C++ later.

Probably the best way to learn C is to learn C on a PC first. The uC is exactly the same, just smaller and without printf(). Usually no malloc() as well.

You can have malloc if you need it. Just make sure you have proper memory bounds checks. And be smart: don't try to avoid printf otherwise you'll be writing your own string conversion and printing routines which are bulkier and worse than printf. If printf turns out to pull in too much extra junk just write a minimalist printf (google will show you how).

@Mojo-chan: pointers are a major source of erros in C code so it is better to avoid them if you can.

[bwat]

I've been writing C code since the mid to late 80s and they way we learned it back then still works today.

1) Get yourself a copy of [K&R] and a machine that boots a *nix variant. I say *nix and not Windows because the book sort of assumes you'll be compiling on *nix - if you've heard of the authors then you'll know why. Anyway, Linux or one of the BSDs, or even OSX will give you all the tools you need for pretty much free. You could do it with Windows but it's a little extra work at the beginning and, well, C and *nix go together like strawberries and cream. Once you've finished the book you'll be able get going with embedded platforms in no time at all.

2) Do not avoid pointers like someone suggested. People who have problems with pointers are people who haven't learned how to use them properly! You have an assembly background and as someone else pointed out, this'll give you an easier time learning about pointers.
 
[K&R] Brian W. Kerninghan, Dennis M. Ritchie, The C Programming Language, 2nd Edition. Prentice Hal, 1988.