ATtiny417 / ATtiny814 / ATtiny816 / ATtiny817

Go To Last Post
285 posts / 0 new

Pages

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

Last Edited: Sat. Dec 10, 2016 - 12:01 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

But there are still many errors in the Instruction set summery :(

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Jump on the tinyX wagon ... or eat dust

I interpret the following as "decision made" (bold type for emphasis) :

AVR Instruction Set Manual
(file size: 2.4MB, 191 pages, revision L, updated: 11/2016)

http://www.atmel.com/Images/Atmel-0856-AVR-Instruction-Set-Manual.pdf

...

 

(page 22)

Table 4-1. Versions of AVR 8-bit CPU

Name, Device Series, Description

...

AVRxt

(AVR)

AVR 2016 and onwards. This variant is based on AVRe and AVRxm.

Closer related to AVRe, but with improved timing.

...

 

(page 189)

129. Datasheet Revision History

...

129.1. Rev.0856L - 11/2016

A complete review of the document.

...

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gchapman wrote:
AVRxt (AVR) AVR 2016 and onwards. This variant is based on AVRe and AVRxm. Closer related to AVRe, but with improved timing.

 

So 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.

Last Edited: Sun. Dec 18, 2016 - 01:41 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:

...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:

 

Then it is a good thing that AVRe has the same timing as AVR, so we can look at that instead.

 

Last Edited: Sun. Dec 18, 2016 - 10:13 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I 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?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

luvocean1 wrote:

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.

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

luvocean1 wrote:

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.

'This forum helps those who help themselves.'

 

pragmatic  adjective dealing with things sensibly and realistically in a way that is based on practical rather than theoretical consideration.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Like 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) 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sparrow2 wrote:

Like 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) 

 

I suppose we will have to measure the timings ourselves and report them to Atmel?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

je_ruud wrote:
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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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 !!! 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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 :(

 

 

Edit

The auto reply number is wrong (one to big)

Last Edited: Tue. Dec 20, 2016 - 08:03 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

je_ruud wrote:
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?

 

 

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

je_ruud wrote:

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.

 

That's impressive.

How did that change impact the simulation speed ?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:

je_ruud wrote:
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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sparrow2 wrote:

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The link is bad again!

 

Add:

Funny this is a reply to #1 but that don't show

 

Last Edited: Tue. Dec 20, 2016 - 08:50 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

And 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)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The link is bad again!

 

Add:

Funny this is a reply to #1 but that don't show

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."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

http://packs.download.atmel.com/#collapse-Atmel-ATtiny-DFP-pdsc

...

1.2.112 ... Addded support for ATtiny1617 and ATtiny1616.

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

 

gchapman wrote:

http://packs.download.atmel.com/#collapse-Atmel-ATtiny-DFP-pdsc

...

1.2.112 ... Addded support for ATtiny1617 and ATtiny1616.

 

This 

http://www.atmel.com/Images/Atme...

shows 1616 as 16k/20p and 1617 as 16k/24p, as expected 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

"Dare to be naïve." - Buckminster Fuller

Last Edited: Thu. Jan 26, 2017 - 02:23 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Atmel START

Change Log

http://start.atmel.com/static/help/index.html?GUID-DC086BFD-7DA2-43E8-8AE0-457F2351FF4C

2017 - January:

...

Content:

New devices / boards:

...

  • ATtiny1616 and ATtiny1617

...

Features:

  • 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).

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

May one spare the one bearing the message?  (hint : cut and paste errors?  mergers & acquisitions exuberance?)

Microchip Technology Inc

Microchip

ATTINY1617 - 8-bit PIC Microcontrollers

http://www.microchip.com/wwwproducts/en/attiny1617

Samples Available

...

 

(expand Documentation, near bottom, Product Document, datasheet dated 03/13/2017)

http://ww1.microchip.com/downloads/en/DeviceDoc/40001893A.pdf (5MB)

...

Microchip Technology Inc

Microchip

ATTINY1616 - 8-bit PIC Microcontrollers

http://www.microchip.com/wwwproducts/en/attiny1616

