Replies: 8 comments 3 replies
-
|
Compliments on your interesting post. |
Beta Was this translation helpful? Give feedback.
-
|
Did you find that the write delay resulted in actually "turning a profit" in terms of time? my experience was that the actual total upload time suffered significantly with the write delay, because the python sleep() function sleeps for longer than requested. Upload time is often dominated by USB latency rather than transfer time. Also with write delay of 1, you will likely get the same behavior as 2, because it actually sleeps for significantly longer than that. There is the implied buffer of 3 bytes (the TXDATAL, the buffer behind it, and the shift register, that can be filled, and data is lost at the start bit of the fourth byte. I am not very good at python though, and I couldn't find a way to get tighter control over the timing in python. That the difference between 115200 baud and 921600 baud is enough to make it work or not on so many parts without write delay is amazing. that's 36 * ((1/115200) - (1/921600) ) = 0.25ms that makes the difference between success and failure... (36 = 3 bytes * (8 data bits + 1 start bit + 1 parity bit + 2 stop bits)) I have definitely had problems where, without the schottky, the lows didn't get low enough to be recognized, though.... |
Beta Was this translation helpful? Give feedback.
-
I recorded times below as reported by
|
Beta Was this translation helpful? Give feedback.
-
I'll test that out later and post some numbers. Although, my main goal is to test the limits so I can find a reasonable compromise between performance and stability.
Thanks, good to know! I used 2 for "good measure" in case 1 was just borderline-working.
I wonder if there is some variability with the ATtiny chips or generations. I thought I'd try out a "worst case scenario" with the
and despite obnoxiously high 1.2V lows, programming was completely reliable at 921600:
Of course, in this case, it makes sense to replace the diode with a wire, which brings the lows down to 0.8V (and up to 0.5V when the UPDI pin is driving the line):
|
Beta Was this translation helpful? Give feedback.
-
|
Edit: OH! you have a buffer in there! Yeah, that makes sense. That's a simple enough addition... I'm interested to know if you see the same sort of behavior I did if you don't have the buffer. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, with the buffer, the adapters are seeing a clean & strong 3.3V on RX. But after seeing your message, I double checked, and a big yikes on my end. What I thought was an FTDI cable is actually a CP2102 cable - this one specifically. At least my original measurements for my CP2105 and what I now know to be a CP2102 are identical! I'll correct the original post. I do plan to test without the buffers after I try a few more things with the existing test circuit. My hunch is that the biggest factor for the best diode & resister setup is going to be whether or not a 470Ω (or other) resistor is protecting the UPDI port. |
Beta Was this translation helpful? Give feedback.
-
|
https://stackoverflow.com/questions/43771575/accurate-sleep-delay-within-python-while-loop Hmmm.... maybe one of those methods could be adapted. |
Beta Was this translation helpful? Give feedback.
-
|
wow, real science, always like that, tnx :-) |
Beta Was this translation helpful? Give feedback.
-
|
This intrigued me enough to throw together a design based on CH340N and dual buffer, 20mm x 16mm, with a switch to turn power from USB (5v) on or off, 3-pin UPDI connection, with target Vcc always used as the voltage the buffer is powered by, while the CH340N is powered at 5V so it should work across to fit the holes in the poor-mans-panels I'm going to send out this weekend. A dozen part placements including a PTC fuse so an excessive load and a shoddy USB current limiting circuit (these are common) can't trash the switch (which has low current limit, because it's a tiny SMD switch, and an indicator LED (bicolor hooked up between RTS and TX - so you get an indication if another program opens the port (almost everything drives RTS low, SerialUPDI doesn't, for almost this exact reason - to tell it apart from the majority of programs that might access the port), and an indication when there's transmitting activity. - and it only needs one resistor (trying to keep the board small and partcount low - this is the first time I get to use the 0.1uF capacitor networks I hunted down a few months back: I needed 3 0.1uF caps right in the middle of the board, each one connected between ground and a different supply rail. For once, those were a useful part. |
Beta Was this translation helpful? Give feedback.
-
|
I just checked in some changes for 2.5.6 that should help with this. |
Beta Was this translation helpful? Give feedback.
-
|
Thats great, I’ll check it out! From command-line, is the primary change the accuracy of the write delay option, or are there additional changes to test? |
Beta Was this translation helpful? Give feedback.
-
I've been struggling to achieve better than 115200bps using SerialUPDI with several adapters for a while, but was surprised recently in the other direction. A CH340E chip on a custom board worked at 921600bps with pretty much any diode and resistor configuration.
Obviously, with the CH340E the UPDI pin looked good on the scope, but the others looked fine too after adjusting resistor and diode configurations despite maxing out at 115200bps. So, I've attempted to isolate the many variables that can affect performance.
Given a capable UART adapter, I've identified the following factors that may affect SerialUPDI performance:
prog.py) quality and timing characteristicsBelow, I'll describe my attempt to abstract away differences in serial adapter hardware through the use of buffers to a) analyze the software (driver and
prog.py) for UART chips independently of the above hardware factors, and b) explore the limits of the UPDI hardware on ATtinys in a controlled environment.The Test Circuit
A 74LVC2G125 buffer was used between the serial adapters and UPDI pin with the expectations that:
the buffers would be able to perform I/O at maximum possible speed on each of the serial adapters,
the UPDI side of the buffers would be consistent and well understood (i.e. consisent drive strength, no series resistor on TX unless one is added, etc.), and
for any given serial adapter, the test framework would provide the best chance of success at high bitrates.
The following test circuit was used:
The following rationale was used for component selection:
Test Circuit Performance
The test circuit was measured to see if it met the following performance goals:
There are two sets of rise and fall times to consider. The first (A) is when the adapter's TX pin pulls the UPDI signal high or low. The second (B) is when the adapter's TX is held high, and the UPDI pin asserts high or low.
The following adapters were tested:
FTDICP2102 USB adapterAs the charts show below, all criteria was met. The horizontal scale is 1µs/div. The UPDI pin is in yellow, and the buffered TX in purple.
fake-PL2303:
CP2102:
CP2105:
CH340E:
So... Does it Work? What About the Drivers and Software?
As mentioned, I previously had trouble achieving speeds above 115200 with some adapters. This appears to have been primarily a driver & software problem.
While working on this, I discovered the SerialUPDI (
prog.py) option-wd WRITEDELAY:Setting
-wd 2improved high speed capability in many scenarios. I tested on Linux (Raspberry Pi 5.10.63-v7l+, armv7l) and MacOS (iMac Pro, Monterey 12.1) with various settings and results. All tests were performed with megaTinyCore version 2.5.4 from command line.Results:
-wd 0-wd 2-wd 0-wd 2-wd 0-wd 2-wd 0-wd 2-wd 0-wd 0-wd 0-wd 2-wd 0-wd 2So, the results are encouraging. With the right driver and software, 921600bps is quite achievable, but
prog.pydoesn't always work with default settings.What Else Can We Learn?
With the test framework in place, components can be adjusted to push the limits of the UPDI port which will help us better design UPDI adapters and set a reference for what should work from a hardware perspective.
Below I'll take a look at the need for the R2 "parallel" pullup resistor and Schottky vs. Small Signal Diode selection.
Is the "Parallel" Pullup Resistor R2 Necessary?
A pullup resistor on the UPDI line of some sort is necessary to reduce rise times for high speed programming. This fact is masked in some real-world UPDI programmers as USB to UART adapters often have pullups on the RX pin, which is directly attached to the UPDI line. But unless the pullup is very strong, another pullup will be required for 921600bps.
The benefit of using a resistor parallel to the D1 diode rather than a pullup to VCC is that the pullup is only required when the TX line is high. When TX is low, the UPDI line will be pulled low, and a pullup to VCC would be counter
productive.
The test circuit calls for a
4.7kparallel resistor, but additional values were tested to show the impact on UPDI rise times.For short (1µs) pulses, a 22k pullup is not adequate to fully pull the UPDI line high:
A 33k pullup is slightly worse:
The test circuit continued to work with no pullup at 921600bps, but the rise time was clearly too low, leaving no margin for error:
Of the adapters I tested, the CH340E had the strongest internal RX pullup, about 20k on my chip, but an additional pullup would still help to assure 921600bps support.
Schottky or not?
Disclaimer: the following is based on my testing and my very basic understanding of the fundamentals. Feedback is welcome.
Using a Schottky diode instead of a silicon small signal diode between TX and UPDI would affect the circuit in a few ways:
Note that even when slowed down by a series resistor, testing has shown that TX can quickly drive UPDI to an acceptably low voltage. The larger concern is the UPDI pin's slow rise time as TX transitions from low to high.
Therefore, for item 1) above, a "lower low" does not provide a real benefit. And, if anything, a lower low may be counter-productive as it may increase the time it takes the UPDI pin to rise to an acceptable high voltage level.
Item 2) actually helps. Given that some sort of pullup is necessary on the UPDI pin, leakage current is beneficial. However, a parallel resistor achieves the same in a much more straightforward and controllable fashion.
Item 3) isn't a huge concern in the test circuit, but may cause problems for real-world UPDI adapters as using a Schottky diode causes slower rise and fall times as the UPDI pin asserts high and low.
Tests were performed with a big, slow 1N5817 Schottkt Diode in place of the 1N4148 signal diode, with interesting results. The parallel 4.7k resistor was also removed. The CH340E adapter was used.
First, we can see that despite the removal of the parallel resistor, rise times on the UPDI pin when driven by TX were very fast:
CH340E with Schottky and without Parallel Resistor
Second, we can see the drag on rise and fall times when driven by the UPDI pin:
CH340E with Schottky and without Parallel Resistor
In my estimation, using a Schottky diode increases complexity without significant benefit, and may cause problems when the UPDI pin drives the line.
Conclusions
prog.pyfor higher data rates. If rise and fall times are within 1µs, failures may be on the software side.Corrections
Beta Was this translation helpful? Give feedback.
All reactions