ATtiny4313 with micronucleus

[tpimh]

Seems that micronucleus supports attiny2313, but it's not possible to upload firmware with it.

[SpenceKonde]

We do not provide Micronucleus support on boards for which it does not make sense in light of the flash constraints. Any time that the bootloader would take more than 1/4th of the flash, roughly speaking, that is someplace where a bootloader is inappropriate. I stand by the rule I have articulated for this core for years: No Micronucleus for < 8k parts. No Optiboot for 2k parts nor 4k parts that do not exist in an 8k version. The only reason that i provide Optiboot for 4k megaTinyCore parts not available in 8k versions (ie, the 8-pin modern tinyAVRs) and 2k megaTinyCore parts is that adding that support involved a grand total of two binaries and one top level menu option to add support for the 8-pin parts, and 0 additional binaries to add support for the 2k parts - it was very nearly zero cost.

The same is not true on the legacy parts supported by ATTinyCore. Version 2.0.0-dev bootloader build scripts involve building hundreds of binaries. Every additional chip supported adds 10 more to the list for micronucleus, and Optiboot involves IIRC 2 builds per chip per clock speed - around 24 per chip. Different chips of otherwise equal specs cannot share bootloader binaries. That's why if you go look at the ATTinyCore 2.0.0-dev branch, you'll see that there are in excess of 700 binaries supplied. 700+ binaries to support 20 parts. megaTinyCore supports over 30 parts with only 22 binaries, and 4 of those are duplicates that change only the LED pin!!

I hate to say it, but the 4313's suck. They suck really bad, and yet they are priced higher than newer parts with more features and much more memory. There has been no sound reason to use an x313 on a new design for over a decade (that's how long there has been a strictly better part available for the same price or less).

[tpimh]

Thank you very much for the explanation! Because of this I have decided against using T4313 with micronucleus in my new design and switching to T426 with optiboot-x instead (I still need an external USB-UART translator, which can be costly).

[SpenceKonde]

CH340N is my go to for anything cost sensitive that needs an on-board USB serial adapter - they're like 30 cents each and dead easy to hand solder prototypes with (SOP-8)., and need no external components except a few caps.

It's definitely a good choice to go with 2-series attiny if you're using Optiboot, since you get the alt-reset pin (you can wire it with the classic autoreset circuit).

[tpimh]

Thank you very much for your recommendation! I was going to use PL2303GL (also SOP-8, but probably much more expensive), but with OTP memory and 3.3V 100mA LDO, but I will also take CH340 parts into consideration (just need an external voltage regulator and an EEPROM).

Could you please provide more information about the alt-reset pin and the classic autoreset circuit? I only have the button-resistor-capacitor for reset in my schematic as the datasheet recommends:

[SpenceKonde]

Sorry for late response.

