1N5817 is leaky with a Cjo of 200pF but it'll still work.
SB120 leaks less with a bit less Cjo.
Correction:
Needs to be a low Cjo Schottky as a 5V USB UART with a low Vcc AVR will cause RESET(dW) -0.5V limit to be exceeded.
SB120 would be better though the best solution is to patch a low Cjo SMD Schottky.
Maybe one from the RB751 series but its forward voltage may be too large for a low Vcc AVR that's at freezing ambient.
BAT54 is better; SOD123 or SOT23 (single, not the duals), low forward voltage well below freezing, leaky, capacitance of 10pF max is too large for 5V USB UART and 2.5V AVR
BAT54 is from more than several manufacturers; can be patched (1.8mm or 3.3mm pitch) though would be easier on a snippet of protoboard (can add pins and/or sockets to create a dwire-debug adapter)
To reduce EOS with a USB UART and AVR (large) voltage mismatch, insert a 499 to 1Kohm resistor between USB UART TXD and BAT54's cathode.
This will be marginal (dW floor, overshoot) with a 2V AVR.
The excessive overshoot is corrected by decreasing TXD's transition speed via inserting a capacitor to ground between an 499 ohm resistor and the Schottky diode's cathode; 1nF for 1N5817, 47pF for BAT54.
Note:
RESET(dW) doesn't have an ESD diode to VCC so observe your ESD training.
If concerned, there are low Cjo TVS that will clamp well before RESET's 13V abs max yet not leak too much at 5V operating.
ESD damage initially manifests as leaky transistors unless the ESD/EOS/EFT/lightning has enough energy then the FET's body diode will short or the gate oxide will be punched through.
Some ESD generates enough EMP to destroy electronics across a small room due to induction (wires are an antenna)
Could try a new mega328P if you think the current one's RESET(dW) signal is flaky or the EOS may have damaged the debugWIRE machine.
The debugWIRE hardware implementation fixes the baud rate at target clock speed/128.
So an estimated max speed of 200Kbps would theoretically support targets of up to 128 x 200KHz = 25.6MHz, a little more than the official 20MHz max speed of these AVR devices.
It works for me with short separated wires. I would avoid long wires, especially in close proximity as in a multiway flat cable.
The work by RikusW suggests baud rates as high as /8 are available, with /128 the default. Have you determined this to be untrue?
I realise that bus characteristics will dictate the maximum attainable speed, but smaller prescalers would permit faster dW comms with lower system clock speeds.
"Experience is what enables you to recognise a mistake the second time you make it."
"Good judgement comes from experience. Experience comes from bad judgement."
"Wisdom is always wont to arrive late, and to be a little approximate on first possession."
"When you hear hoofbeats, think horses, not unicorns."
"Fast. Cheap. Good. Pick two."
"We see a lot of arses on handlebars around here." - [J Ekdahl]
Though not as ubiquitous as a Schottky diode, a level converter would be functional for all dW AVR at all Vcc for the full temperature range for any voltage USB UART.
Some of the packages for such are SOIC and SOT23 so would be easy to protoboard.
I agree logic levels could be to blame, but we're that the case I would expect all operations to exhibit the same hit/miss ratio. I also agree that the added load of erase/program operations could tip the scales, but we're that the case I would expect that erase operations would fail in equal measure to write operations. They do not. I had been using an all-0xFF binary file to 'erase' the chip during testing. I don't believe I have seen that fail. Only write operations with 'non-empty' payloads seem to fail.
I have more testing to do, and I'll implement your suggestions, but it will likely not happen until at least next week, because I am here:
"Experience is what enables you to recognise a mistake the second time you make it."
"Good judgement comes from experience. Experience comes from bad judgement."
"Wisdom is always wont to arrive late, and to be a little approximate on first possession."
"When you hear hoofbeats, think horses, not unicorns."
"Fast. Cheap. Good. Pick two."
"We see a lot of arses on handlebars around here." - [J Ekdahl]
The only time I wouldn't mind a faster connection is when programming a lot of flash, but it's not really been a serious issue.
dwdebug is very careful not to erase or program unnecessarily.
Single-stepping via GDB/DDD or similar, with data watch windows, can require polling large data blocks and the entire register file. Would be nice if that could be faster. I notice a real difference between running a 1 MHz target with a 7.8kbps dW speed v.s. a 16 MHz target with a 125kps dW speed.
"Experience is what enables you to recognise a mistake the second time you make it."
"Good judgement comes from experience. Experience comes from bad judgement."
"Wisdom is always wont to arrive late, and to be a little approximate on first possession."
"When you hear hoofbeats, think horses, not unicorns."
"Fast. Cheap. Good. Pick two."
"We see a lot of arses on handlebars around here." - [J Ekdahl]
OK, I couldn't wait. A quick build and test with a 328P suggests the problems I had earlier with intermittent success at programming the328P have disappeared. A quick return to the old build shows those problems remain intermittent, so whatever it was appears to have been resolved with the latest repo.
r29 issue appears to have been remedied as claimed. Other testing will have to wait.
"Experience is what enables you to recognise a mistake the second time you make it."
"Good judgement comes from experience. Experience comes from bad judgement."
"Wisdom is always wont to arrive late, and to be a little approximate on first possession."
"When you hear hoofbeats, think horses, not unicorns."
"Fast. Cheap. Good. Pick two."
"We see a lot of arses on handlebars around here." - [J Ekdahl]
The latest version barfs with this shortly after ddd connects (via avr-gdb) with 'target remote':
Attempt to read beyond end of flash.
... while ddd reports:
Remote connection closed
Seems ddd tries to fetch machine code past the end of flash, and dwdebug terminates. While ddd probably shouldn't do that, I didn't have that problem with the older version of dwdebug.
One step forward, two steps back :(
Anyone know how to tell ddd how big flash is, and/or how not to read past the end?
"Experience is what enables you to recognise a mistake the second time you make it."
"Good judgement comes from experience. Experience comes from bad judgement."
"Wisdom is always wont to arrive late, and to be a little approximate on first possession."
"When you hear hoofbeats, think horses, not unicorns."
"Fast. Cheap. Good. Pick two."
"We see a lot of arses on handlebars around here." - [J Ekdahl]
Scratch that. The other version did that as well. I'll have to do more testing to figure out what's stopping me from making headway with the new version.
Still interested in getting ddd to play nice with dwdebug.
Any other gdb front ends apart from ddd which someone can recommend?
"Experience is what enables you to recognise a mistake the second time you make it."
"Good judgement comes from experience. Experience comes from bad judgement."
"Wisdom is always wont to arrive late, and to be a little approximate on first possession."
"When you hear hoofbeats, think horses, not unicorns."
"Fast. Cheap. Good. Pick two."
"We see a lot of arses on handlebars around here." - [J Ekdahl]
GDB/MI is a line based machine oriented text interface to GDB. It is specifically intended to support the development of systems which use the debugger as component of a larger system. See The GDB/MI Interface in the GDB manual.
gdbgui - Feature rich browser-based frontend with data structure visualizations (like DDD), and gdb terminal access. Compatible with C, C++, golang, Rust, fortran. Written in Python and JavaScript. pip install gdbgui.
Note how the content of address 0x1e through 0x40 match that of the machine code view from ddd, confirming that it is pulling from SRAM and not flash. Except for the word at 0x001E (which is EEARH:L), and at 0x003E (which is SPH and SREG), the remaining words match, so it would seem that flash addresses are getting converted to SRAM addresses before issuing the commands to the avr-gdb backend.
In a similar vein, attempts to display data memory fail with addresses associated with SRAM i.e. offset by 0x800000.
I'm afraid I have no idea how to drive this thing, and debugging directly at the dwdebug command line seems onerous. I'll likely live without debugging for a while yet ;-)
"Experience is what enables you to recognise a mistake the second time you make it."
"Good judgement comes from experience. Experience comes from bad judgement."
"Wisdom is always wont to arrive late, and to be a little approximate on first possession."
"When you hear hoofbeats, think horses, not unicorns."
"Fast. Cheap. Good. Pick two."
"We see a lot of arses on handlebars around here." - [J Ekdahl]
Thanks for the reminder! Something in the back of my memory was nagging me. Some years ago I'd fiddled with simulavr and ran into the same problem. As I recall, when I used avr-gdb (v7.8) from Atmel's toolchain, it was broken in this way. If I rolled back to my distro's v6.4, the problem went away. I think it created other problems, though. I don't remember.
When I have time, I'll try that here with dwdebug and report back.
Comment 20 Eyck Jentzsch 2017-04-04 18:47:21 UTC
Hi,
the submission of the patch to gdb-patches is more than a year old. Is there any estimate when this patch will become part of the main line?
Oy. Nearly six-year-old thread, and still not resolved :(
"Experience is what enables you to recognise a mistake the second time you make it."
"Good judgement comes from experience. Experience comes from bad judgement."
"Wisdom is always wont to arrive late, and to be a little approximate on first possession."
"When you hear hoofbeats, think horses, not unicorns."
"Fast. Cheap. Good. Pick two."
"We see a lot of arses on handlebars around here." - [J Ekdahl]
When I have time, I'll try that here with dwdebug and report back.
You are welcome to try an already patched gdb 8.0 for linux x64 (if you are willing to trust a binary file downloaded from an unverified source): https://github.com/ccrause/fpc-a...
When I have time, I'll try that here with dwdebug and report back.
Confirm that 6.4 works (although as I said, there are other problems... mostly likely due to the fact that I don't know how to drive this thing ;-)
You are welcome to try an already patched gdb 8.0 for linux x64 (if you are willing to trust a binary file downloaded from an unverified source): https://github.com/ccrause/fpc-a...
I generally don't, but thanks, I may give it a try.
"Experience is what enables you to recognise a mistake the second time you make it."
"Good judgement comes from experience. Experience comes from bad judgement."
"Wisdom is always wont to arrive late, and to be a little approximate on first possession."
"When you hear hoofbeats, think horses, not unicorns."
"Fast. Cheap. Good. Pick two."
"We see a lot of arses on handlebars around here." - [J Ekdahl]
Hypothesis:
Switching diode's forward voltage is close to RESET's limit of 0.1 * Vcc (500mV for 5V)
Tool:
Heatgun
Test:
Heat the diode halfway to boiling.
Is dwire-debug functional?
Proposed Solution:
Schottky diode
One of many is BAS70 from https://www.avrfreaks.net/forum/debugwire-usb-uart#comment-2287616 at Cjo of 3pF (or near equivalent)
1N5817 is leaky with a Cjo of 200pF but it'll still work.
SB120 leaks less with a bit less Cjo.
Correction:
Needs to be a low Cjo Schottky as a 5V USB UART with a low Vcc AVR will cause RESET(dW) -0.5V limit to be exceeded.
SB120 would be better though the best solution is to patch a low Cjo SMD Schottky.
Maybe one from the RB751 series but its forward voltage may be too large for a low Vcc AVR that's at freezing ambient.
BAT54 is better; SOD123 or SOT23 (single, not the duals), low forward voltage well below freezing, leaky, capacitance of 10pF max is too large for 5V USB UART and 2.5V AVR
BAT54 is from more than several manufacturers; can be patched (1.8mm or 3.3mm pitch) though would be easier on a snippet of protoboard (can add pins and/or sockets to create a dwire-debug adapter)
To reduce EOS with a USB UART and AVR (large) voltage mismatch, insert a 499 to 1Kohm resistor between USB UART TXD and BAT54's cathode.
This will be marginal (dW floor, overshoot) with a 2V AVR.
The excessive overshoot is corrected by decreasing TXD's transition speed via inserting a capacitor to ground between an 499 ohm resistor and the Schottky diode's cathode; 1nF for 1N5817, 47pF for BAT54.
Note:
RESET(dW) doesn't have an ESD diode to VCC so observe your ESD training.
If concerned, there are low Cjo TVS that will clamp well before RESET's 13V abs max yet not leak too much at 5V operating.
ESD damage initially manifests as leaky transistors unless the ESD/EOS/EFT/lightning has enough energy then the FET's body diode will short or the gate oxide will be punched through.
Some ESD generates enough EMP to destroy electronics across a small room due to induction (wires are an antenna)
Could try a new mega328P if you think the current one's RESET(dW) signal is flaky or the EOS may have damaged the debugWIRE machine.
http://www.onsemi.com/PowerSolutions/product.do?id=BAS70SL (SMD)
http://www.onsemi.com/PowerSolutions/product.do?id=1N5817 (thru-hole)
http://www.onsemi.com/PowerSolutions/product.do?id=SB120 (thru-hole)
http://www.onsemi.com/PowerSolutions/product.do?id=RB751S40 (SMD)
http://www.onsemi.com/PowerSolutions/product.do?id=BAT54 (SMD)
Edits : correction, RB751, BAT54, resistor, capacitor
"Dare to be naïve." - Buckminster Fuller
- Log in or register to post comments
TopLike PDI, UPDI is symmetric impedance with tri-state whereas dW is open drain with active and hold pull-ups.
Edit : pull-ups
"Dare to be naïve." - Buckminster Fuller
- Log in or register to post comments
TopThe debugWIRE hardware implementation fixes the baud rate at target clock speed/128.
So an estimated max speed of 200Kbps would theoretically support targets of up to 128 x 200KHz = 25.6MHz, a little more than the official 20MHz max speed of these AVR devices.
It works for me with short separated wires. I would avoid long wires, especially in close proximity as in a multiway flat cable.
- Log in or register to post comments
TopThe work by RikusW suggests baud rates as high as /8 are available, with /128 the default. Have you determined this to be untrue?
I realise that bus characteristics will dictate the maximum attainable speed, but smaller prescalers would permit faster dW comms with lower system clock speeds.
"Experience is what enables you to recognise a mistake the second time you make it."
"Good judgement comes from experience. Experience comes from bad judgement."
"Wisdom is always wont to arrive late, and to be a little approximate on first possession."
"When you hear hoofbeats, think horses, not unicorns."
"Fast. Cheap. Good. Pick two."
"We see a lot of arses on handlebars around here." - [J Ekdahl]
- Log in or register to post comments
Toptiny85
Input Low-voltage, RESET pin
VIL2 < 0.2 * VCC
mega328P
VIL2 < 0.1 * VCC
Though not as ubiquitous as a Schottky diode, a level converter would be functional for all dW AVR at all Vcc for the full temperature range for any voltage USB UART.
Some of the packages for such are SOIC and SOT23 so would be easy to protoboard.
"Dare to be naïve." - Buckminster Fuller
- Log in or register to post comments
TopOh yes! I just looked at RikusW's notes again. I'd forgotten all about that so I never got around to trying it.
Mostly the clock/128 speed is fine.
The only time I wouldn't mind a faster connection is when programming a lot of flash, but it's not really been a serious issue.
dwdebug is very careful not to erase or program unnecessarily.
- Log in or register to post comments
TopI agree logic levels could be to blame, but we're that the case I would expect all operations to exhibit the same hit/miss ratio. I also agree that the added load of erase/program operations could tip the scales, but we're that the case I would expect that erase operations would fail in equal measure to write operations. They do not. I had been using an all-0xFF binary file to 'erase' the chip during testing. I don't believe I have seen that fail. Only write operations with 'non-empty' payloads seem to fail.
I have more testing to do, and I'll implement your suggestions, but it will likely not happen until at least next week, because I am here:
"Experience is what enables you to recognise a mistake the second time you make it."
"Good judgement comes from experience. Experience comes from bad judgement."
"Wisdom is always wont to arrive late, and to be a little approximate on first possession."
"When you hear hoofbeats, think horses, not unicorns."
"Fast. Cheap. Good. Pick two."
"We see a lot of arses on handlebars around here." - [J Ekdahl]
- Log in or register to post comments
TopFilling the barn with hay and/or chopping fire wood I would guess before winter.
Or painting the barn red???
Jim
(Possum Lodge oath) Quando omni flunkus, moritati.
"I thought growing old would take longer"
- Log in or register to post comments
TopActually, just visiting. Not a working farm any more.
But it is far from my workshop ;-)
"Experience is what enables you to recognise a mistake the second time you make it."
"Good judgement comes from experience. Experience comes from bad judgement."
"Wisdom is always wont to arrive late, and to be a little approximate on first possession."
"When you hear hoofbeats, think horses, not unicorns."
"Fast. Cheap. Good. Pick two."
"We see a lot of arses on handlebars around here." - [J Ekdahl]
- Log in or register to post comments
TopSingle-stepping via GDB/DDD or similar, with data watch windows, can require polling large data blocks and the entire register file. Would be nice if that could be faster. I notice a real difference between running a 1 MHz target with a 7.8kbps dW speed v.s. a 16 MHz target with a 125kps dW speed.
"Experience is what enables you to recognise a mistake the second time you make it."
"Good judgement comes from experience. Experience comes from bad judgement."
"Wisdom is always wont to arrive late, and to be a little approximate on first possession."
"When you hear hoofbeats, think horses, not unicorns."
"Fast. Cheap. Good. Pick two."
"We see a lot of arses on handlebars around here." - [J Ekdahl]
- Log in or register to post comments
Top"Dare to be naïve." - Buckminster Fuller
- Log in or register to post comments
TopSweet! Don't know when I'll have time to give this attention, but it is high on my list. Thanks for the update!
"Experience is what enables you to recognise a mistake the second time you make it."
"Good judgement comes from experience. Experience comes from bad judgement."
"Wisdom is always wont to arrive late, and to be a little approximate on first possession."
"When you hear hoofbeats, think horses, not unicorns."
"Fast. Cheap. Good. Pick two."
"We see a lot of arses on handlebars around here." - [J Ekdahl]
- Log in or register to post comments
TopOK, I couldn't wait. A quick build and test with a 328P suggests the problems I had earlier with intermittent success at programming the328P have disappeared. A quick return to the old build shows those problems remain intermittent, so whatever it was appears to have been resolved with the latest repo.
r29 issue appears to have been remedied as claimed. Other testing will have to wait.
"Experience is what enables you to recognise a mistake the second time you make it."
"Good judgement comes from experience. Experience comes from bad judgement."
"Wisdom is always wont to arrive late, and to be a little approximate on first possession."
"When you hear hoofbeats, think horses, not unicorns."
"Fast. Cheap. Good. Pick two."
"We see a lot of arses on handlebars around here." - [J Ekdahl]
- Log in or register to post comments
TopJust to be clear, I built from the lwire repo as suggested by the author in #49:
"Experience is what enables you to recognise a mistake the second time you make it."
"Good judgement comes from experience. Experience comes from bad judgement."
"Wisdom is always wont to arrive late, and to be a little approximate on first possession."
"When you hear hoofbeats, think horses, not unicorns."
"Fast. Cheap. Good. Pick two."
"We see a lot of arses on handlebars around here." - [J Ekdahl]
- Log in or register to post comments
Top"Dare to be naïve." - Buckminster Fuller
- Log in or register to post comments
TopWell, that was short-lived.
The latest version barfs with this shortly after ddd connects (via avr-gdb) with 'target remote':
... while ddd reports:
Seems ddd tries to fetch machine code past the end of flash, and dwdebug terminates. While ddd probably shouldn't do that, I didn't have that problem with the older version of dwdebug.
One step forward, two steps back :(
Anyone know how to tell ddd how big flash is, and/or how not to read past the end?
"Experience is what enables you to recognise a mistake the second time you make it."
"Good judgement comes from experience. Experience comes from bad judgement."
"Wisdom is always wont to arrive late, and to be a little approximate on first possession."
"When you hear hoofbeats, think horses, not unicorns."
"Fast. Cheap. Good. Pick two."
"We see a lot of arses on handlebars around here." - [J Ekdahl]
- Log in or register to post comments
TopScratch that. The other version did that as well. I'll have to do more testing to figure out what's stopping me from making headway with the new version.
Still interested in getting ddd to play nice with dwdebug.
Any other gdb front ends apart from ddd which someone can recommend?
"Experience is what enables you to recognise a mistake the second time you make it."
"Good judgement comes from experience. Experience comes from bad judgement."
"Wisdom is always wont to arrive late, and to be a little approximate on first possession."
"When you hear hoofbeats, think horses, not unicorns."
"Fast. Cheap. Good. Pick two."
"We see a lot of arses on handlebars around here." - [J Ekdahl]
- Log in or register to post comments
Topgdbgui?
(haven't tried it)
"Dare to be naïve." - Buckminster Fuller
- Log in or register to post comments
TopI figured out what I was doing wrong with ddd and reading beyond the end of flash. It had to do with the order in which I issued commands to ddd.
Now, of course, there are other issues.
The machine code doesn't show flash contents, but SRAM:
Note the addresses which start at 0x800000.
Compare that to a data dump from the dwdebug command line:
Note how the content of address 0x1e through 0x40 match that of the machine code view from ddd, confirming that it is pulling from SRAM and not flash. Except for the word at 0x001E (which is EEARH:L), and at 0x003E (which is SPH and SREG), the remaining words match, so it would seem that flash addresses are getting converted to SRAM addresses before issuing the commands to the avr-gdb backend.
In a similar vein, attempts to display data memory fail with addresses associated with SRAM i.e. offset by 0x800000.
I'm afraid I have no idea how to drive this thing, and debugging directly at the dwdebug command line seems onerous. I'll likely live without debugging for a while yet ;-)
"Experience is what enables you to recognise a mistake the second time you make it."
"Good judgement comes from experience. Experience comes from bad judgement."
"Wisdom is always wont to arrive late, and to be a little approximate on first possession."
"When you hear hoofbeats, think horses, not unicorns."
"Fast. Cheap. Good. Pick two."
"We see a lot of arses on handlebars around here." - [J Ekdahl]
- Log in or register to post comments
TopPerhaps related to this gdb issue: https://sourceware.org/bugzilla/show_bug.cgi?id=13519 ?
- Log in or register to post comments
TopThanks for the reminder! Something in the back of my memory was nagging me. Some years ago I'd fiddled with simulavr and ran into the same problem. As I recall, when I used avr-gdb (v7.8) from Atmel's toolchain, it was broken in this way. If I rolled back to my distro's v6.4, the problem went away. I think it created other problems, though. I don't remember.
When I have time, I'll try that here with dwdebug and report back.
Oy. Nearly six-year-old thread, and still not resolved :(
"Experience is what enables you to recognise a mistake the second time you make it."
"Good judgement comes from experience. Experience comes from bad judgement."
"Wisdom is always wont to arrive late, and to be a little approximate on first possession."
"When you hear hoofbeats, think horses, not unicorns."
"Fast. Cheap. Good. Pick two."
"We see a lot of arses on handlebars around here." - [J Ekdahl]
- Log in or register to post comments
TopYou are welcome to try an already patched gdb 8.0 for linux x64 (if you are willing to trust a binary file downloaded from an unverified source): https://github.com/ccrause/fpc-a...
- Log in or register to post comments
TopConfirm that 6.4 works (although as I said, there are other problems... mostly likely due to the fact that I don't know how to drive this thing ;-)
I generally don't, but thanks, I may give it a try.
"Experience is what enables you to recognise a mistake the second time you make it."
"Good judgement comes from experience. Experience comes from bad judgement."
"Wisdom is always wont to arrive late, and to be a little approximate on first possession."
"When you hear hoofbeats, think horses, not unicorns."
"Fast. Cheap. Good. Pick two."
"We see a lot of arses on handlebars around here." - [J Ekdahl]
- Log in or register to post comments
TopN-channel JFET as a level translator :
https://www.avrfreaks.net/forum/simple-voltage-level-shifter-questions#comment-2310346
"Dare to be naïve." - Buckminster Fuller
- Log in or register to post comments
Top"Dare to be naïve." - Buckminster Fuller
- Log in or register to post comments
Topmore issues :
https://github.com/dcwbrown/dwire-debug/issues
https://github.com/dcwbrown/dwire-debug/blob/master/ReadMe.md
https://github.com/dcwbrown/dwire-debug/commits/master/ReadMe.md
via the build badge early in the readme :
https://semaphoreci.com/dcwbrown/dwire-debug
PL-2303HX is EOL
https://www.microchip.com/wwwproducts/en/ATtiny13A
Edit: build badge, PL2303HXD
"Dare to be naïve." - Buckminster Fuller
- Log in or register to post comments
TopAwesome, thank you!
- Log in or register to post comments
Top"Dare to be naïve." - Buckminster Fuller
- Log in or register to post comments
Top"Dare to be naïve." - Buckminster Fuller
- Log in or register to post comments
TopmacOS is forthcoming :
Add support for MacOS by DeqingSun · Pull Request #39 · dcwbrown/dwire-debug · GitHub
and merged 5-Nov'18
Edit: merged
"Dare to be naïve." - Buckminster Fuller
- Log in or register to post comments
Topmerged :
Enable dwire-debug usage with VScode by DeqingSun · Pull Request #41 · dcwbrown/dwire-debug · GitHub
"Dare to be naïve." - Buckminster Fuller
- Log in or register to post comments
TopDigisparkSync doen't work for long startup time · Issue #40 · dcwbrown/dwire-debug · GitHub
closed by a solution : https://github.com/dcwbrown/dwire-debug/issues/40#issuecomment-436489702
Digispark USB Development Board - Digistump
Edit: closed
"Dare to be naïve." - Buckminster Fuller
- Log in or register to post comments
Topin-work :
Reduce wait time in dwReadBytes to boost transfer rate from 160Bps to 487Bps by DeqingSun · Pull Request #42 · dcwbrown/dwire-debug · GitHub
"Dare to be naïve." - Buckminster Fuller
- Log in or register to post comments
TopATmega48PA AddrFlag · Issue #44 · dcwbrown/dwire-debug · GitHub
"Dare to be naïve." - Buckminster Fuller
- Log in or register to post comments
TopUsbtiny not work but ft232 usb-serial working · Issue #46 · dcwbrown/dwire-debug · GitHub
"Dare to be naïve." - Buckminster Fuller
- Log in or register to post comments
TopPages