AVR Freaks

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.

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.)

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.

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.

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...

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

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.

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!"

?...Pass 10/10, now 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.

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.

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?

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 ...

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.

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.

I really cannot follow your points and what you would like to prove. does this imply that some microcontrollers from MC /Atmel..or whatever cannot be soldered or programmed. How did you came to this conclusion ?? can you state some microcontrollers that is impossible to program ? or to solder..i am really interested to know?

EDIT: the quote was before GermanFranz edited his points 3 times.

A hobbyist would use a dev kit and not a single uC. if you are already designing your owb PCB then you are a little bit step ahead from being a hobbyist.

If you did that I bet if the chip going to work, decoupling capacitor...LDO(if needed), and more other stuff, here is a start:

http://ww1.microchip.com/downloa...

and a lot more consideration. not to mention that noise will make the chip almost not functioning. so as I said before, if you are already designing your HW and get it to work then this is something else..

well, if it works for you like this: single mcu, connect updi pin GND and right operating voltage then you should open a company immediately and start making some money.