Never heard of that one (and don't see the PL2303GL for sale anywhere),. Having a builtin voltage regulator that can power more than just the USB-serial adapter is a definitely advantage. Not sure how handy the OTP is - would be very situational.

Have you read the reset documentation? https://github.com/SpenceKonde/megaTinyCore/blob/master/megaavr/extras/Ref_Reset.md

I have a section in there with the schematic of the autoreset circuit and a description of how and why it works. The circuit is identical if the alt reset pin is enabled. That's controlled with the bits 2 and 3 of the SYSCFG0 fuse, the first three options are GPIO, UPDI, and RESET (these refer to pin PA0) and the last one, new in the 2-series is "UPDI with alternate reset pin". You can enable this with Arduino by choosing the appropriate option from the Tools - > Reset/UPDI Pin Function menu - Available options are "UPDI (no reset pin)" and "UPDI w/reset on PB4 (2-series only)" plus, if using Optiboot, GPIO (no UPDI or reset) and Reset (No UPDI) are also options (we don't provide a mechanism to . You would just need to pick UPDI w/reset on PB4 when you "burn bootloader" using UPDI in order to make that pin to act as reset.

However, note that the autoreset circuit shown in that document I linked above requires that the serial adapter have either a DTR or RTS pin. Either will work (and for various reasons you may need to choose a specific one, for example if using a CH340N, you don't have a choice since it doesn't have a DTR pin, but it does have an RTS pin). But unfortunately for the PL2303GL, because of the extra pins used for VDDIO and the regulator, the 8-pin PL2303GL doesn't have either of those. It can never trigger an autoreset circuit - the autoreset circuit requires one output line from the serial adapter chip that can be driven low, passed through the RC circuit (again, described in detail with diagrams in the reset reference linked above) producing a LOW pulse on reset. Since most serial consoles, as well as AVRdude, drive both RTS and DTR low when the port is opened, that's how you get your autoreset,.

VDDIO is a lovely and tempting featuire, I can't argue that - but I don't see why you'd need it if you're planning to run the chip on 3.3V. The CH340 can do 3.3v or 5v depending on how you connect it, I can't think of any other serial adapters except the ones with VDDIO that will do anything other than 3.3v, almost used the HT42B534 as a result of it having that feature. Then I discovered the chip was unusable due to a combination of silicon and driver bugs. Pity too, because the thing would just scream - it had USB latency time 1/5th that of a CH340 - and using SerialUPDI, the upload time at high speeds is dominated by time spent in USB latency rather than transfering data, so reducing latency by 80% would improve upload speed by almost 40% (almost because it's so fast that you need to give it a brief pause during the page write operation, while other adapters don't need that pause typically because of the USB latency. But alas - it crashes the app using it constantly, it mishandles modem control pins, and tools to write the configuration EEPROM frequently fail ()both the manufacturers' ones and the third party tools. What an awful part the HT42 turned out to be. Wish I'd realized that before I bought 100 of the chips....

I'll also note that I have never seen someone actually include R1 the schematic you posted. Yeah, I read their reasoning of why you need it - but I'm forced to conclude that it can't possibly be that bad to omit it, since literally no device I have ever looked at the schematic for had it, and I've never seen any reports of problems that are not better explained by other causes.

[tpimh]

Thank you very much for such a detailed description! I'm still considering the USB-serial chip for my design: the space is limited, so I'd really love something in SOIC-8; I only check from well known manufacturers with signed drivers (FTDI, SiLabs, Prolific, Infineon); the ability to change the USB Vendor and Product strings are very welcomed; I don't look at chips with lead time of 50+ weeks or obsolete chips that are no longer produced; it shouldn't be the most expensive part of the circuit.

PL2303GL is on the more expensive side, but considering that it has an LDO and a ROM, it's a good deal. However, if I'm unable to source a compatible Prolific OTP ROM programmer, I'm not buying these. I heard both good and bad things about WCH, but haven't really CH340 because of the drivers. Since autoreset is a good feature to have, an RTS pin might just be more valuable than an LDO, a ROM and seamless OS-support.

[SpenceKonde]

Yeah, WCH definitely has a mixed reputation; I'm convinced that most of that bad rep is underserved - because that's what is used in all the Arduino clones, which are sold by dishonest vendors who claim it's an "Arduino Uno" or an "Arduino Nano" and then people try to install the drivers for those boards. Which obviously doesn't work. That's the fault of dishonest vendors though.

Personally I have a very low opinion of prolific, as they drop driver support the moment someone counterfeits their parts, so there's a bunch of older prolific chips that you have to jump through hoops to get workling drivers for (and the ripoffs are very, ah, prolific). And I have a grudge against FTDI over FTDI gate. I still remember having to spent a whole evening working by flashlight because the lighting controller for my room got bricked because the FTDI adapter that the vendor swore on his mothers grave was legitimate was counterfeit, got bricked, and now I couldn;t turn on the lights. Though I am grudgingly uising one of their parts in a batch of boards going into prodfuction this week - a small run of quad serial adapters meant to be an AVR programmer's dream, because the only alternative was looking like it would involve poorly documented usb hub chips,.

I haven't had problems installing drivers for the CH340's on windows (the only platform I've tested with) in a very long time. Last time I had to (on a Win10 machine) there was no warning about unsigned drivers though, and I think these days they managed to get their drivers into windows update; should check that on a virgin windows system to be sure. I hear they have builtin drivers on Linux too,

I agree that the inability to change the USB identification though the OTP memory is unfortunate (though if you mean using a different VID/PID, that can cause driver problems, and if you don't have a legally registered VID and PID to use? the lords of USB do not distribute those without a hefty fee, and you expose yourself to legal risk if you use call your product USB and are using an unauthorized VID/PID). Losing the separate LDO huirts, though depending on the target market, a 100mA LDO may not cut the mustard. .

If these are little development boards for an educational setting (just taking a wild guess, based on plan to use Optiboot, and the size+cost sensitivity) kids are very good at putting crazy loads on power supplies without reallzing that they're doing so,, and durability suddenly

You have to balance that with the fact the CH340N's are readily available and dirt cheap now, (AFAICT, the PL2303GLis not actually available - neither the western vendors nor aliexpress i have them) and have the RTS pin.

Whatever you do, just don't spot those cheap abundant Holtek chips that canthave their internal EEPROM configured over USB and have some sexy looking features... They're buggy AF.

[tpimh]

alternative was looking like it would involve poorly documented usb hub chips

As for 4-port USB hubs, from my own experience: GL850G – bad, FE1.1s – good. A solution without a hub is much better, obviously.

As for the CH340 software support... On Windows: drivers are not on Windows Update as far as I know, still need to download and install them manually, Administrator permissions are required; On Linux: you just need to use a more or less recent kernel (most mainstream distros would have the module bundled); On macOS: it's a pain, just avoid using it if possible or suffer otherwise.

if you mean using a different VID/PID, that can cause driver problems

Yes, I am well aware of this. I don't want to change chip's VID/PID, just the Vendor and Product strings. Most drivers would only detect the device by VID/PID combination and ignore those strings completely, but userspace software would show the actual name of the device instead of something like "QinHeng Electronics HL-340 USB-Serial adapter".

[SpenceKonde]

Huh. It may just be that the CH340 drivers get installed so early on when I'm the one setting up the system that I forgot about it. I'm the kind of person who routinely has 3-6 CH340 serial adapters dangling off my computer at any given time,,,

I didn't realize that the mac still had problems. I knew there was an issue with the initial state of RTS and DTR being wrong or something, but the way avrdude twiddles both of those lines multiple times, makes that less of a problem for uploads.

[tpimh]

While researching this topic now, I have found two excellent parts chips: CH9340 and HT42B534.

Both implement USB CDC, which means they should work without additional drivers with any modern OS.

CH9340K is comes in ESSOP-10 (similar dimensions to SOP-8, but smaller pitch) and has RTS and DTR pins.

HT42B534 is even better: it has internal LDO and EEPROM with programming tool available. It can come in either SOP-8 (only has VDDIO) or even smaller MSOP-10 (has RTS and VDDIO).

I hope this can help someone who is searching for a good USB-UART.

[SpenceKonde]

Ht42b345 o ly looks good on paper. The drivers hang often, and it doesn't allow arbitrary speeds, only standard ones. Oh and the modem control inputs misbehave

---

Spence Konde Azzy’S Electronics

New products! Check them out at tindie.com/stores/DrAzzy GitHub: github.com/SpenceKonde ATTinyCore: Arduino support for almost every ATTiny microcontroller Contact: @.***

On Sun, Apr 17, 2022, 06:27 Dima Golovin @.***> wrote:

While researching this topic now, I have found two excellent parts chips: CH9340 and HT42B534.

Both implement USB CDC, which means they should work without additional drivers with any modern OS.

CH9340K is comes in ESSOP-10 (similar dimensions to SOP-8, but smaller pitch) and has RTS and DTR pins.

HT42B534 is even better: it has internal LDO and EEPROM with programming tool available. It can come in either SOP-8 (only has VDDIO) or even smaller MSOP-10 (has RTS and VDDIO).

I hope this can help someone who is searching for a good USB-UART.

— Reply to this email directly, view it on GitHub https://github.com/SpenceKonde/ATTinyCore/issues/682#issuecomment-1100848414, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTXEW4S6YLU7RLC4RSFDILVFPRPJANCNFSM5RXEQKNQ . You are receiving this because you modified the open/close state.Message ID: @.***>

[tpimh]

Designing the actual board layout now, I got very confused about software availability and flashing.

My hardware is HT42B534-2 (MSOP-10) and ATTINY826-XU. I believe there are only 3 lines between the two: RX to PB2, TX to PB3, RTS to AutoReset circuit on PB4. First, I would connect PA0 to an external programmer for UPDI flashing (not 100% sure what should be performed at this step, but probably I need to burn a Bootloader and a Blinky, and set fuses for 10MHz internal oscillator and alternative reset pin). Second, I should connect USB for Holtek EEPROM flashing (this is easier, I guess). After this, I would be able to flash directly from Arduino IDE over USB.

Furthermore, Optiboot_X confuses me the most. Here Optiboot for Tiny-2 series is mentioned, however in the README.md it's stated that 2-series support is expected by the first week of May (so probably should already be there, right?). So I ended up creating this issue in Optiboot repo: https://github.com/Optiboot/optiboot/issues/347

@SpenceKonde I know, this is, probably, not the right place to post this, sorry if it bothers you. This is not related to the original issue, so I will try to find a more appropriate place and repost there.

[SpenceKonde]

As documented we do not support micronucleus bootloader on parts with less than 8k of flash because the user experience is crap with so much flash wasted on the bootloader. On a 2k part there would be like no flash left for the sketch....

---

Spence Konde Azzy’S Electronics

New products! Check them out at tindie.com/stores/DrAzzy GitHub: github.com/SpenceKonde ATTinyCore: Arduino support for almost every ATTiny microcontroller Contact: @.***

On Sat, Mar 26, 2022, 10:19 Dima Golovin @.***> wrote:

Seems that micronucleus supports attiny2313 https://github.com/micronucleus/micronucleus/blob/master/firmware/configuration/t4313_default/bootloaderconfig.h, but it's not possible to upload firmware with it.

— Reply to this email directly, view it on GitHub https://github.com/SpenceKonde/ATTinyCore/issues/682, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTXEW5IVYZEEI4JOA3XEHDVB4MFJANCNFSM5RXEQKNQ . You are receiving this because you are subscribed to this thread.Message ID: @.***>