Affordable Microcontroller and Programmer

[ceamiclover]

I have an Arduino, which I would use for prototyping and learning on.  I was looking for a cheap controller to embed in simple projects.

I am not very creative, so I would rather sink $3 into a motion-light for my kitchen, for example, that I will probably replace and upgrade several times.

I come from an automotive installation background and am used to just hardwiring everything.  I have no programming or electrical engineering background, and am trying to push this hobby/interest further.  I thought incorporating micro-controllers with some logic would be the next step.
I'm finding it difficult and not user-friendly at this point.
As I have not gotten the USBASP, I picked up
 http://www.ebay.com/itm/311064700128?_trksid=p2059210.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT
to see if I have better luck.

[BlueBill]

You really can't go wrong with a PICkit3, too bad it isn't as loaded with extras like the older PICkit2. These are full featured programmers (but not production) and can program and debug a blank PIC, no bootloader required.

That said, I still use my old PICkit2 (I also sold kit versions "Junebug" under the name BlueRoomElectronics).

Aside from the PICKit2 having only beta support for some PICs using MPLABX it has some neat secondary features that I still use. A 3 channel logic analyzer and a UART tool, nice.

[dannyf]

I thought incorporating micro-controllers with some logic would be the next step.

It is. It just requires some skills that may or may not be natural to you.

1) programming skills;
2) comprehension - you need to be able to read datasheet quickly;

I'm finding it difficult and not user-friendly at this point.

Unfortunately true. But the reward can be significant as well.

The arduino / AVR is a good starting point -> they are lot easier to work with than the PIC and are also more feature rich.

[kamtar]

By which logic you can recommend for a beginner who want to make some hobby projects something else then arduino? He can start with simple projects using all arduino function and then when he wants to learn more he can try to make some native C AVR code.. learning about registers and MCU while he can fix harder problems just by calling a lib function. But no they will recomend you STM32.. really? -_-

[dannyf]

It depends on who the beginner is.

[Scrts]

Forget that AVR stuff. Real developer needs a debugger. Go step by step in the source code and check the register values instead of doing bunch of prints to the console or even worse - play the try&fail game.

I have an AVR Dragon which provides step debugging but c++ code gets so mangled by the compiler that this feature has very little value

We can get into a discussion what happens after newbie passes that semicolon problem, but is it really worth it? See, if the newbie manages to pass the compiler errors, the next step is to pass the code errors.
Regarding the compiler: I always turn off the optimization when doing debug, so nothing gets mangled.

[Zero999]

You really can't go wrong with a PICkit3, too bad it isn't as loaded with extras like the older PICkit2. These are full featured programmers (but not production) and can program and debug a blank PIC, no bootloader required.

That said, I still use my old PICkit2 (I also sold kit versions "Junebug" under the name BlueRoomElectronics).

Aside from the PICKit2 having only beta support for some PICs using MPLABX it has some neat secondary features that I still use. A 3 channel logic analyzer and a UART tool, nice.

The main disadvantage with PICs the optimised C compiler is ridiculously expensive and the licensing is silly. It's fine if you're Ok with a crappy unoptimised compiler (read deliberately made slow) and using assembly but it's no good really. Microchip are really shooting themselves in the foot by charging so much for their development software.

With AVR you get a nice free optimised compiler and plenty of other free tools.

[janoc]

I have an AVR Dragon which provides step debugging but c++ code gets so mangled by the compiler that this feature has very little value

I haven't tried debugging with my Dragon yet (I generally find the problem by debug prints on AVRs faster than it would take to hook the Dragon up), but GDB has no problems with C++ code. Are you sure you are loading a non-stripped, non-optimized ELF binary (not disassembling the raw binary used for programming!) into it? That is not how the code is compiled by default by the Arduino toolchain, so you may want to ensure you have -g -O0 options enabled (-g = debug symbols, -O0 = disable optimization). You can find the compiler settings in one of the text files in the Arduino folder (don't remember which one it was out of top of my head now).

If a newbie wants to continue, an AVR debugger is not out of reach either. On the other hand, unless you're willing to deal with gdb ARM development becomes very expensive as soon as one grows out of demo boards.

Well, unless you are dealing with AVR Studio, AVR debugger is also GDB-based - avr-gdb.

Re ARM development - most expensive proprietary toolchains use variants of the free (and pretty good) GCC/GDB behind the scenes, only putting fancy IDE in front. A really glaring example is LPCXpresso from NXP - a crippled version of Eclipse preconfigured to work with their Xpresso demo boards and nothing else, using a gcc/gdb toolchain.

If you are a bit skilled with the tools (and you probably should be if you are developing for ARM), it will take you perhaps half an hour to set up a free toolchain with an IDE of your choice, including debugger integration, so that you can use graphical debugger instead of typing GDB commands directly.

