Attiny3226,1626 uploading the program and at the same time monitoring the serial port

[Brendy1986]

I would like to upload the program as in the classic Arduino and run the serial port monitor to have a preview without switching the cable.

[hmeijdam]

Invest 2 or 3 dollar in an extra USB-serial adapter and keep that connected to the TX/RX pin while uploading via UPDI with the modified serial USB adapter.
At least that is what I did and works exactly as you describe.
I am using HTERM as terminal program as the IDE cannot open 2 comports at the same time.

[SpenceKonde]

On the 2-series with 20 or 24 pins this is easy.

Set for alt-reset on PB4, and wire the classic DTR autoreset to that pin.

Bootload with optiboot via UPDI, and you've got it.

For everything else, since you need a reset to enter the bootloader, you have to plug+unpluig the board to upload via optboot so it's not as nice.
Now, if you don't want to use the bootloader and want a single serial adapter that can both upload and do serial console, that is just not possible. However the boards I sell default to connecting the almost-never-used CTS pin of the FTDI header to UPDI. With a special dual serial adapter (I eventually gave up on the idea of a non-dual adapter doing this - I've made attempts, but they never came close to working, and now WCH has a dual serial adapter IC which is a much more graceful solution). One of the designs I'm ordering next will be a CH342K with it's first port brought out to every pin except the what was nominally the CTS line (which by default is tied to UPDI). It's second port is wired for UPDI with the UPDI line connected to that nominal CTS pin. Thus, with my breakouts and that future serial+updi adapter, when the second port selected in Arduino IDE, uploads will happen via UPDI, and using the first port, you get the serial console. (there's never a way to do UPDI and serial over the same port - they need different connections, meaning you need to either switch the port in the method I described above, or flip a switch on the serial adapter. But because the Arduino IDE's serial monitor is a terrible, terrible serial monitor which lacks every feature I consider a must have (I run windows, and use HTerm, which was written by an embedded software person and has all the good features), I don't think that's a problem - in fact, having the 2 ports is better, because that way you can keep the port open in the external console, while uploading on the other port of the dual serial adapter.

But yeah, those are the options. Either you have to use a bootloader, or you have to have a dual serial adapter and either a Rev. C breakout board from me on default settings or Rev. B with CT-UP jumper bridged.

