Playing with the new tinyAVR 1-series

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

I've recently moved from Arduino to "bare AVRs", and now making my own PCBs. Most recently, I've decided to explore the newer AVRs, and specifically I've chosen attiny1614 (very low cost, hobbyist-friendly SOIC-14 package) -- I see it as attiny84 replacement.

 

Just want to share my experience and maybe start a discussion on a few things.

 

Toolchain:

Having a preference for free (as in freedom) software and small footprint, I was able to successfully set up a minimal toolchain on Linux (Ubuntu) without having to use Atmel/Microchip IDE.

I've documented the process on my github: https://github.com/vladbelous/tinyAVR_gcc_setup -- hopefully someone might find this useful.

 

Some key takeaways:

  • These new AVR parts are much closer to atxmega rather than to (previous) attiny/atmega parts. In GCC, it is classified under avrxmega3 architecture.
  • Recent GCC versions natively support avrxmega3 / attiny1614, but there's no support (yet?) in avr-libc (as of version 2.0.0). My workaround here is to get a few additional files (in my case, just 5) from Atmel/Microchip packs.
  • avrdude can be used for programming using El Tangas (thanks!) modified avrdude.conf and jtag2updi firmware -- it allows you to setup another AVR as the programmer (similar to the popular "Arduino as ISP" approach). However, the avrdude.conf modifications are not yet upstream (as of version 6.3).

 

 

Questions:

Is there any information on adding these new parts to upstream avr-libc (i.e. http://download.savannah.gnu.org/releases/avr-libc/)? Do we have anyone from avr-libc in these forums?

 

When (if at all) do we expect the jtag2updi work of El Tanga (or some other form of UPDI support) to be added to mainline avrdude?

 

I think it's quite important to have a simple/small cross-platform toolchain if these new parts are to become more popular in hobbyist community.

 

 

avrxmega3 architecture:

Having some experience with (older) attiny and atmega parts, and no experience with atxmega, a lot of things ended up a surprise to me during programming, causing a non-trivial debugging time.

 

One the one hand, some architecture unification in 8-bit AVR parts seems like a good idea to me (new megaAVR 0-series is also avrxmega), and personally I'm ok with it being atxmega-like, but I'm worried that in hobbyist community there's much more experience/material on the (previous) attiny/atmega, and atxmega is less known. What do you think about this?

 

Also, do we know if this is indeed Microchip's plan to have all new 8-bit AVRs use avrxmega architecture, or do we expect new attiny/atmega-like parts to come too?

 

 

Attiny1614-based board:

I've designed (and had it manufactured) a PCB for attiny1614 and put all the design files and further information here: https://github.com/vladbelous/avr-attiny1614-mini

 

So far, the board works well, and I was able to use UART, timers and even drive an APA106 programmable LED (similar to the popular WS2812). I'm not using any frameworks, just C++ with avr-libc.

 

One issue I ran into is UPDI/RESET pin: you have to select either UPDI functionality or RESET functionality via a fuse (default is UPDI). If you choose to make it a RESET source, you'll need to apply 12V to program it again.

 

I've recently had an issue in one of my designs, where a small leakage through a turned-off MOSFET ended up harvested enough by a boost converter circuit to "partially" start the connected AVR MCU. "Partially" means it got stuck in some non-working condition such that even after supplying a stable 5V, a physical RESET was still necessary.

Basically, I learned the importance of RESET signal and voltage supervisors, but now it appears the new attiny parts are somewhat inconvenient in this regard -- or am I missing something here?

 

 

What are your thoughts on the new tinyAVR 0/1-series and megaAVR 0-series parts? Is it the future of AVR for hobbyists?

I'm quite interested in seeing (and contributing to) it becoming more popular, but it's not yet clear if there are enough stakeholders. I know the new Arduino boards are using atmega4809 (which is megaAVR 0-series), but I have some doubts it will lift off.

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

VladB wrote:
  Questions: Is there any information on adding these new parts to upstream avr-libc (i.e. http://download.savannah.gnu.org...)? Do we have anyone from avr-libc in these forums?

When (if at all) do we expect the jtag2updi work of El Tanga (or some other form of UPDI support) to be added to mainline avrdude?

I think it's quite important to have a simple/small cross-platform toolchain if these new parts are to become more popular in hobbyist community.

 

I don't think my mods will be added, what I did is basically an hack, avrdude 6.3 does't really support UPDI. The firmware jtag2updi just pretends the AVR-0/1 are xmegas and uses the PDI support present in avrdude 6.3, specifically via the jtagice MkII protocol.

If you look at the definition for the avr-0/1 family inside my avrdude.conf, you will notice some stuff is commented out and replaced:

#------------------------------------------------------------
# AVR8X family common values
#------------------------------------------------------------

part
    id		= ".avr8x";
    desc	= "AVR8X family common values";
#    has_updi	= yes;
    has_pdi	= yes;
    nvm_base	= 0x1000;
#    ocd_base	= 0x0F80;

Here, I edited the family definition to say they use the PDI interface instead of UPDI. But edited from where? Actually, there is an official version of avrdude that supports UPDI:

http://svn.savannah.gnu.org/view...

 

This was being supported by Atmel, but since the acquisition I'm not so sure. There are new chips an a few wrong signatures that were not corrected, so I have a feeling Microchip is no longer committed to support avrdude.

 

Another problem is that UPDI is only supported officially by protocols that use USB exclusively and I wanted to make a programmer that uses serial interface, so I used this work-around of tricking the jtagice MkII interface of avrdude.

 

edit:

If I could, I would extend the jtagice mkII protocol to support higher programming speeds, and modify avrdude accordingly. Also correct a few things such as hardcoded memory names and types.

The UPDI interface can R/W SRAM and I/O registers at will, but this is not really possible to do with the current capabilities of avrdude. It would only require slight modifications, though, and the interactive mode of avrdude could be used for limited debugging.

 

Last Edited: Sat. Jan 5, 2019 - 01:12 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I feel completely happy with these new small parts. Using official tools I found no problem, programming/ debugging is very nice with one pin only. But, in my opinion this UPDI Pin should not have different functions, should be always accessible. I have never used the external reset.
PCBs can be very easy. For the controller itself, usually only one capacitor is needed. Sufficient stable clock and many features are already included in these great powerful chips. My favorites are the double AD converters with many voltage references.

Last Edited: Sat. Jan 5, 2019 - 02:44 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Is there some reason you're not using the beta for MPLABX on Linux?

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

El Tangas wrote:
But edited from where? Actually, there is an official version of avrdude that supports UPDI: http://svn.savannah.gnu.org/view...

 

Interesting. I only checked the latest released version, which is 6.3 from 2016, according to http://download.savannah.gnu.org/releases/avrdude/.

Do I understand correctly that if you have a programmer of type jtagice3_updi, it should work with avrdude from trunk? Since it's USB, does it require special drivers, or does it use some common interface?

 

There's definitely value in having a serial-based solution, like yours. Perhaps still it can be modified/cleaned enough to be included in upstream? The principle itself seems reasonable - it's not much different from the popular Arduino-as-ISP approach.

 

BTW, somewhat off-topic: what is the purpose of series resistor in the wiring diagram? I tried without it, and it seemed to work fine too. Given UPDI is bidirectional, I decided to keep the resistor in my designs as a safety measure, but wondering if there are other reasons.

 

 

clawson wrote:
Is there some reason you're not using the beta for MPLABX on Linux?

 

I cannot say anything bad about MPLABX, since I've never tried it, and I'm not advocating for avoiding it :)

Coming from (non-embedded) software world, I'm just more used to modularity: compilers are independent from editors, and all parts bring only minimal dependencies. There are many reasons one might prefer that (though embedded development could be quite different, I admit).

 

The fact that there's AVR architecture support in upstream GCC is of huge benefit to AVR as a hobbyist platform, we just need to get avr-libc to the same level.

AVR-GCC toolchain is readily available in official repos of many Linux distros, but I doubt vendor-specific IDE bundles will ever be there. Others can build on top of it and create new development platforms (e.g. platformio.org), create frameworks using modern C++ features, add support for other languages (e.g. there's some projects adding AVR backend for LLVM), etc. Overall, the hobbyist can afford to get creative without a business reason :)

In any case, this was not the main emphasis of my post. If you're interested in creating a separate post discussing merits of different toolchain/IDE setups, I'll gladly expand there!

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

VladB wrote:
Do I understand correctly that if you have a programmer of type jtagice3_updi, it should work with avrdude from trunk? Since it's USB, does it require special drivers, or does it use some common interface?

Yes, I suppose so, if you have a programmer that "talks" jtagice3, you can use it with the unreleased version of avrdude to program UPDI chips.

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

The thing about MPLABX is that it comes from Microchip with THEIR version of avr-gcc, this is generally 1..2 years ahead of the FSF mainline version so will support new models.

Last Edited: Sun. Jan 6, 2019 - 01:54 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
The thing about MPLABX is that it comes from Microchip with THEIR version of avr-gcc, this is generally 1..2 years ahead of the FSF mainline version so will support new models.

 

Well, that's not entirely true. First, note that AVR-GCC is just regular GCC configured to output for AVR instruction set. This is what it means for GCC to natively support AVR architecture.

So almost by definition upstream/mainline AVR-GCC is the latest. Also, if Microchip/Atmel made significant changes to "their" AVR-GCC, they would also have to publish the sources, as required by GPL.

 

According to other posts in this forum (e.g. https://www.avrfreaks.net/forum/mplabx-first-users?page=all), MPLAB X comes with AVR-GCC version 5.4.0, while upstream stable GCC is 8.2.0. Note that 5.4.0 was release on June 3, 2016, while 8.2.0 was July 19, 2018.

 

However, the other important part of the toolchain is libc, and in it is true that mainline avr-libc is indeed behind in terms of new tinyAVR support, hence my guide.

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

A I understand it, the issue is NOT gcc but the product definition files! Those are what really lag in the distributions.

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

Last Edited: Sun. Jan 6, 2019 - 10:42 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

there's no support (yet?) in avr-libc (as of version 2.0.0).

My workaround here is to get a few additional files (in my case, just 5) from Atmel/Microchip packs.

I'm not sure what you mean by "avr-libc" support.  Traditionally, Atmel has been responsible for added new device support to ... everything, and recently it seems pretty clear that the "packs" are their preferred solution (as opposed to actually updating packages maintained outside of their control.)  So it's not quite like avr-libc hasn't gotten updates, it's more like updating avr-libc itself is no longer the preferred method of getting those updates.

 

(I don't particularly like this: https://www.avrfreaks.net/forum/device-family-packs-are-annoying, but it seems to be the way things are going...)

 

For better or worse, avr-libc "support" doesn't extend much beyond the avr/io.h definitions.  (I guess eeprom and pgmspace could use an update.)

 

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

westfw wrote:

I'm not sure what you mean by "avr-libc" support.

I think we are on the same page here. Programming C/C++ usually requires some additional runtime libraries/code, which however are not part of the compiler itself (see below for an example).

But to clarify my point still: today we can program attiny85/atmega328p/etc with just (upstream) gcc + avr-libc -- in this sense these parts "are supported by avr-libc 2.0.0". The same cannot be said of attiny1614, unfortunately.

 

I really hope avr-libc project will not die. Was Atmel the only significant contributor? Do you happen to know if any other maintainers of it are on these forums?

 

ka7ehk wrote:

A I understand it, the issue is NOT gcc but the product definition files! Those are what really lag in the distributions.

Yes, I that's correct. But there's also a few additional things other than product definitions.

 

For example, C/C++ language definition has floating point types, and defines mathematical operations on it. However, the AVR instruction set does not have any hardware FP support, so they need to be emulated in software.

Traditionally, this implementation is done through external libraries which are not part of the GCC itself. In case of FP, these operations are implemented in libm, which is part of avr-libc.

It also happens that libm is architecture-specific (not part-specific), and avr-libc has libm implementations for avrtiny, avr5, avrxmega2, avrxmega4, etc, but NOT avrxmega3. Hopefully this is be improved soon.

 

 

As I've mentioned, in my case, to be able to program attiny1614, I had to manually add these files (otherwise normally supplied by your avr-libc):

  • libm.a and libc.a -- these are avrxmega3-specific, and apply to all tinyAVR 1-series (and similar) MCUs. These include math operations, stuff for working with EEPROM, and C standard library stuff.
  • libattiny1614.a, crtattiny1614.o -- these are part-specific. I don't exactly know what these are responsible for, but I think that, e.g. interrupt vector map is one of those things.
  • iotn1614.h -- also part-specific. This defines names for all IO-registers, interrupt vector addresses, etc.

 

 

 

 

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

Quick update:

 

I've found that there is actually work being done on adding avrxmega3 support to avr-libc: http://savannah.nongnu.org/patch... -- last updates are as recent as Dec 2018.

 

It looks like it's using a very similar approach (borrowing from Atmel/Microchip atdf packs and their packaged toolchain). I'll probably test out the patch some time later, report here and update my guide :)

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

It also happens that libm is architecture-specific (not part-specific), and avr-libc has libm implementations for avrtiny, avr5, avrxmega2, avrxmega4, etc, but NOT avrxmega3.

 Really?  In between the latest toolchain from Atmel and the downloaded "pack", I have:

 

 pwd

.../Atmel.ATtiny_DFP.1.3.229/gcc/dev/attiny1614/avrxmega3
WWHackintosh<9998> ls
crtattiny1614.o         libattiny1614.a

 

pwd
/usr/local/avr8-atmel-3.6.1.495/avr/lib
WWHackintosh<10007> ll avrxmega3/
total 896
-rw-r--r--@  1 wheel  295126 Jun 13  2018 libc.a
-rw-r--r--@  1 wheel   65984 Jun 13  2018 libm.a
-rw-r--r--@  1 wheel    5934 Jun 13  2018 libprintf_flt.a
-rw-r--r--@  1 wheel    2710 Jun 13  2018 libprintf_min.a
-rw-r--r--@  1 wheel    6976 Jun 13  2018 libscanf_flt.a
-rw-r--r--@  1 wheel    3836 Jun 13  2018 libscanf_min.a
drwxr-xr-x@  8 wheel     256 Jun 13  2018 short-calls/

 

(the xmega3/libc.a came with avr8-gnu-toolchain-3.6.1.496 from http://distribute.atmel.no/tools/opensource/Atmel-AVR-GNU-Toolchain/3.6.1/)

 

These are essentially the same things you'd have to download to get support for the most recent chips even in AS (though perhaps AS would do it for you automatically, even if it didn't come with the latest compiler.)

 

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

westfw wrote:
 Really?  In between the latest toolchain from Atmel and the downloaded "pack", I have:

 

My comment was specifically about upstream avr-libc, not Atmel/Microchip's toolchain, sorry if it wasn't clear.

Basically upstream released avr-libc does not have avxmega3 or any of the new attiny part support, but there is work in progress.

In the mean time, to get it to work with latest gcc (8.2), we can borrow a few files from Atmel/Microchip packs and their packaged toolchain, which are the ones you are showing.

 

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

VladB wrote:
Basically upstream released avr-libc does not have avxmega3 or any of the new attiny part support, but there is work in progress.
Yes but it is COMPLETE in Atmel/Microchip's version so why on earth wouldn't you save yourself a load of hassle and just simply use that?

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

...THEIR version of avr-gcc, this is generally 1..2 years ahead of the FSF mainline version so will support new models.

The Atmel (Microchip) avr-gcc is 1..2 years ahead WRT device support, and 2..3 years behind WRT gcc version.  Decisions, decisions...

(OTOH, that means that the majority of people using avr-gcc are using an older gcc, and I'm not sure that I *trust* FSF to keep AVRs working.  Ie: https://github.com/arduino/Arduino/issues/1208 )

 

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

clawson wrote:

VladB wrote:
Basically upstream released avr-libc does not have avxmega3 or any of the new attiny part support, but there is work in progress.
Yes but it is COMPLETE in Atmel/Microchip's version so why on earth wouldn't you save yourself a load of hassle and just simply use that?

I don't understand the borderline hostility here. I'm not suggesting you should use mainline avr-libc (or that anyone should not use Atmel/Microchip tools), but if anyone else wants to (and I've already mentioned a few reasons), I only provided information how they can achieve that.

It's great that Atmel/Microchip has full support of their parts, no doubt, but it's also a good thing for that to be in mainline avr-libc. Nothing to be antagonistic about.

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

Oh don't get me wrong,  I'm a great advocate for FSF / FOSS / GNU and so on. But I'm simply pointing out that if you pick any AVR the fastest route to a Linux installation to support this is to take a distribution from Atmelchip. Sure Bill is right this takes you back to a 5.4 when mainline GCC is at 8.x but those two aren't actually that far apart - there was a pretty major leap in GCC versions after the 5.X's and 6.X and 7.X were almost never seen. So a stable 5.4 with full device support still looks like the quickest/easiest option. It is true that Georg-Johan's ISR streamlining stuff in 8.X does make it quite attractive though if you are really tight on cycles/bytes.

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

VladB wrote:
Also, do we know if this is indeed Microchip's plan to have all new 8-bit AVRs use avrxmega architecture, or do we expect new attiny/atmega-like parts to come too?
The ones at Microchip will hold close to their vests the answers to your questions (8b MCU market is competitive)

XMEGA's architecture does vary from megaAVR 0-series (DMA, bus matrix difference due to DMAC master, separate memory spaces versus unified memory)

Microchip has a major competitor in Texas Instruments.

EBI by megaAVR and XMEGA AVR is looking long in tooth.

AVR16?

VladB wrote:
... where a small leakage through a turned-off MOSFET ended up harvested enough by a boost converter circuit to "partially" start the connected AVR MCU.
There are relatively low leakage FETs but you have to search for 'em.

Some SMPS are by BJT in order to reduce leakage at an elevated temperature.

 

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

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

GermanFranz wrote:
But, in my opinion this UPDI Pin should not have different functions, should be always accessible.
Should be multiplexed as tinyAVR 0-series is a follow-on to tiny102 and the very popular tiny85.

MPLAB PICkit 4 has Vpp and UPDI for the following in MPLAB X v5.10 :

  • tiny202
  • tiny204
  • tiny402
  • tiny404
  • tiny804
  • tiny1604

Apparently similar for MPLAB Snap.

MPLAB® Snap vs. MPLAB® PICkit™ 4 - Developer Help

 

edit: strikethru

 

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

Last Edited: Mon. Mar 18, 2019 - 12:21 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

VladB wrote:
The fact that there's AVR architecture support in upstream GCC is of huge benefit to AVR as a hobbyist platform, ...
likewise for Texas Instruments MSP430TM.

https://gcc.gnu.org/onlinedocs/gcc-8.2.0/gcc/MSP430-Options.html#MSP430-Options

VladB wrote:
Overall, the hobbyist can afford to get creative without a business reason :)
Indeed though a perk at some workplaces is, IIRC, Fridays where one can effort a personal project that may have a link to that business or may be simply FOSS.

 

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

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

gchapman wrote:

Should be multiplexed as tinyAVR 0-series is a follow-on to tiny102 and the very popular tiny85.

 

Same thing with tinyAVR 1-series: I would call that a crazy engineer's idea. The possibility to brick devices should be excluded for all time, in principle. Programmability should always be ensured. New controllers like ATMEGA4808/09 do it right: A fixed UPDI Pin for nothing else. I hope that will go without saying for future devices.

 

To get out of the way of the discussed complex GCC issues I only use simple assembler- for me the means of choice for simple controllers cheeky

Last Edited: Fri. Jan 11, 2019 - 10:33 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Vlad, thanks for your useful Github projects, I've set up my toolchain as described and it works well with the attiny1614.

 

I like the 1614.

 

I don't see how the UPDI / RESET pin is a problem in UPDI mode. If you want to have a reset button in your production device, you can write the firmware to reset when some other pin is pull down.

 

The UDPI interface can also reset the target device easily enough with a few commands (I added a --reset option to pyupdi.py for this purpose).

 

This is still better than older devices, which consume at least two pins for programming plus reset.

 

Reasons to like the attiny1614:

 

  • True one-pin programming makes board layout and hacking easier.
  • The package - soic with 150mil width - is small enough to fit on a very small board but not too small to hand-solder (like qfn parts, etc)
  • It works with 5v unlike a lot of other modern mcu (like approx 100% of arm parts)

 

It also happens to have a feature set which fits my application quite well.

Last Edited: Mon. Mar 18, 2019 - 12:11 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

markxr wrote:
The package - soic with 150mil width - is small enough to fit on a very small board but not too small to hand-solder (like qfn parts, etc)

 

The term small doesnt really fit to SOIC packages, why ? because when designing a PCB, the pin traces that connects you IO to your HW components will be also cosidered. Now here comes the difference between different packages, let it be QFN/SOIC...etc.

 

Regards,

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

I appreciate the work VladB.  I do prefer to work at the command line on my Unbuntu (18.04) system.  BTW, avr-gcc etc are in the APT repos.

Last Edited: Tue. Mar 19, 2019 - 12:50 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

MattRW wrote:
BTW, avr-gcc etc are in the APT repos. 
Possibly true but very likely massively out of date. The place to get the toolchain is the .tar.gz direct from Microchip.

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

When the hobbyist community moves away from the AVR (primarily as the Arduino UNO/Nano/ProMini) it will go to the ESP8266.  These are currently mass-produced and available on eBay at about  the same price as an Arduino UNO.   They can be programmed with the Arduino system: meaning you can use the same code as the UNO but have more speed and flash size.  Plus all the WiFi stuff.  And you don't need any special cables, adapters, or programming/debug modules because the CPU board already has a USB interface.  

   Here is an example: https://www.ebay.com/itm/NEW-ESP...

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

Simonetta wrote:
When the hobbyist community moves away from the AVR
Never going to happen.

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

Probably some fraction, will (move away from AVR). But, like clawson, I don't see it (a large scale migration) happening any time soon. If it does happen, it will be because some software (GUI) will provide the intelligence to remove the technical knowledge requirements (much as the Arduino IDE has for the AVR, now). The ESP8266 is simply too complex for the bulk of the hobby users.

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

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

Esp8266 does NOT have built-in USB...
The popular nodeMcu boards have an added usb controller, just like an arduino Nano (but usually a cp210x, I think)
Not the ESP32, either. (I suspect that it has something to do with not paying USB organization fees...)

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

clawson wrote:

Simonetta wrote:

When the hobbyist community moves away from the AVR

 

Never going to happen.

 

appreciate the confidence, but well......

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

Guys no body knows what will happen exactly, technologies are evolving and emerging everyday. remember the 90s when Nokia was the top, where is Nokia now ?! ah busy with some mapping and GIS apps.

 

 

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

Remember the early years of the new millennium: First AVRs appeared in the world. And now? More then 600 different controllers. More and more fresh types. And why? They are easy to use. They are easy to understand. They do a lot of tasks and there is no sign that these tasks are getting less. For the future, I do not want more complex controllers, stupid configuration monsters, but just smarter controllers that are even easier to program.

Last Edited: Wed. Mar 20, 2019 - 09:16 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Moe123 wrote:

clawson wrote:

Simonetta wrote:

When the hobbyist community moves away from the AVR

 

Never going to happen.

 

appreciate the confidence, but well......

The promise was that when Cortex got down to or below 8 bit micro prices that everyone was going to switch over to those. They are now higher specified and lower cost. Do we see a massive tidal wave of movement from AVR to ARM? Sure there is a slow trickle but it's not happening in the numbers that would suggest the early demise of AVR8. By the same token when devices like AVR, MSP430, some PIC appeared they were going to "kill off the 8051". Has that happened?

 

Indeed what on earth are Microchip doing recently releasing all these AVR-0/AVR-1 new models if their business plan sees the demise of the 8bit MCU market??

 

The one thing I will grant you is that Intel 4004s are not being very widely used these days!

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

Just read the datasheet of a 32 bit part and it will be immediately clear why 8 bit MCUs still exist. The 32 bit chips are much more complex, you need to spend lots of time studying when you could just be programming your simple 8 bit AVR instead.

I mean, just to setup the clock of a SAMD... sheesh... the oscillator connects to the PLL connects to the the clock-whatever connects to.. aaargh... with an AVR 0/1 you just write a couple of registers.

 

It's like hardware designers think "Hey, we have 32 bit registers and a 32 bit address space, so lets add every single feature we can! Yay!"

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

El Tangas wrote:

with an AVR 0/1 you just write a couple of registers

 

- Set Fuse to 16 or 20 MHz internal clock

- Enable writing to prescaler via CPU_CCP if needed

- Set your preferred frequency in prescaler!

 

Last Edited: Wed. Mar 20, 2019 - 02:15 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

GermanFranz wrote:

El Tangas wrote:

 

with an AVR 0/1 you just write a couple of registers

 

- Set Fuse to 16 or 20 MHz internal clock

- Enable writing to Prescaler via CPU_CCP if needed

- Set your preferred frequency in prescaler!

 

 

?...Pass 10/10, now try to blink a LED.

 

;-)

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

- Set Fuse to 16 or 20 MHz internal clock

- Enable writing to Prescaler via CPU_CCP if needed

- Set your preferred frequency in prescaler!

Traditional AVR are possibly even easier?

 

Apply power

Err...

... that's it.

Last Edited: Wed. Mar 20, 2019 - 02:09 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Moe123 wrote:

try to blink a LED

 

Well, using new PIT its easy too.

1) Set Portbit to LED-Output

2) Enable PIT with with the desired prescaler value in RTC_PITCTRLA.

3) Enable PIT Interrupt in RTC_PITINTCTRL.

 

