Go Down

Topic: New megaTinyCore for 1-series and 0-series ATtiny (like 1616, 3217, etc) (Read 21113 times) previous topic - next topic

grandaspanna

I am obviously missing something here. Once you disconnect the "device programmer" from the chip (talking stand alone custom board)will it still run the main program without a boot loader?
Yes. It works really well and is simple.

The bootloader is simply an optional program that can be used to load a program into memory over the serial interface.

When the device powers up, it runs whatever program is at the start address.

If you don't have a bootloader, it just runs your code straight away.

If you do have a bootloader, it will do some things to see whether or not you're trying to load a new program. Bootloaders have various strategies for working that out. If it decides you're not looking to invoke its services, it jumps to your program.


windoze_killa

Engineers design things.....technicians make them work.

I don't need anti-static wrist straps.....an instructor years ago told me I had no potential.

BJHenry

Regarding the JTAG2UPDI programmer, are we likely to see a version that runs on the ATMega32U4 so that we can use something like a Micro/Pro Micro?
Also, I don't know if you've seen but there is more information on the tinyAVR-2 series up on the Microchip website now, including this family overview.

DrAzzy

Very nice! Looks like they'll be around soon!

analogRead() will take some work, but probably not much, since we will just be using in single-ended mode. One odd thing I saw was that they may not support native 10-bit analog readings - just 8 or 12... but we can work around that easily enough...

The rest of the stuff, I think, will "just work"...

Joy to the world on the second USART! That's the one thing that really held back the tinyAVR 0/1-series...

I'm not going to touch the 32u4 issue - that looks like mondo work and I don't want to spend any more time on that damned jtag2updi.
ATTinyCore and megaTinyCore for all ATtiny, DxCore for DA/DB-series! github.com/SpenceKonde
http://drazzy.com/package_drazzy.com_index.json
ATtiny breakouts, mosfets, awesome prototyping board in my store http://tindie.com/stores/DrAzzy

Paul_N

Hi Dr Azzy --

In your May 5th post in this thread you mentioned that you were making some CH340G based USB to Serial adapters.  Is there a reason you choose the CH340G over the Silicon Labs CP2102N?  Maybe it was cost or available packages?  I see that Mouser has the PC2102N at $1.33 in singles but the only package available is the QFN28.  Not the easiest thing to hand solder.

The reason I ask is because the windows 10 driver for the CH340G does not appear to honor XON-XOFF flow control (but the CH340G does pass the ^s and ^q without interference).  I know from a project I'm doing that the CP210x set of drivers from Silicon Labs *does* honor XON-XOFF flow control.  Also the drivers are royalty free.

Thank you,

Paul_N

westfw

