| Author |
Message |
|
|
Posted: Nov 25, 2009 - 06:19 AM |
|


Joined: Mar 28, 2001
Posts: 20374
Location: Sydney, Australia (Gum trees, Koalas and Kangaroos, No Edelweiss)
|
|
|
Quote:
Are you saying that the XMEGA's USART is connected to USART1
No, the XMEGA's USART1 is used for "future"?? PDI programming, but I'm thinking of hacking the board. There are 2 resistors that can be removed to free up USART1, all that is then required is to connect the USART1 pins to USARTC0 in the XMEGA.
The pins currently used for soft uart can just be left connected as long as they are inputs in the 1287.
edit I can't see the .hex file for the bridge, I can try it if you get it compiled. |
_________________ John Samperi
Ampertronics Pty. Ltd.
www.ampertronics.com.au
* Electronic Design * Custom Products * Contract Assembly
|
| |
|
|
|
|
|
Posted: Nov 25, 2009 - 07:47 AM |
|


Joined: Jan 23, 2004
Posts: 9827
Location: Trondheim, Norway
|
|
Hmm, I've been meaning to add PDI support to my AVRISP programmer project, since the official AVRISP-MKII now supports it. If I get that going, I could extend the bridge to allow for PDI programming also. It would be ironic if I manage to get it all up and running before Atmel does...
Nothing EVER works the first time in these sorts of things, but I've attached the build of the first version here for you to try.
- Dean  |
_________________ Atmel Studio 6.1 is now released, grab it here.
Report AS6/ASF bugs here.
|
| |
|
|
|
|
|
Posted: Nov 25, 2009 - 08:25 AM |
|


Joined: Mar 28, 2001
Posts: 20374
Location: Sydney, Australia (Gum trees, Koalas and Kangaroos, No Edelweiss)
|
|
OK so where do I get the drivers now for LUFA? I have programmed the new code into the chip but windows want to know where the drivers are located.  |
_________________ John Samperi
Ampertronics Pty. Ltd.
www.ampertronics.com.au
* Electronic Design * Custom Products * Contract Assembly
|
| |
|
|
|
|
|
Posted: Nov 25, 2009 - 08:28 AM |
|


Joined: Jan 23, 2004
Posts: 9827
Location: Trondheim, Norway
|
|
Whoops! Sorry! The firmware actually uses Windows' own CDC drivers, but you need a special INF file in order for it to use them. Point the driver wizard to the attached file once you've renamed the extention to .INF.
- Dean  |
_________________ Atmel Studio 6.1 is now released, grab it here.
Report AS6/ASF bugs here.
|
| |
|
|
|
|
|
Posted: Nov 25, 2009 - 08:34 AM |
|


Joined: Mar 28, 2001
Posts: 20374
Location: Sydney, Australia (Gum trees, Koalas and Kangaroos, No Edelweiss)
|
|
| SUCCESS!! I'll try it now with another Xmega program see how it beHaves. |
_________________ John Samperi
Ampertronics Pty. Ltd.
www.ampertronics.com.au
* Electronic Design * Custom Products * Contract Assembly
|
| |
|
|
|
|
|
Posted: Nov 25, 2009 - 08:35 AM |
|


Joined: Jan 23, 2004
Posts: 9827
Location: Trondheim, Norway
|
|
You can receive and send data?!
That's GOT to be a first. Granted, all the components have been tested individually, but for something to work first time is nothing short of a miracle.
Also, the LUFA bridge implements proper buffering and whatnot, and so should be as suceptable to lost characters as the official code apparently is.
- Dean  |
_________________ Atmel Studio 6.1 is now released, grab it here.
Report AS6/ASF bugs here.
|
| |
|
|
|
|
|
Posted: Nov 25, 2009 - 08:36 AM |
|


Joined: Aug 13, 2006
Posts: 6701
Location: Bellingham, WA - USA
|
|
| From the looks of the avatar above it would appear the space aliens have snatched Dean and replaced him with someone else. It also happened to my daughter as a senior in high school. |
_________________ Chuck Baird
"It's better to catch the trapeze than test the safety net" -- RPi book
http://www.cbaird.org
|
| |
|
|
|
|
|
Posted: Nov 25, 2009 - 08:53 AM |
|