Now you can visible toggle your LED-Portbit in PIT Interrupt.

Please not forget to clear Interrupt Flag manually there.

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

Actually, the PIT signal is a square wave. You can connect it to the event system, then enable an event output pin and connect an LED.

This way, you can have a blinky all in hardware, without spending a timer that may be used for other things.

 

Seems complicated, but the whole thing is still simpler than setup the damned SAMD clock.

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

El Tangas wrote:
This way, you can have a blinky all in hardware, without spending a timer that may be used for other things.

That is certainly the most elegant way using a LED only. But a separate timer is never needed in interrupt solution too, PIT peripheral has its own. I would still prefer the PIT interrupt to be able to solve other tasks there in a controlled (slowly) timing.

Last Edited: Thu. Mar 21, 2019 - 02:31 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Herr Franz,

 

you do understand that you can use same interrupt for different things or ?

 

Grüße,

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

A thing is a pity: There is only one Timer Type A that can count pin signal changes - > events very useful in hardware without the need for an interrupt / cpu involvement (equally valid for series 0/1).

Or does anyone have an idea how to do that in other ways?

Last Edited: Sun. Mar 24, 2019 - 07:34 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Looking at the documentation, it seems that the TCD peripheral can also count pulses / events. I haven't tried it.

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

markxr wrote:

it seems that the TCD peripheral can also count pulses / events.

 

I don't know how.

Type D is used for waveform generation / available in series1 only.

 

I'm just looking for counter possibilities in a Mega4808 0-Series project.

Interestingly, the Tiny 1-Series is superior in some hardware features:

More Timer Types, more ADC, more DAC, more AC ...

Last Edited: Sun. Mar 24, 2019 - 09:54 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, the RTC can be clocked from the TOSC1 or EXTCLCK pins, therefore it may be possible to get it to count pulses.

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

Every input pin can generate an interrupt.

 

So if you can count them quickly enough in an interrupt service routine, it will work.

 

Of course ISRs take time, I suppose something like 100 cycles - @20mhz is about 5us. That's the fastest pulse rate you can count without missing any, they need to arrive more slowly if you want the cpu to have time to do other tasks at the same time.

 

If you have multiple pins generating pulses, they will have to arrive more slowly to allow time for the cpu to work out which counter to increment.

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

markxr wrote:
Every input pin can generate an interrupt

Yes and no. Every port can generate one interrupt only. Within this interrupt then the individual pins must be evaluated. This takes time, time time... Event driven timer counter are far superior. But, because there is only one type A timer, I also need counting interrupts. The RTC is unfortunately already in use.

Last Edited: Sun. Mar 24, 2019 - 06:37 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It depends how fast your pulses are. Yes, you can only have one ISR for several pins, and it will need to check which pin caused the interrupt to increment the correct counter. This does take some time, but you should still be able to count quite quickly.

 

If you desperately need to count high speed pulses on multiple channels with good accuracy, I'd consider using different (or additional) hardware. I expect there's some i2c pulse counter chip available.

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

markxr wrote:
It depends how fast your pulses are.

 

Sure. But it also applies: In a system which should provide reserves for further expansion maximum efficiency from the outset is necessary. Keeping short / dispensing with interrupts is essential for that.