On the 1-series and 14-pin 2-series, the dual serial adapter method is the only one that doesn't require unplugging anything, unless you're willing to sacrifice easy UPDI programming and have an HV UPDI programmer, in which case you can fuse UPDI to act as reset, wire up autoreset and use optiboot (note that autoreset needs to be disabled on those parts case when using any sort of UPDI programming - as in not connected to the UPDI/Reset pin, by clearing the RST_EN jumper on my boards or disconnecting it on some other board.

I think most people do what @hmeijdam does - we just have two serial adapters, one permanently rigged as a UPDI adapter and one left as a normal serial adapter (and again, this has the bonus of being able to keep the port open during the uploads with an external serial monitor, which you want to use because the IDE's serial monitor is trash)

[SpenceKonde]

(actually, I have a shitload of serial adapters, and a shitload of serial adapters rigged for perma-UPDI, because everything uses fucking dupont connectors, and I use the adapters so much that the cables crap out constantly if I dont use the eye-wateringly expensive real Dupont connectors (I've had 5 serial adapters rigged for permaupdi fail to work at the same time. 1 was totally busted, 2 had a crack in the diode, and 2 had tired cheapo dupont connectors on them that had stopped working. Chinese dupont terminals are TERRIBLE, particularly on a 3-pin cable (more stress on each terminal). They're a knockoff not of the DuPont connector (which was an excellent connector) but Harwin's M20 connector. Harwin's connector wasn't very good even from a western manufacturer, and the chinese cheaping out just made the design worse) - it was a knockoff of the real DuPont connector. Real DuPont connectors supply the retaining force via a leaf spring. The ones derived from the M20 on the other hand (including all the chinese ones) just rely on the brass (or sometimes plated steel - a while back I dragged a magnet through my bin of dupont cables and threw everything that stuck to it into the junk bin - it was about half of the jumpers). Brass is not a good spring material, as it deforms permanently to a greater extent than it springs back to it's original shape.

Youll notice, if you look, that the DuPont/dupont connector is the only common connector where there isn't some sort of soft-latch molded into the plastic, so the plastic can handle some of the force. You can't do that on dupont-like terminals, since they, uniquely, are a 0.1" pitch connector that fits entirely in a 0.1" square....

That's why harwin connectors are rated for 100 connection cycles (gold plated, inserted and removed with a machine that does it with perfect technique; humans are worse than machines at unplugging and plugging connectors without damage to the terminals), and DuPont connectors are rated for 1000 connection cycles, followed by several hours in a corrosive atmosphere, and the specification states that at that point there is a maximum that the contact resistance is permitted to have increased by (vs harwin, where the 100 connection cycles appears to be for working at all, vs working and maintaining low contact resistance, and with no exposure to moist hydrogen sulfide atmospheres to accelerate corrosion). The chinese connectors likely fall well short of the reliability of the harwin ones that they're a knockoff of. And that's certainly consistent with my experience using them. I also had all 4 of my Jtag2UPDI's fail (all due to dupont connector issues) within a day of eachother.

DuPont spun out their connector division to Berg to focus on their core business of manufacturing polluted drinking water, which they're one of world leaders in now, and then Berg was bought by connector giant Amphenol, and they now sell the good terminals. Be sure you get the right part number - you want the ultra-high spring force version with the right size for the thickness of wire you want to crimp onto them, and you definitely want the gold plating on them, and expect to pay about 30 cents per terminal. There are like 4 (wire thickness) * 4 (spring force) * 7 (surface treatment) * 2 (box of individual terminals for a 2:1 markup vs a strip that you need to cut apart with wirecutters (can't bend them back and forth to snap it off like you can on most terminals)) for around 200 different part numbers, not counting the historical discontinued part numbvers still in catalogs.

Or use chinese dupont terminals, and be prepared to clip them off and crimp on new ones regularly, because they suck.

[hmeijdam]

Muldental in Germany makes and sells servo connectors that can have 1000 cycles

[SpenceKonde]

Interesting - they dupont compatible? I think I've run into them occasionally - I suspect they are better by far than the chinese crap ones, but worse than real DuPont ones, because they still use only a single piece of stamped metal, and with single piece of stamped metal, you will never get the kind of reliability you can with an actual spring

[hmeijdam]

Yes. Servo plugs have the 0.1 inch pitch as well.

[SpenceKonde]

I couldn't immediately see what the price per terminal was on those? Where do they fall between the 1.5 cent chinese ones and the 25-30 cent Amphenol ones based on the DuPont design?

[hmeijdam]

Approx $ 5.- per 10pcs

[Brendy1986]

thanks for the help will try tomorrow. I did it quickly and it also works, the program is uploaded and I have a preview on the monitor, only later I have to disconnect because the processor does not go into a deep sleep, I have 1.5mA but you can upload and check the program on the monitor, everything is visible.

[SpenceKonde]

Recheck power consumption after a power cycle after bootloading, I thought we were always properly disabling updi, but that sounds like about the amount of waste if updibwas not properly disabled

…

____________ 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 Fri, Jan 27, 2023, 16:37 Brendy1986 ***@***.***> wrote: thanks for the help will try tomorrow. I did it quickly and it also works, the program is uploaded and I have a preview on the monitor, only later I have to disconnect because the processor does not go into a deep sleep, I have 1.5mA but you can upload and check the program on the monitor, everything is visible. [image: Screenshot_2023-01-27-22-36-36-535_org telegram messenger] <https://user-images.githubusercontent.com/118827809/215205377-4fbc75a7-f941-40cb-afa0-555decf61212.jpg> — Reply to this email directly, view it on GitHub <#904 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABTXEW2ERV7EMCRGJG3U52TWUQ5Z7ANCNFSM6AAAAAAUJCSABI> . You are receiving this because you commented.Message ID: ***@***.*** com>

[Brendy1986]

Something like this happens:
with a 1.5mA diode, I disconnect the diode, press interrupt and then 1.5mA.
I disconnect the diode and disconnect the power supply, I jack up again, I press interrupt and then it's about 0.8uA from the RTC.
by the way, if he wants to check the program, the patent with a diode works.
What do you think, can I leave it like this?
Is there any way to fix this when it comes to sleeping?

[SpenceKonde]

1.5mA diode? Huh?

Do you mean disconnecting the serial-adapter as updi? Because you'd just programmed via updi? Thsts what I was saying - I thought we were correctly killing the updi session, but if you see excess power usage of around 1.5ma when you try to deepsleep, when you have programmed via updi since the previous power cycle, I guess there's a bug in serialupdi. It's an easy bug to end up with, because you won't notice it unless you check power consumption and nobody tests power consumption while developing the programming tooling. And by nobody I mean I didn't and I did most of development of serialupdi after it was initially made to work. Them Quentin would look and my hideous google-written python, and polished it up into something slightly less ugly, though the microchip code is as ugly as mine, for ib large part the same reason: c programmers writing python as if it was c (though they also did an inexpert job of combining several tools). I thoroughly regret using that as the basis for serialupdi.

[Brendy1986]

yes, programming via UPDI.
when I upload the program with the diode connected as in the diagram. I disconnect the programmer and connect the batteries and the processor itself has a consumption of over 3mA and drops to 1.5mA, it means that the processor does not go into deep sleep through the diode.
I think I can make a smd switch on the pcb, which will disconnect the 1n4148. If I want to take readings from the port monitor, the switch will turn on 1n4148

[SpenceKonde]

Okay, I'm finally home and am able to clearly see that schematic.

You can't have the serial adapter wired such that transmitting or receiving normal console messages drive the UPDI line. Any UART activity can cause the UPDI to activate, which can have unpredictable but never desirable effects.

The TX and RX serial line used for the console should not be connected to the same wire as UPDI. That is why I recommend either using the optiboot approach, or the dual serial adapter approach.

[Brendy1986]

Thank you for your response. I understand, I will take it into account.
hmmm I've been using it for over 1.5 years and haven't noticed anything wrong.
I finally managed to get rid of the 1.5mA current draw. I tested and it works. Everything from one programmer upload and read.

[SpenceKonde]

One thing worth noting - there has been one method that I had always hoped would solve the issue of wanting one port for UPDI and serial. I eventually gave up. The dual adapter solution is more functional anyway as the serial console can stay connected during the upload.

Here's the key trick: Using SerialUPDI, neither DTR nor RTS are asserted (driven low) while the port is open. The vast majority of serial consoles however, assert both of them whenever the port is open (i consider the lack of a way to configure this to be disqualifying in terms of serial consoles, and it rules out at least 90% of such programs, though compared to the other features whole absence disqualifies a serial console, it barely registers as a filter); hterm lets you select whether DTR and/or RTS are asserted, either after the port is open, or before you open the port, in which case the settings are applied as soon as the port is opened).

So, if you imagine yourself with perfect knowledge of the state of the wires coming from the non-USB side of the adapter, and perfect ignorance of everything else - as is the case for the wiring between the adapter and target, (and assuming you know that when using a REAL serial console you've gotta have it assert a control line), you know whether the port is being used by a serial console, or is unused or being used for UPDI.

Thus, you should be able to use a bidirectional analog switch - these are readily available and cheap as dirt, having debuted with the 7400 series of parts decades ago; a common configuration is a TPDT one - 3 common pins, call 1, 2 and 3 can each connect to one of two pins, call them A and B, and the connection depends on the level of an select pin. So with SEL on DTR or RTS, when DTR is high, TX and RX (connected to say 1 and 2) would be connected to 1A and 2A, which are connected to the UPDI diode and/or resistor. When DTR/RTS goes low, it's a serial monitor not UPDI, and 1 and 2 would be connected to 1B and 2B, which would be connected to RX and TX of the target. The third switch can be used to illuminate an LED to indicate what mode it is in, for example. I have tried to build this several time, and have never successfully made one that, when plugged into the computer, did not immediately experience hardware failure as evidenced by the port being shut down for overcurrent, the adapter or analog switch getting hot, or in one case, a pop noise and a wisp of smoke. I never understood those failures. And without understanding a problem, fixing it is a fools errand.

* I know of only a single program, hterm, that has several features that I feel are 100% non negotiable absolute must haves. With thousands of serial console tools in existence, these represent must-have features whose absence eliminates 99%+ of the serial consoles. It's as if the people had no fucking idea what the people using serial today need. Today UART is almost exclusively the province of embedded and industrial systems which almost universally use bespoke protocols that cannot be interpreted effectively without them: the ability simultaneously display input as BOTH ascii and hex (hterm takes it a step further and and even does binary and decimal, though the former is too bulky and thus limits how much can be shown at once, and the latter of very rare usefulness), the option to highlight parity and framing errors (how the hell are you supposed to debug serial comms problems, particularly in software serial implementations if all you see is the incorrect character? Short of using a scope instead of a serial console, you can't! You have no idea if the sender sent the wrong character, or sent the right character and instead the serial implementation is malfunctioning!), and the ability to build a string to send (in one go) from a mixture of ascii and hex (which makes it impossible to send, say, a message wherein the start of the message and/or field delimiters are ascii control characters, but between those are readable ascii characters). It's common to be able to switch between hex and ascii, but if the receiving device has a timeout that is faster than human scale (say, if it starts getting a message, but considers the message invalid and ignores it if theres more than 50ms between successive characters or something), you would need to go to hex mode, and then manually convert the message to hex, add in the control characters, and send as hex.). I mean for fucks sake, you could probably rule out >90% of serial consoles simply by the fact that they don't bother to display the state of the 4 modem control inputs. Did you know that a proper serial adapter has 2 outputs and 4 inputs - general purpose inputs and outputs (active low/open drain, inputs are pulled up internally by the adapter). In the case where the device is on the opposite end of a long usb cable to the adapter, such that it is out of your line of sight, or you're using remote desktop to a headless computer located in another room, town or continent, and you don't have a webcam there to watch the status LEDs through), you can use the inputs on the adapter to serve purposes you might normally serve with an LED by connecting them instead of the LEDs, and see it on the computer screen. This is a functionality that I relied extensively upon to debug a device that couldn't be connected into a functional form without sealing it in a case (the crucial antenna would have required a saw to separate from the case) which I was responsible for the firmware but not the hardware of (if I was responsible for the hardware, they probably wouldn't have needed to hire me for the firmware, but the hardware designer made half a dozen unforced errors because I don't think they'd read the datasheet nor ever even used an AVR before)

[Brendy1986]

I uploaded the bootloader via UPDI. I connected but I can't upload anything, I keep getting an error.

[SpenceKonde]

that shows rx of adapter connected to rx of target. Serial needs each part's Tx pin connected to the other's Rx pin (Tx and Rx are Transmit and Receive - you want each device to receive what the other transmits).

Serial doesn't imply any sort of protocol (like SPI, where the directions of the pins is defined relative to which device is initiating the transaction and generating the clock, or in I2C where there is detailed process for a transfer, Serial defines only the concept of data framing, and that the idle state of the line is high; the two devices are peers with equal right to transmit data at any time. The only way you can have communication in that case is by giving each device one pin they can send on, and another they can transmit on, and requiring that each part's receive is connected to the other transmit.

[Brendy1986]

there is an error in the diagram, I connected it crosswise all the time, the same does not upload