$1 MCU review — looking for AVR part suggestions

Go To Last Post
165 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Hey everyone! I'm reviewing $1 (@ 100 QTY) general-purpose 8/16/32-bit MCUs from a wide range of vendors (NXP/Freescale, Microchip/Atmel, Silicon Labs, Texas Instruments, Renesas, ST, Infineon), and I'd like to include an AVR part. The review will include quantitative comparisons between feature sets, benchmarking, power analysis, plus more qualitative stuff (development environment, SDKs, compiler choices, development/debugging experience, etc).

 

The Atmel SAM D10 was an obvious choice (and might end up leading the pack when all is said and done), but, somewhat to my surprise, I'm really struggling to find an AVR part that seems comparable to the rest of the field. The part I'm testing with is the ATTiny84, but it's pretty spartan on peripherals, only runs at 10 MHz at 3.3V, and doesn't even have an internal oscillator that can run the part at full speed. While I bet it was great when it came out, it seems like an older part that probably shouldn't be used in new designs.

 

The brand new 417/814/816/817 should help (especially with the internal oscillator issue), but the part doesn't seem like it's widely in production yet, and I can't seem to find it at any retailers, so I don't think I'll want to include it in my write-up.

 

Are there any parts you suggest looking at that I've glossed over? Or is the <$1 market not something Atmel is invested in for its general-purpose 8-bit line? (which is totally understandable — just wanted to check)

​Thanks for the feedback!

This topic has a solution.
Last Edited: Sat. Jul 22, 2017 - 04:08 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Actually, the SAM D21 seems to be the "sweet spot" of Atmel ARMs these days.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Really? All the under-$1 D21s have been obsoleted, and all the other ones seem like they're no longer normally stocked by vendors.

 

I was under the impression that the D21 was a bit long in the tooth. Again, I'm not a regular Atmel user, so if you know something I don't, please chime in! Thanks for the feedback!

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jaycarlson wrote:
... and I can't seem to find it [tinyAVR 1-series] at any retailers, ...
tiny1617 is at several distributors; tiny1616 and tiny1614 are only at a few.

Don't know when tiny3217 and etc will be announced; it is in-work.

 

https://octopart.com/search?q=attiny1617&avg_avail=(1__*)&start=0

https://octopart.com/search?q=attiny1616&avg_avail=(1__*)&start=0

https://octopart.com/search?q=attiny1614&avg_avail=(1__*)&start=0

 


http://www.avrfreaks.net/forum/attiny417-attiny814-attiny816-attiny817

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jaycarlson wrote:

Really? All the under-$1 D21s have been obsoleted, and all the other ones seem like they're no longer normally stocked by vendors.

 

I was under the impression that the D21 was a bit long in the tooth. Again, I'm not a regular Atmel user, so if you know something I don't, please chime in! Thanks for the feedback!

 

Yeah, you're right, they are from rev. A, which is obsolete. My bad. Anyway, don't forget to check Chinese stuff from Holtek and Nuvoton.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jaycarlson wrote:
Are there any parts you suggest looking at that I've glossed over?
PIC32MM and recent PIC18.

There may be some PIC24 that would be low price but I didn't look.

 

http://www.microchip.com/design-centers/32-bit/architecture/pic32mm-family

http://new.microchipdirect.com/ProductSearch.aspx?Keywords=PIC32MM0064GPL028-I/SO (slightly over the price requirement)

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gchapman wrote:

tiny1617 is at several distributors; tiny1616 and tiny1614 are only at a few.

Don't know when tiny3217 and etc will be announced; it is in-work.


Wow — I swear these weren't on DigiKey when I first shopped three weeks ago. If they were, must have totally glossed over them. Thanks a bunch for the recommendation! Buying a few 1616s right now!

gchapman wrote:

PIC32MM and recent PIC18.

There may be some PIC24 that would be low price but I didn't look.

El Tangas wrote:

 

don't forget to check Chinese stuff from Holtek and Nuvoton.


 

 

Thanks for the suggestion. If you're curious about the selection so far, I've got the SAM D10, PSoC 4000S, Freescale KE04 and KL03 (very different beasts), Infineon XMC1100, PIC16 (one of the new ones with the core-independent peripherals), the PIC32MM, the LPC811 (old, but only LPC part in the price range), the Renesas RL78/G12, the Silicon Labs EFM8LB11, the STM8, STM32F0, the STC 15W, and the MSP430FR. You're right that I can squeeze in a PIC24 — the F04KL100 comes in at just under $1 (which is a hard and firm rule for this review).

​I've worked with the Nuvoton ARM stuff, but couldn't find anything in stock on this side of the ocean in the <$1 price range. I'd love to get a Holtek chip if you have any recommendations!

One thing I'm struggling with is getting debuggers and IDEs for some of these industry/automotive-heavy parts. For example, I'd love to get a Cypress (Fujitsu) F2MC-8FX, but I can't seem to get access to the IDE / toolchain (even after emailing them). On Semi now has the Sanyo LC87, but I can't get a debugger for it (it's also out of the price range for this write-up).

 

Last Edited: Sat. Jul 22, 2017 - 10:49 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Are there any parts you suggest looking at that I've glossed over?

 ATmega8, ATmega32a, and even ATmega128 seem to be available for about $1, from gray-market suppliers (aliexpress, eBay)

(these are relatively "old" chips)
I don't know whether that "counts", but it's an interesting phenomena from a hobbyist PoV....

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

westfw wrote:

Are there any parts you suggest looking at that I've glossed over?

 ATmega8, ATmega32a, and even ATmega128 seem to be available for about $1, from gray-market suppliers (aliexpress, eBay)

(these are relatively "old" chips)
I don't know whether that "counts", but it's an interesting phenomena from a hobbyist PoV....

 

Thanks for the recommendation; even on DigiKey, you can get a few megaAVR MCUs for under a buck. Definitely thought about it. I should back up and explain that I'm testing all MCUs with their internal oscillators only (it's 2017, people — external oscillators are for RTCs and RF), so I doubt these older guys would look good, especially compared to the new Tiny1616 I just ordered. Also, there's not much of an overall difference between the Tiny and the Mega, as the ecosystems are identical (Atmel Studio, AVR Dragon, AVR-GCC, avr/io.h, etc).

 

I *am* reviewing the Kinetis KE04 and the KL03, which are both Cortex-M0 MCUs from Freescale/NXP, but I'm doing this because they have very, very different peripherals and power numbers — and they have totally different development environments. The KE04 uses the old-school Processor Expert (CodeWarrior-style) in Kinetis Design Studio — while NXP is pushing MCUXpresso for the KL03 (which is a much newer part, and isn't supported by classic Processor Expert components). Otherwise, I'm trying to find one chip representative of the architecture; I'm not reviewing PIC10, PIC12, and PIC16 parts separately, for example.

 

Thanks for the idea, though!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Infineon XMC1100?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jaycarlson wrote:
Also, there's not much of an overall difference between the Tiny and the Mega, as the ecosystems are identical (Atmel Studio, AVR Dragon, AVR-GCC, avr/io.h, etc).
fyi, tinyAVR 1-series have UPDI instead of debugWIRE; UPDI is not in AVR Dragon.

Will need an Atmel-ICE for the tiny1616.

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Katman wrote:

Infineon XMC1100?

 

Already on the list! Cute little part!

 

gchapman wrote:

jaycarlson wrote:
Also, there's not much of an overall difference between the Tiny and the Mega, as the ecosystems are identical (Atmel Studio, AVR Dragon, AVR-GCC, avr/io.h, etc).
fyi, tinyAVR 1-series have UPDI instead of debugWIRE; UPDI is not in AVR Dragon.

Will need an Atmel-ICE for the tiny1616.

 

Ugh. You're killing me, Atmel. It was hard enough for me to get that AVR Dragon up and running. I'll order one of those Xplained boards for the 817 — that supports debugging, right?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Microchip Technology    ATMEGA168PB-MU       16KB FLASH 32QFN    on DigiKey

 

This one clocks in at just over $1 per unit.  But, it is 16K flash with a good array of peripherals.  It also has support [this website and hundreds of thousands of Arduino users],  a cheap programmer (USBASP devices on eBay for  $2-3), and a free high-quality AVR-GCC compiler.  It's documentation is clear and well-written.  There are thousands of libraries for every peripheral device available for download. 

 

Sure, you might find a BOZO XKE processor for $0.97 with the same range or even slightly better specs.   But then you have to buy a $200 compiler and a $200 in-circuit emulator.  And the compiler has some little bug that the seller is reluctant to fix because they've only sold 350 copies of the software in the past two years.  And then you have to wade through a 300-page datasheet (with the most challenging parts written in REMOVED  "....ADC part supplys most 12-bit sequence for extra service detail range in low motion....).   And it may be cancelled next year.   Then your technician leaves to get a job where he doesn't have to deal with BOZO XKEs any more, and you have to bring a new guy up to speed.

 

Removed Poor choice of wording

Last Edited: Sat. Jul 22, 2017 - 02:14 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Simonetta wrote:

 

Sure, you might find a BOZO XKE processor for $0.97 with the same range or even slightly better specs.   But then you have to buy a $200 compiler and a $200 in-circuit emulator.  And the compiler has some little bug that the seller is reluctant to fix because they've only sold 350 copies of the software in the past two years.  And then you have to wade through a 300-page datasheet (with the most challenging parts written in Chinglish  "....ADC part supplys most 12-bit sequence for extra service detail range in low motion....).   And it may be cancelled next year.   Then your technician leaves to get a job where he doesn't have to deal with BOZO XKEs any more, and you have to bring a new guy up to speed.

 

...well that spiraled down quickly. I'm sure your comment is well-intentioned, but there's not much you wrote that has any basis in reality. First of all, many of the MCUs I'm looking at aren't $0.97 — they start as low as 20-30 cents, even in fairly low volumes. If you consult my list, you'll notice I don't mention any BOZO XKE processors. Every vendor I listed has shipped 100 million units or more of the part that I reviewed. All of these architectures have been around for a while, and are well-supported. 

 

The USBASP is not an ICE, so I would never consider buying it. I don't know why you mention it when you're discussing ICEs. While working on this review project, I've purchased nearly a dozen debuggers for ARM, EFM8, Renesas, STM8, and Microchip. Most manufacturers have "open-enough" debuggers, which allow low-cost clones to be purchased in the $5-20 range (ST-Link, Silicon Labs USB Debug Adapter, Microchip PicKit3). At $55, the most expensive debugger I've purchased so far is the AVR Dragon — the cheapest debugger you can buy for the AVR (and, as @gchapman pointed it, not capable of debugging new tinyAVR devices). Even my J-Link EDU edition was cheaper (though admittedly I bought it on sale), and it's much more powerful and flexible. If you're talking about programming-only, many of the MCUs I tested (Kinetis, EFM8, STC15, LPC811) actually have a factory-programmed UART bootloaders, requiring no programmer at all. I'm not sure how AVR wins the ICE debate in your head?

 

As for compilers, I would not call AVR-GCC "high quality" — I would call it completely average, when compared to other platforms and compilers I've tested so far. Without the optimizer on, it produces fairly mediocre code (a bit-set operation was compiled into 9 instructions, in my testing), and with the optimizer configured to do anything useful, the code is very difficult to debug — I'm often forced to use assembly breakpoints, as Atmel Studio can't seem to figure out what I'm trying to do. I didn't experience this problem on any other platform or IDE I tested. Atmel Studio's disassembly-view-as-an-afterthought exacerbates this problem, by not showing me side-by-side views at all times, as literally every other platform does.

 

On your second note about compilers being expensive and buggy, I'm not exactly sure what you're comparing AVR to, but all of the vendors I tested have excellent, free compilers that work much better than AVR-GCC out-of-the-box. ST partnered with Cosmic to give away free, unrestricted, lifetime licenses of their STM8 compiler. Silicon Labs gives away the full version of Keil ($3300!!) for free to anyone who downloads Simplicity Studio, their free, cross-platform, Eclipse-based IDE for their EFM8. Most of the ARM vendors use ARM-GCC (Atmel included), but it's important to remember that ARM-GCC is much more reasonable than GCC versions targeting 8-bit platforms. Also, MDK's free version works fine for up to 32 K of flash — more than most Cortex-M0 parts have, and plenty for most hobbyist projects. Again, how does AVR come out ahead in terms of compilers? When they start bundling IAR with Atmel Studio, let me know!

 

Also, I find your comment about "Also Removed" in the datasheets absurd, racist, and really uncalled for. Almost ironic to your comment, I found the STC15W datasheets some of the most pleasant documentation to read, so far in my testing. And this is a company that didn't even have an English web site two years ago.

 

For what it's worth, I agree with you that there's a nice, large, Atmel community, so it's easy to get help quickly. And, yes, there's lots of peripheral libraries out there, in the internet. But it'll be interesting to explore how that balances against many of these other devices — which also have communities — but also have excellent code-generation tools, well-documented header files, and other resources that make MCU programming extremely productive.

 

I know I probably won't change your mind, but there's a big MCU world out there, and from your comments, I feel like you're missing out on a lot of the changes that have happened in the last 5-10 years. Just my two cents.

 

Repeat of poor choice of wording...agreed innapropriate - Moderator.

Last Edited: Sat. Jul 22, 2017 - 02:16 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

By the way, this ATtiny161x is a beast. I can't wait to get mine in the mail to play with! 

 

It has a strange resemblance in density and peripheral selection to some of the higher-end EFM8 parts from Silicon Labs (16K flash/2K RAM, 20-24 ADC channels, three DACs, configurable logic block, timer configuration, etc). I wonder if it was designed to be a direct competitor? Anyone know the scoop on this new part?

Last Edited: Sat. Jul 22, 2017 - 02:43 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jaycarlson wrote:

​I've worked with the Nuvoton ARM stuff, but couldn't find anything in stock on this side of the ocean in the <$1 price range. 

Nuvoton now have a direct store, and in the 8-bit sector, they have N76E003/N76E885/N76E616.

Octopart shows stocks of N76E003, the price was around 22c/1k for 18kF/12b ADC/UART/i2c/PWM/SPI

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jaycarlson wrote:

... If you're talking about programming-only, many of the MCUs I tested (Kinetis, EFM8, STC15, LPC811) actually have a factory-programmed UART bootloaders, requiring no programmer at all. 

I found the STC15W datasheets some of the most pleasant documentation to read, so far in my testing. And this is a company that didn't even have an English web site two years ago.

If you are looking at STC micros, and also somewhat to the future,  look at their STC8F - a much faster core version of STC15.

The errata around this makes 'interesting reading', given they have been making MCUs for a long time, some of the oops are a bit fundamental.

Still, revision letters are ticking up quickly, so this could be a good family for 2018 ?

Price and road maps are in http://www.stcmcu.com/STC8F-DATA...

 

If you want to cast a broad net, the Zilog Z32F series just sneaks inside that $1/100 threshold, it's another Wide Vcc ARM, similar to XMC1xx series.

If you want USB, the Silabs EFM8UB1 series is the lowest cost USB MCU I've found.

Some Atmel ATSAMD11 USB members also come under $1

Last Edited: Sat. Jul 22, 2017 - 03:21 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Who-me wrote:

 

Nuvoton now have a direct store, and in the 8-bit sector, they have N76E003/N76E885/N76E616.

Octopart shows stocks of N76E003, the price was around 22c/1k for 18kF/12b ADC/UART/i2c/PWM/SPI

 

Wow! Super cool! Thanks for the info. I had no idea they made 8051s, honestly — I'm excited to try their on-chip debugging in Keil. It'll be interesting to see how it compares to the (really wonderful) SiLabs Simplicity Studio experience I've had thus far. Need to pick up some of their Cortex-M0s, too.

 

It's crazy that they have an M4 that's under $2 @ 100 QTY (but if I need an M4, I probably need more than the 22 MHz it can run at internally. I'd probably stick to the $2.20 Kinetis K02 — runs at 100 MHz!)

 

Anyway, definitely time to go shopping :-)

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jaycarlson wrote:

