Get ready to rumble! [Thierry] made the exact same Hello-World-esque project with two microcontrollers (that are now technically produced by the same firm!) to see how the experience went.
It’s not just an LED-blinker, though. He added in a light-detection function so that it only switches on at night. It uses the Forest Mims trick of reverse-biasing the LED and waiting for it to discharge its internal capacitance. The point is, however, that it gives the chip something to do instead of simply sleeping.
Although he’s an AVR user by habit, [Thierry] finds in favor of the PIC because it’s got a lower power draw both when idling and when awake and doing some computation. This is largely because the PIC has an onboard low-power oscillator that lets it limp along at 32 kHz, but also because the chip has a lower power consumption in general. In the end, it’s probably a 10% advantage to the PIC on power.
If you’re competent with one of the two chips, but not the other, his two versions of the same code would be a great way to start familiarizing yourself with the other. We really like his isDarkerThan() function which makes extensive use of sleep modes on both chips during the LED’s discharge period. And honestly, at this level the code for the two is more similar than different.
(Oh, and did you notice [Thierry]’s use of a paper clip as a coin-cell holder? It’s a hack!)
Surprisingly, we’ve managed to avoid taking a stray bullet from the crossfire that occasionally breaks out between the PIC and AVR fans. We have covered a “shootout” before, and PIC won that round too, although it was similarly close. Will the Microchip purchase of Atmel calm the flames? Let’s find out in the comment section. We have our popcorn ready!
Awaiting MSP430 in this fight!
Why not also one of the (supposedly) super-power-saving-better-than-8bit ARM chips while we’re at it? (probably an M0+ based thing)
Technically MSP430 would also qualify as better-than-8bit too as it’s 16-bit.
yes
+1: Low power consumption is one of the MSP430’s best features. I can’t wait to see how it would do vs the AVR and PIC. Or should i say how they would stack up against it if power frugality is the name of the game…
Compare it to a PIC12F629’s sleep current.
Checkout Param No. D020 in the datasheet.
OTOH one could develop for both MSP and AVR using usual GCC C compiler, which is FLOSS/Linux friendly, quite decent at code optmization and could compile “usual” C code, so one could use fancy C99 features, if not parts of C++ like Arduino does. Needless to say it is more fun compared to utterly crappy PIC devtools and saving pennies on bulk prices is the only issue if you’re up for millions of units. Which isn’t about DIY/HACKs at all, where saving $0.1 at cost of extra dev time just does not pays for itself at all.
My biggest gripe with MSP430 back-in-the-day was the proprietary gdbproxy program binary needed to talk to the device via JTAG using gdb. I remember it only working on Windows.
The situation might have changed now, but I’ve been reluctant to go near MSP430 ever since, especially since ARM chips seem to be able to do as much, if not more.
4RedHatter: IIRC there should be opensource debug tool interfacing MSP to GDB these days. Though I’ve not used MSP430 in a while, and TBH I’m not a big fan of HW debugging. But these days HW debugging considerably improved under Linux thanks to OpenOCD gaining some traction (for me, OpenOCD is still valuable tool to do e.g. JTAG “debricking” of stuff like SOHO routers).
As for MSP430 I do not really get their point. Sure, they are good at power consumption, but at the end of day, where I really care about battery power, it comes down to radio RX/TX times, not mcu power at all. So I do not have issues with STM32, especially STM32L series. Somehow 32-bit thing could be modest in power requirements. Maybe it is not goundbreaking, but its real 32 bit with decent cpu core, plenty of superb peripherals and far more common ARM architecture, better supported by all kinds of tools around. Point of 16-bit proprietary architecture is really unknown to me these days. MSPs aren’t anyhow bad. Just targeting some very niche markets, relatively unpopular these days and 16 bits imply there is no way to scale in elegant ways. Not to mention 16 bit suxx when it comes to crypto, etc.
” An Arduino for the ATTiny”
I’m not suprised of the results.
okay … looked into code and arduino seems to be only programmer.
Nothing wrong with Arduino on a tiny.
I currently have an “Arduino” powered ATTiny5 (yes, a 6 pin Tiny5, not a Tinyx5) on my desk, with it’s staggering 32 bytes of RAM and 512 Bytes of Flash… and there’s still enough room to do something useful with it…. admittedly I use my own fork of the ATTinyCore which I put a bit of work into optimising along the way.
Just because something is “Arduino” doesn’t mean it’s automatically bloated or hungry.
I second this. I use Arduino as the IDE for lots of things that I turn into “LCD backpacks” with an ATTiny84 driving a 2 line LCD display.
I do this mostly because I’m too lazy to rewire the LiquidCrystal library to operate standalone, but still.
Hm….comparing old “regular” device with a new “super highly low power optimized” device.
Anyway, i would be curious how the tiny burns if you add the prescaler and turn the clock further down. What was it max, 256? that would be 500Hz operation.
Not necessarily better.
At lower clock rates, the CPU stays awake for a longer time to do the same work, than at higher rates.
Meaning, that also the non-productive leakage currents flow for a longer time.
Often it’s better to let the core run at higher speeds, but for a shorter time than the other way around.
yes, i understand that, was just curious why the author of the test did not do that, to at least make a 1:1 comparison in some aspects.
I’ve used paperclips as cheap coin cell holders for a number of small project and hacks – they work quite well.
https://s31.postimg.org/4opbmeo0b/Curious_C_Battery_Clips.jpg
(I hope that this is the right way of posting an image here….)
Nice, i have never thought that you can solder paperclips.
Yeah me too until I used one. Ohm-ed it out, all good. Works.
Some of them. Some paperclips are enamel-coated, so you want to avoid those, obviously.
And staples. Also common zinc-plated hardware, like nuts. The majority of things are solderable, especially with supplemental flux.
http://vignette2.wikia.nocookie.net/spongebob/images/3/3a/Squid-Baby_72-Hours-Later…_.PNG
A PIC is better in about a thousand ways than the AVR except for having no easy way to a higher level language for programming without shelling out cash. Had microchip been as friendly (free) with access to anything but assembly like arduino does for the AVR, there wouldn’t be a discussion to be had. By the time microchip realized that and bought atmel, you have a strong showing from ARM which will eventually make 8 bit micro’s not worth your time, if they haven’t already.
Since you are putting it in time….. that is what makes the 8 bit micros worth it in many places. They are simpler to operate and learn, so they will take less time to get the job done. Of course, there are many factors at play…. and many more new devices: ARMs that are super simple and with few peripherals that rival the 8 bit micros. And 8 bit micros that have super complex peripherals. etc…
You can program the PIC in C using open-source SDCC. The uIP TCP stack has been ported to SDCC on the PIC.
Like I say, something easy… Arduino easy and this are not in the same universe I’m afraid.
Ahh.
http://hackaday.com/2011/09/15/microchip-puts-up-two-1000-prizes-for-usb-and-tcpip-stacks/#comment-2671659
You can. But the PIC targets are unfortunately not all that great. For example, local static variables are not initialized properly and you’ll get no warning or anything, you’ll need to use globals instead (that one really bit me in the …). Code generation is not very good either.
SDCC is great and it is to my knowledge the only free (as in freedom) C compiler for PICs. I just wish it was further along.
Shelling out cash? The PIC toolchain is free from Microchip. True, some optimizations are disabled, but you ARE able to program in C at no cost.
You mean, the code gets intentionally bloated if you don’t pay
Non optimized means that it gets translated about 1:1 from C to asm. Behind the scenes compilers can do a lot of tricks that make your program run faster or take up smaller size, which are disabled if you don’t pay. https://en.wikipedia.org/wiki/Optimizing_compiler
> Shelling out cash? The PIC toolchain is free from Microchip.
But only works in Windows IIRC, which is hardly convenient for devs & somesuch. Linux is better for devs & advanced users, being also extremely advantageous if one wants “automation core” aka “IoT hub” aka “gateway”, which is very convenient to implement using small ARM SBC like Pi and Linux, so advanced PC-grade networking could meet low-level microcontrollers and somesuch, finally joining both worlds together. That’s how IoT funstuff begins.
Not to mention learning “free” microchip prog is 100% vendor lock, obtained knowledge will be of little use somewhere else, since other architectures are totally different and their toolchain does not really supports something else either. So one gets locked on crappy arch and have to spend a lot of efforts to use something else, learning entirely new toolchain and entirely different arch. Say, Cortex M things are often using “CMSIS”, peripheral abstraction lib, which allows one to migrate to different MCU vendor with modest pain when it comes down to code rewrite.
Bah. I used 16F series PICs in the past. Once I needed a larger RAM, I have found that I would have to use external RAM chip, if I was to avoid bank switching idiocy. For the price of PIC+RAM, I could buy an AVR with all this included.
I don’t think 8 bits MCU will disappear soon. They are still the highest volume sold.
For one thing there is legacy products to support and secondly when designing for high volume production any cent count and I doubt the cheapest 32 bit ARM MCU can rival the cheapest 8 bit. An engineer will consider what fit the requierement at the lowest cost. If an 8 bit can do the job cheaper than an 32 bit ARM M0 he will chose the 8 bit one.
I sort of agree with you. However, looking at how they started making very simple arm (STM32F031 comes to mind) it might be that they will be able to hook people up and get familiar with the environment.
You have not looked at the IDE available from Microchip for the PIC line lately have you. There is a free C compiler available for the IDE for the eight bit, sixteen bit, and thirty two bit Microchip PIC lines. It even includes the full C environment unlike the Arduino IDE, so you can do things like “#include stdio.h” and then use printf and friends. By the way, this was added to the Microchip IDE before they bought Atmel.
The last time I used an 8 bit mcu in a professional environment was more than 10 years ago (cypress ezusb thing)
They are going the way of the dodo. Even if they are still a high volume, it’s mostly from legacy and low cost outsourced project.
Don’t waste time on 8/16 bits if you are a student/young engineer, even on troll like PIC vs AVR, it’s a thing of the past.
I also did a inside-the-pcb battery holder using more parts of the paperclip :-)
Topside:
https://s31.postimg.org/w1uih5f57/Blingtag_Top_Angle.jpg
From bottom:
https://s31.postimg.org/dxrhwihgr/Blingtag_Bottom_Angle.jpg
Though dubious from a mass-manufacture point of view, I absolutely *love* designs with through board implementations like this. Looks great!
Liking the through-pcb other components too!
Ah that is beautiful. Well done!!
Awesome
If you’re going to go through the effort of laying out a PCB, why would you not use a proper battery holder?
What material is the paper clip made out of?
What material is the battery surface made out of?
What happens in an environment of sustained high humidity when these two meet and you put a current through their connection?
Paper clips don’t have the springiness needed for this job. Put the unit in an environmental chamber and cycle it.
That said, you sir are very clever!
Paperclip: Steel; Battery: (stainless) Steel.
But anyway: It is no good Idea to have high (condensing) humidity around a coin cell. The small distance between case (+) and (-)-Pole leads to creepage and corrosion very fast. The current is not the problem, the permanent potential difference (voltage) of 3V is the problem.
The low springiness can become a problem though.
As shown in the “bottom” photo, a misaligned cell will short the positive and negative terminal against the edge of the paperclip. If the coin cell was flipped over, this wouldn’t be an issue.
ridiculously simplistic challenge. i like PIC because they have a more complete suite of random integrated peripherals, but that’s hard to measure in a single competition (though i guess you’ve got it here with the 32kHz oscillator).
i never wind up using more than two or three of them in each project, but i use a different set for each project so the PIC wins on average. plus AVR users are bad engineers – see arduino. hah! sad.
Really?
https://people.ece.cornell.edu/land/courses/ece4760/FinalProjects/#f2014
I mean, he did switch to PICs recently, but.. yeah, anyone that says AVRs are only used by bad engineers needs to have a conversation with Prof. Land.
real engineers don’t use compilers unless they’ve got 32 bits
don’t put everyone together. I would say you should distinguish between arduino users and avr users, even though there can be the same uC. There are plenty of people doing great stuff with AVRs that don’t use the arduino crap.
As someone designing products based around the ATtiny platform (and AVR-C), I humbly agree with this statement.
Too obvious trying to derail a PIC sucks discussion into an AVR = Arduino flame. Too obvious.
now lets compare pic24 series to avr
Is 128kHz really the slowest the ATtiny will run at? With the right fuse settings (clock from watchdog oscillator, CKDIV8 fuse bit set) isn’t it possible to run it at 16kHz? Whether that actually reduces total power usage is another issue.
I started with pics WAY back in the day – no interrupts even. As they grew up, they were quite loyal to their customers re making it easy to upgrade chips and backport existing code. Just about no one had a free compiler then and atmel was “who is that?”. It was a nice self-contained pic, an 8051, or something a lot more complex and expensive. As pics grew, the really dandy peripherals became the winning strategy in many embedded designs I did for Telco’s and others. You could even do hacks like use a digital I/O for an analog gate (short a signal to ground or not – and very low ground bounce noise), or a schmitt trigger input and very little else (a capacitor and fet) to make an a/d converter when no digital chip had one built in.
Compilers ranged from CCS ($35 then, inferior then but working, $300 now and very good) to HiTech – around $1000 then and could often beat an experienced ASM programmer, later on Microchip’s $300 one that positively sucked (I even tried to get my money back from DigiKey) and didn’t even handle interrupts or saving temp variables – it just copied their app notes, to finally the CCS new expensive version that works great or did last I used it with that hockey puck (we’ve been through a few flavors of that one, all of which worked).
But the advent of the Arduino changed that. I no longer design for 100,000+ lot products either. Having to make a board just to get going vs a cheap chinese Ard clone – you gotta be kidding. The IDE sucks compared to the best but it works, and all that good code (CCS had some good libs too, not as comprehensive) and community…it just became no contest whatever.
I tried throughout most of my active career to convince various large companies, Microchip, TI and the FPGA guys, to fix their attitude that their toolsets should be a cost center with some limited success. I pointed out that as a designer I wasn’t prepared to pay sometimes upwards of $10k for the “privilege” of designing their DSP or FPGA into a customer’s product.
Some of them got it, some not – at least some dev boards came out – but still at a “cost center” pricing. These idiots did not realize that whatever a perpetually financially challenged college lab could afford would be what would get designed into major product when those kids graduated. And some failed as a result of that short-sightedness.
Not that some of us didn’t set an example (and no, I don’t make these anymore, but this is from the days of the overpriced basic stamp and is, well, quite a lot better): http://www.coultersmithing.com/OldStuff/logmoth/logmoth.html
The part numbers should give the date more or less. I don’t maintain that particular site anymore.
Look familiar, anyone?
I love projects like this. Building it on a generic breakout board is a nice touch too, to go along with the paperclip. All together it warms the gears of my heart.
It would be interesting to see if you could improve the power usage further, setting pull-ups on unused pins, adjusting clock settings, etc. Of course the LED swamps uC power use, but clearly that’s not the point of the project.
Also comparing ATtiny10 vs PIC10F would be interesting. Hopefully they could squeeze out even more power efficiency, and “fly to the moon” on 1 uA, Dave Jones (EEVblog) style.
PIC vs AVR fights are so 90s..maybe early 00s at best. How about STM32 vs TIVAC/MSP432 vs ATSAMD vs AVR32 vs PIC32 ??
I think it should more be like STM32 vs LPC vs *add other ARM brand*
Currently it looks like STM is winning this battle thanks to the avaibillity of easy-to-use opensource tools (ac6).
You can add NXP Kinetis as they acquired Freescale and Kinetis is very strong in industrial markets (but mostly absent from hobbyist one).
I wish people understood how powerful the integrated peripherals are.
Too many high level language programmers on this site. Code is their hammer. Moar speed, moar memory, moar better.
I recently redesigned a customer’s circuit from a 100MIPS software controlled four channel PWM motor controller to a 4MIPS 8bit PIC using it’s integrated modules. I was even able to add a bunch of stuff the previous controller couldn’t handle because it was so over-worked.
I did a similar thing last year. Previous engineer was trying to measure two fast pulses by simply polling the inputs with a very fast processor. I used the PICs capture compare module instead of code and was able to eliminate both ~$5 processors on the board. That alone reduced BOM cost by 50%, but since it consumed much less power and took up less space, required fewer support components, etc… the final BOM cost reduction was more like 80%.
I second this.
The newer analog peripherals in the PICs are pretty hard to beat. You can build a fricken SMPS or LED driver out of them now.
Peripherals are important no doubt. And I agree…the newer analog peripherals on the PIC are quite amazing.
Now if only Microchip can release a CPU core worth a damn…to go with these amazing super duper peripherals…..and offer a decent uncrippled open source compiler to go with it…….One can only dream
Yeah, the PIC peripherals are awesome, really well thought out and sport some amazing capabilities. But I agree, the CPU core mightily sux.
One previous poster said, the compiler is “free”, but only if you want to use a compiler that *deliberately adds* junk bloat code. To anyone reading the output ASM, it just makes your blood boil at how obvious & deliberate it is. IMO it is nothing but a (mouldy) carrot to entice a user to pay.
Maybe Microchip will shove PIC peripherals onto an Atmel CPU core now they own both? Atmel cores are supremely better than the PIC cores, but not as good as some. At least doing something like that would be a step in the right direction.
A chip with Avr-core and pic-periferals supported by AVR-gcc? That must be doable now is it not?
I whole heatedly agree. The PIC peripherals are quite complete and hard to beat. Despite the otherwise horribly outdated core, I find myself gravitating to PIC all too often.
That being said, I’ve been eyeing the new ATtiny817 series. Not the same exact set of peripherals as the PIC16, but still impressive (most notably it lacks the Peripheral Pin Select, which is unfortunate). Perhaps a sign of more good things to come?
Lol, software-controlled LED/Bucks/Boosts/SEPICs aren’t something new.
Say, look on http://forum.fonarevka.ru/showthread.php?t=20429 these crazy russians. What you thing you see on the first page? All-software BUCK circuit using just AtTiny. This thread is 2.5 years old and this circuit isn’t exactly new by 2014. There was few SEPIC and buck drivers similar in spirit even before this. Some smartass got idea to use TS5A3159 (1 Ohm analog switch) as low-voltage “FET driver” and IRLHM630 (40Amp capacity in tiny PowerQFN) FET for uber-efficient power convrsion in “ultimate” custom led torches. Mentioned circuit is a “simplified” version, using IRLHS6342 FET, which capable of “just” 8/19Amps but much lower gate charge and therefore “direct drive” by microcontroller port, despite of quite high driving freq. That’s how one gets multi-mode, high-eff, all-software SEPIC/BUCK/BOOST. Notice they’ve inserted their buck coil into what has been supposed to be “ground” rail, to be able to use N-FET and “direct drive” instead of (inherently worse) P-FETs :)
Just for sake of completeness, for those strange ppl who want to play with fire and hack the world using all-software-defined way: http://forum.fonarevka.ru/showthread.php?t=26562 is how you do uber-efficient, super-compact, multi-mode BOOST converter (for state of art LED torch) using mere Tiny 85: http://forum.fonarevka.ru/showthread.php?t=26562 (srsly, only few places where 8 bits still make some sense).
Notice scheme itself is quite straightforward: take a look on Wikipedia, replace abstract switch with N-fet, and it is software and good selection of components & clever hack with TS5A as “low voltage FET driver” what makes this thing to rock. This funny thread also showcases hardcore-DIY version of quite advanced PCB and “proper” version of the very same circuitry manufactured on factory. Yeah, best of DIYs do not mind QFNs and eventually getting able to submit their boards to fabs for mass production. That’s how DIY becomes the Engineer.
Yest, it can be done, but that doesn’t mean that it is optimal. Microcontroller switchers aren’t particularly high performance as the ADC/processing speed/PWM are the bottleneck in the overall bandwidth/switching frequency. Jitters you have in the control loop can affect regulation.
You can get switchers with on-chip switches that have PWM frequency of 1.5MHz these days. You can get very tiny inductors, using only ceramic caps and have very fast transient response running SMPS at those frequencies.
> Yest, it can be done, but that doesn’t mean that it is optimal.
These schemes are using 250kHz, 2.2uH coils, epic PMEG diodes, 100uF cercaps. Buck hits 95+% efficiency, boosts hit 90%+ either. Task-specific “cheat” in “buck”: once battery drains to D=100%, switching stops and FET is completely open. Efficiency hits 99%. Yet LED never exceeds rated current since this trick only happens on drained battery, which is unable exceed limits.
These guys are obsessed on efficiency. Flashlights imply tight space either. They craft circuits for themselves, trying to get most of (fun) of it, so they could afford ULTIMATE components and designs. Some designs are using several schottky in parallel to improve efficiency and/or current handling capacity further. Not to mention they’ve took a great deal to make it as small as possible as well. Some of them managed to fit it 15 mm flashlights, dammit.
By the way, have you noticed these crazy guys are using IRLHM620? Feel free to google PDF. This thing is epic, it is 40A FET in QFN. Yea, they solder QFNs and doing prototype batches using direct toner transfer (also sometimes launching real batches on nearby factories). Hello breadboard lovers :-).
> You can get very tiny inductors, using only ceramic caps
Since their task assumes tiny size they were forced to do exactly the same. So they’ve put a great deal at optimizing parts selection. They have idea about switching loses vs
> and have very fast transient response running SMPS at those frequencies.
OTOH 1.5MHz high-current circuit is very demanding on PCB routing. Even 250kHz is not to be taking lghtly: mcu hangs in no time if placed too close to coil. Btw, do you understand they are doing 4-5 different currents on user’s choice, right? Dare to show 5 different modes on 1.5MHz SMPS wuthout mcu? This particular set of circuits do NOT deals with fast transients: battery discharge is slow process. If one cares about fast transients, they should check it twice if MCU could handle desirable. But if someone up for SMPS, they HAVE to learn some things. Else they are doomed to face a lot of woes. And I’m sorry to inform breadboard lovers, but you can’t do real SMPS on breadboard. It going to be disaster even on 100kHz. Btw, these ppl care about Rds and computer conductance vs switching loses. Low-power mutations of circuits are recommended to use IRLHS6242 FETs instead. Rds_on of 620 is ultimate, but gate charge is high. OTOH IRLHS6242 gate charge so low and switching curve is so steep uC could handle it without TS5A “gate driver”, driving it directly by GPIO. It costs few percents of efficiency and 6242 could handle considerably less curent and Rds_on is higher.
Good luck to beat e.g. DMA-backed peripherals if one needs fast data xfers without keeping CPU core busy. The only advantage AVR got over STM32 is slightly more predictable timings/less jitter, to degree one guy implemented USB Low Speed 1.5Mbps in pure software. STM32 wouldn’t do that, but it could do far more feasible things.
Not to mention even $1 STM32 ICs are coming with a powerhouse timers and at least one of them also drives real 3-phase PWM, capable of automatic dead time insertion and so on. Guess what it means for motor control. Overall, STM32 timers are cool, even $1 ICs got plenty of fast and advanced peripherals beating PIC and AVR to the dust. And when it comes to DIY, dealing with crap like PIC is really suboptimal unless one really plans to manufacture 10 000 000 devices so PIC development horrors pay for itself.
Granted current prices, superb cpu cores and ultimate peripherals, 32-bit MCUs are going to show these 8 bit things who is king of the hill and 8-bit markets are already squeezed a lot in favor of 32 bit M0/M3 ;)
I was able to remove interrupt jitter on my STM32F030 for my VGA terminal project with nothing but C code, running code in FLASH and not even requiring compiler directives. That IRQ triggers DMA for the video output and any jitters even one clock cycles would have messed up the display. A more advanced DMA (e.g. NXP/Freescale Kinetis) wouldn’t even need that IRQ to trigger the DMA.
With more advance peripherals,you rarely need to worry about jitters. Why bitbang when your hardware does the job for you.
Uhm, last time I’ve seen NXP uCs, their flash controller has been smouldering wreck, demanding one to call their crappy api code to write into the flash and api had plenty of odd requirements. Not sure if they got rid of this awful crap in later uCs, but I’ve been scared enough not to touch NXPs with 10′ pole next 10 years. Somehow STM did this part MUCH better to my taste.
As for bitbang, it could be fun to learn about protocols and how things are working and so on. If that was part of plan. Otherwise it just delays development for no good reason. Whatever, when it comes to DIY, there is no point to save few cents on parts. Even if doing real batch, optimizing cost only makes sense for really large batches, where gains from reduced price covers these efforts. Saving $5 by doing 10 extra hours of work on tough crap isn’t exactly epic, right? The only thing one could admit in such scenario is project management failure.
Like in some Youtube Videoblog (I’m not sure if it was EEVBlog or something similar). The guy hacked a digital scale which had an SPI Interface between ADC and CPU. Ha talked quite some time how fast this is (2 or 3 figure kHz range) and that it is impossible to catch the EN and CLK with polling :-) His solution was a 8 or 9 core parallax propeller board. Instead using an SPI port in slave mode, which exists since decades even in the ancient 8051. Or any 8-bit shift register 74HCxxx.
Like if your only known tool is a hammer, every problem looks like a nail. And if it doesn’t, you need a bigger hammer. :-)
All of these comments make it painfully clear, code is their hammer.
As they are effectively the same company now it would be good to see an addition to the ATMega328 line with things like 12bit ADC, dual UARTs and better Peripheral Pin Select and of course the reliable volumes that the PICs have always had the advantage of.
Look at the XMega range.
XMEGA32E5. Lovely!
However, for the same price you can get a SAMD21E with 128K of code. All that is missing is the dual 12 bit DAC.
I’m sorry to inform Atmel but they suck when it comes to 32 bits & featured UCs. STM32 got decent 12-bit DAC and ADC in fairly cheap STM32F100. XMEGAs are pointless, Atmel’s own proprietary 32-bit UCs failed and they were really slow to spin-up Cortex M so their peripherals still not on par against of competitors. Atmel is really uncompetitive, with both A-series cortex and M-series MCUs. Chinese SoCs are beating Atmel to the dust in A-series domain, STM/NXP and plenty of other less known vendors like EnergyMicro & somesuch are taking on M-series very seriously.
It depends what you are looking for. Comparing the 128k version of the STM32F100 with the SAMD21 they are about the same price*(little more for ST), with the ST having more stuff and being faster, but less energy efficient. I cannot say I have been won by the L series from ST as an alternative, about 50% more expensive than SAM, same performance, some extra things here and there.
For me using things as hobby, the lack of need for more performance, energy efficiency and familiarity with the good IDE has kept me with xmega and SAM. However, depending on what I need I can throw in a nucleo and some mbed.
*I am looking at prices from local big distributors. Where you are on the globe might change the balance. Not counting counterfeit china crap.
This “energy efficient” marketing BS is annoying. Why the hell I’m supposed to care of it if my uC sleeps most of time in most scenarios and if e.g. most of power drained by RF RX/TX anyway, etc? All these cool stories about uber power efficiency are funny. But I have no major probs with STM32. They have STM32L for more demanding low-power tasks, btw. Whole STM32 thing is good ‘coz it scales. They range from cheapest parts making even 8 bit stuff to struggle against their pricing, while high-end parts could even boot Linux (someone commited support into mainline kernels for some STM32s, unexpectedly enough). Atmel? Ok, cool, GL to migrate from e.g. megas to SAMD. Do they have same peripherals you’re familiar with? Do they have comparable portfolio that scales? Or you’re going to have it hard instead? Not to mention Atmel ignored Cortex M way too long. I can’t wait each and every retard on the planet. If atmel gives a “duck” about power efficiency, they should really take a look on their A series stuff instead of doing dumbass marketing. That’s what surely needs some love when it comes to power efficiency. Isn’t it shameful some $5 china SoCs like Allwinner and Rockchip are beating atmel to the dust when it comes to Cortex A? In both pricing, performance, peripherals and performance per watt. No, they aren’t “counterfeit”. It is more likely Atmel who is going to resort to producing clones of china ICs and so on. I’m sorry to inform Atmel but they’ve really got quite some competitors and not exacly most competitive company around these days. Megas/xmegas are quite expensive yet totally outdated and cortex-M from atmel aren’t epic either.
@LinuxDude you are not right about the energy efficient being BS. Look at the datasheets yourself, for both the standby current and running current. It is a few (maybe lots) of times worse, and no, it is not negligeable in a system running on batteries.
However, you are right about most of the other things. Yes, atmel’s portfolio does not scale as nice as STs, but that is not necessarily a bad thing. I would not need a 1K tiny to have the same ADC as a beefy 32 bit cortex processor for a lot of reasons.
I can’t really comment on Atmel, since i basically never used them.
Just wanted to inform you that EnergyMicro is dead, it was acquired by Silicon Labs, they kept the EFM32-Family and these gecko names tho.
We usually do some quick cross-competition comparisons between the larger Cortex-M manufacturers. But so far, we’ve always found just the right device for the task in the ST catalogue, so we stuck with that because it’s just easyer for the FW-Dev to stay with the same vendor, his libraries and toolchains. We now have products covering the range from L100 to F100, F200, F400 and even a F700.
One thing can be said for sure…we now have an S*** tonne of choice when it comes to microcontrollers. And while this is generally good, it means one has to do more research/investigations to find the parts that suit his/her needs best. For me personally I love the STM32F072/42, STM32F103 & STM32F411 parts. The fact that I can use STM32Cube HAL library with all 4 parts and port code between those parts is amazing!
I also must admit that the peripherals on the STM32 are totally kickass..and in many cases arguably better than anything that you’ll find on a PIC. The DMA alone as LinuxDude mentioned in an earlier comment is total kickass. In addition the ADC’s can do 2.4MSPS on the STM32F4’s, and upto 5MSPS on the F3’s, they have incredible built in flexibility with injected channels, analog watchdog and many more features. The Timers are quite amazing as well. as are the UARTS with their fractional baurate generators (F4’s). Part of what makes the STM32 somewhat intimidating is how complicated the peripherals are. But complexity is the price of having such power peripherals.
Also you can get stm32F1 nano-like boards (called bluepill) from aliexpress for $2 and you can get an ST-LINK from the same site for another $2. Things really don’t get much cheaper than that.
I don’t really use EnergyMicro, just evaluated ’em for few tasks. So I haven’t tracked their fate recenly. But it seems it explains why I see SILabs ARMs in some devices around these days.
I like STM32 portfolio too. Fairly logical and complete, with no major flaws and shortcomings. If one sticks to STM32, they could do most thnigs microcontrollers are supposed to do. Maybe they’re not best in everything. But they were quick to introduce cortex M and managed to do it sane ways while definitely being “good enough” for most tasks. Unlike Atmel who has been lagging behind for a while trying to push own proprietary 32 bit stuff instead, while selling expensive but crappy atmegas, etc. Speaking for myself I’ve got fed up with it and as far as I can see, Atmel still haven’t really recovered from these strange decisions.
Like many, I started with a pic16F84, a classic mcu. I built a rs232 programmer I’ve found in an Eloktor magazine. This was really primitive, slow and error prone, especially in windows 98. It could only program a select few devices. Mplab x with xc has come a long way and with a pickit 3 programmer can program all pics availble and future devices. Just hitting F6 compiles and programs in one go. No more separate hex programmers where you needed to reload the hex file after each change and recompilation.
Availability has improved a great deal too. At the beginning of this millenium only the most popular pics were available and no atmels yet. Now I can just pick any pic in the selection guide and order it from my local supplier.
Over the years I’ve used many peripherals in these pics and have been impressed how much they offload work from the cpu and almost can be considered co processors. Espscially on pic24 and pic32, like auto adc capture and conversion. Some things are just not possible using bit banging, like measuring in the sub nanosecond range with the ctmu module or capturing fast logic timings on a floppy drive. The comparator can be used as a trigger for the adc to start sampling automatically, effectively making it a digital oscilloscope. Manual triggering makes the scope trace loose sync and jump around.
I only used atmel chips in arduinos and the arduino studio for programming. It’s certainly impressive how quickly you can get it setup and running, but somehow I like pics better in my projects. I guess I’m more familiar with the pic toolchain. It would take considerable time to get to the same level. It’s true the 8 bit pics are low on flash memory but the pic24 and pic32 are good alternatives. Usually if you run out of memory you either have to use compiler optimization, optimize your code manually or avoid memory hogging libraries. Especially printf and float usage can fill up a 4k device in no time at all. These are often unnecessary, primitive substitute functions usually do the job fine.
Microchip seem to have very recently released a new PIC32 family the PIC32MM. Very competitive with the arm cortex-m0. The PIC32MM clocks in 3.17Coremark/Mhz vs the Cortex-m0’s 2.49.
http://ww1.microchip.com/downloads/en/DeviceDoc/40001851A.pdf
Another PIC32MK family is also being released….But very little info on that one.
Next free toolchain.
Whatever, if one isn’t noob in microcontrollers, STM32 is the victory!!!
1) Low end ICs could cost low as $1 and below. I’ve even got bulk rate discont on top of that from my supplier, buying 30 PCS at once. That’s for Cortex M3 thing, yay (I’ve been really lucky with this deal).
2) Different fancy packages, like TSOP-20 for low-density things, assorted TQFPs if one needs more pins, QFN for those who wants something really small yet featured and even CSP/BGA for those who decided to kick for the real, doing it on the edge of techs. This said, advanced hobbysys could deal with TQFP and even QFN if they have idea how to do “direct toner transfer” thing right :P. This way one could etch quite funny device right on their kitchen.
3) Superb peripherals, capable of doing wonders if you need or want it. Say, it could do DMA. Imagine CPU and periph running in parallel, with most data movement crap offloaded from CPU. So it could do WAY more things.
4) Reasonable devtools. Including opensource ones. So one could develop for these e.g. running Linux, etc. Just usual gcc would do, OpenOCD got support for these, if someone is fan of HW debuggers, cheap FTDI2232/4232 convertors would do for HW debugging and dozen of these readily works with OpenOCD. Now one could get high-profile HW debugging under mere $20. Forget about expensive proprietary tools for $100+.
5) Plenty of libs, ready firmwares, examples, … – Cortex M is really popular these days. For a good reason!!
6) Builtin boot loader using just usual UART. So it could be flashed using arbitary 3.3V UART/TTL cable. Say, Atmel lacks it. So flashing empty Atmel requires “hardware programmer” circuitry. If one on e.g. Arduion manages to destroy boot loader, there is no way to fix it using just serial wire, it takes “HW programming interface”. Which isn’t a mere UART wire, so arbitrary UART cable wouldn’t do and one needs circuit more resembling “HW debuggers” instead.
7) Real 32 bits. Especially M3 things are kicking for sure. Doing some RF comms like by using NRF24, etc? One does not wants neighbors fiddling with their radio-controlled stuff, right? So Cortex M is cool enough to run a bit of “real” encryptoin. Say, stripped down “tweetnacl” lib doing public key crypto (!!!) goes down to 3KiB of code and very little use of RAM, leaving plenty of space for other things.
8) Unlike PICs and AVRs, Cortex M is von-neuman for dev and harvard for hardware, taking best of both worlds. No sucking RETLWs like PICs do, no stupid data vs program mem separation like on AVR. One could run code from RAM if desired, handy if one wants to e.g. update their custom boot loader, etc. Or store static data in flash with no special handling, compiler only have to know regions and who is RO/RW.
The only good thing about Atmel is Arduino, which is easy for beginners. But somewhat annoying and limited and 8 bit things are really bad at math, if one needs to do any results processing, they get very slow code which is also huge. Say, mentioned striped down tweetlnacl is 3KiB code in ARM, but 12KiB for AVR. Whoa.
Code is your hammer. Real peripherals will set you free.
Where’s the hack? Oh, there’s the clip.. :D :D