Forum Menu




 


Log in Problems?
New User? Sign Up!
AVR Freaks Forum Index

Post new topic   Reply to topic
View previous topic Printable version Log in to check your private messages View next topic
Author Message
js
PostPosted: Nov 25, 2009 - 06:19 AM
10k+ Postman


Joined: Mar 28, 2001
Posts: 20617
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
 
 View user's profile Send private message Visit poster's website 
Reply with quote Back to top
abcminiuser
PostPosted: Nov 25, 2009 - 07:47 AM
Moderator


Joined: Jan 23, 2004
Posts: 9872
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 Twisted Evil

_________________
Atmel Studio 6.1 is now released, grab it here.
Report AS6/ASF bugs here.
 
 View user's profile Send private message Send e-mail Visit poster's website 
Reply with quote Back to top
js
PostPosted: Nov 25, 2009 - 08:25 AM
10k+ Postman


Joined: Mar 28, 2001
Posts: 20617
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. Sad

_________________
John Samperi
Ampertronics Pty. Ltd.
www.ampertronics.com.au
* Electronic Design * Custom Products * Contract Assembly
 
 View user's profile Send private message Visit poster's website 
Reply with quote Back to top
abcminiuser
PostPosted: Nov 25, 2009 - 08:28 AM
Moderator


Joined: Jan 23, 2004
Posts: 9872
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 Twisted Evil

_________________
Atmel Studio 6.1 is now released, grab it here.
Report AS6/ASF bugs here.
 
 View user's profile Send private message Send e-mail Visit poster's website 
Reply with quote Back to top
js
PostPosted: Nov 25, 2009 - 08:34 AM
10k+ Postman


Joined: Mar 28, 2001
Posts: 20617
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
 
 View user's profile Send private message Visit poster's website 
Reply with quote Back to top
abcminiuser
PostPosted: Nov 25, 2009 - 08:35 AM
Moderator


Joined: Jan 23, 2004
Posts: 9872
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 Twisted Evil

_________________
Atmel Studio 6.1 is now released, grab it here.
Report AS6/ASF bugs here.
 
 View user's profile Send private message Send e-mail Visit poster's website 
Reply with quote Back to top
zbaird
PostPosted: Nov 25, 2009 - 08:36 AM
Raving lunatic


Joined: Aug 13, 2006
Posts: 6750
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
 
 View user's profile Send private message Visit poster's website 
Reply with quote Back to top
js
PostPosted: Nov 25, 2009 - 08:53 AM
10k+ Postman


Joined: Mar 28, 2001
Posts: 20617
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 Laughing

_________________
John Samperi
Ampertronics Pty. Ltd.
www.ampertronics.com.au
* Electronic Design * Custom Products * Contract Assembly
 
 View user's profile Send private message Visit poster's website 
Reply with quote Back to top
j0n90
PostPosted: Nov 25, 2009 - 10:28 AM
Wannabe


Joined: Aug 01, 2007
Posts: 99


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!!
 
 View user's profile Send private message  
Reply with quote Back to top
js
PostPosted: Nov 25, 2009 - 08:09 PM
10k+ Postman


Joined: Mar 28, 2001
Posts: 20617
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. Smile

_________________
John Samperi
Ampertronics Pty. Ltd.
www.ampertronics.com.au
* Electronic Design * Custom Products * Contract Assembly
 
 View user's profile Send private message Visit poster's website 
Reply with quote Back to top
mkmckenzie
PostPosted: Nov 26, 2009 - 06:17 PM
Newbie


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
 
 View user's profile Send private message  
Reply with quote Back to top
j0n90
PostPosted: Nov 26, 2009 - 06:31 PM
Wannabe


Joined: Aug 01, 2007
Posts: 99


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.
 
 View user's profile Send private message  
Reply with quote Back to top
js
PostPosted: Nov 27, 2009 - 02:15 AM
10k+ Postman


Joined: Mar 28, 2001
Posts: 20617
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
 
 View user's profile Send private message Visit poster's website 
Reply with quote Back to top
abcminiuser
PostPosted: Nov 27, 2009 - 06:53 AM
Moderator


Joined: Jan 23, 2004
Posts: 9872
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 Twisted Evil

_________________
Atmel Studio 6.1 is now released, grab it here.
Report AS6/ASF bugs here.
 
 View user's profile Send private message Send e-mail Visit poster's website 
Reply with quote Back to top
j0n90
PostPosted: Nov 27, 2009 - 09:24 AM
Wannabe


Joined: Aug 01, 2007
Posts: 99


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.
 
 View user's profile Send private message  
Reply with quote Back to top
js
PostPosted: Nov 27, 2009 - 10:35 PM
10k+ Postman


Joined: Mar 28, 2001
Posts: 20617
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
 
 View user's profile Send private message Visit poster's website 
Reply with quote Back to top
david.prentice
PostPosted: Nov 28, 2009 - 09:27 AM
10k+ Postman


Joined: Feb 12, 2005
Posts: 16536
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.
 
 View user's profile Send private message Send e-mail  
Reply with quote Back to top
j0n90
PostPosted: Nov 28, 2009 - 05:40 PM
Wannabe


Joined: Aug 01, 2007
Posts: 99


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.
 
 View user's profile Send private message  
Reply with quote Back to top
david.prentice
PostPosted: Nov 28, 2009 - 08:20 PM
10k+ Postman


Joined: Feb 12, 2005
Posts: 16536
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.
 
 View user's profile Send private message Send e-mail  
Reply with quote Back to top
js
PostPosted: Nov 28, 2009 - 09:31 PM
10k+ Postman


Joined: Mar 28, 2001
Posts: 20617
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
 
 View user's profile Send private message Visit poster's website 
Reply with quote Back to top
Display posts from previous:     
Jump to:  
All times are GMT + 1 Hour
Post new topic   Reply to topic
View previous topic Printable version Log in to check your private messages View next topic
Powered by PNphpBB2 © 2003-2006 The PNphpBB Group
Credits