Quote
the windows 10 driver for the CH340G does not appear to honor XON-XOFF flow control
I don't see any indications in the CH340 *chip* datasheet that it has any support for XON/XOFF flow control.  Just "hardware flow control."
I guess you lose some functions when you pay 1/5 the price :-(
(I suppose that you could try to support Xon/Xoff in the windows driver, but that seems very "distant" considering that a single USB message might contain 64 bytes of data...)

windoze_killa

Just a quick question.

If i program a 3217 and set the protection fuse can it be reprogrammed with a new revision of code?
Engineers design things.....technicians make them work.

I don't need anti-static wrist straps.....an instructor years ago told me I had no potential.

DrAzzy

I chose the CH340G because the part is cheaper than dirt, dead easy to solder, physically and electrically very resilient, and I have a great deal of experience using them (modifying boards based on them, have designed multiple boards, etc).

Just a quick question.

If i program a 3217 and set the protection fuse can it be reprogrammed with a new revision of code?
Yes, assuming you are using UPDI programming. The "chip erase" operation clears the lockbits as well as the flash.
ATTinyCore and megaTinyCore for all ATtiny, DxCore for DA/DB-series! github.com/SpenceKonde
http://drazzy.com/package_drazzy.com_index.json
ATtiny breakouts, mosfets, awesome prototyping board in my store http://tindie.com/stores/DrAzzy

windoze_killa

Engineers design things.....technicians make them work.

I don't need anti-static wrist straps.....an instructor years ago told me I had no potential.

DrAzzy

Yikes - realized I forgot to post about version 2.0.4/5 here!

megaTinyCore v2.0.4 released 7/8/2020 (with 2.0.5 less than 24 hours later)

The biggest change here is the switch to new and improved compiler toolchain. This fixes a few odd errors, most notably the 'relocation truncated to fit: R_AVR_13_PCREL against symbol tablejump2' error shown when a sketch was too large on a part that used RJMP (ie, 8k or less of flash). This also includes a bugfix for eeprom.h (this is the builtin <avr/eeprom.h> one, not EEPROM.h) where the eeprom_is_busy() macro it provided would throw a compile error on these parts because it referred to registers that don't exist here. We have also updated the datasheets to the latest versions. The header files and datasheets contained another big surprise - a bunch of the BOD settings were removed! According to Microchip ATpack release notes, these were "unqualified" BOD settings. Now, only 1.8, 2.7 and 4.3 are "official" - these correspond to 5 MHz, 10 MHz and 20 MHz guaranteed operating speeds. Accordingly, the menu was updated to list the official ones and the speeds they are guaranteed for; the "unqualified" ones (which seemed to work for me!) were marked as such. They are not guaranteed to work, and may vanish in future silicon revisions.
This version also introduced improved naming of exported binaries and assembler listings - the name now includes everything that could effect the .hex output. As part of this initiative, it was discovered that the attempt to delete merged hex files could result in failure to export compiled binary on some linux platforms (#201) because such merged hex files were not created for non-optiboot board definitions (and never got deleted on optiboot ones, by design).
And some other assorted fixes:

Significant documentation improvements, including a page listing errata and table of which applies to what parts... as there are unfortunately a lot of errata in some of these parts!
Improve backwards compatibility of Wire.h (#203)
Fix strange bug in EEPROM.h that was somehow missed (note that there is still #200 which I don't know how to fix)
Possibly fix #189 (timing glitches when TCA0 used as millis timing source)
Fix problem with millis not being entirely disabled when set to be disabled.
Ever so slightly improve baud rate accuracy, reduce space taken by Serial.begin() by a few bytes.
Fix compile error from Tone() on parts without a second type B timer (ie, everything not a 1614, 3216, 1616, 3217, or 1617) when TCB0 was selected as a millis source. (part of #189)
Correct bug in micros() timekeeping when TCA0 is used as millis() timing source (introduced in 1.1.9 - after the exhausive testing for these sorts of issues) (#189)
ATTinyCore and megaTinyCore for all ATtiny, DxCore for DA/DB-series! github.com/SpenceKonde
http://drazzy.com/package_drazzy.com_index.json
ATtiny breakouts, mosfets, awesome prototyping board in my store http://tindie.com/stores/DrAzzy

DrAzzy

Oh - also - I decided against making a super-serial-adapter using the CH340G...

Because I found a much better part! It's the Holtek HT42B534 USB UART adapter.

It has some compelling advantages over the CH340G:
* 0.25% clock accuracy without a crystal (the non-crystal CH340 adapter's oscillator is mediocre at best)
* Dedicated pin for an activity LED - so it doesn't load down RX just to light an LED.
* Has true VDDIO pin, which works from 1.8~VDD (ie, 5v or whatever the adapter is running at - as many of us know, some the hard way, many USB "phone charger" type supplies actually give 5.3v).
* Hardware RTS/CTS flow control

On the CH340G, it's not explicitly stated that you can switch the voltage supplied to the part from 3.3 to 5v while it's live. It happens to work (the trick is, you have external 3.3v regulator tied to the 3v3 pin, rather than relying on the on-chip regulator to get it from the 5v line. that way you can switch the voltage on that pin to change what voltage the I/O is running at, without putting a glitch on the 3.3v pin that actually runs the electronics).

The Holtek chip gives you a dedicated VDDIO pin that you have to connect a voltage to - and that voltage is what a "high" that the board tries to output is.

I'm going to have a *three* position switch (I just got them in, they're adorable!). I've seen designs where people put the full current of a USB adapter through that sort of switch, but as I call my design the ultimate serial adapter, halfassing it like that isn't exactly an option. So tje common on switch will be ground, and the 1P3T switch will just decide which of the three P-channel MOSFETs iomn. First one will connect VBUS to Vcc, second will connect the 3.3v one, and the third will keep both off them off (there will be a third FET and outline on back for an optional second regulator to be installed (or they can add their own) - but by default, you'd use that setting to use "whatever logic level whatever it's plugged into is" Particularly handy for devices in low power applications where the device is running straight off a LiPo at ~3.8v,

For the activity lights, the LED pin will drive one LED, and I'll run a second one from the TX light, using a bicolor LED - between the two of them, it will be kinda like you had a real RX light, but without the load on RX pin.

There will be a 2-position switch to choose if that sixth pin is DTR or RTS (some tools use DTR for reset, some use RTS, and some just brute force and try both to reset the chip, while the hardware flow control wants RTS.

And then TX and RX will both have 1k series resistor to the 6-pin header which can be bypasses with a solder bridge jumper on the back (I have done this to multiple adapters - sometimes you desperately need one or both of them to be tied *diretly* to the serial adapter,

So that's the plan. Obviously, all the modem control pins, as well as all the voltages, will be broken out (I'm imagining 6p on one of the narrow ends, miniusb on the other, and the 6 modem pins. VBus, VDDIO, and  ground on one long side, switches on the other.

Oh, and (hopefully) obviously, the switch that controls the transistor gates will also control the power LED, setting it to either 5v (white, just like my 5v boards), green (just like my 3v3 boards), orange (for external or third regulator). I have most of the parts, though I still haven't laid out the board. If they work as well as I hope, I'll probably have a few hundred made to sell.
ATTinyCore and megaTinyCore for all ATtiny, DxCore for DA/DB-series! github.com/SpenceKonde
http://drazzy.com/package_drazzy.com_index.json
ATtiny breakouts, mosfets, awesome prototyping board in my store http://tindie.com/stores/DrAzzy

westfw

Quote
the non-crystal CH340 adapter's oscillator is mediocre at best
How can you tell?  Doesn't it have to be "very close" for USB to work at all?

DrAzzy

How can you tell?  Doesn't it have to be "very close" for USB to work at all?

I am referring to baud rate generation.

From the datasheet, "the baud rate error of CH340G/CH340T/CH340R UART transmission is less than 0.3%, less than 1% for CH340C/CH340E/CH340B"

The latter three are the models without external crystal. That implies that they've got *at least* 0.7% or so inaccuracy in their timebase (which I think is close enough for USB, based on VUSB working with just tuned internal) But the Holtek chip specs 0.25%...
ATTinyCore and megaTinyCore for all ATtiny, DxCore for DA/DB-series! github.com/SpenceKonde
http://drazzy.com/package_drazzy.com_index.json
ATtiny breakouts, mosfets, awesome prototyping board in my store http://tindie.com/stores/DrAzzy

trimarco232

Hi,
I didn't read everything, nor understand all of it, so 3 questions ; sorry and thanks for answering !

1) CH340 : the easiest to solder is CH330N (CH340N) : can it be used for auto-reset, since it has no DTR, but only RTS ?

2) auto-reset : is there a way to use it at PA0, while PA0 is configurated as UPDI ? ; ie. in UPDI mode, PA0 works as PIO too, thus can generate an interrupt that resets the chip by software … so one can use the bootloader in auto-reset mode, while UPDI can still be used (if needed), and there is no need to HV it (le beurre et l'argent du beurre)

3) the yet remaining issue concerning parts like AtTiny1616 is the rich set of silicon bugs … : do the libraries take care of that, do they make differences between infected and non infected parts ?

DrAzzy

1. Yes, avrdude manipulates both DTR and RTS such that either can be used to do autoreset (

2. It may be possible to set an interrupt on that pin al-la-ersatz reset even if it is set to UPDI. It is on my list of things to test, but it is 20-30 action items down the list so I have no ETA of when I will have information here, it is not getting closer to the top as urgent things of higher priority are coming up faster than I can check things off. I am way WAY behind on everything right now.

3. I have a section in the core documentation where I list the errata and characterize the size of the impact on users of the core, with a sentence or two describing the impact on users of the core for every issue and what measures, if any, are taken to correct for it in the core. The vast majority of these issues will only be relevant if you are implementing functionality which is not exposed by the Arduino core or included libraries.
ATTinyCore and megaTinyCore for all ATtiny, DxCore for DA/DB-series! github.com/SpenceKonde
http://drazzy.com/package_drazzy.com_index.json
ATtiny breakouts, mosfets, awesome prototyping board in my store http://tindie.com/stores/DrAzzy

Go Up