Joined: Mar 28, 2001
Posts: 20374
Location: Sydney, Australia (Gum trees, Koalas and Kangaroos, No Edelweiss)
|
|
FANTASTIC!!! Congratulations Dean and John, much better than the original Atmel bridge.
This one does NOT drop any characters unlike the original whose screen shot I posted in the 1st page, even with the much hated Hyperterminal  |
_________________ John Samperi
Ampertronics Pty. Ltd.
www.ampertronics.com.au
* Electronic Design * Custom Products * Contract Assembly
|
| |
|
|
|
|
|
Posted: Nov 25, 2009 - 10:28 AM |
|

Joined: Aug 01, 2007
Posts: 98
|
|
Change and use away, glad it is of some use!
I did notice a bit of a silly in the uart_init routine where there is an atomic section that needs to include the read of TCNT3H and TCNT3L. It may cause a problem (sometimes!).
Code:
// grab timer value
lds r18,TCNT3L
lds r19,TCNT3H
// drop down tx line for start bit
lds r20, PORTD
andi r20,0xFD
sts PORTD,r20
// set trigger for tx timer
cli
sts OCR3BH,r19
sts OCR3BL,r18
sei
should be
Code:
// grab timer value
cli
lds r18,TCNT3L
lds r19,TCNT3H
// drop down tx line for start bit
lds r20, PORTD
andi r20,0xFD
sts PORTD,r20
// set trigger for tx timer
sts OCR3BH,r19
sts OCR3BL,r18
sei
No the xmega's usartC0 is connected to pins PORTD pin0 and pin1 which does not correspond with the hardware uart... which would have made things a lot simpler!! |
|
|
| |
|
|
|
|
|
Posted: Nov 25, 2009 - 08:09 PM |
|


Joined: Mar 28, 2001
Posts: 20374
Location: Sydney, Australia (Gum trees, Koalas and Kangaroos, No Edelweiss)
|
|
Just to wrap this up, Atmel just send me the Xplain USART bridge code and programmed it into the board.
It suffers from character drop out like what is visible in the earlier screen shot posted.
So I have gone back to Dean\John's code for the USART bridge.
So far I only have tested one way, when I get a bit of time I'll try sending and receiving unless someone beats me to it.  |
_________________ John Samperi
Ampertronics Pty. Ltd.
www.ampertronics.com.au
* Electronic Design * Custom Products * Contract Assembly
|
| |
|
|
|
|
|
Posted: Nov 26, 2009 - 06:17 PM |
|

Joined: Nov 12, 2009
Posts: 4
|
|
Sorry if this is tangential, but I'm having a hard time getting started with my XPLAIN. From the schematic it looks like the 1287 could be programmed (via FLIP?) to be a PDI programmer for the XMEGA, (e.g. AVRISP emulator?). Is this related at all to the LUFA and/or UART bridge you're discussing?
Out in the boonies,
-Mike |
|
|
| |
|
|
|
|
|
Posted: Nov 26, 2009 - 06:31 PM |
|

Joined: Aug 01, 2007
Posts: 98
|
|
It could work but the software implementation was never there from Atmel. The uart bridge being discussed is to purely provide a USB to Uart connection and nothing more. I have sucessfully used a bootloader in the xmega this way but debug is not possible yet. If you have a dragon or an JTAG ICE II you can directly connect it for debug.
Dean has mentioned a pdi possibility with the LUFA project.
John. |
|
|
| |
|
|
|
|
|
Posted: Nov 27, 2009 - 02:15 AM |
|


Joined: Mar 28, 2001
Posts: 20374
Location: Sydney, Australia (Gum trees, Koalas and Kangaroos, No Edelweiss)
|
|
I now have a simple echo program running on the Xmega (in ASM of course...) and I can send text files and receive the text on the terminal screen without problems with the LUFA bridge.
After many files I could see only 1 character messed up. The files are pretty short, up to 447 bytes. |
_________________ John Samperi
Ampertronics Pty. Ltd.
www.ampertronics.com.au
* Electronic Design * Custom Products * Contract Assembly
|
| |
|
|
|
|
|
Posted: Nov 27, 2009 - 06:53 AM |
|


Joined: Jan 23, 2004
Posts: 9827
Location: Trondheim, Norway
|
|
Neat! Glad you're able to get some use out of it John. I'll be using it myself when I get my own XPLAIN board which I just won off Ebay.
Now, on to PDI programming. The part I'm stuck on is how to expose it to the host, so that it's actually useful. I could make the USB AVR appear as an AVRISP-MKII to the host, but that would break the UART bridge (since the cruddy Jungo drivers only work on devices with the correct VID/PID, rather than by interface). I suppose I could make a button toggle between modes, but I'll be interested to see what route Atmel themselves take.
- Dean  |
_________________ Atmel Studio 6.1 is now released, grab it here.
Report AS6/ASF bugs here.
|
| |
|
|
|
|
|
Posted: Nov 27, 2009 - 09:24 AM |
|