It's crazy that they have an M4 that's under $2 @ 100 QTY (but if I need an M4, I probably need more than the 22 MHz it can run at internally. I'd probably stick to the $2.20 Kinetis K02 — runs at 100 MHz!)

I think some of their parts have PLLs ?

I have their NUC505 tagged as the lowest priced MCU with HS-USB I can locate.

Have you looked at CooCox ? That has good Nuvoton support in ARMs.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ATMEGA168PB ... clocks in at just over $1 per unit.

Oh!  Good point.   The 88pb and 48pb are both under $0.90 at digikey...

 

 

I would not call AVR-GCC "high quality" — I would call it completely average, when compared to other platforms and compilers I've tested so far.

Without the optimizer on, it produces fairly mediocre code

Why would you run it without the optimizer on?  All you get is meaningless results...

 

and with the optimizer configured to do anything useful, the code is very difficult to debug

 Oh.  That.  Yes, the optimizer tends to be so good that tight correspondence with HLL source code is lost, and source-level debuggers don't seem to be very good at figuring it out.

Have you tried the (new) "-Og" optimization level?

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There is also that obscure company Logic Green Technology that makes AVR clones. Finally I found a cheap board to play a bit, I think I'm going to order a couple:

https://www.aliexpress.com/wholesale?SearchText=TTGO+XI

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

And remember that the 417/814/816/817 ...........   

Don't have a crystal osc, so if you sometimes need time precision there is nothing saved.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I just checked on digikey and 100 ATMEGA16-16MQR cost $26 , is that about obsolete or what?  because that is cheap! 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

http://www.semiconductorstore.com/cart/pc/viewPrd.asp?idproduct=64222http://www.semiconductorstore.com/cart/pc/viewPrd.asp?idproduct=64222http://www.semiconductorstore.com/cart/pc/viewPrd.asp?idproduct=64222http://www.semiconductorstore.com/cart/pc/viewPrd.asp?idproduct=64222

Who-me wrote:

If you are looking at STC micros, and also somewhat to the future,  look at their STC8F - a much faster core version of STC15.

I briefly looked at the STC8F, but wasn't able to find much English documentation. I really wish I would have taken Chinese in high school instead of Latin — that was dumb of me frown

 

Who-me wrote:

If you want to cast a broad net, the Zilog Z32F series just sneaks inside that $1/100 threshold, it's another Wide Vcc ARM, similar to XMC1xx series.

I think I'm good on ARM parts for now — unless they have a particularly interesting IDE / ecosystem?

 

Who-me wrote:

 

If you want USB, the Silabs EFM8UB1 series is the lowest cost USB MCU I've found.

Some Atmel ATSAMD11 USB members also come under $1

I do a lot of USB projects and I'm a big fan of the EFM8UB1. For this review, I'm using the LB1, since I'm trying to get as close to $1 without going over, and Symmetry (SiLabs' distributor) squeezes several of them in at that price point (e.g. http://www.semiconductorstore.co...).

 

While I've just started preliminary benchmarking, the LB1 should hold up well — its 72 MHz core clock is much faster than the 48 MHz Cortex-M0s in the round-up, and it should put up good active-mode power figures.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sparrow2 wrote:

 

And remember that the 417/814/816/817 ...........   

Don't have a crystal osc, so if you sometimes need time precision there is nothing saved.

Yes, but for everything other than weirdo projects​1, "time precision" really means "a good RTC" — typically, once you're in active mode running on the main oscillator, you don't care how fast you're running; just as long as it's as fast as possible, so you can get your work done as quickly as possible and go back into sleep mode. The new Tinys have finally caught up with everyone else in that they have an internal 1%-ish RC oscillator that can run the chip at full-speed.

 

The New Tinys look good peripheral-wise, but I was really disappointed that they still have crazy-high active-mode current (10 mA??). Hopefully Microchip/Atmel will get a core internal regulator into their design sometime soon, otherwise it's going to get eaten alive in power benchmarks compared to.... well, everyone else. It's good to see standby power consumption with the RTC running in the 700 nA range, though.

 

1 I recently required a very precise 48 MHz time base for some ultrasonic wind measurement time-of-flight work.

Last Edited: Sat. Jul 22, 2017 - 05:29 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jaycarlson wrote:
... I really wish I would have taken Chinese in high school instead of Latin — that was dumb of me....
You might like to read this, which may help with any buyer's remorse.

- John

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jaycarlson wrote:
At $55, the most expensive debugger I've purchased so far is the AVR Dragon — the cheapest debugger you can buy for the AVR ...
An alternative to AVR Dragon is the Atmel-ICE board though AVR Dragon has some functionality that's not in Atmel-ICE.

jaycarlson wrote:
... actually have a factory-programmed UART bootloaders, requiring no programmer at all.
Microchip is adding more AVR that can be programmed at Microchip; otherwise, some distributors will program AVR.

AVR application notes will have source code for a UART bootloader.

jaycarlson wrote:
Again, how does AVR come out ahead in terms of compilers?
For 8-bit MCU, computer languages (BASIC, Pascal, Ada) in addition to C and C++.

An advantage for some 32-bit MCU and one 16-bit MCU architecture is Python is available (might not meet the MCU price requirement)

 


http://new.microchipdirect.com/productsearch.aspx?Keywords=ATATMEL-ICE-PCBA (there was stock there a few days ago)

https://octopart.com/search?q=atatmel-ice-pcba&avg_avail=(1__*)&start=0

http://new.microchipdirect.com/ProductSearch.aspx?Keywords=ATAVRDRAGON

http://new.microchipdirect.com/programming/CPNPricingFrame.aspx?type=menu&mid=2

http://start.atmel.com/#examples/boot

https://www.mcselec.com/index.php?option=com_content&task=view&id=14&Itemid=103 (1 of 2 or 4 for AVR BASIC)

http://www.e-lab.de/AVRco/index_en.html (1 of 3 for AVR Pascal)

https://sourceforge.net/projects/avr-ada/ (1 of 3 for AVR Ada)

https://github.com/micropython/micropython

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Its price may be a typo though the price might be true (better to sell to customers than sell the lot to a NRND/EOL distributor)

ATMEGA16 is NRND.

 

http://www.microchip.com/wwwproducts/en/atmega16

http://www.microchip.com/wwwproducts/en/atmega16a

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jaycarlson wrote:
Hopefully Microchip/Atmel will get a core internal regulator into their design sometime soon, ...
An internal regulator is another source of failure (reverse current, surges cause cumulative damage to the pass transistor, over-voltage, stability is likely conditional)

RF AVR are 1.8V AVR that have an internal voltage regulator (and significantly lower active and etc currents)

jaycarlson wrote:
I recently required a very precise 48 MHz time base for some ultrasonic wind measurement time-of-flight work.
fyi, a recent arrival at Mouser is the Microchip MEMS oscillators that are 25ppm or 50ppm max (48MHz in stock) :

http://www.mouser.com/new/microchip/microchip-dsc6-oscillator/

MEMS oscillators are vibration and impact resistant though not "low" power (other than the 32KHz MEMS oscillators)

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jaycarlson wrote:
The New Tinys look good peripheral-wise, but I was really disappointed that they still have crazy-high active-mode current (10 mA??).
XMEGA's active current is about a third of that but XMEGA's price is about double the tinyAVR 1-series.

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Before you decide I guess you should answer this kind of questions:

1: is the for general AVR jobs, or the best for one specific job?

2: which voltage?, to avoid step up/down which other things will be on the PCB?

3: does power matter? (powered from AC no, battery yes) 

4: how accurate does you timers etc. need to be ?(about 1ppm 100ppm 1%(10000ppm) )

5: do you need eeprom, ADC(how good),UART etc.

6: how fast?

7: how big programs(flash ,RAM needs) and which language do you want to use ?

8: numbers of IO's and the speed of those?

 

I guess that there are more but if we know those I guess that we have a good picture of what you relly need. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

9. EEPROM? (that sets AVR apart from quite a lot of others)
.
PS loved the joke above about GCC optimiser! A bit like the one about the guy who bought a Ferrari but never used anything but 1st gear.

Last Edited: Sat. Jul 22, 2017 - 07:44 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jaycarlson wrote:

Who-me wrote:

If you want to cast a broad net, the Zilog Z32F series just sneaks inside that $1/100 threshold, it's another Wide Vcc ARM, similar to XMC1xx series.

I think I'm good on ARM parts for now — unless they have a particularly interesting IDE / ecosystem?

I trialed the Z51F (8051) systems, and they worked quite well, with a HS-USB link helping ICE Debug response times.

 

However, just looking at the Z32F EVALS, they look expensive, ($60+) and under-resourced.

Unlike Nuvoton's ~$25 eval boards, or Infineon's, or Atmel's, or SiLabs....,   Zilog Z32F have no included Debug at all, just a USB-UART. You have to add a 20pin external ARM debugger.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

At $55, the most expensive debugger I've purchased so far is the AVR Dragon — the cheapest debugger you can buy for the AVR ...

You can get asssorted "Xplained Mini" evaluation boards that include a debugger for about $10.  One of these has an ATtiny817, and one has a ATmega168pb - two of the "under $1" chips we have been discussing...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sparrow2 wrote:

1: is the for general AVR jobs, or the best for one specific job?

2: which voltage?, to avoid step up/down which other things will be on the PCB?

3: does power matter? (powered from AC no, battery yes) 

4: how accurate does you timers etc. need to be ?(about 1ppm 100ppm 1%(10000ppm) )

5: do you need eeprom, ADC(how good),UART etc.

6: how fast?

7: how big programs(flash ,RAM needs) and which language do you want to use ?

8: numbers of IO's and the speed of those?

 

All of those things, balanced equally, under $1. In other words, a modern, general-purpose, 16-32 pin MCU that you would drop in entry-range, current-generation products. If you look at my list of other controllers I've selected thus far, that means 3.3V, internal oscillator, low active current, lots of timers, 10-14 bit ADC with tons of channels, 6+ PWM channels, 8-16 K of flash, 1K+ of RAM, one or more UART/SPI/I2c modules, and maybe some secret sauce — programmable logic, waveform generators, DACs, etc.

 

@gchapman pointed me to the ATTiny1616, which I think I'm essentially settled on as the AVR representative for this round-up I'm doing. Unless you've got an alternative idea?

 

Sounds like now the discussion is moving onto other non-AVR parts to consider — which I'm totally open to!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
9. EEPROM? (that sets AVR apart from quite a lot of others).

 

Yeah, I don't know why EEPROM sort of went away. The AVR, PIC16, and STC15W parts have it, but I'm not sure anyone else does. I think, these days, MCUs in this price range have enough RAM that you can just read/modify/write a 64-byte bank of flash memory, and it's no big deal. Obviously not as convenient as byte-addressable EEPROM, but if we're just talking about user configuration options or something like that, storing it in Flash is totally reasonable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thank you for your extended response.  AVR is the only CPU that I've dealt with in the past 20 years.  Before that I did assembler in 8051 and 6502.   Until the Internet appeared, embedded systems was done either by professional engineers with budgets to buy compilers, debuggers, and in-circuit emulators, or "islands" of lone individuals groping blindly in the dark.   Until Arduino appeared and stablized, I couldn't learn C because I couldn't understand the multitude of error messages that I received from compilers.  I am not a student, nor am I an employee now, nor have I ever been an employee of a company that had the resources to invest the professional development of their workers.  Every single little detail about the entire subject of microcontrollers, I've learned on my own research and reading.  Nor have I ever worked with any other electronic technicians that had any interest in microcontroller systems.

 

  A "high quality" compiler, by my definition, is one that is free: easy-to-get functional, and doesn't often crash for some incomprehensible reason on Windows.  In the 20th century, there were few high quality compilers.  As for today, I don't know.  I use Arduino.  I believe that sooner or later, everyone will use it for the same reason that everyone uses Windows: it works well enough, and it is cheap enough.  "BOZO XKE" is my general term for over-hyped and somewhat ridiculous technology.  I did not know about any other microcontroller companies linkages with compilers.  I welcome all development tools for all microcontrollers.  But if these microcontroller companies were serious about promoting their devices, then they would develop versions of Arduino for their company's CPU products.  Arduino is becoming the world standard for microcontroller development.  

   

   I have a dragon and an ICE-200.  Both are fragile, expensive and hard-to-use.  I bought them about ten years ago.  I haven't bought any hardware ICE product since.  The only exception is the USBasp for $3.  If it plugs into a PC on side and a microcontroller on the other side, then it's close enough to being an ICE as far as I'm concerned.  I hope that ICEware continues to improve; but I'm still not buying any more it.  I debug with a serial port, LED blinkers, and a digital oscilloscope.

 

   Removed and Chinese-language-only data sheets are a reality in today's world.  Sometimes a company's part datasheet are the cut-and-pasted output of Google translate.  These web-based language translators do a reasonable job with European languages.  But going from English to Chinese and back coherently is just beyond their present abilities.  If you've never had to deal with

incomprehensible data sheets for a complex part, well, I envy your good luck.  Try studying the data sheets for various TFT display controllers.  I assumed that some of the CPU datasheets would as bad, but I must be wrong here.   To be considered racist for quoting Removed datasheets is absurd.  It doesn't help solve the real-world 21st-century problem of incomprehensible machine language translations.

 

Good luck in your continued market research.   A 20 cent microprocessor is a wonder of the modern age.  But if you give someone a quarter and get a microchip in return, you won't be able to do anything with it.  But spending $2.50 for an Arduino Nano clone on eBay, you have a real CPU development system, ready to rock and roll.  Plug it into a PC and you have the same capacities for CPU development that one had to pay $3000+ for back when I got my Electronic Technology degree.

Last Edited: Mon. Jul 24, 2017 - 12:39 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Take a look at ATMEGA328PB...I bought  10  for $1.11 each at Arrow, I think in 1000's they hover around $1....but Mouser wants >$2.50 for the same part!

Has extra 16 bit timers, dual UART, 32K flash, 2K RAM....they are outta stock, but more will be had between now & 2018

 

https://www.arrow.com/en/products/atmega328pb-au/microchip-technology

 

 

 

When in the dark remember-the future looks brighter than ever.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Simonetta wrote:

AVR is the only CPU that I've dealt with in the past 20 years.

This is abundantly obvious.

 

Simonetta wrote:

Every single little detail about the entire subject of microcontrollers, I've learned on my own research and reading. 

Yup, same as many of us.

 

Simonetta wrote:

A "high quality" compiler, by my definition, is one that is free: easy-to-get functional, and doesn't often crash for some incomprehensible reason on Windows. 

It's miraculous that in the last 20 years, compilers other than AVR-GCC have figured out how to meet these requirements.

 

Simonetta wrote:

if these microcontroller companies were serious about promoting their devices, then they would develop versions of Arduino for their company's CPU products.

Many do (NXP, Atmel, Nuvoton, etc). It's annoying. Give me a small break-out board I can put on my breadboard and get on with my life.

 

Simonetta wrote:

Arduino is becoming the world standard for microcontroller development.  

Arduino has shipped 4 or 5 million units total. Microchip ships a billion PICs a year. Go take apart things around your house. AVRs are rare to encounter, and if you do encounter one, it's probably not an ATMega328p. It would be a logical fallacy to conclude that they're consequently bad parts — but it certainly doesn't seem like Arduino/AVR is making much of a dent in the global MCU economy. I hand them out to all my non-engineer / artist friends, though, and their kids. They're groovy little boards if you want to build simple interactive projects.

 

Simonetta wrote:

"BOZO XKE" is my general term for over-hyped and somewhat ridiculous technology.

I'd argue that a $25 dev board with a 16 MHz microcontroller and a USB-to-UART on it is over-hyped and ridiculous — but that's just me. 

 

I tried to be nice. When you stuck your head in this thread and wrote up your "ATMega is good enough, there's really no need for anything else" comment, I tried to be polite. But seriously, we're having a great discussion about current/new MCUs out there — I've been getting caught up on the AVR ecosystem by @gchapman (thanks!), and learning about all the stuff Nuvoton is doing, and really enjoying the conversation.

 

...but then you come in and start making racist comments about the Chinese and their products. I read a few of your other posts, and look, I'm sorry that the cheap TFT you bought on eBay was made in Shenzhen and not Chicago, but when you buy products from people who live in different countries than you do, language barriers are going to happen. We all deal with it. You could have dropped $70 at Newhaven Display's web site and chose to support an American company who might have supported you back, but you didn't go that route.

 

And instead of, you know, actually choosing a proper microcontroller to drive a 320x240 TFT (like one that actually has an LCD controller on it, perhaps?), you're trying to string together some random Arduino code you found on the internet with some random display you found on the internet, without investing in the time required to understand how these displays operate at the register level. And you're upset about the grammar in the datasheet!?

 

If you would ask for MCU recommendations in this thread instead of using it as a soapbox for your disparaging remarks about Chinese products, someone would have pointed you to an MCU that has a parallel RGB LCD interface, which is a much better way of driving large pixel-array displays (such as full-color 320x240 TFTs, like the ones you mentioned). Because these MCUs have LCD controllers built-in, you can use $4 "dumb" RGB displays; the only thing you need to look up in the datasheet is the timing parameters. It turns a display into a commodity product that can be easily swapped out. Higher-end Kinetis, LPC, and STM32 parts support it, along with I'm sure many others.

 

You've admitted you aren't up-to-date on anything we're talking about — why not use it as an opportunity to ask questions and listen?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Keep this civil please. 

 

Moderator

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Like others I would go with a MEGA328PB but again it depends.

 

If you want a lot of cheap IO's (but no EEPROM or ADC), look at something like AT89LP52-20MU, but perhaps the future for atmel 8051 chips are unclear in microchips hands. (but in small numbers they used to be about $0.75 and that is one of the cheapest chips with 32+ IO's (it has 36))