I am developing on STM32 series of chips using a self-compiled toolchain, CMake and Emacs, but I am software dev by profession, so I prefer to have things set up my way. Otherwise e.g. Eclipse works really fine (I am using it for AVR stuff), but there are others, such as CoIDE (basically preconfigured Eclipse) or emIDE (http://www.emide.org/ - CodeBlocks).

Unless you have a particular requirement that necessitates it, there is really no need for hobbyist to blow thousands of $$ to buy a proprietary toolchain and IDE (such as Keil or IAR) when developing for ARM. However, you may have to invest a bit of time to learn the ropes how to set things up - which will make you a better dev, IMO. Pushing magic buttons on a black-box IDE that spits out a binary is cool - when it works. When something goes south, you are screwed unless you know how it is setup and how it is supposed to function.

One bad thing about Atmel is that they don't have any good parts except entry level 8-bitters so there is nowhere to grow. PICs are much better in this respect, their 16-bitters are very nice micros and from what I see Microchip actively develops this line.

Indeed - I wouldn't say that the parts are not good, more like they are really overpriced for what they offer. This is pretty much the reason I am using AVRs only for quick hacks and prototyping where the Arduino libraries are a large time saver. Anything more "permanent" or "serious" will likely get a PIC or ARM in it instead.

[janekm]

By which logic you can recommend for a beginner who want to make some hobby projects something else then arduino? He can start with simple projects using all arduino function and then when he wants to learn more he can try to make some native C AVR code.. learning about registers and MCU while he can fix harder problems just by calling a lib function. But no they will recomend you STM32.. really? -_-

Yes, absolutely I would recommend an STM32 (or similar) to a beginner. If they're keen on having the Arduino style of quickly getting an LED blinking they could use mbed, which is a web-based IDE with drag-and-drop programming: http://developer.mbed.org/platforms/ST-Nucleo-F103RB/

And from there they can expand to basically anywhere, even within the mbed ecosystem there are many interesting options including Bluetooth LE, fast options with DSP-style functionality (Cortex-M4F), multi-core devices, ultra-low power devices, large memory devices... That beginner could run the same code on devices from a sub-$1 Cortex-M0 to a 120MHz Cortex-M4. How would the AVR line compete?

(and yes, once they get bored of the web IDE they can download the code for the project and continue developing in a gcc environment).

I consider it very limiting to recommend a single-vendor solution to a beginner these days considering what the ARM ecosystem has to offer (sound a bit like a sales drone... but it just makes sense doesn't it?).

[dannyf]

Yes, absolutely I would recommend an STM32 (or similar) to a beginner.

How such a recommendation will actually work out for a beginner is highly questionable.

That beginner could run the same code on devices from a sub-$1 Cortex-M0 to a 120MHz Cortex-M4.

You can certainly write a piece of code for CM0 and not have it run on CM4. You can actually write a piece of code for CM0 and not have it run on the same vendor's other CM0.

How would the AVR line compete?

I can certainly write a piece of code for one AVR and have it run on another AVR, or PIC, or CM0 or CM4, ...

[janekm]

Yes, absolutely I would recommend an STM32 (or similar) to a beginner.

How such a recommendation will actually work out for a beginner is highly questionable.

What makes you say that? I've played with some of the mbed dev-boards and the experience appears just as easy (if not more so) than on an Arduino to me (I may have some blindness since I can't quite call myself a beginner). But the "path to blinky" is simply:

• Plug dev-board into computer, it appears as a USB drive
• Log in to developer.mbed.org/compiler/
• Hit New, Select Platform, Select "Blinky" Template
• Hit Compile, the compiled .hex file is downloaded
• Drag&Drop that file to the dev boards "USB Drive"

That's not harder than using Arduino is it? But that same dev board also has a proper debug interface included so it offers space to grow.

That beginner could run the same code on devices from a sub-$1 Cortex-M0 to a 120MHz Cortex-M4.

You can certainly write a piece of code for CM0 and not have it run on CM4. You can actually write a piece of code for CM0 and not have it run on the same vendor's other CM0.

How would the AVR line compete?

I can certainly write a piece of code for one AVR and have it run on another AVR, or PIC, or CM0 or CM4, ...

OK I wasn't being explicit enough here... The nice thing here is that you can take a whole application, making use of a hardware abstraction layer that handles things like GPIO, I2C, SPI (...), and libraries that interface with many external chips (http://developer.mbed.org/components/),  and directly recompile it for a different dev-board from a different manufacturer, having to change nothing other than the pin assignments (and quite possibly not even that if you use the default assignments for the dev boards). Of course you can also screw that up, mainly by not using that HAL, but that's all part of the learning experience

Sure to some extent the Arduino ecosystem offers something similar, and the libraries have been ported to different manufacturers dev boards, but to me the non-AVR Arduino environments always appeared a bit like second-class citizens (but I may be mistaken).

(I'm not saying mbed is the greatest thing since sliced bread... I don't use it myself in earnest though I have played with it, and may well use it more in the future... But for a beginner it's a sensible option to consider).

[Alex Eisenhut]

Forget that AVR stuff. Real developer needs a debugger. Go step by step in the source code and check the register values instead of doing bunch of prints to the console or even worse - play the try&fail game.

Or at least a simulator. When I do write some PIC stuff, I always simulate many times before programming an actual chip.

[dannyf]

But the "path to blinky" is simply:

Try something a little bit more, like reading from an i2c adc and sending the data to a spi dac, all over dma.

Do it on STM32F1 and then STM32F4.

If you get it working then share the code here for us to try.

The nice thing here is that you can take a whole application, making use of a hardware abstraction layer that handles things like GPIO, I2C, SPI (...), and libraries that interface with many external chips (http://developer.mbed.org/components/),  and directly recompile it for a different dev-board from a different manufacturer, having to change nothing other than the pin assignments (and quite possibly not even that if you use the default assignments for the dev boards).

Only true for some of the simplest things you do on those chips, and only assuming that those libraries exist for the target board and maintain the same calling convention.

[Fat]

Good.  Thank you.  I ordered 2 of them from China, so they will get here in 1-100 business days.

Isn't that the truth.  Last one I ordered took 65 days.

[janekm]

But the "path to blinky" is simply:

Try something a little bit more, like reading from an i2c adc and sending the data to a spi dac, all over dma.

Well, the DMA part I wouldn't consider a beginner's problem, from what I remember of the DMA controllers on the STM32 line they're not exactly beginner friendly, I had to read over that section of the reference manual a good number of times before it made sense For the rest of it, here you go: http://developer.mbed.org/users/janekm/code/ADC2DAC/ (granted without DMA it's fairly trivial).

Do it on STM32F1 and then STM32F4.

If you get it working then share the code here for us to try.

The nice thing here is that you can take a whole application, making use of a hardware abstraction layer that handles things like GPIO, I2C, SPI (...), and libraries that interface with many external chips (http://developer.mbed.org/components/),  and directly recompile it for a different dev-board from a different manufacturer, having to change nothing other than the pin assignments (and quite possibly not even that if you use the default assignments for the dev boards).

Only true for some of the simplest things you do on those chips, and only assuming that those libraries exist for the target board and maintain the same calling convention.

True enough, once you're interesting in using the more unique features of a chip (even just DMA or more specific configuration of a peripheral) that's the limit of this sort of approach. But for a beginner it can take you pretty far (similar to the Arduino environment, granted).

[janoc]

Forget that AVR stuff. Real developer needs a debugger. Go step by step in the source code and check the register values instead of doing bunch of prints to the console or even worse - play the try&fail game.

Or at least a simulator. When I do write some PIC stuff, I always simulate many times before programming an actual chip.

Hmm, I think the last time I have used a software simulator was sometime around 2000 or so, working with AT89C2051 ... Considering the problems with simulating the hardware accurately, I prefer the real thing and a debugger.

If  you have high level code, then it is probably better done on a PC with stubs and test harnesses and then ported to the embedded system.

[dannyf]

True enough

If so, how's an ARM materially better than an AVR, or a PIC, etc.? Whatever those "simple things" a CM0/CM4 chip can do, an AVR/PIC/etc. can do too.

[janekm]

True enough

If so, how's an ARM materially better than an AVR, or a PIC, etc.? Whatever those "simple things" a CM0/CM4 chip can do, an AVR/PIC/etc. can do too.

Of course, but what's the justification for recommending a PIC or AVR to a beginner? Are they materially easier to get started with? I'm not convinced.
Any other reason?

So why not recommend the ecosystem which can quite literally offer a microcontroller for practically any conceivable need, all with the same toolchain and a lot of overlap in calling conventions, register naming conventions, etc? I'd wager it's a lot easier to move from one manufacturer's Cortex-M chip to another one's than between AVR and PIC, for example (in terms of the mental effort, at least). And there's something very fun about for example using a micro with built-in radio peripheral:

Code: [Select]

(snip config)
NRF_RADIO->SHORTS = ( RADIO_SHORTS_READY_START_Msk | RADIO_SHORTS_END_DISABLE_Msk | \
                                                      RADIO_SHORTS_ADDRESS_RSSISTART_Msk | RADIO_SHORTS_DISABLED_RSSISTOP_Msk )
NRF_RADIO->PACKETPTR = (uint32_t)&packet;
NRF_RADIO->TASKS_TXEN = 1U;
while (NRF_RADIO->EVENTS_DISABLED == 0U)
    {
        // wait
    }


[BlueBill]

I am looking for cheap, programmable micro-controllers and a programmer to embed in simple hobby circuits.  Examples motion-triggered light, etc.

pic10f200 are less than a dollar.

PICkit3 PIC KIT3 debugger is on ebay for $27

Are these reasonable for simple projects and learning?

PICs & AVR 8 bit microcontrollers are pretty similar, available in DIP (through hole), have high current ~20mA output pins, and require little more than power to get running. On the other hand an ARM is more a microcomputer and much more powerful and complex. if you need that kind of horsepower a Raspberry Pi or MIPs core PIC32 might be of interest.

I use a PICkit3, MPLABX, XC8 & SwordFish BASIC (for the 18F series it's very easy & powerful).
The PICkit3 can program & debug, too bad it doesn't have the logic or UART tool the old PICkit2 had.

[dannyf]

So why not recommend the ecosystem which can quite literally offer a microcontroller for practically any conceivable need, all with the same toolchain and a lot of overlap in calling conventions, register naming conventions, etc?

The same is true for PIC / AVR / etc.

I'd wager it's a lot easier to move from one manufacturer's Cortex-M chip to another one's than between AVR and PIC, for example (in terms of the mental effort, at least).

I thought you had agreed earlier that the same can be done with AVR/PIC/etc., especially if you stay with the simple stuff.

And there's something very fun about for example using a micro with built-in radio peripheral:

You can do that with lots of 8051 chips.

[Alex Eisenhut]

Forget that AVR stuff. Real developer needs a debugger. Go step by step in the source code and check the register values instead of doing bunch of prints to the console or even worse - play the try&fail game.

Or at least a simulator. When I do write some PIC stuff, I always simulate many times before programming an actual chip.

Hmm, I think the last time I have used a software simulator was sometime around 2000 or so, working with AT89C2051 ... Considering the problems with simulating the hardware accurately, I prefer the real thing and a debugger.

If  you have high level code, then it is probably better done on a PC with stubs and test harnesses and then ported to the embedded system.

Luxury! I mean for stuff I'm making at home, there isn't any known good hardware to start with, so at least with the simulator I can check for gross software mistakes.

[janekm]

So why not recommend the ecosystem which can quite literally offer a microcontroller for practically any conceivable need, all with the same toolchain and a lot of overlap in calling conventions, register naming conventions, etc?

The same is true for PIC / AVR / etc.

Is there really a compiler toolchain that targets both PIC and AVR? Or a debug interface that can talk to both?

I'd wager it's a lot easier to move from one manufacturer's Cortex-M chip to another one's than between AVR and PIC, for example (in terms of the mental effort, at least).

I thought you had agreed earlier that the same can be done with AVR/PIC/etc., especially if you stay with the simple stuff.

But there's a difference between "can be done" and "easier"...

And there's something very fun about for example using a micro with built-in radio peripheral:

You can do that with lots of 8051 chips.

That same code would look a lot more complicated on a CC2430 (you'd need to set up DMA and handle the interrupts) or an NRF24LE1 (uses an internal SPI interface). And besides even TI just came out with the CC2650 which has both a CM0 and CM3 inside: http://www.ti.com/product/CC2650

Anyway my sole point was that if a beginner came to me asking for a recommendation, I would in many cases point them towards the ARM ecosystem (though I have also on occasion pointed them to Arduino when that would clearly suit their needs, i.e. if they were more interested in interfacing sensors to actuators in creative ways rather than being interested in learning about microcontrollers and embedded development per se).
I have not yet seen a convincing argument for why one of the ARMs would be a bad choice for a beginner, the nicer ones (not necessarily STM32, though they often have the most bang for buck...) combine the nice Arm cores with simple and elegant peripherals (the NRF51 for example has a really elegant set of peripherals and task/event system).

[dannyf]

Is there really a compiler toolchain that targets both PIC and AVR?

Why does it have to be the same? You can code them so that the same source file works under different chips.

[dannyf]

I have not yet seen a convincing argument for why one of the ARMs would be a bad choice for a beginner,

Complexity, both in terms of hardware and software. A uart may take 5 registers to setup on a PIC/AVR, and it is not uncommon for them to have 20 - 30 registers in the ARM land.

The setting up of a project itself can be quite involved as well. For PIC/AVR, it is fire-and-go; For those ARM chips, you have to load up the right start-up files, load up the right cmsis (and -dsp, -os, or -dap if you wish to use them), the OEM libraries, board package definitions, and set up the environmental variables + paths....

They may not seem to be a lot for people who have done it. To people who are new, it is a different matter.

[BlueBill]

Luxury! I mean for stuff I'm making at home, there isn't any known good hardware to start with, so at least with the simulator I can check for gross software mistakes.

Both the PICkit3 and AVR Dragon have debug. The PICkit3 uses debug hardware on the target PIC but I believe the Dragon is more an emulator. Both are inexpensive.