Future Product

...

Microchip Technology Inc

Microchip

ATTINY1614 - 8-bit PIC Microcontrollers

http://www.microchip.com/wwwproducts/en/attiny1614

Future Product

...

due to :

Atmel START

Change Log

http://atmel-studio-doc.s3-website-us-east-1.amazonaws.com/webhelp/GUID-4E095027-601A-4343-844F-2034603B4C9C-en-US-1/index.html?GUID-DC086BFD-7DA2-43E8-8AE0-457F2351FF4C

2017 - March:

....

 

New examples:

...

  • Getting Started With ATtiny1617
  • Getting Started Events ATtiny817
  • Quadrature Decoding using CCL with TCA and TCB (ATtiny1617)
  • Core Independent Night Light using CCL (ATtiny1617)

 

...

 


http://www.microchip.com/samples/Default.aspx?DeviceFamily=ATTINY1617

 

Edits : strikethru on and off, samples URL

 

"Dare to be naïve." - Buckminster Fuller

Last Edited: Sat. May 20, 2017 - 08:17 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

PICs?

 

You have gotta be kidding me!

 

Definitely "fake news"...

 

Ross McKenzie ValuSoft Melbourne Australia

Last Edited: Thu. Mar 16, 2017 - 12:35 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ross you "hair" is not the right colour.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yeah... the buggie microwave turned it grey/white.

Ross McKenzie ValuSoft Melbourne Australia

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Microchip Technology Inc

Microchip

New tinyAVR® MCUs Increase System Throughput While Lowering Power Consumption in Embedded Applications

Chandler, Ariz., March 13, 2017

https://www.microchip.com/en/pressreleasepage/new-tinyavr-mcus-1617

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.”

 

For more information, visit: www.microchip.com/1617series

[http://www.microchip.com/promo/tiny1617-mcu-family]

...

 

Pricing and Availability

The three new tinyAVR MCUs are available today for sampling and in volume production.

  • The ATtiny1617 is available in a QFN24 package starting at $0.68 for 10k units.
  • The ATtiny1616 is available in a QFN20 and SOIC20 package starting at $0.67 and $0.55 respectively for 10k units.
  • The ATtiny1614 is available in a SOIC14 package starting at $0.52 for 10k units.  

...

due to

http://www.avrfreaks.net/forum/attiny1617-launch-avrfreaks-give-away

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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?

 

Thanks.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Swulf wrote:
Does someone know of some documentation produced by Atmel (or others?) that explains this new approach?
Am not aware of a tinyX document that's equivalent to

AVR1313: Using the XMEGA IO Pins and External Interrupts

http://ww1.microchip.com/downloads/en/AppNotes/doc8050.pdf

via http://www.microchip.com/wwwproducts/en/ATxmega32E5

Meanwhile, what's in the datasheet :

http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-42721C-AVR-ATtiny417-814-816-817-Datasheet_Complete.pdf

(page 146)

16.  PORT - I/O Pin Controller

 

16.1 Features

...

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)

 

16.2 Overview

...

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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...

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

http://packs.download.atmel.com/#collapse-Atmel-ATtiny-DFP-pdsc

...

1.2.118 Added support for ATtiny3217, ATtiny3216, ATtiny3214, ATtiny1617, ATtiny1616, ATtiny1614, ATtiny416, ATtiny414, ATtiny412, ATtiny214 and ATtiny212.

The 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

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

"Dare to be naïve." - Buckminster Fuller

Last Edited: Wed. May 10, 2017 - 12:11 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

The location of the USERROW EEPROM page is at the end of Table 7.1 Peripheral Module Address Map.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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 ...

Bob.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Nothing 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...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

mraardvark wrote:

Nothing 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...

 

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.

Bob.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

mraardvark wrote:

Nothing 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...

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 ?

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Who-me wrote:
Q: can USB-UARTS really manage that 0.1ms inter-char spacing ??.
Exar has high throughput USB UARTs; did not examine its latency.

http://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

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Who-me wrote:
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.

Pages