Last Edited: Sun. Jul 23, 2017 - 02:25 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Go take apart things around your house. AVRs are rare to encounter

I actually have seen many AVR's (and other types); perhaps excepting toys & remote controls where the volume supports a custom 10 cent chip.

 

Here are some rankings (take this with a grain of salt---since it is published by Microchip/Atmel).  See page 20

 

https://www.microchip.com/investor/Pressrelease/Investor%20Presentation%20June%202017.060617.pdf

 

 

When in the dark remember-the future looks brighter than ever.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Atmel have sold millions of tiny28 for remote controls. 

 

add:

and back then (about 15 years ago), it was what you call a 10 cent chip.

Last Edited: Sun. Jul 23, 2017 - 06:01 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

And totally forgot this 2$ thing, but you have wifi aswell:

 

http://linuxgizmos.com/tiny-low-...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Now I'm curious. Does anyone knows any MCU based on the Xtensa architecture, apart from the ones from Espressif (like the ESP8266)? Weren't they supposed to try to rival ARM?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You'll find the xtensa in a lot of ASICs. The license cost is supposedly cheaper than ARM. The first time I'd come across the architecture was in a job interview 5 years ago for a company that did their own ASIC. Then a couple of years later i see it in the esp8266.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I doubt these older guys [atmega32a, etc] would look good [because they don't have a full-speed internal clock]

If you're insisting on a full-speed internal clock, you're getting awfully judgemental, rather than the "quantitative review" you implied in your first message.

A 40pin DIP $1 processor is an "interesting" chip with a lot of potential applications, almost regardless of clock speed.   (look at all of the <1 MIPS 8051 chips that are still being deployed...)

 

 

>> free: easy-to-get functional, and doesn't often crash

It's miraculous that in the last 20 years, compilers other than AVR-GCC have figured out how to meet these requirements.

 Which non-gcc compilers are you thinking of that meet those requirements?

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

westfw wrote:

A 40pin DIP $1 processor is an "interesting" chip with a lot of potential applications, almost regardless of clock speed.   (look at all of the <1 MIPS 8051 chips that are still being deployed...)

The DIP package is quietly being retired, and the prices reflect that. You now pay more for DIP.

 

The cheapest 44~48 pin MCUs for IO expansion type use I've found, are Atmel AT89LP51MU  (71c/100) and N76E616 (83c/100, 53c/1k) - both are 8051 cores, but not < 1MIP.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Simonetta wrote:
A 20 cent microprocessor is a wonder of the modern age.

 

 

Holtek Semiconductor's HT66F0025 8-bit MCU is about $0.19 in 10K quantities programmed with your code, and placed in Reels.  It's a few cents less if you simply order the Micros.  The smaller HT66F002 is a couple cents less same quantity and programming and packaging.

 

I will throw some water onto the fire before it starts.

 

1) the IDE is over 12 years old, and is not digitally signed, and is clunky.

 

2) the ICE is primitive, but it does work.  Once you order the special IC's for I.C.E....This reminded me of the old PODS from NOHAU with the "HOOKS MODE" or "BONDOUT MODE" micros on the PODS

 

3) the Datasheets are tough to understand due to the language barriers, but they are not horrible either compared to some datasheets I have read.  It took a few reads, and some experimentation. 

 

4) there is little to no support although the rep in the Americas office does a decent job trying to get answers.

 

 

You get what you pay for.  But the micros do what they are advertised as.

 

It's by no means a speed demon, large flash, big SRAM et. al.  but for super simple stuff, or a glue logic replacement they have their niche.

 

Jim

If you want a career with a known path - become an undertaker. Dead people don't sue! - Kartman

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jgmdesign wrote:

Holtek Semiconductor's HT66F0025 8-bit MCU is about $0.19 in 10K quantities programmed with your code, and placed in Reels.  It's a few cents less if you simply order the Micros.  The smaller HT66F002 is a couple cents less same quantity and programming and packaging.

...

It's by no means a speed demon, large flash, big SRAM et. al.  but for super simple stuff, or a glue logic replacement they have their niche.

As Micros trend down, and the 20~30c price band gets quite capable MCUs, I've noticed glue logic/MSI parts are going up in price.

 

Highest volume logic can be close to 10c, but it's surprising how fast prices climb 'on the skirts', with some HCMOS Counters, shift registers, Oscillators,  landing in the 50~70c band.

 

Silego have some interesting glue-logic replacement parts, and the larger package Atmel ATF16V8Bxx is similar in price to some of those MSI parts. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avrcandies wrote:
Take a look at ATMEGA328PB
Concur

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avrcandies wrote:
they are outta stock, but more will be had between now & 2018
The AVR supply problem is visible

Microchip Technology Inc

Microchip

Clients Letter

April 4, 2017

http://www.microchip.com/docs/default-source/announcements-documents/letter-to-our-clients.pdf?sfvrsn=2

Microchip has been relocating wafer&die fab and/or package&test of some Micrel products to Microchip plants; maybe the same will occur for popular AVR (PB megaAVR?)

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

westfw wrote:

If you're insisting on a full-speed internal clock, you're getting awfully judgmental, rather than the "quantitative review" you implied in your first message.

The reason the mega328 isn't in the review is that it's more than $1. It's amazing how much it's come down in price: microchipDIRECT has the 328pb — which I agree is a substantial upgrade to its predecessor — for $1.05. But that's still more than $1. You can make fun of me, but the problem is as soon a I say $1.05 is OK, then I'll be looking at some great NXP part that's just 10 cents more, and then I really ought to swap out that PIC16 for a PIC24, and... blah blah blah. Plus, it's way more fun to try to squeeze as much out of the parametric searches as possible :-)

 

As for "being picky" literally *every other* microcontroller that I'm reviewing operates at full speed on 3.3V from an internal oscillator. I don't think I've ever had to lay down a random 20 MHz crystal on a board to drive an MCU before in my life. It's just sort of a weird, foreign concept. Should I include the price of the crystal when talking about the MCU price? What about package dimensions? Small crystals are really expensive. Or do I just test the mega with its fastest internal oscillator, as this is the configuration that most designs will use? 16 MHz, I think?

 

Voltage is another problem. The device I use for measuring really accurate current consumption only outputs 3.3V, which literally every other MCU plays fine with. Do I cobble together some other way to accurately measure current consumption — just to test this single part? Do I test it at 3.3V, which, again, I assume most designs will be using? (I can't think of the last commercial product I've designed or torn down that had a 5V MCU in it). I don't know — I'm still thinking about how to review the tinyAVR1616, because it's got the same voltage issues.

 

I'd be willing to evaluate a megaAVR (as long as it's $1 or cheaper), but I'd like input from you on how you would go about working through that stuff. Also, if I'm already reviewing a tiny1616, what's the point? Is the development process different? Is the core performance going to be substantially different? (not rhetorical questions — seriously, let me know, as I'm not knowledgeable about AVR).

 

For testing, I'm essentially doing four things: First, I'll measure speed and power consumption while running a 64-sample array through a second-order high-pass filter implemented as a 16-bit signed direct form I biquad (to test math and memory speed). I'll do a simple LED toggle (to illustrate the instruction cycle / system clock / number of instructions relationships — more just for fun, as it's not a serious way of measuring overall system performance, but it gives the reader intuition about the how the architecture works). Finally, I'm going to implement a DMX-512 receiver that controls an RGB LED, and measure active power consumption (so I can get a feel for the platform's code-generation tools / peripheral libraries, and to measure power consumption in an environment where you can't actually sleep the MCU, and instead just halt it). I'll also put the chip in deep sleep with an RTC running (if the MCU has it), just to collect similar data across all platforms at the same voltage (which is the annoying part about comparing MCU power consumption from their datasheets).

 

Big winners will be efficient architectures that can do a lot of math quickly (as well as with low active power consumption), as well as architectures that have very low idle current, and architectures that have very low sleep current.

 

westfw wrote:

 

A 40pin DIP $1 processor is an "interesting" chip with a lot of potential applications, almost regardless of clock speed.   (look at all of the <1 MIPS 8051 chips that are still being deployed...)

Yeah! I love playing around with that stuff. I found some original 8751s (basically, 8051s with EPROM — not EEPROM) on eBay and wrote up a post on my new blog about developing and programming them with current-generation tools (Silicon Labs Simplicity Studio, modern USB-based EPROM programmers, etc). 

 

westfw wrote:

Which non-gcc compilers are you thinking of that meet those requirements?

I was referring to AVR-GCC, not GCC in general. So other platforms' GCC implementations (ARM, MSP430, RL78), along with other open-source compilers, like SDCC (which is finally starting to get decent at 8051 and STM8 code, though from what a friend tells me, still struggles to produce good PIC code — haven't verified myself).

 

But the other thing is this: if you're a student, hobbyist, or a professional looking to evaluate an MCU, I think you'll be fine with the free "limited" compilers — no matter which platform you're using (ok, except Microchip if you want any semblance of performance). I know you're going to criticize me for calling expensive, proprietary, limited compilers "free" but effectively, they are. (We're talking free-as-in-beer, not open-source).

 

Take CC-RL, Renesas's in-house compiler for the RL-78, which I've been playing around with all weekend for the review. It produces absolutely fantastic code. Yes, after 60 days, it goes into code-size-limited mode — but the limit is 128 KB of linked code. That's almost comically high. I don't know about you, but I've never used that much code on an 8-bit MCU before in my entire life, and probably never would.

 

A lot of these ARM MCUs on my list are pretty weak in terms of flash (the PSoC 4000S has 16K, but everything else is running 8). Need a good, efficient compiler for an 8 KB part? Go download a free version of MDK, which, by many measures is the absolute best ARM compiler for microcontrollers. It's code-size-limited to 32K, but who cares? If you're buying a 64K or a 128K part, you can probably switch back over to ARM-GCC and have enough headroom to lose a bit of efficiency.

 

Also, keep in mind that many semiconductor houses work with compiler vendors to provide free versions of them to their users. The best STM8 compiler on the planet, Cosmic, is now totally free and unrestricted. Silicon Labs gives away full versions of Keil C51 ​with Simplicity Studio and — you didn't hear it from me — it can be used to compile code for any 8051 (useful if you're a hobbyist and don't mind skirting under the EULA to squeeze in a bit of extra code).

 

The other thing is cross-platform support. I'm on Windows, but if I wasn't, I'd probably be much more comfortable with Silicon Labs or an ARM vendor, since they all provide officially supported macOS and Linux builds of their entire products. Sure, you can easily setup an AVR toolchain to build code on macOS or Linux, but with no IDE and no debugging support, it's not a viable option for the general professional market (we're lazy).

Last Edited: Mon. Jul 24, 2017 - 05:34 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jgmdesign wrote:

Holtek Semiconductor's HT66F0025 8-bit MCU is about $0.19 in 10K quantities programmed with your code, and placed in Reels.  It's a few cents less if you simply order the Micros.  The smaller HT66F002 is a couple cents less same quantity and programming and packaging.

 

I will throw some water onto the fire before it starts.

 

1) the IDE is over 12 years old, and is not digitally signed, and is clunky.

 

2) the ICE is primitive, but it does work.  Once you order the special IC's for I.C.E....This reminded me of the old PODS from NOHAU with the "HOOKS MODE" or "BONDOUT MODE" micros on the PODS

 

3) the Datasheets are tough to understand due to the language barriers, but they are not horrible either compared to some datasheets I have read.  It took a few reads, and some experimentation. 

 

4) there is little to no support although the rep in the Americas office does a decent job trying to get answers.

 

 

You get what you pay for.  But the micros do what they are advertised as.

 

It's by no means a speed demon, large flash, big SRAM et. al.  but for super simple stuff, or a glue logic replacement they have their niche.

 

Jim

 

I would *love* to review a Holtek part. Part of my review is to illustrate the balance between subjective IDE metrics, raw performance, and price. For example, look at the STM8. STVD — the STM8 IDE — is... uhh, pretty basic. But ST-Link debuggers are $5 on eBay, and STM8 parts are 5 cents each on Taobao, and they're great little microcontrollers. They're also widely available in the U.S. of course. Arrow and Avnet have a bunch in the 35-cent range, and I think DigiKey even has some of the higher-end ones.

 

Anyway, back to Holtek: What do I need to get started? Could you send me any links to the IDE I need to download, or the debugger tool? 

Last Edited: Mon. Jul 24, 2017 - 05:57 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I looked at the HT66F0025, and it's... well, it's cute, but I wouldn't call it a general-purpose MCU. 

 

Instead, I found a bunch of HT66F0185s on Taobao for 30 cents in single quantities. These guys are in a 28-pin SOP package with an integrated 16 MHz oscillator, 8K of flash (4K x 16), and 256 bytes of RAM, with 128 bytes of EEPROM. 8-channel, 12-bit ADC, UART/SPI/I2c. Three timer channels. Seems much more general-purpose to me.

 

You scared me with the datasheet comment, but I actually find the datasheet for this guy perfectly readable. Of course, I'll be regretting this comment when I start programming these chips and find a bunch of errors.

 

I always read the timers section of a datasheet first — if I can understand your MCU's timers, everything else is smooth sailing.

 

They guarantee a flash program memory retention of >10 years. Hey, at least they're not overselling this thing.

 

It looks like I'll need to actually buy the HT66V0185 emulator chips, and hook them up to an e-Link debugger. I found both of those on Taobao, too. Looks like the emulator chips are going to be about $2.22 each, which is more than I'd expect. the e-Link debugger is $48.

 

Is there a better place to buy this stuff, @jgmdesign?

Last Edited: Mon. Jul 24, 2017 - 06:40 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Or do I just test the mega with its fastest internal oscillator

 That, if you're insisting on the "no crystal" rule.  8MHz for the (legacy) ATmega32a, ATmega8a, ATmega128 and (new) ATmega168pb, ATmega88pb...

My experience is opposite yours - the only designs without some sort of external crystal or oscillator I've seen are the ones with the really small pin-count CPUs.
Arduino has crystals (two of them!)  Cheap mice have resonators.  Cheap eval boards have crystals.   Perhaps in your quest for <$1 chips, you haven't run into as many chips with larger pin counts.  But they are available.  External timing is generally (and perhaps inaccurately) seen as necessary for serial communications, and you need rather good crystals (or some other time source) if you want to to keep "acceptable" time (1 minute/day is better than 0.1% accuracy.)

 

 

Voltage is another problem. The device I use for measuring really accurate current consumption only outputs 3.3V

I'm pretty sure most of the ATmega's we're talking about run at 3.3V, at least at the speed supported by the internal oscillator.

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

Or do I just test the mega with its fastest internal oscillator

westfw wrote:

My experience is opposite yours - the only designs without some sort of external crystal or oscillator I've seen are the ones with the really small pin-count CPUs. Arduino has crystals (two of them!)  Cheap mice have resonators.  Cheap eval boards have crystals.  

Definitely agree with you on mice and other commodity products with really really cheap MCUs in them. Good 1% on-chip oscillators are expensive to make and calibrate, so it makes sense. All USB micros used to need external crystals, but now all the $0.75+ USB micros do crystal-less designs by PLLing from the USB D+/D- signals — lets the USB port on your computer generate the clock. Brilliant. The CH340 and other cheapo USB peripheral chips still use crystals though. Other, non-USB cheap MCUs? Idk... seems like most of them are crystal-less, too. I think everything you're saying was dead-on... 5-10 years ago. But $1 buys you a lot of microcontroller these days.

 

westfw wrote:

Perhaps in your quest for <$1 chips, you haven't run into as many chips with larger pin counts.

I mean, $1 isn't going to buy you a 144-pin beast, but most of these chips I've listed are 24-32 pin. The STC15W is the monster — 40-pin PDIP (with 61K of flash! $0.88!)

 

I think the Freescale KE04, Tiny1616, and SAM D10 are the smallest at 20 pins.

 

Definitely no 8-pin doodads.

 

westfw wrote:

External timing is generally (and perhaps inaccurately) seen as necessary for serial communications,

Agreed with the "inaccurately" — I've run 1 Mbps UARTs with 1% on-chip oscillators without issues. Well, without "too many" issues...

 

westfw wrote:

I'm pretty sure most of the ATmega's we're talking about run at 3.3V, at least at the speed supported by the internal oscillator.

Yup, good point. They all run at 3.3V with their internal oscillator.

 

westfw wrote:

and you need rather good crystals (or some other time source) if you want to to keep "acceptable" time (1 minute/day is better than 0.1% accuracy.)

Yup, RTCs and RF are the two exceptions I see all the time and design with myself.

 

I'm glad you mentioned time-keeping, because RTCs are actually one of the reasons why I shy away from MCUs without good, full-speed internal oscillators. Since most general-purpose MCUs only have one crystal input, you're sort of up a creek if you need precise time-keeping if you're using something that doesn't have a full-speed internal oscillator or a PLL/FLL. Sure, you can hook up an RTC to your crystal input (I assume?), but when you wake up from an RTC event, you'll be running at 8 MHz instead of 20 MHz. At best, it's just going to drain your battery faster (maybe not an issue for your application). At worst, it isn't going to be able to run your code fast enough to do whatever it's supposed to be doing.

 

I bet you that in many applications, neither of these is an issue. But the whole point of this review is to provide exposure to a wide range of MCUs, and point out some trends. 

 

At the most basic level, I want to help people develop some intuition when they ask themselves "What can I get for a buck?" — and, because I'm involved in education — "I know Arduino. Now what should I learn?"

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jaycarlson wrote:
the e-Link debugger is $48.

 

I paid $65.00 direct from Holtek's USA website so nice deal.  Shipping may bite you though.

 

jaycarlson wrote:
Is there a better place to buy this stuff, @jgmdesign?

Looks like you found a better place.  I bought everything direct from Holtek.

 

This site is dedicated to the AVR, so for me to start delving into the ins and outs of a competitors product would be "Tacky" to say the least.  Your question in your OP was regarding sub $1.00usd micros, and the parts I mentioned above, along with some of their relatives fit that parameter so I mentioned them.

 

JIm

If you want a career with a known path - become an undertaker. Dead people don't sue! - Kartman

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

Last Edited: Mon. Jul 24, 2017 - 01:15 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Alright, I'm planning on setting up the Tiny1616 code tonight in Atmel Studio. It's my understanding that ASF only supports megaAVR and ARM parts. What's Atmel's recommended peripheral library to use? Is there a code generator tool for peripheral initialization I should be using? Searching the Google didn't immediately yield anything, so any recommendations are appreciated!

Last Edited: Mon. Jul 24, 2017 - 05:02 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Peripherals on mega's and tiny's are pretty easy to setup, ok the timers can be a bit complex, most have examples in the data sheet. 

Commercial compilers supply a wizard to make setup easier, Codevision and Imagecraft do at least.  

You can ask questions here as well, lots of projects with example code to steal from as well.

 

Jim

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jaycarlson wrote:
What's Atmel's recommended peripheral library to use?
Your brain.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jaycarlson wrote:
(...)

But ST-Link debuggers are $5 on eBay

 

They are less than $2 on AliExpress, it's a bit ridiculous.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It is a bit of a mystery how STM32F103 chips can be bought, assembled into ST-Link or BluePill boards.

And then sold for $3 with free postage.

Just like ATmega8 on a USBASP or ATmega328P on a Pro Mini or Nano board.

 

One would hope that the Chinese Vendors make some profit.   Just like Microchip/Atmel should make some profit.

 

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jaycarlson wrote:

...

As for "being picky" literally *every other* microcontroller that I'm reviewing operates at full speed on 3.3V from an internal oscillator. I don't think I've ever had to lay down a random 20 MHz crystal on a board to drive an MCU before in my life. It's just sort of a weird, foreign concept. Should I include the price of the crystal when talking about the MCU price? What about package dimensions? Small crystals are really expensive. Or do I just test the mega with its fastest internal oscillator, as this is the configuration that most designs will use? 16 MHz, I think?

 

Voltage is another problem. The device I use for measuring really accurate current consumption only outputs 3.3V, which literally every other MCU plays fine with. Do I cobble together some other way to accurately measure current consumption — just to test this single part? Do I test it at 3.3V, which, again, I assume most designs will be using?

 

I think it's fine to test at 3v3, & internal oscillator is fine, provided you state the MHz used. That gives one known point on a curve, and users can figure 5V from that and the data sheet curves, which are quite good for Atmel.

 

If doing a Matrix, is it useful to spec if the part can use Crystal, as it is a new trend to remove Xtal osc ability from some MCUs.

That makes the 'next step' for better precision, an external Oscillator, which can cost more than the MCU.

 

Are you able to easily measure the internal oscillator frequency ?  Reporting that, even for a small sample size, can give some idea of factory-cal precision. 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Interesting Thread.

 

I think the criteria for the selection is a bit arbitrary, as everyone has their own areas of interest and expertise.

That said, you carefully defined the criteria, so be it.

 

I had to laugh a little at the debugger availability requirement.

When I used UV erasable 2716's (?), and 15 minutes per code/test cycle, using a true ICE was very useful.

These days I debug with an LED, an LCD, and an O'scope.

In my hands I can debug faster with this toolkit than I can match my HLL to ASM to a breakpoint and what some register holds.

YMMV, obviously.

I have a Dragon or two, but the last time I used it was on very early XmegaE5 chips.

 

Likewise the low power requirement.

If you design battery powered applications that will be important.

I don't, so it isn't.

But then most of my stuff is either hobbyist oriented, or are one-off projects to meet a specific requirement and are not intended for mass production.

The only time I got burned on power it was for an early GPS automatic vehicle location system, and the GPS used ~ 50 mA.

The first prototypes didn't power the GPS on and off, but kept them running for instant location, (no warm-up), and if the vehicles sat non-used for a few days they could run down the vehicle's battery.  Since the GPS and the radio link used far more energy than the micro, the micro's current just wasn't an issue.

For most of my projects once I plug in a wall-wart saving the planet just isn't a priority.

 

Interesting comments about external Xtals.

As noted, many small 8-bitter projects / devices might run well on the internal RC Osc.

The Xmegas, (and perhaps the newer Tinies), have much better accuracy than the older Mega chips, but the Xmegas exceed the $1limit.

Most of my projects have had an external Xtal, although truth be known some of them clearly didn't "require" one.

Old habits on that one, I guess.

For short, easily maintainable code, removing unnecessary routines is helpful, and USART auto-synch is an easy one to ditch.

For quantity < 10 boards, the cost of an Xtal and two caps just isn't an issue.

 

Speaking of cost, the cost < $1 is an interesting spec.

That might make sense for mass produced products.

Not my world, however.

Cost of the micro, be it $1 or $10 just doesn't matter.

Familiarity with the peripherals, I/O pin count, language/IDE, etc., are more important.

 

Anyway, the point is I suspect the specific spec's for the review vary widely in importance to different members of the audience.

 

That said, however, I found the range of offerings, and associated comments, very interesting.

 

JC

 

 

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

El Tangas wrote:

[ST-Link debuggers] are less than $2 on AliExpress, it's a bit ridiculous.

 

Yeah, it's nice to see vendors handing out schematics and firmware hex files to their debuggers. Both ST's ST-Link and Freescale/NXP's OpenSDA debugger on their FRDM boards are fairly open, and it's cool that both can be programmed with free J-Link firmware, too. Which means that $2 ST-Link is now a $500 J-Link debugger (read the EULA, though).

 

You can get $10 clones of Silicon Labs' C2 debuggers on eBay, or just buy the pre-programmed debugger chip and build a board yourself (that's what I did!), and PicKit clones are <$20 on Amazon last I checked.

 

Seems like everyone's moving in the direction of low-cost "MCU breakout" boards with on-board debuggers, which is great. Feels like ST was the first? Not sure on that, though. I always hated having to use those old-school "evaluation boards" that seem like they're designed more to market an MCU with flashy LCDs and stuff, instead of providing a useful development environment.

 

Silicon Labs is still kind of stuck in that old-school evaluation board mindset, but they have a great on-board current measuring device with a huge dynamic range that integrates with Eclipse nicely for real-time plotting.

 