Joined: Aug 01, 2007
Posts: 98
|
|
John, do you have an idea what byte was messed up and what it should have been? Are you using the corrected uart code?
John. |
|
|
| |
|
|
|
|
|
Posted: Nov 27, 2009 - 10:35 PM |
|


Joined: Mar 28, 2001
Posts: 20374
Location: Sydney, Australia (Gum trees, Koalas and Kangaroos, No Edelweiss)
|
|
|
Quote:
do you have an idea what byte was messed up
I think it was a full stop, but thats after sending 450 bytes file out to the chip continuously.
Edit these were the 2 files used for the test. The CV version has a clock output on PD7 and needs a negative pulse on PA6 to trigger the printing.
The asm version prints a little banner (repeatable if ESC pressed) and then just echoes back whatever comes in. The clock for both is 2.027MHz because that's what I have in my board. |
_________________ John Samperi
Ampertronics Pty. Ltd.
www.ampertronics.com.au
* Electronic Design * Custom Products * Contract Assembly
|
| |
|
|
|
|
|
Posted: Nov 28, 2009 - 09:27 AM |
|

Joined: Feb 12, 2005
Posts: 16314
Location: Wormshill, England
|
|
John,
I tried both of your hex files. My Xplain currently has the bridge code posted by j0n90.
The CV code displays correctly but is hardly an onerous test. e.g. small quantity of text output slowly.
The ASM version obviously copes with my typing. But if I send a 18k text file directly from a file I lose characters everywhere.
IMHO a soft UART should be able to cope with full speed reception of 9600 baud with NO loss. Of course a soft UART has to have an interrupt latency less than a single bit time. I expect that Dean can make some comments on the service time of the USB interrupts.
So a sensible test of "fitness for purpose" would consist of the PC sending say a 10k text file and the xmega sending a similar amount of continuous text.
In practice a PC is only going to send a small quantity of text to an "echo" program running on the xmega. However non-echoing text should be foolproof in both directions.
David. |
|
|
| |
|
|
|
|
|
Posted: Nov 28, 2009 - 05:40 PM |
|

Joined: Aug 01, 2007
Posts: 98
|
|
David it is difficult to know what release of hex you are running... I have released 2, one based on the atmel cdc example and the other on Deans MYUSB.
There is a danger that if you have the one that I hashed together with deans MYUSB cdc project that bytes could be missed if the scheduler got a bit delayed in transfering what was received in to the ring buffer as I didn't have it transfering on receive. It might be worth using the hex that dean has posted that he has compiled as it uses the lastest LUFA cdc project and will most likely prove more reliable. It could also be the bit interrupt isn't quick enough especially in full duplex operation, maybe doing bits both rx and tx and also doing USB stuff is overwhelming the processor. I think it should be ok but I can't say for sure.
John. |
|
|
| |
|
|
|
|
|
Posted: Nov 28, 2009 - 08:20 PM |
|

Joined: Feb 12, 2005
Posts: 16314
Location: Wormshill, England
|
|
I will do a bit of experimenting shortly. I know that your bridge captures everything from the xmega ok. e.g. if you do a massive hex dump from the xmega to a PC terminal. The Atmel code would corrupt. This is basicly testing the soft UART RX from the xmega TX.
John had an "echo" program. So you get the PC terminal to send a text file. The 1287 receives this over USB, and soft TX's it to the xmega UART RX. The xmega UART then just echoes it back i.e. the 1287 soft UART has to receive it and pass back through USB to the terminal.
This gives the 1287 full speed TX and RX. If the soft UART uses the hardware to time the OC2 bits it should cope.
David. |
|
|
| |
|
|
|
|
|
Posted: Nov 28, 2009 - 09:31 PM |
|


Joined: Mar 28, 2001
Posts: 20374
Location: Sydney, Australia (Gum trees, Koalas and Kangaroos, No Edelweiss)
|
|
| Are INT0\INT1 used for the soft uart or is it just polled? Anyway Dean's code works MUCH better than the original. |
_________________ John Samperi
Ampertronics Pty. Ltd.
www.ampertronics.com.au
* Electronic Design * Custom Products * Contract Assembly
|
| |
|
|
|
|
|