I have never looked at the EDBG package. I had just assumed it would be TQFP-32 or TQFP-44. After all, it only needs power, JTAG, USB for itself. And a handful of pins for its interface to the outside world.
When I downloaded the schematic for an Arduino Zero, I saw that it is using an 80-pin or 100-pin package.
I then looked at the STLink chip. TQFP-44 and pretty straightforward. The Chinese even sell STLink clones for about $3.
Admittedly, the EDBG chip handles more debug/programming protocols than a regular STLink or CMSIS-DAP debugger.
It still has the same number of pins for the outside world. It needs a few more kB of Flash to hold the AVR firmware.
My point has always been: it costs Atmel very little for a UC3 TQFP-44, an ARM TQFP-44, an AVR TQFP-44. But the UC3/ARM would give better performance.
NXP, Freescale, TI, ... use one of their own chips for "DBG" in their evaluation boards.
I still don't get what core independent peripheral is about. Seems like a marketing term?
Yup.
All MCU peripherals are to some degree already 'core independent'.
Any UART relieves the otherwise bit-banging SW, plus allows TX and RX to occur at the same time.
luvocean1 wrote:
How is it operationally different to any other Atmel uControllers?
I think it allows one peripheral to trigger another. Of course, MCUs have also done that for a while, without needing a sound-bite.
DMA can claim to be closer to giving 'core independent peripheral' operation, but the ATtiny817 lacks that... so the 'independent' is more marketing imagination, than dictionary-correct.
I still don't get what core independent peripheral is about.
Over in PICworld CIPs seem to refer to peripherals that are a bit more 'intelligent'. So things like counters that can measure both the period and duty of an incoming waveform without CPU intervention.
#1 This forum helps those that help themselves
#2 All grounds are not created equal
#3 How have you proved that your chip is running at xxMHz?
#4 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand." - Heater's ex-boss
I have reported a bug on the instruction set. If you urgently need to know how many cycles an instruction takes you can test them in the simulator. Just watch the cycle counter while stepping.
Now, I appreciate the response and the concern. But why would one think that the simulator would be all-knowing in this? Wouldn't the simulator implementors use the same documents released to us mortals?
You can put lipstick on a pig, but it is still a pig.
I've never met a pig I didn't like, as long as you have some salt and pepper.
No there is a chance that the simulator use some high level part based on the VHDL/Verilog logic the chip is made with.
and the data sheet , is the normal cut and paste from other papers with more or less errors.
It's for sure not done by someone that use the chips, and that could be ok if someone that know better actually did some proofreading of it, but that have never been Atmels style :(
The simulator models are made with the exact same RTL code that the chips are made with. We take all the synthesizable code, replace the necessary non-synthesizable parts with synthesizable behaviour-correct modules and compile it with http://www.veripool.org/wiki/verilator. That's why you can trust the simulator. The only thing that can prove it wrong is the real device.
The simulator in AVR Studio 4 was a C++ implementation based on the datasheets, but we figured it was too much work and too error prone. With the introduction of Simulator2 in AVR Studio 4 we started with simulator models based on the RTL code. In all Studios after AVR Studio 4 there has been only one simulator, which is the same as Simulator2.
The simulator models are made with the exact same RTL code that the chips are made with. We take all the synthesizable code, replace the necessary non-synthesizable parts with synthesizable behaviour-correct modules and compile it with http://www.veripool.org/wiki/verilator. That's why you can trust the simulator. The only thing that can prove it wrong is the real device.
The simulator in AVR Studio 4 was a C++ implementation based on the datasheets, but we figured it was too much work and too error prone. With the introduction of Simulator2 in AVR Studio 4 we started with simulator models based on the RTL code. In all Studios after AVR Studio 4 there has been only one simulator, which is the same as Simulator2.
The only thing that can prove it wrong is the real device.
sparrow2 wrote:
So if the simulator is correct LDS take 3 clk from RAM and 3 clk from IO
? True?
I'll try to get an answer from the IC designers, but I'm afraid it is so.
Who-me wrote:
How did that change impact the simulation speed ?
There is of course a trade-off between speed and accuracy. I don't have any numbers for the old simulator, but we have done some benchmarking on our models, and our smallest models executes at >=100kHz, whereas the bigger designs like UC3 is down to ~10kHz. The execution speed will of course depend on the PC you are using to run the simulation. Unfortunately the models are single threaded, so number of CPU cores have no impact. (One of the improvements we would like to seen in the Verilator is multi-threaded execution.) Cache size on the other hand matters a lot. But, I can't remember I've heard any complaints about speed, so I believe the speed is good enough for most cases.
So if the simulator is correct LDS take 3 clk from RAM and 3 clk from IO
So:
1:
It not optimized but slower than all other AVR's (in this case).
2:
Especially compared to "real" tiny's where most important IO's can reached with IN, that only take 1 clk.
And it's funny that a "clasic" AVR should be able to take other than 2 clk for LDS !!!
Short answer: "Yes, LDS takes 3 cycles in the new tinys."
I'm not sure how much of the "long answer" I'm allowed to share, so I'll leave that to others. But rest assured: There are thoughts and ideas behind this. It is not accidental. Benefits in some areas turned out negative for the LDS instruction. Other LD/ST-instructions uses same number of cycles or less.
But a quick guess is that it has a shared buss so it can only do 1 read (of any kind) pr clk, and because LDS is two instruction reads and a RAM read it will take 3 clk!
All the other LD's have only one instruction read, so it can be done in 2 clk.
One the other hand it it looks like it has both a load and store buss, so it can do a store and load at the same time.
That kind of thing happens when a post has been deleted from a thread, I think even if the reply is made after the deletion. I'd guess a spam post had previously been deleted from this enormously long and long-lived thread.
"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]
Support for using alternative pins (I/O set) for ATtiny417, ATtiny814, ATtiny816 and ATtiny817 by automatically configuring the Control C register of the Port Multiplexer (PORTMUX.CTRLC).
Microchip Continues Expansion of AVR Microcontroller Product Line with
Addition of Three New tinyAVR Devices
...
The new devices extend the memory offering for these next generation tinyAVR MCUs with new 16 KB Flash options, while remaining pin and code compatible with the recently released ATtiny817 series devices.
...
“There is more growth and innovation in the AVR MCU portfolio now than at any point in the past decade,” said Steve Drehobl, vice president of Microchip’s 8-bit MCU division. “Microchip is committed to continue the AVR MCU family of products.”
I have a little experience with other ATtiny's and so I was very interested to see these new devices. They look great.
I have one point of confusion though. I found some example code in the Atmel application note 'Atmel AVR42781: Getting Started With ATtiny417/814/816/817' on page 10:
int main (void)
{
/* Configure SW0 User Button as input */
PORTC.DIRCLR = PIN5_bm;
/* Configure Yellow LED0 pin as output */
PORTC.DIRSET = PIN0_bm;
while (1)
{
/* Check the status of SW0 User Button */
/* 0: Pressed */
if (!(PORTC.IN & (PIN5_bm)))
{
/* Yellow LED0 on */
PORTC.OUTSET = PIN0_bm;
}
/* 1: Released */
else
{
/* Yellow LED0 off */
PORTC.OUTCLR = PIN0_bm;
}
}
}
This code looks pretty different from what I am used to with other Tiny's. Does someone know of some documentation produced by Atmel (or others?) that explains this new approach?
Sorry if this is a dumb question. I'm used to things like the ATTiny 2313A for example, and the register manipulations here don't look like anything I have seen before. How to get a handle on it?
The equivalents are DDRC &= ~PIN5_bm or DDRC &= ~(1<<5)
PORTC.DIR is the same as DDRC
PORTC.OUT is PORTC
PORT.IN is PINC
.
The ARM and Xmega have steering registers like OUTCLR and OUTSET. These make life simpler and faster.
Efficient and safe access to PORT pins
– Hardware read-modify-write through dedicated toggle/clear/set registers
– Mapping of often-used PORT registers into bit-accessible I/O memory space (Virtual Ports)
This code looks pretty different from what I am used to with other Tiny's. Does someone know of some documentation produced by Atmel (or others?) that explains this new approach?
It's not really that different; you COULD have done that on previous Tinys, but it wasn't how Atmel distributed the io.h definitions for each chip.
It's a more modern C-like approach (whereas the traditional is more like "assembly code written in C.) ARM CMSIS specifies it as THE method for ARM chips (to prevent every vendor from doing it differently), and various other systems have been doing for ages.
I found this bit in a quick search ("overlaying C data structures on peripheral registers"), which describes the basic idea: http://www.e-reading.club/chapte...
Hmm, I am very late to the party, but I just noticed these "new" chips. I admit the main draw for me is that tiny817 is a quite bit cheaper than tiny84, which was my first idea.
Still seem to be some supply issues, but I think I can get the various bits without waiting with a combination of suppliers. I guess I also need to bite the bullet and get an ATMEL-ICE while I am at it ...
...but the "new" AVR devices have a super-simple programming (+debugging) interface, which means they can be programmed using a serial-port adapter and a resistor: https://github.com/mraardvark/py...
...but the "new" AVR devices have a super-simple programming (+debugging) interface, which means they can be programmed using a serial-port adapter and a resistor: https://github.com/mraardvark/py...
Fantastic! I was looking for a way for "end users" to program devices with just a simple hardware dongle and downloader. I also want to have a play with tiny10 devices though, so I need TPI as well.
...but the "new" AVR devices have a super-simple programming (+debugging) interface, which means they can be programmed using a serial-port adapter and a resistor: https://github.com/mraardvark/py...
That Python approach looks very cool :)
I have one question about the Python code, I can see it used
# Inter-byte delay
self.ibdly = 0.0001
Q: can USB-UARTS really manage that 0.1ms inter-char spacing ??.
There are many buffers in play here.. plus the 1ms USB quanta effects. Seem more optimistic than realistic ?
Q: can USB-UARTS really manage that 0.1ms inter-char spacing ??. There are many buffers in play here.. plus the 1ms USB quanta effects. Seem more optimistic than realistic ?
I guess it would depend on how you feed it, wouldn't it?
[without doing any research] I'd think that if my AVR fed my FT232R a continuous "packet" of bytes that the FT wouldn't send each individually 1ms apart.
Just more noodling: 9600bps is about 100us per bit. In my real apps, I usually use 57600.
I'd think it would be the same way the other way around -- PC sending to USB is going to load up a buffer of some type.
You can put lipstick on a pig, but it is still a pig.
I've never met a pig I didn't like, as long as you have some salt and pepper.
I have never looked at the EDBG package. I had just assumed it would be TQFP-32 or TQFP-44. After all, it only needs power, JTAG, USB for itself. And a handful of pins for its interface to the outside world.
When I downloaded the schematic for an Arduino Zero, I saw that it is using an 80-pin or 100-pin package.
I then looked at the STLink chip. TQFP-44 and pretty straightforward. The Chinese even sell STLink clones for about $3.
Admittedly, the EDBG chip handles more debug/programming protocols than a regular STLink or CMSIS-DAP debugger.
It still has the same number of pins for the outside world. It needs a few more kB of Flash to hold the AVR firmware.
My point has always been: it costs Atmel very little for a UC3 TQFP-44, an ARM TQFP-44, an AVR TQFP-44. But the UC3/ARM would give better performance.
NXP, Freescale, TI, ... use one of their own chips for "DBG" in their evaluation boards.
In fact Freescale seem to use a QFN-32 package.
David.
- Log in or register to post comments
TopDatasheet was updated :
http://www.atmel.com/devices/ATtiny817.aspx
"Dare to be naïve." - Buckminster Fuller
- Log in or register to post comments
TopBut there are still many errors in the Instruction set summery :(
- Log in or register to post comments
TopJump on the tinyX wagon ... or eat dust
I interpret the following as "decision made" (bold type for emphasis) :
"Dare to be naïve." - Buckminster Fuller
- Log in or register to post comments
TopSo they "completely review" the document.
Then the table uses the same Name for two versions (i.e. AVRe):
...yet for all those popular models in AVRe , they all apparently take no cycles for each instruction as there is no column in the table:
You can put lipstick on a pig, but it is still a pig.
I've never met a pig I didn't like, as long as you have some salt and pepper.
- Log in or register to post comments
TopThen it is a good thing that AVRe has the same timing as AVR, so we can look at that instead.
- Log in or register to post comments
TopI still don't get what core independent peripheral is about. Seems like a marketing term?
How is it operationally different to any other Atmel uControllers?
- Log in or register to post comments
TopYup.
All MCU peripherals are to some degree already 'core independent'.
Any UART relieves the otherwise bit-banging SW, plus allows TX and RX to occur at the same time.
I think it allows one peripheral to trigger another. Of course, MCUs have also done that for a while, without needing a sound-bite.
DMA can claim to be closer to giving 'core independent peripheral' operation, but the ATtiny817 lacks that... so the 'independent' is more marketing imagination, than dictionary-correct.
- Log in or register to post comments
TopOver in PICworld CIPs seem to refer to peripherals that are a bit more 'intelligent'. So things like counters that can measure both the period and duty of an incoming waveform without CPU intervention.
#1 This forum helps those that help themselves
#2 All grounds are not created equal
#3 How have you proved that your chip is running at xxMHz?
#4 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand." - Heater's ex-boss
- Log in or register to post comments
TopLike that it has improved timing!
It a tiny where most IO is outside IN/OUT reach , and yet it's the only AVR where LDS take 3 clk !!!!
(I guess that it's only a typo but it shows how bad AVR datasheets are)
- Log in or register to post comments
TopI suppose we will have to measure the timings ourselves and report them to Atmel?
- Log in or register to post comments
TopI have reported a bug on the instruction set.
If you urgently need to know how many cycles an instruction takes you can test them in the simulator. Just watch the cycle counter while stepping.
- Log in or register to post comments
TopNow, I appreciate the response and the concern. But why would one think that the simulator would be all-knowing in this? Wouldn't the simulator implementors use the same documents released to us mortals?
You can put lipstick on a pig, but it is still a pig.
I've never met a pig I didn't like, as long as you have some salt and pepper.
- Log in or register to post comments
TopSo if the simulator is correct LDS take 3 clk from RAM and 3 clk from IO
So:
1:
It not optimized but slower than all other AVR's (in this case).
2:
Especially compared to "real" tiny's where most important IO's can reached with IN, that only take 1 clk.
And it's funny that a "clasic" AVR should be able to take other than 2 clk for LDS !!!
- Log in or register to post comments
TopNo there is a chance that the simulator use some high level part based on the VHDL/Verilog logic the chip is made with.
and the data sheet , is the normal cut and paste from other papers with more or less errors.
It's for sure not done by someone that use the chips, and that could be ok if someone that know better actually did some proofreading of it, but that have never been Atmels style :(
Edit
The auto reply number is wrong (one to big)
- Log in or register to post comments
TopThe simulator models are made with the exact same RTL code that the chips are made with. We take all the synthesizable code, replace the necessary non-synthesizable parts with synthesizable behaviour-correct modules and compile it with http://www.veripool.org/wiki/verilator. That's why you can trust the simulator. The only thing that can prove it wrong is the real device.
The simulator in AVR Studio 4 was a C++ implementation based on the datasheets, but we figured it was too much work and too error prone. With the introduction of Simulator2 in AVR Studio 4 we started with simulator models based on the RTL code. In all Studios after AVR Studio 4 there has been only one simulator, which is the same as Simulator2.
- Log in or register to post comments
TopYou can put lipstick on a pig, but it is still a pig.
I've never met a pig I didn't like, as long as you have some salt and pepper.
- Log in or register to post comments
TopThat's impressive.
How did that change impact the simulation speed ?
- Log in or register to post comments
TopI'll try to get an answer from the IC designers, but I'm afraid it is so.
There is of course a trade-off between speed and accuracy. I don't have any numbers for the old simulator, but we have done some benchmarking on our models, and our smallest models executes at >=100kHz, whereas the bigger designs like UC3 is down to ~10kHz. The execution speed will of course depend on the PC you are using to run the simulation. Unfortunately the models are single threaded, so number of CPU cores have no impact. (One of the improvements we would like to seen in the Verilator is multi-threaded execution.) Cache size on the other hand matters a lot. But, I can't remember I've heard any complaints about speed, so I believe the speed is good enough for most cases.
- Log in or register to post comments
TopShort answer: "Yes, LDS takes 3 cycles in the new tinys."
I'm not sure how much of the "long answer" I'm allowed to share, so I'll leave that to others. But rest assured: There are thoughts and ideas behind this. It is not accidental. Benefits in some areas turned out negative for the LDS instruction. Other LD/ST-instructions uses same number of cycles or less.
- Log in or register to post comments
TopBut a quick guess is that it has a shared buss so it can only do 1 read (of any kind) pr clk, and because LDS is two instruction reads and a RAM read it will take 3 clk!
All the other LD's have only one instruction read, so it can be done in 2 clk.
One the other hand it it looks like it has both a load and store buss, so it can do a store and load at the same time.
- Log in or register to post comments
TopThe link is bad again!
Add:
Funny this is a reply to #1 but that don't show
- Log in or register to post comments
TopAnd Atmel have same problem the first thing that pop up on Atmel.com with a search for "tiny817" is a dead link (the correct come as number 8 or so)
- Log in or register to post comments
TopThat kind of thing happens when a post has been deleted from a thread, I think even if the reply is made after the deletion. I'd guess a spam post had previously been deleted from this enormously long and long-lived thread.
"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
TopThis
http://www.atmel.com/Images/Atme...
shows 1616 as 16k/20p and 1617 as 16k/24p, as expected
- Log in or register to post comments
Tophttps://www.iar.com/iar-embedded-workbench/#!?architecture=AVR&device=ATtiny1617
"Dare to be naïve." - Buckminster Fuller
- Log in or register to post comments
TopThough no stock (it's forthcoming) microchipDIRECT has entries for
onetwo tinyX AVR :http://www.microchipdirect.com/productsearch.aspx?Keywords=ATtiny817
via
https://octopart.com/search?q=attiny817&avg_avail=(1__*)&start=0
tiny816 :
http://www.microchipdirect.com/productsearch.aspx?Keywords=attiny816
Edit : tiny816
"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
TopMay one spare the one bearing the message? (hint : cut and paste errors? mergers & acquisitions exuberance?)
due to :
http://www.microchip.com/samples/Default.aspx?DeviceFamily=ATTINY1617
Edits : strikethru on and off, samples URL
"Dare to be naïve." - Buckminster Fuller
- Log in or register to post comments
TopPICs?
You have gotta be kidding me!
Definitely "fake news"...
Ross McKenzie ValuSoft Melbourne Australia
- Log in or register to post comments
TopRoss you "hair" is not the right colour.
John Samperi
Ampertronics Pty. Ltd.
www.ampertronics.com.au
* Electronic Design * Custom Products * Contract Assembly
- Log in or register to post comments
TopYeah... the buggie microwave turned it grey/white.
Ross McKenzie ValuSoft Melbourne Australia
- Log in or register to post comments
Topdue to
https://www.avrfreaks.net/forum/attiny1617-launch-avrfreaks-give-away
"Dare to be naïve." - Buckminster Fuller
- Log in or register to post comments
TopI have a little experience with other ATtiny's and so I was very interested to see these new devices. They look great.
I have one point of confusion though. I found some example code in the Atmel application note 'Atmel AVR42781: Getting Started With ATtiny417/814/816/817' on page 10:
int main (void) { /* Configure SW0 User Button as input */ PORTC.DIRCLR = PIN5_bm; /* Configure Yellow LED0 pin as output */ PORTC.DIRSET = PIN0_bm; while (1) { /* Check the status of SW0 User Button */ /* 0: Pressed */ if (!(PORTC.IN & (PIN5_bm))) { /* Yellow LED0 on */ PORTC.OUTSET = PIN0_bm; } /* 1: Released */ else { /* Yellow LED0 off */ PORTC.OUTCLR = PIN0_bm; } } }This code looks pretty different from what I am used to with other Tiny's. Does someone know of some documentation produced by Atmel (or others?) that explains this new approach?
Sorry if this is a dumb question. I'm used to things like the ATTiny 2313A for example, and the register manipulations here don't look like anything I have seen before. How to get a handle on it?
Thanks.
- Log in or register to post comments
TopThe equivalents are DDRC &= ~PIN5_bm or DDRC &= ~(1<<5)
PORTC.DIR is the same as DDRC
PORTC.OUT is PORTC
PORT.IN is PINC
.
The ARM and Xmega have steering registers like OUTCLR and OUTSET. These make life simpler and faster.
- Log in or register to post comments
Topvia http://www.microchip.com/wwwproducts/en/ATxmega32E5
Meanwhile, what's in the datasheet :
"Dare to be naïve." - Buckminster Fuller
- Log in or register to post comments
TopIt's not really that different; you COULD have done that on previous Tinys, but it wasn't how Atmel distributed the io.h definitions for each chip.
It's a more modern C-like approach (whereas the traditional is more like "assembly code written in C.) ARM CMSIS specifies it as THE method for ARM chips (to prevent every vendor from doing it differently), and various other systems have been doing for ages.
I found this bit in a quick search ("overlaying C data structures on peripheral registers"), which describes the basic idea: http://www.e-reading.club/chapte...
- Log in or register to post comments
TopThe 32KB tinyX will fill-out the flash part of the unified memory.
The 2KB tinyX might be for growth from a tiny102 and tiny104.
"Dare to be naïve." - Buckminster Fuller
- Log in or register to post comments
Top16KB tinyX AVR datasheet was updated today :
http://ww1.microchip.com/downloads/en/DeviceDoc/40001893A.pdf (5MB)
via
http://www.microchip.com/wwwproducts/en/attiny1617
"Dare to be naïve." - Buckminster Fuller
- Log in or register to post comments
TopMouser has placed an order (MCU, URL, ETA) :
tiny1617, http://www.mouser.com/search/ProductDetail.aspx?R=0virtualkey0virtualkeyATtiny1617-MFR, 2017-
05-22051506-16http://new.microchipdirect.com/ProductSearch.aspx?keywords=ATtiny1617
Edits : ETA
"Dare to be naïve." - Buckminster Fuller
- Log in or register to post comments
TopIn stock at microchipDIRECT :
http://new.microchipdirect.com/ProductDetails.aspx?Catalog=BuyMicrochip&Category=ATTINY1617
"Dare to be naïve." - Buckminster Fuller
- Log in or register to post comments
TopThe location of the USERROW EEPROM page is at the end of Table 7.1 Peripheral Module Address Map.
- Log in or register to post comments
TopHmm, I am very late to the party, but I just noticed these "new" chips. I admit the main draw for me is that tiny817 is a quite bit cheaper than tiny84, which was my first idea.
Still seem to be some supply issues, but I think I can get the various bits without waiting with a combination of suppliers. I guess I also need to bite the bullet and get an ATMEL-ICE while I am at it ...
Bob.
- Log in or register to post comments
TopNothing wrong with buying an Atmel-ICE...
...but the "new" AVR devices have a super-simple programming (+debugging) interface, which means they can be programmed using a serial-port adapter and a resistor: https://github.com/mraardvark/py...
- Log in or register to post comments
Tophttps://www.avrfreaks.net/forum/cant-figure-out-how-program-attiny817#comment-2034271
"Dare to be naïve." - Buckminster Fuller
- Log in or register to post comments
TopFantastic! I was looking for a way for "end users" to program devices with just a simple hardware dongle and downloader. I also want to have a play with tiny10 devices though, so I need TPI as well.
Bob.
- Log in or register to post comments
TopThat Python approach looks very cool :)
I have one question about the Python code, I can see it used
# Inter-byte delay
self.ibdly = 0.0001
Q: can USB-UARTS really manage that 0.1ms inter-char spacing ??.
There are many buffers in play here.. plus the 1ms USB quanta effects. Seem more optimistic than realistic ?
- Log in or register to post comments
Tophttps://www.avrfreaks.net/forum/ch340g-ic-vendor#comment-2115341
https://www.exar.com/products/interface/uarts/usb-uarts
"Dare to be naïve." - Buckminster Fuller
- Log in or register to post comments
TopI guess it would depend on how you feed it, wouldn't it?
[without doing any research] I'd think that if my AVR fed my FT232R a continuous "packet" of bytes that the FT wouldn't send each individually 1ms apart.
Just more noodling: 9600bps is about 100us per bit. In my real apps, I usually use 57600.
I'd think it would be the same way the other way around -- PC sending to USB is going to load up a buffer of some type.
You can put lipstick on a pig, but it is still a pig.
I've never met a pig I didn't like, as long as you have some salt and pepper.
- Log in or register to post comments
TopPages