I really like that Atmel is making these Xplained Mini boards — I just wish they had jumpers on them like the MSP430 Launch Pads or ST Discovery boards so you could easily debug external targets. It looks like the only way I'll be able to do that is by slicing some tracks on the PCB, or popping off the target MCU, as they don't even have removable zero-ohm resistors :-(

Last Edited: Mon. Jul 24, 2017 - 09:07 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jaycarlson wrote:

I really like that Atmel is making these Xplained Mini boards — I just wish they had jumpers on them like the MSP430 Launch Pads or ST Discovery boards so you could easily debug external targets. It looks like the only way I'll be able to do that is by slicing some tracks on the PCB, or popping off the target MCU, as they don't even have removable zero-ohm resistors :-(

Yes, that's a poor oversight.  

 

I like the approach Nuvoton, Infineon & some others use, which is to have a very clear Debug PCB area, and with a break-off/cut line, with pin headers each side, not fitted.

 

I also like the debuggers with Crystals, as that gives a precision timing reference that can be used to check the MCU oscillator.

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jaycarlson wrote:
I'd be willing to evaluate a megaAVR (as long as it's $1 or cheaper), ...
mega168PB is, for 100, 0.99USD each at Microchip; 1.02USD at Digi-Key with better minimums.

jaycarlson wrote:
(to test math and memory speed)
fyi, CoreMark does that in a portable form (across MCUs)

jaycarlson wrote:
Also, keep in mind that many semiconductor houses work with compiler vendors to provide free versions of them to their users.
For AVR, Atmel teamed with IAR for the C compiler.

IAR EWAVR Kickstart is the 4KB zero price version (Windows only)

It's likewise 4KB for the evaluation version of CodeVisonAVR.

45 days for the demonstration version of Imagecraft JumpStart C for AVR.

jaycarlson wrote:
Sure, you can easily setup an AVR toolchain to build code on macOS or Linux, but with no IDE and no debugging support, it's not a viable option for the general professional market (we're lazy).
fyi, PlatformIO has AVR GCC for some megaAVR and tinyAVR with integration for multiple IDE but no debug for AVR (it's debug for ARM Cortex-M and MSP430)

 


http://new.microchipdirect.com/ProductSearch.aspx?Keywords=ATMEGA168PB-MU

https://www.digikey.com/product-detail/en/ATMEGA168PB-MU/ATMEGA168PB-MU-ND/5029504

http://www.eembc.org/coremark/about.php

https://www.iar.com/iar-embedded-workbench/#!?architecture=AVR (expand "Download a free trial!")

http://hpinfotech.ro/cvavr_download.html (CodeVisionAVR, Download)

https://imagecraft.com/download/demo-software

http://platformio.org/platforms/atmelavr

http://docs.platformio.org/en/latest/plus/debugging.html#platforms

http://platformio.org/pricing

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gchapman wrote:

mega168PB is, for 100, 0.99USD each at Microchip

Neat -- I'll throw it into the mix since there appears to be a lot of interest.

 

gchapman wrote:

fyi, CoreMark does that in a portable form (across MCUs)

Yeah, maybe it's just me, but I feel like reading "16-bit second-order filtering at 400 kHz" gives me better intuition for how powerful a processor is.

 

gchapman wrote:

or AVR, Atmel teamed with IAR for the C compiler. IAR EWAVR Kickstart is the 4KB zero price version (Windows only)

I don't think I want to get into a compiler review scenario, so I'll stick with the manufacturer-supplied toolchains. Maybe I'll play with EWAVR a bit. Is this more commonly used by professionals than Atmel Studio? Sorry, I really don't know this architecture very well at all.

 

@gchapman, I have to sincerely thank you for taking so much time to walk me through everything and provide links to most everything you mention. I'm new here, but I'm quickly wishing there were more people like you on the other forums I visit.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jaycarlson wrote:
Good 1% on-chip oscillators are expensive to make and calibrate, so it makes sense.
After calibration, 1% for PB megaAVR and 1.5% for tinyAVR 1-series.

jaycarlson wrote:
All USB micros used to need external crystals, but now all the $0.75+ USB micros do crystal-less designs by PLLing from the USB D+/D- signals — lets the USB port on your computer generate the clock.
IIRC, USB SOF.

Non-USB AVR can use the UART SOF.

jaycarlson wrote:
Definitely no 8-pin doodads.
That's one of the tinyAVR characteristics is an AVR in a low pin count package; tiny85 is a classic.

tinyAVR 1-series maxes out at 24 leads (in QFN); for more leads or pins it's megaAVR or XMEGA AVR.

 


http://www.microchip.com//wwwAppNotes/AppNotes.aspx?appnote=en591004 (AVR054: Run-time calibration of the internal RC oscillator via the UART)

http://www.atmel.com/images/AVR054.zip (software to match the AVR054 app note)

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jaycarlson wrote:
It's my understanding that ASF only supports megaAVR and ARM parts.
and XMEGA AVR with a wee bit of tinyAVR in ASF3.

jaycarlson wrote:
What's Atmel's recommended peripheral library to use?
Microchip ASF4

jaycarlson wrote:
Is there a code generator tool for peripheral initialization I should be using?
Atmel START

It's "should" wink

 


http://asf.atmel.com/docs/latest/search.html?device=tiny

ASF4 API Reference Manual

http://atmel-studio-doc.s3-website-us-east-1.amazonaws.com/webhelp/GUID-2A8AADED-413E-4021-AF0C-D99E61B8160D-en-US-1/index.html?GUID-819376C9-5C19-4F1E-9320-ED29CF2A0627

http://start.atmel.com/#examples/tiny16

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

If you don't mind going a bit OT, it so happens that my Chinese clone sub-$2 ST-Link just arrived in the mail. I'll just show you guys what's inside:

 

 

 

So this chip alone, STM32F101CBT6, costs 2-3 dollars and is inside a device I bought for 1.6 euro. And with a nice aluminium case. Go figure...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jaycarlson wrote:
... but they [Silicon Labs] have a great on-board current measuring device with a huge dynamic range that integrates with Eclipse nicely for real-time plotting.
Likewise for Xplained Pro that integrates with Atmel Studio 7.

jaycarlson wrote:
I really like that Atmel is making these Xplained Mini boards — I just wish they had jumpers on them ... so you could easily debug external targets.
Xplained Mini runs the target MCU at 5V; Xplained Pro runs the target MCU at 3.3V

Voltage level translation is only in Atmel-ICE.

There's an EDBG board in the ATtiny817 QTouch Moisture Demo Kit, but the level translators are on the main board with the tiny817.

 


http://www.microchip.com/DevelopmentTools/ProductDetails.aspx?PartNO=ATTINY817-XPRO

http://www.microchip.com/DevelopmentTools/ProductDetails.aspx?PartNO=ATTINY817-QTMOISTD

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gchapman wrote:
[...] Microchip ASF4, Atmel START [...]

This is exactly what I was looking for. Thanks a bunch!

 

I'm super excited to give this AVR stuff a spin — it's been so long!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jaycarlson wrote:
Is this [EWAVR] more commonly used by professionals than Atmel Studio?
I have no data to answer your question.

From the POV of a large corporation, it's buy* the tool.

From the POV of a small business (individual, partnership, small team), likely the zero price tool though there is value in "low" price tools.

EWAVR is not "low" price though, IIRC, it's less than 10KUSD.

Some niche AVR IDE would be in the region of 10KUSD.

jaycarlson wrote:
Sorry, I really don't know this architecture very well at all.
No problems.

Glad you're asking questions.

 


* GCC tool chains and some IDE are zero price; what's not zero price is the value-added to such (dual license - GPL for zero price, non-GPL for commercial)

 

Edit : typo

 

"Dare to be naïve." - Buckminster Fuller

Last Edited: Tue. Jul 25, 2017 - 12:54 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

El Tangas wrote:

If you don't mind going a bit OT, it so happens that my Chinese clone sub-$2 ST-Link just arrived in the mail. I'll just show you guys what's inside:

 

So this chip alone, STM32F101CBT6, costs 2-3 dollars and is inside a device I bought for 1.6 euro. And with a nice aluminium case. Go figure...

 

 

2-3 bucks? psh, try 5 CNY ($0.74), in SINGLE QUANTITIES:

 

Now imagine buying them in 1k-100k volume... you'd make a handsome profit selling that debugger for $1.50 laugh

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I don't know, that's TaoBao, right? It seems a bit shady to me cheeky

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jaycarlson wrote:

Instead, I found a bunch of HT66F0185s on Taobao for 30 cents in single quantities. ..I found both of those on Taobao, too.

 

How do you access Taobao ?  All I can find is Chinese, and what look like translate-wrappers that are 3rd party ?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

El Tangas wrote:
I don't know, that's TaoBao, right? It seems a bit shady to me cheeky

 

Who-me wrote:

How do you access Taobao ?  All I can find is Chinese, and what look like translate-wrappers that are 3rd party ?

 

When I had my wisdom teeth taken out and I was jacked up on hydro, laying in bed with my laptop, bored out of my mind, I set up an account. The most annoying thing about Taobao is it's a little "too secure" — your account has to be linked to a mobile phone number, and they'll do a 2-factor authentication whenever you sign in on a new device.

 

Go through https://world.taobao.com/ — it seems to be the site you can use when you want to ship stuff out of the mainland. Tips:

  • Use Google Chrome's built-in page-translation capabilities. You'll feel like you're on eBay or Ali Express. Seriously, it's uncanny. I often forget if I'm on Taobao or Ali Express (that is, until I look at the prices...)
  • The hardest part is setting up an account. Lots of javascript-based pop-ups you have to fill out that Google Translate doesn't pick up on. At one point, I had to find "United States" (美国) in a list of countries. They were alphabetized, but... well, I don't speak Chinese.
  • If you can't select text to paste into https://translate.google.com (like a hint in a text field, for example), hit F12 to pull up the developer console, find the HTML, and select the text that way.
  • When you find something to buy and you click "Add to Cart" nothing will happen — you always have to click the "the country" pop-down by the originating location, and choose "overseas" before the javascript will let you click the "Add to Cart" button.

 

This all seems moderately insane, but after you spend an hour doing it, you'll have access to an amazing resource to buy stuff.

  • Taobao uses shipping consignment companies, which is awesome. Let's say you buy 10 different items from various vendors on Taobao. Instead of paying EACH of those to ship overseas, you actually pay local postage (<$1) to ship them to these consignment warehouses, which then package stuff up and ship it to you in one box. It takes longer, and it's a two-step purchase process, but it's cheaper. By the way, it really is a two-step process. Once the items arrive at the warehouse, I think you only have 10 days ship them. So it's annoying if you're waiting on an item or two to ship. make sure you login and keep track of that stuff, because after 10 days, I think they either start charging fees, or send the items back to the seller.
  • It looks like most sellers offer direct shipping, too. You can check the "Ask the seller to ship" checkbox when submitting payment, and write a little note with your address. Again, seems sketchy, but these people really do work hard to make things right. One guy kept the fast EMS shipping — overseas — and didn't charge more for shipping. I felt kind of bad.
  • Taobao is operated by Alibaba, which is equivalent in size, scope, and corporate stewardship to eBay. If you trust eBay, you should trust Taobao.
  • All financial transactions go through Alipay (Alibaba's PayPal equivalent), and it works similarly to eBay or Ali Express.
  • The site has a wayyyy better selection of silicon than AliExpress does, and the site allows partial string searches, which is amazing for us electronics folks. "STC15W" on AliExpress only turns up three hits — if you wanted to find some STC15W parts, you'd have to iterate through all of the different part numbers. On Taobao, "STC15W" yields 86 pages (yes, pages) of results.
Last Edited: Tue. Jul 25, 2017 - 02:40 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am sure that these Chinese websites can deliver with such ridiculously low prices.

It all seems too complicated for me as a hobbyist.

 

I have always looked at the world as someone, somewhere provides a service and makes a profit.    People are employed.    The Global Economy works.

Civilisation progresses.

 

I am quite happy for a European Distributor to sell semiconductors at a profit.   Do they get a similar "deal" from ST as the Chinese ?

Obviously they have contractual agreements with Manufacturers.    But I do not see how there could be such a massive disparity.

 

Your $1.00 quest becomes crazy when the "Tabao" market is involved.

On the other hand,   when you are committed to 100k production,   how reliable would these sources be?

 

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I mean, $1 isn't going to buy you a 144-pin beast, but most of these chips I've listed are 24-32 pin.

For your amusement, here's a 100pin beast for less than $1 (without even needing to go to China!)
http://www.newark.com/cypress-se...

I'm not quite sure how Newark's "excess inventory" pricing relates to the real world, though.  Digikey's price for the same chip is up near $4, I think.

 

The availability of "very cheap" large-ish pincount microcontrollers  is a bit of a game changer; it reminds me of when I first noticed that 74xx ICs from the dealers in Popular Electronics were cheaper than mere transistors from my local "electronic parts store" (Lafayette (sp?))...

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Surely a large pin count chip has got to have a larger die size than the smaller models.   Purely for the package bonding wires,

 

I would expect manufacturing costs to be related to die size and yield.    If a particular chip sells well,  it just means that lots more wafers are in a batch.

 

The real mystery is:  What happens to old DIP chips that have been on Distributor's shelves for years and years?

 

I know nothing about Bill's cheap Cypress/Spansion chip.    Who would want a 40MHz M3 ?    They will only shift it at a giveaway price.

 

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A 40MHz M3 will wee on a 48MHz M0 along with a healthy amount of ram, flash and 5V as well. That's good bang for yo buck!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I agree that M3 trumps a M0. It seems wiser to have M3 with a faster core. Reduce running frequency to save power.
.
Of course some applications need lots of pins but no performance.
.
David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The 5V parts seem to be speed limited.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have never looked at Cypress parts.    I would expect the Core to run at 1.8V or whatever design voltage/speed.   Any 3.3V or 5V logic to the outside world would be due to output/input electronics.

 

Supposed 5V tolerance generally applies to GPIO functionality.   If it is performing a peripheral function,   you have to read the data sheet very carefully (with most manufacturers).

 

I have played with several makes of ARM.   I do not have the enthusiasm to study Cypress too.

As I said in #85.   Some applications only need low performance but high pin count.

 

As a hobbyist,  I am more interested in a part that can do "everything" and modest.    A commercial product is more interested in "sufficient" and CHEAP.

 

David.

Last Edited: Tue. Jul 25, 2017 - 02:32 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

david.prentice wrote:
As a hobbyist, I am more interested in a part that can do "everything" and modest. A commercial product is more interested in "sufficient" and CHEAP.

 

These days, everything really means everything. Even a modest modern MCU like the Tiny 1617 has DAC, event system, custom logic, it's impressive. Cypress has configurable analog blocks, and the modern SAM L series also has configurable analog.

Sometimes, the CPU hardly needs to do anything, just configure the peripherals and go to sleep. The peripherals are becoming so smart, they can do simple tasks on their own. And of course, the datasheets to explain all that can easily grow beyond 1000 pages...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I would agree with this for most TQFP-32 - TQFP144 ... packages.    But you still get some differences between family members of the same age and size.

 

Smaller packages often mean that the family junior member loses some features.

This is most noticeable on the legacy Tiny AVRs.   You have to choose the model that does what you need.

Microchip PIC models have always had different capabilities.  e,g. CAN, USB, ...

 

Modern chips can often re-assign pins and peripherals.   So you can pack more punch into a small package.

 

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

david.prentice wrote:

I am sure that these Chinese websites can deliver with such ridiculously low prices. It all seems too complicated for me as a hobbyist.

Your $1.00 quest becomes crazy when the "Tabao" market is involved. On the other hand, when you are committed to 100k production, how reliable would these sources be?

Haha, this thread has gone off-track a few times (which led to some great discussions), but just to clarify: I'm talking about $1 or less, shipped from a major U.S.-based distributor (something you'd find on Octopart), or directly from the manufacturer in quantities of 100. Newark has crazy sales and close-out specials all the time that I'm not considering, nor am I considering Taobao prices. That was just for fun.

 

So yeah, I totally agree with you. I play around on Taobao not because of the prices (who cares? we're talking about paying 30 cents instead of 80 cents), but just for fun — and also for access to East Asia ICs that I don't otherwise have any access to.

 

STC is a great example of a huge manufacturer of 8051 MCUs that have a totally reasonable, hobbyist-friendly development path (free Keil or SDCC download, USB-to-serial converter for programming and debugging, decent English datasheets, and 23749283472938472 different web sites out there with 8051 samples). But it's tough to find STC parts outside of Taobao / Ali Express. 

 

david.prentice wrote:

As a hobbyist, I am more interested in a part that can do "everything" and modest.

Oh, totally. If I'm building one-offs, I'd have no problems paying for a $5 or $10 MCU. But:

  • MCUs that can do everything (popular example is the STM32F4) are complicated to configure, use, and lay down on a board.
  • There are a ton of $1 MCUs that I'd say can do "about anything" that are also *really* easy to use. 

 

I think the disconnect is that some people on this thread have it stuck in their brains that cheap MCUs from lesser-known brands must be really unfriendly to use, as they're not popular among hobbyists. But in my testing so far, I've actually found the opposite to be true. As an example, I had never touched a Renesas part in my life before last weekend, and I had an entire DMX-512 RGB LED project built from start to finish in about fifteen minutes.

 

Modern code-gen tools and well-documented peripheral libraries, coupled with the fact that most manufacturers are going to Eclipse-based IDEs means that it's super simple to jump around between architectures. I'm talking, like, an hour's worth of work to skim through the datasheet, download the tools, and get stuff set up before you can start your project. It's insane. Anyway, that's what sparked this whole quest in the first place.

Last Edited: Tue. Jul 25, 2017 - 08:17 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jaycarlson wrote:

... this thread has gone off-track a few times (which led to some great discussions)...

 

And here comes another one...

 

jaycarlson wrote:

STC is a great example of a huge manufacturer of 8051 MCUs ...

 

The '51, in its original form, was the first uC I used and I still have a bit of a soft spot for them. However, I also remember that they weren't very good at supporting high-level languages; things like the lack of registers that could be used as memory pointers made for some very kludgey generated code.

 

Have compilers improved that much that they are now a decent match for other, newer, uCs?

 

I guess Jay's benchmarking will answer that question.

'This forum helps those who help themselves.'

 

pragmatic  adjective dealing with things sensibly and realistically in a way that is based on practical rather than theoretical consideration.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Accessing external memory was never the 8051's strong point. Various chips added one or more dptrs, which was handy. The high clock speed devices just get around this issue with speed. Nevertheless, the 8051 instruction set was quirky but seemed to have instructions that solved most problems easily. I enjoyed writing asm, except when i had to access external ram.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

if you want easy set up for a AVR then use mega168pb or something like that, stay away the new tiny's, they are new hybrids that use the HW things from the xmegas, that is good if you come from a xmega, unnecessary complicated if you aren't into AVR's.

with mega168(p)(b) there a ton's of programs (been out for 10+ years).  

 

and about 8051:

 I enjoyed writing asm, except when i had to access external ram.

?

what is wrong with mowx using r0 or r1 as pointers that give you a total of 8 pointers to external RAM.(+ DPTR that on some chips,  like the atmel LP versions are two pointers) 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

I can't help it....

Optimizing pricing for a processor in the hundreds is ridiculous. Buy a good easy to use processor and be done.

Once you get to quantities of OVER 10,000 then a cursory look is probably OK.

Ive had SO many customers trying to save $.05 per unit on 500 units by spending $1000's.

Seriously messed up, do the math. Time / delayed sales matter too.

Keith Vasilakes

Firmware engineer

Minnesota

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Keith, there's nothing like the feeling of saving!

I concur - for most of my work the engineering time writing the code dominates.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you read the thread you will find out that OP want this for educational use!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
I concur - for most of my work the engineering time writing the code dominates.

Certainly there will be at least some learning curve going to something "different".

 

Besides writing the code, there may well be a needed investment in toolchain, programmers, debuggers, and similar.  A modest e.g. $250 is still a buck each if you are building a couple hundred.

 

Besides writing the code, the design itself to get a solid board with the "different" chip has a learning curve.  For example, once we had done a number of AVR8 apps we "know" how to lay out the board without surprises.

 

=============

The "about a buck" is still an interesting and perhaps useful exercise.  A decade or more ago, it was nearly impossible to make a very simple and dirt-cheap device at domestic prices, even at somewhat higher quantity.  About that time, a smattering of under-a-buck micro models appeared.  Now, as the thread shows, one can get fairly powerful micros at that price point.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

keith v wrote:

...Buy a good easy to use processor and be done.

...

 

But it doesn't hurt to step back once in a while and see what's out there. Atmel's AVR pricing has been all over the place since the merger; especially when bought through stocking distribution over here in the UK. I've seen the price of a DIP '4313 nearly double at one point before settling back down to less than what I was paying over a year ago when I last updated the BOM prices.

 

We can quibble about what seems like the arbitrary set of criteria chosen by the OP but you do need 'rules' to do this sort of exercise. If you start out with a 'no more than 1$' rule but accept devices at $1.10 then why not accept $1.21 and then why not $1.33?

'This forum helps those who help themselves.'

 

pragmatic  adjective dealing with things sensibly and realistically in a way that is based on practical rather than theoretical consideration.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

keith v wrote:

Optimizing pricing for a processor in the hundreds is ridiculous. Buy a good easy to use processor and be done.

 

Totally agree! If you're building 100 units, you should never drop a proven MCU and switch to a different architecture, solely to save money. That would be ridiculously silly.

 

I'm not talking about optimizing — the question started as "hey, wouldn't it be cool to look at a bunch of different MCUs out there, check out the vendor tools, debuggers, development hardware, performance measurements, and compare everything?"

 

But there's an overwhelming number of MCUs out there, and it seems silly to compare an 8-pin ATTiny with an STM32F4, so I thought it would be fun to narrow it down and see what a buck can buy you these days.

Don't get me wrong: it's completely arbitrary, and done purely for fun. Just explaining my rationale laugh

 

Why do this? Imagine that you're starting a new, long-term project, and you're spec'ing the MCU for it. Do you want to drop in the same part you've been using in projects for the last 5 or 10 years? Does it make sense to consider trying out a new MCU architecture you've never used before? Will you see any performance gains? How much faster or easier is the development process going to be?

 

What's funny is, while doing this, I've stumbled upon ecosystems that I've never used before that I was actually able to get up and running faster than the MCUs I have a lot more experience with. It just shows you how important developer tools are (especially for quick projects where you want to minimize that "DC bias" at the beginning — pin-muxing, peripheral configuration, board bring-up, etc).

 

Brian Fairchild wrote:

The '51, in its original form, was the first uC I used and I still have a bit of a soft spot for them. However, I also remember that they weren't very good at supporting high-level languages; things like the lack of registers that could be used as memory pointers made for some very kludgey generated code.

 

Have compilers improved that much that they are now a decent match for other, newer, uCs?

I think you would be blown away by the Silicon Labs EFM8 stuff. Three-stage pipelined architecture, running up to 72 MHz. None of this old-school 12-cycle-machine-clock rubbish; this is a single-cycle machine that, clock-for-clock, matches the TinyAVR closely (not going to say more until I finish testing!)

 

I haven't gotten my EFM8LB11 in yet, but I'm really curious to see if it can hold its own against the 20-30 MHz ARMs in the field (highly doubt it can withstand the 48 MHz Atmel and NXP parts, but we'll see!)

 

The best part about the EFM8 for hobbyist / one-off projects is all the code-gen tools that Simplicity Studio, their free IDE, has. Comes with a full version of Keil C51 for free. I think hobbyists/makers will appreciate that it's got identical support across Windows, macOS, and Linux, too. No need to cobble together an open-source toolchain (which can be fun, but overwhelming if you're a beginner).

 

As for the quality of the compilers, ironically, the 8051 / Keil C51 combo is one of the only compiler setups I haven't had to configure at all in my testing; while I had to mess with RL78-GCC, AVR-GCC and ARM-GCC compiler settings extensively to be able to get it to toggle a GPIO pin efficiently, Keil C51 produced a two-instruction "xor" / "jump" routine without even turning on the "optimizer"

 

This makes sense; it's 2017 — surely we can build a compiler that produces efficient code for CISC architectures.

Last Edited: Wed. Jul 26, 2017 - 11:31 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jaycarlson wrote:

I haven't gotten my EFM8LB11 in yet, but I'm really curious to see if it can hold its own against the 20-30 MHz ARMs in the field (highly doubt it can withstand the 48 MHz Atmel and NXP parts, but we'll see!)

Being 8 bit, it will compare well on boolean/byte level operations, and no so well on 32 bit maths.

The real appeal of a part like EFM8LB1, is in the peripherals, where it has 14b ADC and 12b DACs, and I've found the DACs work just fine as INC DAC and DEC DAC SFRs for up to 36MHz step-rate linear ramps.

Not sure how the ARMs go doing that ?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Who-me wrote:

The real appeal of a part like EFM8LB1, is in the peripherals, where it has 14b ADC and 12b DACs

Yes! I'm excited to play with it. All I've played around with is the EFM8UB1 and the EFM8SB1 parts so far. Well, "played around with" is the wrong word — I just wrapped up a 2000-run commercial project with the SB1, and it worked like a treat.

Who-me wrote:

I've found the DACs work just fine as INC DAC and DEC DAC SFRs for up to 36MHz step-rate linear ramps.

That's crazy — I never thought about that. Like I said, I'm super excited to play around with that part when it comes in.

 

My Nuvoton N76E003 dev board just showed up, so that's what I'm playing with right now. Thanks for the recommendation on that guy, by the way! They have a bizarre SDK that's quite different from anything I've seen before — looking forward to writing it all up.

Last Edited: Wed. Jul 26, 2017 - 11:54 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jaycarlson wrote:
while I had to mess with RL78-GCC, AVR-GCC and ARM-GCC compiler settings extensively to be able to get it to toggle a GPIO pin efficiently,
Tell us more about the extensive settings needed for avr-gcc when toggling a pin? With nothin but -Os on the command line a write to PIN will be an SBI and for an older school AVR that requires an RMW it will be 3 opcodes. How could it be more efficient than this and that is with nothing more than -Os ?? (which most IDE and makefiles pass as the default anyway)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

But that open good and simple a tool do you get for free!

 

Studio 7 is good but big! and if you don't know microsoft studio it will get some time to get used to, and hard to find some simple things.

 

So if it was to get something up running in a hurry I guess that something like studio 4 would have been better!

 

But that said efficient toggle an IO with AVR-GCC should be a 2 sec deal! (and you would spend way more time with the datasheet finding out how to do it.)

(But perhaps it's because you use a 1616 and not a "normal" mega168 or so!)

 

 

 

 

 

Last Edited: Thu. Jul 27, 2017 - 10:32 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm not necessarily talking about using an IDE anyway. If I sit at a command line and type only "avr-gcc -mmcu=at<something> -Os avr.c -o avr.elf" that will build a program that uses "tight" toggling code so I'm still a little perplexed by the extensive settings claim. perhaps that original "joke" about GCC optimisation wasn't a joke at all and OP simply does not understand how to drive GCC? While it still cannot claim to be as good as IAR I would say the code generation model is no as "tight" as just about any other choice of C compiler for AVR. Especially with G-J's changes going into v8.x

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

but I tried this 

/*
 * GccApplication18.c
 *
 * Created: 27-07-2017 14:57:59
 * Author : Admin
 */ 

#include <avr/io.h>


int main(void)
{
    /* Replace with your application code */
	DDRB=0x01;
    while (1) 
    {
        PINB=0x01;
    }
}

to toggle one a mega328 (would be same on 168), and it's 2 lines of code I wrote, and it can't be done faster then the output code:

int main(void)
{
    /* Replace with your application code */
	DDRB=0x01;
  cc:	81 e0       	ldi	r24, 0x01	; 1
  ce:	84 b9       	out	0x04, r24	; 4
    while (1) 
    {
        PINB=0x01;
  d0:	83 b9       	out	0x03, r24	; 3
  d2:	fe cf       	rjmp	.-4      	; 0xd0 <main+0x4>

everything is default  

 

And it took less than 5 minutes, from start (created a new project) to single step the ASM output code!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sparrow2 wrote:
it can't be done faster then the output code

With "manual" toggle code, indeed I can't see better.  clk/6 frequency, right?

 

clk/2 can be had with timer CTC mode.  Would require two more setup lines for the A and B timer control registers, and an empty loop [optional].

 

Xmega, and most Cortex I've had a pee at, have an "OUTTOGGLE" register or equivalent.  Should be able to get similar performance, so I don't know exactly where the "hard to toggle" is coming from.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Can I take you back to this in #15 (a lot of posts ago)...

jaycarlson wrote:
As for compilers, I would not call AVR-GCC "high quality" — I would call it completely average, when compared to other platforms and compilers I've tested so far. Without the optimizer on, it produces fairly mediocre code (a bit-set operation was compiled into 9 instructions, in my testing), and with the optimizer configured to do anything useful, the code is very difficult to debug — I'm often forced to use assembly breakpoints, as Atmel Studio can't seem to figure out what I'm trying to do.

Clearly rubbish or a joke but maybe not? OP doesn't seem to know how to operate GCC if he thinks it would ever be relevant to run without optimizer!!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Xmega, and most Cortex I've had a pee at, ... 

Freudian slip there, Lee?

 

JC 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

DocJC wrote:
Freudian slip there, Lee?

lol.  And here I just got done laughing at http://www.avrfreaks.net/comment...

Paulvdh wrote:

 back off ass fast as possible

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

Tell us more about the extensive settings needed for avr-gcc when toggling a pin?

  • With the optimizer off, GCC (on AVR, ARM, or RL78) doesn't seem to know what SFRs are — it treats everything as 16-bit memory, with multiple instructions for indirect accesses. No other compiler I've tested so far does this.
  • With the optimizer set to -O1 or -Os, AVR-GCC begins treating SFRs as SFRs (with "in" and "out" instructions), but GCC's RL78 backend did not — in fact, it *never* understood SFR memory. I tried many, many settings, to no avail.
  • With the optimizer turned on at all in AVR-GCC, many of my breakpoints stopped working, and temp variables are immediately compiled out. I tried many different combinations of "Debug level" and "Optimization level" settings in Atmel Studio, but I could never get perfect debugging along with actual register manipulation. Please help if you have suggestions — seriously! Maybe this is more the Atmel Studio debugger's fault instead of avr-gcc, but I'm sort of referring to the toolchain as a whole when talking about AVR-GCC (sorry if this offends you). At the end of the day, other compilers/toolchains didn't have this problem.

 

clawson wrote:

Clearly rubbish or a joke but maybe not? OP doesn't seem to know how to operate GCC if he thinks it would ever be relevant to run without optimizer!!

I have no problem turning on the optimizer, but I need basic breakpoints to work, too. Even when I have the optimizer cranked all the way up in most environments, breakpoints still work (though variable watches don't). I understand if a variable gets optimized out (that's fine), but to get basic breakpoints working, I end up having to read through the assembly listing (which is not as easily-accessible as in other IDEs), and set assembly breakpoints instead of C breakpoints.

 

None of this is the end of the world. I get that. GCC is perfectly fine — and I will gladly continue using it when working on AVR projects. But the whole point of this project is to compare what's out there, and compared to the other compilers I've tested on these different MCU platforms, I'd call it completely average. That was all I was saying.

 

If you want me to say something nice about AVR-GCC specifically, I will say that it's much better than the RL78's GCC implementation. Will you get off my back now?

Last Edited: Fri. Jul 28, 2017 - 12:48 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jaycarlson wrote:

I think you would be blown away by the Silicon Labs EFM8 stuff. Three-stage pipelined architecture, running up to 72 MHz. None of this old-school 12-cycle-machine-clock rubbish; this is a single-cycle machine that, clock-for-clock, matches the TinyAVR closely (not going to say more until I finish testing!)

 

I have some sitting on the bench back home and one of the first jobs when I get back from holiday is to run them up and do some tests.

 

They are certainly very different to the 12T 12MHz parts I first used last century. On raw MIPS they will be no slouch when compared to the AVR; I just wonder what they will be like in the real world when the lack of modern 'compiler-friendly' features starts to bite. The early design decisions made by Atmel, as documented in the PDF which gets linked to from time to time, along with their collaboration with the compiler writers has yielded a vert capable 8-bitter which seems remarkably unconstrained unlike some other chips.

'This forum helps those who help themselves.'

 

pragmatic  adjective dealing with things sensibly and realistically in a way that is based on practical rather than theoretical consideration.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

for debugging use -Og for the optimizer!

 

If you want ok code, in the order you write.

 

And it's a problem for a (good) compiler to make a breakpoint if your code don't exist any more because it don't do anything.

 

For small test programs make sure that make "key" variables volatile or something like that, if not GCC will not generate any code because it's not used for anything!  

 

Add:

Perhaps show some code where you don't like the GCC's way of compile/debug.

Last Edited: Fri. Jul 28, 2017 - 02:58 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sparrow2 wrote:

 

for debugging use -Og for the optimizer!

If you want ok code, in the order you write.

And it's a problem for a (good) compiler to make a breakpoint if your code don't exist any more because it don't do anything.

For small test programs make sure that make "key" variables volatile or something like that, if not GCC will not generate any code because it's not used for anything!  

Thanks for the good tips, but I'm well aware of all of these -- and none of them address what I'm saying: AVR-GCC doesn't use register accesses when the optimizer off, but as soon as you switch the optimizer on any level at all, breakpoints can start being problematic.

 

I'm not in front of AVR Studio right now, but I believe I've got a pathological case to illustrate what I'm saying:

while(1) {
    DDRB ^= 1;
}

With the optimizer off, that single line of code will get compiled to a single instruction to write the immediate value "1" to a register (used as the xor argument), followed by 3 or 4 instructions to do an indirect fetch from 16-bit memory, an xor operation, and another 3 or 4 instructions to do an indirect write back to 16-bit memory, followed by a jump. No "out" or "in" instructions will be present, even though we're obviously dealing with SFRs.

 

Alright, that's crap, so let's turn the optimizer on any setting -- -Og, -O1, whatever -- and if you recompile, those gross 4-instruction memory fetches turns into a single "in" instruction and a single "out" instruction. Atmel knows this is how you have to use AVR-GCC, so they make -O1 the default option. However, if I try to set a breakpoint on the DDRB toggle line, it will fire ONCE when the program starts, but never fire again. Why? Because they breakpoint is getting set on the single "load value 1" register call that happens outside the loop (since the optimizer is on!).

 

Again, I know perfectly well how to deal with this. You can go to the assembly view and set the break point on the "in" instruction. But this would be easier if AVR-GCC always used "in" and "out" instructions when doing register operations, even with the optimizer off. No other compiler considers these "optimizations"

 

That was the only point I was trying to make when I said "I find GCC completely average" when compared to everything else out there. It's certainly not "the best" and it's certainly not "the worst" -- and if you know how it works, you can use it to efficiently generate AVR code; but it takes a bit more "thinking" than other compilers do.

Last Edited: Fri. Jul 28, 2017 - 04:30 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Brian Fairchild wrote:

 

I just wonder what they will be like in the real world when the lack of modern 'compiler-friendly' features starts to bite. The early design decisions made by Atmel, as documented in the PDF which gets linked to from time to time, along with their collaboration with the compiler writers has yielded a vert capable 8-bitter which seems remarkably unconstrained unlike some other chips.

I think RISC cores with lots of registers were seen as the "modern, compiler-friendly" architecture when AVR designed it way back when, but -- and I'm not trying to start a flame war -- more CISC-ish cores seem like they ultimately came out ahead, since compilers started getting more and more advanced. It's much easier to write a compiler for AVR than for 8051, however, there are compilers that work equally well for both of them.

 

Note that there are a few... uhh... eccentricities that you have to deal with. For performance reasons, Keil passes parameters to functions using predefined registers, not stacks, so Keil will throw a warning if you call a function from within itself (though you can append "reentrant" to the function declaration to force Keil to use a different strategy for passing values that is safe for re-entrant functions).

 

I think the biggest one for beginners that even modern compilers don't try to solve for you is the RAM vs XRAM thing. A compiler can be instructed to assume all variables go in either RAM or XRAM, but you'll still find yourself specifying this manually. Or you can just put everything in XDATA and not care about squeezing out performance. My 16-bit signed biquad filter performance tests of the Nuvoton N76 (an 8051-derivative) produced I think 35 ksps when the buffers are in XRAM and 40 ksps when the buffers are in RAM. Huge difference, but it's not, like, you know TEN TIMES or something insane like that.

 

I agree AVR is a good architecture. But for it to be "unconstrained" when compared to, i.e., the EFM8 stuff, I'd like to see it with a 72 MHz core clock and an internal LDO to allow a much smaller process with a 1.8V core. Again, clock for clock, they're about the same -- but on AVR, you hit that 20 MHz speedbump pretty quickly (and that's assuming you want to drop a crystal into your design that could cost nearly half as much as the MCU itself!)

 

So yeah, there's other things at work than just the core architecture design.

Last Edited: Fri. Jul 28, 2017 - 04:51 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

for the 8051 the keil invented a 3 byte pointer, so all memory can be reached, don't they have that any more ?  

 

to be ANSI C the code need to be reentrant, if not it's cheating, and my guess is that you can force the GCC to do the same.(I remember some 8051 code where I had to have some double library routines so main and ISR could do the same things (that was the BSO compiler))

 

a limit of 20 MHz , then there are all the xmegas with 32MHz but I guess that they start at around $2, and they have dma controller, faster ADC etc. (take a look at something like a ATXMEGA32E5 for $2.06 @100 at digikey), and the good thing is same tool. (and it run 32MHz from internal clk.)

 

about crystal for 20MHz yes it's sad, the chips used to be able to run 20MHz from a $0.15 crystal, but some of the newer chips don't do that :(

 

speed compared between 8051 and AVR, I would say that (single clk)8051 is in general faster(at same clk speed) if you can stay inside the 256 byte RAM, where the AVR don't have any penalty for more RAM, and there it's normally faster.

 

But all this said normally I used to say if it's only for the price, a AVR is only a contender if you need EEPROM, but for normal small numbers your developing speeds means more than the chip price.

And the good thing is that the same compiler/tool handle AVR's from 1/2 Kbyte flash upto 512Kbyte(perhaps there is a bigger out now)  

 

 

 

 

 

 

Last Edited: Fri. Jul 28, 2017 - 08:05 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sparrow2 wrote:

for the 8051 the keil invented a 3 byte pointer, so all memory can be reached, don't they have that any more?

Yup, they do. I'm impressed you know that detail! It's called a "generic pointer" — Keil does automatic conversion between pointer memory spaces for you, but it obviously can require extra instructions. Functionally, though, it's completely transparent to the user.

 

sparrow2 wrote:

to be ANSI C the code need to be reentrant, if not it's cheating, and my guess is that you can force the GCC to do the same.

Yeah, like I said, Keil can generate reentrant-capable functions if you decorate the function declaration appropriately, but if a function doesn't need to be reentrant, you save a few cycles by leaving it default (non-reentrant)

 

sparrow2 wrote:

then there are all the xmegas with 32MHz but I guess that they start at around $2, and they have dma controller, faster ADC etc. (take a look at something like a ATXMEGA32E5 for $2.06 @100 at digikey), and the good thing is same tool. (and it run 32MHz from internal clk.)

Yeah! I'll probably buy an Xmega at some point to play with, but not for this review. I'm curious where you think they fit into the world, in 2017, with all the Cortex-M0 stuff Atmel is doing? The SAM D10, a 48 MHz modern part, is significantly cheaper than a mega168pb, and has similar capabilities. 

sparrow2 wrote:

speed compared between 8051 and AVR, I would say that (single clk)8051 is in general faster(at same clk speed) if you can stay inside the 256 byte RAM, where the AVR don't have any penalty for more RAM, and there it's normally faster.

Yup, you got it. With Silicon Labs' pipelined cores, the number of clock cycles an instruction takes is simply equal to the number of bytes long the instruction is (minus conditional branches). You have essentially three levels of granularity on the 8051 -- registers, "scratchpad" RAM, and XRAM, so MOV and math operations can take 1, 2 or 3 clock cycles, depending what you're operating on (gross simplification, but useful way of thinking about things, in my opinion).

Last Edited: Fri. Jul 28, 2017 - 09:29 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yup, you got it. With Silicon Labs' pipelined cores, the number of clock cycles an instruction takes is simply equal to the number of bytes long the instruction is (minus conditional branches). You have essentially three levels of granularity on the 8051 -- registers, "scratchpad" RAM, and XRAM, so MOV and math operations can take 1, 2 or 3 clock cycles, depending what you're operating on (gross simplification, but useful way of thinking about things, in my opinion).

On a 8051 I would divide the internal RAM into two parts lower 128 byte and high 128 bytes (unless you reserve the high 128 as stack only)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jaycarlson wrote:

sparrow2 wrote:

speed compared between 8051 and AVR, I would say that (single clk)8051 is in general faster(at same clk speed) if you can stay inside the 256 byte RAM, where the AVR don't have any penalty for more RAM, and there it's normally faster.

Yup, you got it. With Silicon Labs' pipelined cores, the number of clock cycles an instruction takes is simply equal to the number of bytes long the instruction is (minus conditional branches). You have essentially three levels of granularity on the 8051 -- registers, "scratchpad" RAM, and XRAM, so MOV and math operations can take 1, 2 or 3 clock cycles, depending what you're operating on (gross simplification, but useful way of thinking about things, in my opinion).

There is some spread in the 'faster' bands.

8051 has boolean opcodes, interrupt priority and register bank switching, and can DJNZ on any DATA memory location - code that uses those features, benefits

AVR has some 16b-data opcodes and better pointer operations, so code that uses those can look better.

The biggest difference is AVR tops out at 16-20MHz at 5V, but lower MHz at lower Vcc. 8051 top out at 72MHz(LB1) at 3v, or 25~33MHz at 2.2~5.5V for other vendors.

 

The SiLabs series have what is effectively a fractional baud UART, even on the smallest parts, so peripherals can make a difference.

 

jaycarlson wrote:

 With Silicon Labs' pipelined cores, the number of clock cycles an instruction takes is simply equal to the number of bytes long the instruction is (minus conditional branches). 

Most 1T 8051's have at least some 1 byte 1 cycle opcodes, in the better ones nearly all 1 byte opcodes are 1 cycle.

The new STC8F makes quite a leap, into a 24b opcode fetch, which means all opcodes (1,2 or 3 byte) can have a 1 cycle base - eg bit/push/pop & mov dir,dir are now all 1 cycle instructions.

 

Last Edited: Fri. Jul 28, 2017 - 10:46 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Who-me wrote:

The new STC8F makes quite a leap, into a 24b opcode fetch, which means all opcodes (1,2 or 3 byte) can have a 1 cycle base - eg bit/push/pop & mov dir,dir are now all 1 cycle instructions.

I ordered some from Taobao. Not sure when/if they're going to ship (seller seems a bit funny). Can't track down an English datasheet. If you have any leads, let me know!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jaycarlson wrote:

Who-me wrote:

The new STC8F makes quite a leap, into a 24b opcode fetch, which means all opcodes (1,2 or 3 byte) can have a 1 cycle base - eg bit/push/pop & mov dir,dir are now all 1 cycle instructions.

I ordered some from Taobao. Not sure when/if they're going to ship (seller seems a bit funny). Can't track down an English datasheet. If you have any leads, let me know!

Did you order parts, or the Eval modules ? Taobao seems to have a few simple break-out boards, in the Y35~39 region, that could be fine for testing.

Look to use a STC8A8K64S4A12 LQFP64S.  Ones from a vendor called GEEK+ seem to have 2017 parts ?

A few tag CH340 USB-UARTS, but only one has a visible crystal, another has PADS for Xtal/Caps, but not fitted - maybe there is a Xtal-less CH340 variant now ?

I thought all CH340 needed a crystal, and I quite like crystals on Eval Boards, as it gives BAUD a high precision, allowing RC Osc calibrate checks.

 

I've used the older 1T STC15 parts, but re the new STC8, I've been waiting a little until the errata settles down...

http://www.stcmcu.com/sample-req...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

One thing is that push and pop etc is one clk, but with a limited stack size on a 8051 you have some challenges!

What is the real stack used for on the keil ? (just return, or also parameters, and what about local variables)

 

It's would not be fair for the AVR if the 8051 can use a faste model for test that won't work on a real application with more code! (read more RAM use).  

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sparrow2 wrote:

One thing is that push and pop etc is one clk, but with a limited stack size on a 8051 you have some challenges!

The 8051 uses register bank switching for interrupts, so Stack is usually for call/return. Params can be passed in registers.

The Atmel AT89LP51Rx2 series added an extended stack option, to place Stack into XDATA, and so that frees all of DATA/IDATA for user variables, but that is somewhat rare.

(it also means some side-door stack access is not so easy).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

it's more important where Keil place local variables! if it's not a stack it can't be reentrant!   

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sparrow2 wrote:

it's more important where Keil place local variables! if it's not a stack it can't be reentrant!   

And as I said, Keil's C51 compiler does not generate reentrant functions unless you explicitly ask it to (by decorating the function with the "reentrant" keyword). Locals end up in registers, until Keil runs out of space, and then it starts using RAM.

Last Edited: Sun. Jul 30, 2017 - 04:43 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So I will just say that isn't fair for the AVR, and to be harsh, that is like a C compiler competing with ASM written with C syntax. devil 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sparrow2 wrote:

So I will just say that isn't fair for the AVR, and to be harsh, that is like a C compiler competing with ASM written with C syntax. devil 

I hear you. I wouldn't call it "fair" or "unfair" — just different strengths and weaknesses based on different design choices. I get what you're saying about the "competing with ASM written with C syntax" but it's really just that the developer needs to have more thorough understanding of the memory model of the platform, which you don't need for AVR. That's what made AVR look very elegant when it was introduced. For what it's worth, I've had to use reentrant functions precisely once in the three or four commercial projects I've done on 8051s, and it's easily accomplished by adding the "reentrant" keyword to your function. Keil will throw a warning (though not an error, oddly!) if you forget this. Annoying, but workable. Generally, you don't need to know what's going on under the hood, unless you really care.

 

When you declare global variables without decorating them, they'll go in whichever memory space is "default" for for your memory model. Keil's "small" model places variables in RAM by default, while the "large" model places variables in XRAM by default, freeing your precious 128-bytes of RAM for locals and other stuff you need to optimize a bit. You can always override where variables are stored with the "xdata" or "data" keywords (horrible, horrible keywords — to this day, I always do a double-take when I get a weird compiler error thrown by a "void myFunction(uint8_t data)" declaration).

 

This stuff doesn't bother me as much as the 128-byte SFR limit, which is pretty easy to hit on modern MCUs with tons of peripherals. Manufacturers often use paging (sort of like bank-select statements in PIC), but unlike Microchip's XC8 compiler, Keil doesn't automatically generate SFR page select instructions, so if your Timer1 starts acting up when you try to enable Timer5, chances are you forgot to switch pages. That's a huge trap for new guys that's really annoying. Other manufacturers do all sorts of weird stuff — STC is the biggest offender in the "strange hacks" realm: they maintain Timer0/Timer1 compatibility with classic 8051 MCUs, but they turn them into auto-reload ("period") timers by putting a "hidden" reload register, aliased with the timer's value register, that's only accessible when the timer is in 13-bit mode, and stopped. It's clever, but pretty gross. They also quickly ran out of SFRs with their 6-channel 16-bit arbitrary-phase PWM module (which has almost 30 registers for configuration!), so they just gave up and dumped the whole peripheral into the end of XRAM somewhere. Hey, what do you want for a buck? wink

Last Edited: Sun. Jul 30, 2017 - 05:49 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This is a strange thread, growing fast & long

I'll also throw in a few cents in #127.

 

Just searched for "microcontroller" on octopart and ordered by price:

https://octopart.com/search?q=mi...

 

Most of the cheapest are "microcontrollor supervisory circuits"

But the first page also has a 100 or so pin device from rochester ??? Probably a typo ???

https://octopart.com/sak-xc2364a...

 

On page 11 it's getting serious with an attiny9 for 27ct

https://octopart.com/search?&q=m...

 

And on page 99 (the end) we're still at 60 cent or so, so that's 900 different uC's to choose from.

https://octopart.com/search?&q=m...

 

Paul van der Hoeven.
Bunch of old projects with AVR's:
http://www.hoevendesign.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Paulvdh wrote:

This is a strange thread, growing fast & long

I'll also throw in a few cents in #127.

Please do!

 

Paulvdh wrote:

Just searched for "microcontroller" on octopart and ordered by price:

https://octopart.com/search?q=mi...

Good idea. I stumbled upon some lower-price LC87 microcontrollers; these were originally Sanyo parts, but it looks like ON Semiconductor acquired them. Looks like Micah Scott was able to dump the LC87 firmware used on a Wacom tablet, but otherwise, I had never heard of them.

 

Trying to get a dev kit ordered as we speak! I sure do love me some strange microcontrollers....

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

By the way, these new Tinys are a substantial improvement over the previous-generation ones I was using. PDI (UPDI? Whats the difference?) feels like a normal debug interface now — no more switching back and forth between debugWIRE and weird ICSP mode to burn fuses. Also, it's nice to see much of the clock configuration done at run-time instead of with fuses. Really brings the platform in-line with other products.

 

I didn't realize how different the peripherals were, too? Even the GPIO port structure is completely different. Registers are grouped as offsets-from-base-addresses, just like how most ARM peripherals work, which I've never seen on an 8-bit MCU: 

PORTB.DIRSET = 1; // set B0 as an output
PORTB.OUTSET = 1; // set B0
PORTB.OUTTGL = 1; // toggle B0
PORTB.OUTCLR = 1; // clear B0

Interesting to see separate SET and CLR registers — I thought AVR always had a set-bit/clear-bit instruction, so I'm not sure why this was done? Anyone have insight into this? By the way, no, these are not preprocessor trickery — these are individual registers.

 

Sorry if this is super old news to everyone, but I think it's interesting to see such dramatic changes in a family, and I'd love to hear any background information, if anyone has any details?

Last Edited: Tue. Aug 1, 2017 - 03:44 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

IIRC the new tiny's are based more on XMEGA - did you look at how they do things ?

The AVR does have Set/Clr bit opcodes, but of quite limited reach - the usual trade off of reach vs size applies to all MCUs

The SET CLR register approach is more general, but likely needs larger code.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Registers are grouped as offsets-from-base-addresses, just like how most ARM peripherals work, which I've never seen on an 8-bit MCU: 

XMEGA, from the beginning.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jaycarlson wrote:
PDI (UPDI? Whats the difference?) ...
PDI can be via a USART whereas UPDI can be via a UART (synchronous vs self-clocking)

LUFA AVRISP2 is on a USB megaAVR to program XMEGA PDI.

Currently, UPDI is only via Atmel-ICE, JTAGICE3, EDBG, mEDBG, or a USB UART bridge; might not take much to add UPDI to LUFA AVRISP2.

jaycarlson wrote:
... I think it's interesting to see such dramatic changes in a family, and I'd love to hear any background information, if anyone has any details?
Possibly in

http://www.avrfreaks.net/forum/attiny417-attiny814-attiny816-attiny817

 


LUFA

AVRISP-MKII Clone (2010)

http://www.fourwalledcubicle.com/AVRISP.php

http://www.avrfreaks.net/forum/attiny417-attiny814-attiny816-attiny817?page=4#comment-2147276 (UPDI via USB UART bridge)

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jaycarlson wrote:
I thought AVR always had a set-bit/clear-bit instruction, so I'm not sure why this was done?
Atomicity. (no RMWs)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I don't think SBI & CBI have a RMW issue (such as you'd see in the old PIC ports)...if you SBI a bit, that bit gets set to 1 & the others will be unaffected

I seem to remember some discussion regarding automatically clearing bits (such as IRQ flags) potentially being an issue, but can't find now.  The new instructions let you set (or clear) multiple bits at once--a great convenience.

 

...I found this old comparison between pics & avr:

 

I/O
Seperate PORT and PIN registers avoid read-modify-write issues with capacitively loaded pins. (Although has any AVR user never spent time wondering why their input port isn't working because they used PORTx instead of PINx...? ).

When in the dark remember-the future looks brighter than ever.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jaycarlson wrote:
! I sure do love me some strange microcontrollers....

Sometimes, when I'm really bored I watch EEVBlog.

A long time ago he took a toothbrush apart.

In it was  a small probably 6 legged device.

After a bit of researching he found out it was a 4-bit uC which was not available from any store (I believe) but only directly from the manufacturer

(Probably in minimum quantities of half a million or so).

 

What's a toothbrush got to do?

On/of button and a 2 minute timer?

Maybe it was also connected to the battery charging circuit.

 

Note:

About the strangeness of this thread:

This is #135 and #4 was marked as "the solution" :)

 

Paul van der Hoeven.
Bunch of old projects with AVR's:
http://www.hoevendesign.com

Last Edited: Tue. Aug 1, 2017 - 02:01 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

About the strangeness of this thread:

This is #135 and #4 was marked as "the solution" :)

Strange?  That's pretty typical around here...

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

About the strangeness of this thread:

This is #135 and #4 was marked as "the solution" :)

Strange?  That's pretty typical around here...

"We sell solutions, not answers" is today's mantra. 

When in the dark remember-the future looks brighter than ever.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avrcandies wrote:
I don't think SBI & CBI have a RMW issue (such as you'd see in the old PIC ports)...if you SBI a bit, that bit gets set to 1 & the others will be unaffected I seem to remember some discussion regarding automatically clearing bits (such as IRQ flags) potentially being an issue, but can't find now. The new instructions let you set (or clear) multiple bits at once--a great convenience.

 

I will just quote from a typical AVR datasheet:

Alternatively, ADIF is cleared by writing a logical one to the flag. Beware that if doing a Read-Modify-Write on ADCSRA, a pending interrupt can be disabled. This also applies if the SBI and CBI instructions are used.

 (emphasis mine)

 

This means SBI/CBI read the whole byte, not just the one that is modified. This can have side effects, normally on interrupt flags.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

an interesting post from the past:

 

It's even more insidious than simply the sequence "IN ... ORI ... OUT" being non-atomic. (In fact, the specific example that Boxbourne gave is actually inaccurate, since most interrupt flags actually cannot be cleared by accidentally writing a "0" to them...)

In the AVR architecture, 32 of the I/O registers are directly bit-addressable. You can set and clear bits, as well as do some level of conditional branching, based entirely on the state of individual bits within the first 32 I/O registers. Bit setting and clearing on these 32 registers can happen in a single, atomic instruction, using the SBI and CBI op-codes.

But on most AVR's (the devices which are exceptions to this rule have notes in the Register Summary section of the datasheet), even these so-called bitwise operations actually operate on the whole register, even if only one bit is being changed. In a single instruction cycle (two clocks in this case), the whole I/O register is read into a scratch space, a single bit is modified, and the whole scratch register is written out to the I/O register again.

If at the point that the register was read in, there was an interrupt flag set, then that flag will be copied into the scratch space. Then the single bit will be modified. Then, the whole scratch space, including the interrupt flag, will be copied back into the I/O register. Writing a '1' to an interrupt flag generally causes that flag to be cleared, and thus you lose an interrupt. Even if you did it atomically.

Some AVR's have "fixed" the SBI/CBI op-code so that they truly only operate on single bits without any possibility of affecting the surrounding bits within the register.

..... hmmmm which ones?

When in the dark remember-the future looks brighter than ever.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I would guess that AVR cores where SBI/CBI takes just 1 cycle do not have the RMW problem. That would be xmega and AVR8L (like ATtiny 10).

 

Edit: And the new "Xtiny" like the tiny 817.

Last Edited: Tue. Aug 1, 2017 - 11:45 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This means SBI/CBI read the whole byte, not just the one that is modified. This can have side effects, normally on interrupt flags.

In modern AVR, SBI/CBI touch only one bit in the target SFR.  No other bits are affected.  Anything introduced in the last 10 years.  Older AVR cores were subject to RMW effects for the CBI/SBI instructions, including (I believe) the m16.

 

The quoted datasheet excerpt likely is a copy/paste error.  I don't know if there's an authoritative list of which AVRs handle CBI/SBI as RMW.  If there is one, I'd like to know.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avrcandies wrote:
The new instructions let you set (or clear) multiple bits at once-
Atomically - that was my point.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

SBI / CBI ?

 

Some time ago I dipped a part of my littlest pinky toe in the ARM world. (STM32F103C8T6)

It's a 32 bit processor but the I/O structure (timers, etc) is apparently mostly 16 bit.

It does not have and instruction to set or clear an I/O bit but instead it has a 32 bit Set/Clear I/O registers, one for each 16 bit port.

If you write a 32 bit value to that port. Then all the zero's in that value leave the I/O bits unchanged. The one's in that 32-bit value either set or reset the corresponding bit on the corresponding output port.

So with a single asm instruction for a regular port write you can set or reset anything from zero to all bits in the output port without touching bits which should not be touched. Single instruction, same CPU cycle, intrinsic atomicity (is that a word, it sure is a combo of 9 letters).

Neat feature.

 

I'm not sure what happens when both the set and reset bits are written to. I think it would toggle the output bit, but I'm not sure.

Paul van der Hoeven.
Bunch of old projects with AVR's:
http://www.hoevendesign.com

Last Edited: Wed. Aug 2, 2017 - 11:29 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Go on. ARM7TDMI had steering registers before the minellium. Xmega has had steering registers since 2007.
Your STM32F103 is vintage 2007. The new Tiny817 has got steering registers.
.
Oh, and the M3 STM32F103 is trashed by the Cortex-M4.
The actual GPIO performance depends on the actual PORT Silicon. The Xmega trashes M0 and a lot of M3.
.
David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@OP

 

Have you seen...

 

https://dannyelectronics.wordpre...

 

...?

 

If you go back over several months you'll find various blogs on benchmarking various chip families.

'This forum helps those who help themselves.'

 

pragmatic  adjective dealing with things sensibly and realistically in a way that is based on practical rather than theoretical consideration.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@david.prentice

 

And what's your point?

I didn't even hint at I/O performance, dates or a trashing contests and I haven't got a clue what a steering register is.

The only thing I pointed out is that the ..F103... has a different I/O structure and it has an inherent ability to set/reset multible bits on an I/O port atomically.

Paul van der Hoeven.
Bunch of old projects with AVR's:
http://www.hoevendesign.com

Last Edited: Wed. Aug 2, 2017 - 01:43 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Steering register is the name given to this mechanism. i.e. setting a bit, clearing a bit without the delay and atomicity difficulty of RMW.
My point was that this is nothing new. And the STM32F103 is a mature chip.
Furthermore, the Xmega is a similar vintage with similar mechanism and better GPIO performance.
Of course the 32-bit ARM core has a faster processing throughput.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I haven't got a clue what a steering register is.

Allows the peripherals to be mapped to different pins, rather than fixed.  Also allows 20 different functions in an 8 pin part, but you can only choose to use 4 of the 20 (: 

 

for example:

Datasheet PIC16F887 - DS41291F page 146.

11.6.7 PULSE STEERING MODE

In Single Output mode, pulse
steering allows any of the PWM pins to be the modulated signal. Additionally, the same PWM signal can be simultaneously available on multiple pins.

 

Once the self-driving AVRs are introduced, the steering register may take on a new meaning.

When in the dark remember-the future looks brighter than ever.

Last Edited: Wed. Aug 2, 2017 - 02:49 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Perhaps I have been using the wrong terminology.

 

I have always called Freescale PCOR, ST BSRR, Xmega OUTCLR registers "IO steering" registers.

And pin-mapping registers like ST MAPR register "mapping" registers.

 

Microcontrollers have always had "Alternate Functions" on particular pins.   It is fairly recent ( < 15 years)  to move a specific function to a different pin.

It makes life easier in some respects.   But it does mean you can't always assume that a physical pin is always using its default functionality.

 

David.

Last Edited: Wed. Aug 2, 2017 - 02:52 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ah, so that is the "steering" part.

Triggers a memory about a story floating on (or sunk deep into) the 'net.

It was about a uC occasionallly losing bits in it's I/O configuration registers. The whole uC (or FPGA?) kept running happily, just some outputs stopped outputting the right signals untill the uC got a hardware reset. Then it worked all perfectly for a while, so no hardware pins blown, but the problem kept recurring.

The likely culprit was probably marginal decoupling / emc design, whatever but investigating and PCB revisions take time.

 

So as a (temporary) solution they put the whole I/O configuration in flash and used a periodic interrupt to rewrite it to the I/O ports.

 

 

Paul van der Hoeven.
Bunch of old projects with AVR's:
http://www.hoevendesign.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Gotta watch those weak bits....long ago, during college a student built a pretty neat "robot" & was giving a demo to the campus reporter, who was taking a bunch of up close action photos.  Apparently the camera flash disrupted a few EPROM program bits, giving the robot a serious case of spasms, nearly tearing itself apart. 

When in the dark remember-the future looks brighter than ever.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Paulvdh wrote:

Some time ago I dipped a part of my littlest pinky toe in the ARM world. (STM32F103C8T6)

It's a 32 bit processor but the I/O structure (timers, etc) is apparently mostly 16 bit.

That's one of my pet peeves with some ARMs. I cannot see the sense in a 32b MCU, with 16b Timers ?

Some 8b MCUs even allow Timer cascade to 32b, such is the demand for the better dynamic range/precision.

 

NXP 'gets this' & have (IIRC) 32b timers and 32b prescalers, and Nuvoton are close, with 24b timers.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Paulvdh wrote:

Ah, so that is the "steering" part.

Triggers a memory about a story floating on (or sunk deep into) the 'net.

It was about a uC occasionallly losing bits in it's I/O configuration registers. The whole uC (or FPGA?) kept running happily, just some outputs stopped outputting the right signals untill the uC got a hardware reset. Then it worked all perfectly for a while, so no hardware pins blown, but the problem kept recurring.

The likely culprit was probably marginal decoupling / emc design, whatever but investigating and PCB revisions take time.

 

So as a (temporary) solution they put the whole I/O configuration in flash and used a periodic interrupt to rewrite it to the I/O ports.

That's more common than you realize, and is somewhat standard ESD hardening. Always a good idea to 'refresh the config', where practical.

 

Worse was the part where we found Reset was more of a 'Reset Request', and it could disable under ESD stress tests - outcome was a Power Removal watchdog design, that I'm surprised is not seen much.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 2

In case anyone was wondering if I ever got around to finishing this write-up, the answer is "Yes! Finally!"

 

Check out The Amazing $1 Microcontroller on my blog.

 

It took several months of on- and off-again work, but I got through all 21 parts I selected.

 

I'd like to thank everyone on this thread for their help --- I got steered in the right direction toward the new tinyAVR 1-Series (which pulled in some impressive performance), and I also got some suggestions for other parts that ended up getting included, too.

 

If there are things you think need to be mentioned that I'm forgetting, please drop a line on this thread (or, shamelessly plugging my blog, as a comment on this post smiley)

 

Thanks again for the wonderful discussions!

Last Edited: Mon. Nov 6, 2017 - 07:12 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Wow ... and that's from only a skim.

Plan is to put a comment onto that web page "soon"

Thanks for the follow-up.

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Jay, a stunning roundup of the chips and the oft ignored tools. This must have taken you some time. I'm glad you investigated some of the more obscure parts that, whilst I'd heard of, have never really appeared on my radar.

 

A couple of comments - the PIC16 series aren't RISC - they are accumulator based, not single cycle and not load/store. Microchip grabbed the moniker and repurposed it for their own ends.
One thing I found missing was the voltage range of the various devices - the M051 and XMC1100 for example are 5 volt parts which for ARM ('arm') based parts sorta sets them apart.

 

As for using Arduino shields, I have used the prototype ones ( the ones with lots of holes) to build up some test hardware for the XMC1100 and STM32 parts. I've even used used one with a small solderless breadboard on top for some quick prototyping.

 

Great work.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:

the PIC16 series aren't RISC - they are accumulator based, not single cycle and not load/store. Microchip grabbed the moniker and repurposed it for their own ends.

Thanks for the comment --- RISC is a loaded term (as you can imagine), so I've added additional clarity to explain that while it is RISC in the sense that each instruction is precisely one word long and executes in a single cycle (unlike CISC parts like the 8051), it is *also* an accumulator-based architecture, which is quite different than most RISC parts. I hope you think this change makes the information more useful.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just thought I'd let you know: Your navigation pane does not behave well on smallish screens. The bottom of it is off the screen and it is not scroll'able. Only if I zoom out to about 70% can I see the whole navigation pane. At 100% the last visible entry is "Dev Tools".

 

Chromium Version 59.0.3071.109 , display is 1366 x 768.

"He used to carry his guitar in a gunny sack, or sit beneath the tree by the railroad track. Oh the engineers would see him sitting in the shade, Strumming with the rhythm that the drivers made. People passing by, they would stop and say, "Oh, my, what that little country boy could play!" [Chuck Berry]

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JohanEkdahl wrote:

Just thought I'd let you know: Your navigation pane does not behave well on smallish screens. The bottom of it is off the screen and it is not scroll'able. Only if I zoom out to about 70% can I see the whole navigation pane. At 100% the last visible entry is "Dev Tools".

Good call — I will fix this as soon as traffic calms down (I can't even get a login page).

 

EDIT: No quick fix, other than removing content, unfortunately. I'll look at some core CSS changes I can make long-term to shrink that down, but there's a lot of dependencies I'll have to work through. Sorry about the inconvenience!

 

By the way, for people who tried visiting earlier and got 503'd, I've made some changes to my network configuration, and I think the site should be back up for most users.

 

I'll save you the scrolling: https://jaycarlson.net/microcont...

Last Edited: Mon. Nov 6, 2017 - 11:15 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This is a superb reviewyes. Thanks for keeping us posted.

 

It's amazing what you get for < $1 these days.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I will say one error in the notes is that the AVR have a flat ISR, the new tiny's (tiny1616 was the one you picked), have a two level.

 

Now since it a relativ new chip I'm not sure if the Compiler support it.

 

And then it's not clear when you run 10MHz and when 20MHz on the AVR, (And find it a bit funny that you have to trick your 5V device to run 3.3V :D )

 

I don'e see that you have a 3v3 volt rule.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

https://jaycarlson.net/microcont...

Comments

 

AVR
1. "And interrupts are one of the weak points of the AVR core: there’s only one interrupt priority, ..."
   tinyAVR 1-series has two interrupt priority levels (datasheet, CPUINT)
2. like megaAVR, tinyAVR 1-series is Harvard architecture but with unified memory (datasheet, Memories, Memory Map)
3. tinyAVR 1-series UPDI is more capable than megaAVR debugWIRE

 

Parametric Reach
megaAVR
XMEGA AVR are a follow-on to some megaAVR.
--
ATmega2561   - 16MHz, 64 pins, 256KB,  8KB
ATxmega384C3 - 32MHz, 64 pins, 384KB, 32KB
--
ATmega1280    - 16MHz, 100 pins, 128KB, 8KB + 56KB on EBI
ATxmega128A1U - 32MHz, 100 pins, 128KB, 8KB + 16MB on EBI

 

Atmel Studio
"The excellent IntelliSense engine that Microsoft spent years perfecting has been replaced by some sort of Atmel-proprietary “Visual Assist” technology that ..."
1. IntelliSense and AVR is available from third party(ies)
2. Visual Assist from Whole Tomato Software

 

Microchip Customizations
"As these compilers [XC] are quite expensive and ..."
About 1USD/day though the dongle is 1495USD

 

Discussion
megaAVR
"While the megaAVR has a perplexing debugging experience that requires two completely different interfaces and protocols to work with the part, ..."
fyi, once debugWIRE is enabled then stay with it until done.
"... low-cost, open-source programmers (which don’t support the UPDI interface)."
pyupdi is Python UPDI programming via an inexpensive USB UART; debug via UPDI is currently only Atmel-ICE or Power Debugger

PIC32
"... expensive compilers ..."
Can chipKIT PIC32 GCC be invoked from MPLAB X?

 

Thank you!

 

------------------------------------
Notes
1. IntelliSense with most AVR is available from VisualGDB
2. IntelliSense is in Visual Studio Code and AVR might be available via the Native Debug extension
3. The next release of PlatformIO may restore AVR debugging; Visual Studio(s) are some of the IDE that integrate PlatformIO
4. LLVM AVR may be a current or future alternate to AVR GCC
5. ATmega328PB is approaching 1USD each for 100 though it has a supply and demand problem that's easing 17Q4 (should be resolved 18Q1)
6. 32KB tinyAVR 1-series is likely for '18 and probably under the price limit

Ref.
VisualGDB, https://visualgdb.com/tutorials/...
Visual Studio Code, https://code.visualstudio.com/
Native Debug, https://marketplace.visualstudio...
PlatformIO, AVR, http://platformio.org/platforms/...
PlatformIO for Visual Studio Code, https://marketplace.visualstudio...
Whole Tomato Software, https://www.wholetomato.com/defa...
XC8 PRO subscription, http://www.microchip.com/Develop...
Featured MPLAB XC Compiler Licenses, http://new.microchipdirect.com/p...
LLVM, Changes to the AVR Target, http://releases.llvm.org/5.0.0/d...
Python UPDI driver for programming "new" tinyAVR devices, https://github.com/mraardvark/py...
chipKIT, http://chipkit.net/

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Wow! That's a very impressive write-up.

 

There seems to be an inconsistency between the chart and your writing.

 

You wrote:

 

Unfortunately, the STC8 simply does not care about power consumption — so it barrels along at 1.62 mA (still not the worst part in this round-up — not by a long shot).

 

However, the chart shows that the STC8 consumed 5470 microamps in your test. It was the STM8 that consumed 1620 microamps (1.62 mA).

 

There's also a few typos, such as "sense" in the sentence "but has sense expanded" (should be "since") and "faired" (should be "fared").

 

Besides those, I didn't see any other issues.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

"And interrupts are one of the weak points of the AVR core: there’s only one interrupt priority, ..."

 All things considered, I much prefer the AVR "one priority but lots of vectors (separate vectors for uart rx and tx, even!)" over something like the PIC "two priorities = two vectors" scheme.  Or even the 68k "7 priorities with one vector per priority."

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I see that Jack Ganssle has linked to the survey in his latest newsletter...

 

Quote:

Many readers sent this link, which explores 21 different microcontrollers, pondering the strengths and weaknesses of each. Some vendors will not be pleased...

'This forum helps those who help themselves.'

 

pragmatic  adjective dealing with things sensibly and realistically in a way that is based on practical rather than theoretical consideration.