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 19, 2009 - 04:14 AM
10k+ Postman


Joined: Mar 28, 2001
Posts: 20630
Location: Sydney, Australia (Gum trees, Koalas and Kangaroos, No Edelweiss)

So I zapped the 1287 with the 1287 firmware provided with the Xplain docs using the Dragon, but it seesm to be just the bootloader code so the existinng application for the USART bridge has now disappeared.

Where do I find it? Looked around the Atmel site but could not find any info.

I should be able to program it back in using FLIP, correct?

_________________
John Samperi
Ampertronics Pty. Ltd.
www.ampertronics.com.au
* Electronic Design * Custom Products * Contract Assembly


Last edited by js on Nov 25, 2009 - 08:03 PM; edited 2 times in total
 
 View user's profile Send private message Visit poster's website 
Reply with quote Back to top
j0n90
PostPosted: Nov 19, 2009 - 09:56 AM
Wannabe


Joined: Aug 01, 2007
Posts: 99


Hey what revision hardware do you have? Mine is revision 1 and I modded the hardware to get the xmega bootloader working through the USB port.
 
 View user's profile Send private message  
Reply with quote Back to top
abcminiuser
PostPosted: Nov 19, 2009 - 12:13 PM
Moderator


Joined: Jan 23, 2004
Posts: 9878
Location: Trondheim, Norway

How does the 1287 interface with the XMEGA? I could modify my LUFA USBtoSerial demo in a few minutes to solve that problem everyone's been having with the board...

- 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
david.prentice
PostPosted: Nov 19, 2009 - 12:50 PM
10k+ Postman


Joined: Feb 12, 2005
Posts: 16545
Location: Wormshill, England

Dean,

The Xplain uses a soft UART in the 1287 to interface to the xmega.

I wrote a suitable soft UART and adapted the LUFA code. But then ran into problems with Windows... ? and generally got fed up and gave up.

The Xplain board obviously comes with a 1287 application that provides the CDC comms to the PC for the xmega UART. It is also supposed to interface to a xmega bootloader as the communication device.

Read the Xplain app note for a better explanation.

The 1287 DFU bootloader is available on the Atmel website. But if you install this, you lose the magic 1287 app that provides the UART bridge. An of course there is no replacement binary for the 1287 app on the Atmel website.

I have asked a couple of times for someone to READ the 1287 app into a hexfile, so that you can re-install. But no-one has chosen to oblige. I presume that they have all done the same as John and me. --- installed the DFU and erased the chip in the process.

The idea behind a single board which can just connect to a PC via one USB cable is brilliant. BUT ONLY IF IT WORKS. You can investigate most of the xmega features with the Xplain and it would be an excellent evaluation tool.

However if you compare this with evaluation boards from other manufacturers, it falls far behind. However good the xmega is, it can hardly compete with the available silicon + functional devkits from other vendors.

David.
 
 View user's profile Send private message Send e-mail  
Reply with quote Back to top
j0n90
PostPosted: Nov 19, 2009 - 02:35 PM
Wannabe


Joined: Aug 01, 2007
Posts: 99


Quote:
How does the 1287 interface with the XMEGA?


The XMega connects to PD0(XMega TX) and PD1(XMega RX) of the 1287 chip. I'm sure a software uart should be possible. I don't seem to remember a com port being discovered by the pc with the old firmware though. The USB may have been designed as a debug port as the pdi port is connected to the 1287 too.
 
 View user's profile Send private message  
Reply with quote Back to top
js
PostPosted: Nov 19, 2009 - 10:02 PM
10k+ Postman


Joined: Mar 28, 2001
Posts: 20630
Location: Sydney, Australia (Gum trees, Koalas and Kangaroos, No Edelweiss)

Dean, I was thinking of using LUFA for a replacement but it may all be well beyond me... Smile If you are preared to mess around with it I'll try...nothing more to lose!

Reading the 1287 would be ok IF the chip is not locked.

Anyway I only zapped the code because I was under the false understanding that the code provided was the entire code and not just the bootloader. Yep, the old ASS_U_ME.

Atmel should supply the code, surely it is not top secret, well maybe they think that someone will make a few bucks by using a 1287 as a PDI progammer??

The board is version 2 by the way.

_________________
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 20, 2009 - 04:48 PM
Wannabe


Joined: Aug 01, 2007
Posts: 99


I've replaced the hardware uart with an asm software uart i wrote last night in the CDC example that is on the atmel website. The xmega bootloader also available on the atmel website is working fine with the AVROSP utility.
I'll upload the code when i've tidied it up.
If anyone wants the binaries in the meantime.....
 
 View user's profile Send private message  
Reply with quote Back to top
js
PostPosted: Nov 20, 2009 - 08:43 PM
10k+ Postman


Joined: Mar 28, 2001
Posts: 20630
Location: Sydney, Australia (Gum trees, Koalas and Kangaroos, No Edelweiss)

Quote:
I've replaced the hardware uart with an asm software uart
I'm confused, there is no hardware uart from the 1287 to the Xmega, just a bit banged version.

The harware USART1 is used for PDI programming by the looks of things.
Quote:
The xmega bootloader
You mean there WAS one in the Xplain's Xmega chip? Laughing that would have been obliterated within the first few minutes after I got the board and proceeded to plug in the Dragon with it's new found powers.

All I need is basically a USB to TTL converter out of the 1287, nothing else for now. There is some USART code already available that works with USARTC0 in CVAVR. (of coure I have plenty of RS232 to TTL boards around if I need to use other USARTs)

Anyway I have posted a ticket for the above with Atmel.

_________________
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
alancarr
PostPosted: Nov 21, 2009 - 04:07 AM
Rookie


Joined: May 27, 2007
Posts: 39
Location: Portland, OR

I don't know if any of you still need it, but attached is a hex file read from the 1287 on my Xplain board.
 
 View user's profile Send private message  
Reply with quote Back to top
js
PostPosted: Nov 21, 2009 - 04:42 AM
10k+ Postman


Joined: Mar 28, 2001
Posts: 20630
Location: Sydney, Australia (Gum trees, Koalas and Kangaroos, No Edelweiss)

Alan that seems to be the whole chip, application and bootloader, correct?

Is that for a version 1 or version 2 board? The bootloader section seems different than the one supplied with AVR1907 for version 2 board.

I'll give it a try anyway.

oops goofed, there is no [bootloader programmed in the] 1287 in version 1 board it seems. Embarassed

_________________
John Samperi
Ampertronics Pty. Ltd.
www.ampertronics.com.au
* Electronic Design * Custom Products * Contract Assembly


Last edited by js on Nov 21, 2009 - 05:10 AM; edited 1 time in total
 
 View user's profile Send private message Visit poster's website 
Reply with quote Back to top
js
PostPosted: Nov 21, 2009 - 04:57 AM
10k+ Postman


Joined: Mar 28, 2001
Posts: 20630
Location: Sydney, Australia (Gum trees, Koalas and Kangaroos, No Edelweiss)

We have lift off!! Com 50 comes back on when I plug in the USB lead. Bootloader seems OK too as FLIP can see it if I power up with the bootloader jumper in place.

_________________
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
js
PostPosted: Nov 21, 2009 - 08:18 AM
10k+ Postman


Joined: Mar 28, 2001
Posts: 20630
Location: Sydney, Australia (Gum trees, Koalas and Kangaroos, No Edelweiss)

And to round things off this is the (messed up) USART bridge at work. I have used the CVAVR code for the STK600 as the Xmega USART C0 is already prewired to the 1287 bridge.

Also used PDI for "debugging" ie single stepping through the code. Who knows where the problem lies, most likely with the bridge and soft UART??

_________________
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 24, 2009 - 11:20 AM
Wannabe


Joined: Aug 01, 2007
Posts: 99


Sorry, I think some wires got crossed with software/hardware on my previous post. Also forgot to attach the binarys to it!!

I've got this working reliably if you want to try it out. It basically provides a 9600 baud serial bridge out of the 1287 to the xmega chip USARTC0.

The bootloader application for the xmega is also in there too.


Last edited by j0n90 on Nov 24, 2009 - 06:39 PM; edited 1 time in total
 
 View user's profile Send private message  
Reply with quote Back to top
david.prentice
PostPosted: Nov 24, 2009 - 01:08 PM
10k+ Postman


Joined: Feb 12, 2005
Posts: 16545
Location: Wormshill, England

The 1287 Bridge hex file successfully installs a COM port.

It then repeatedly sends "Select Pressed !" to the Terminal.
You can get your xmega application to send text out through this "port" but is a little unreadable since the screen fills completely with the "Select Pressed !" text.

Since the 1287 has no user accessible pins, how can you stop this?

Incidentally the Atmel 1287 HEX file posted a few days ago provides a 9600baud soft UART but it loses characters like they are going out of fashion.

It looks as if this soft UART is more robust. But I suspect that you have to pull a 1287 pin high or low for this "text" to stop.

Has anyone got this working?

David.

Edit. I think that I have found the problem. I was using the DataFlash on the Xplain board. I suspect that the 1287 bridge code is reading the SS pin. (which is of course being used by when you access the DataFlash)
 
 View user's profile Send private message Send e-mail  
Reply with quote Back to top
j0n90
PostPosted: Nov 24, 2009 - 09:17 PM
Wannabe


Joined: Aug 01, 2007
Posts: 99


At the risk of offence, most likely to Dean after unashamedly hijacking his fantastic USBtoSerial demo for his LUFA project (sorry). Here is the source for anyone who is interested.

Think the makefile could do with some attention as I've never used them before!

Cheers.

John.
 
 View user's profile Send private message  
Reply with quote Back to top
js
PostPosted: Nov 24, 2009 - 09:27 PM
10k+ Postman


Joined: Mar 28, 2001
Posts: 20630
Location: Sydney, Australia (Gum trees, Koalas and Kangaroos, No Edelweiss)

Of course it would be nice if Atmel addressed this problem, I put in a ticket but nothing more than an automated response so far.

I'm getting into the hacking mood to disconnect the 1287 from the Xmega, remove the 2 resistors from the USART1 pins and use that for the bridge as I don't really care about possible PDI programming via the 1287. In fact there is no need to cut tracks as the pins now used for soft uart can just be made inputs.

But I'll need to come to grips with Dean's LUFA (or whatever the new name is) code I guess. 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
abcminiuser
PostPosted: Nov 25, 2009 - 12:06 AM
Moderator


Joined: Jan 23, 2004
Posts: 9878
Location: Trondheim, Norway

Quote:

At the risk of offence, most likely to Dean after unashamedly hijacking his fantastic USBtoSerial demo for his LUFA project (sorry). Here is the source for anyone who is interested.

Think the makefile could do with some attention as I've never used them before!

Cheers.

John.


John,

That codes based off MyUSB 1.5.3, which is at *least* a year old. Do you mind if I convert it over to the latest LUFA framework? Also, can I have your permission to use your soft USART code in the code, which will be used as an official LUFA project?

- 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
valusoft
PostPosted: Nov 25, 2009 - 01:12 AM
Raving lunatic


Joined: Jul 02, 2005
Posts: 6039
Location: Melbourne, Australia

abcminiuser wrote:
- Dean Twisted Evil
ahh, look who has new "sunnies" ...

_________________
Ross McKenzie
ValuSoft
Melbourne Australia
 
 View user's profile Send private message  
Reply with quote Back to top
js
PostPosted: Nov 25, 2009 - 02:39 AM
10k+ Postman


Joined: Mar 28, 2001
Posts: 20630
Location: Sydney, Australia (Gum trees, Koalas and Kangaroos, No Edelweiss)

Ohh THAT John...

Anyway I think you should make the program flexible enough so that either a soft USART code or the real USART1 could be used... with a little hack, with a little hack

oh that's a Beatle's song.

_________________
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 - 04:24 AM
Moderator


Joined: Jan 23, 2004
Posts: 9878
Location: Trondheim, Norway

Well, I'm still pending John's approval for his code (yes, it's MIT licensed, but I'd rather have explicit permission when I can) but I've managed to knock up a first revision:

http://code.google.com/p/lufa-lib/sourc ... INBridge.c

See how much better it all is with the new framework? Very Happy

I haven't got a XPLAIN board yet to test it with, but it should be functionally identical to John's version based on the ancient MyUSB distribution.



John - I really need to dig up the schematics. Are you saying that the XMEGA's USART is connected to USART1 of the AT90USB1287? If so, I might as well remove the software USART and switch over to hardware.

- 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 - 06:19 AM
10k+ Postman


Joined: Mar 28, 2001
Posts: 20630
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: 9878
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: 20630
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: 9878
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: 20630
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: 9878
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: 6758
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: 20630
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: 20630
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: 20630
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: 9878
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: 20630
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: 16545
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: 16545
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: 20630
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
david.prentice
PostPosted: Nov 28, 2009 - 10:01 PM
10k+ Postman


Joined: Feb 12, 2005
Posts: 16545
Location: Wormshill, England

My conclusions:

For xmega UART TX:

The original Atmel loses many characters.
j0n90's cdc.hex loses no characters
Dean's XPLAINBridge.hex loses the odd char.

None are very robust if you fire full bursts at 9600 baud both ways.

However both of the last two options are usable.

I will look at the soft UART code. In my opinion you can get a pretty good two-way soft UART using INT0, COMPA, COMPB interrupts. You receive on the INT0 pin, and TX via the OC2B pin. For example you can echo 115200 baud at full speed without losing a single character. (no other IRQs being serviced)

As an aside. The design of the XPLAIN is for the 1287 UART to provide PDI for the xmega. Surely a regular RS232 bootloader is the simplest arrangement? But I suppose you have no fuse access.

If the 1287 UART was directly connected to any of the xmega's eight uarts, you would have seamless communication. The xmega PDI / JTAG capabilities are already provided by the 10 pin header.

David.
 
 View user's profile Send private message Send e-mail  
Reply with quote Back to top
yopper
PostPosted: Nov 28, 2009 - 10:18 PM
Newbie


Joined: Nov 23, 2009
Posts: 4


Hi all,

I'm experiencing the same serial problems as everyone here. However, I also have problems programming with Flip. Maybe someone knows the answer how to get the AT90USB chip to boot in DFU mode. The jumper on J200 pin 1+2 does not seem to do the trick.

I noticed that the revision 2 schematic and board layout that are in AVR1902 do not match with the board I received. My board does say A08-0551 Rev 2 though.

As far as I understand Flip, I need to get a different USB product code (USB\VID_03EB&PID_2FFB) when in bootloader mode to communicate with Flip, but I keep getting the virtual COM port (USB\VID_03EB&PID_210D).

Don't have any atmel JTAG programmer. Only the AVRISP mkII.

Once I get this going I'd be happy to test some of the serial stuff. Thanks for any tips.
 
 View user's profile Send private message  
Reply with quote Back to top
nedward
PostPosted: Nov 28, 2009 - 10:19 PM
Hangaround


Joined: Jun 10, 2007
Posts: 475
Location: Auckland, NZ

Man, you guys are amazing Smile would love it if dean could finish up atmels short comings Smile maybe you should sell atmel your code dean hahaha
 
 View user's profile Send private message  
Reply with quote Back to top
abcminiuser
PostPosted: Nov 29, 2009 - 03:44 AM
Moderator


Joined: Jan 23, 2004
Posts: 9878
Location: Trondheim, Norway

Quote:

Man, you guys are amazing Smile would love it if dean could finish up atmels short comings Smile maybe you should sell atmel your code dean hahaha


I wish - I'd love to get some income from LUFA (even though I purposly made it open source and MIT so that more people would use it, to help my job prospects later on) however I don't think Atmel are interested -- after all, they continue to develop their own USB stack.

Quote:

I'm experiencing the same serial problems as everyone here. However, I also have problems programming with Flip. Maybe someone knows the answer how to get the AT90USB chip to boot in DFU mode. The jumper on J200 pin 1+2 does not seem to do the trick.


You need to short the AVR's /HWB pin to GND (I assume that's what that jumper is designed to do) while resetting the AVR. Try shorting the jumper while powering up the board.

I think I remember that some of the boards were supposed to have been released without a DFU bootloader installed on the AT90USB1287; perhaps you were unlucky enough to have received one of those.

Quote:

j0n90's cdc.hex loses no characters
Dean's XPLAINBridge.hex loses the odd char.


Is that loss only in the one direction? The soft UART code is still the same between the two HEX files, as I've simply converted it over to the latest LUFA distribution. The only problem I can see would be characters lost from the XMEGA if the software UART's receive function isn't called fast enough before another character arrives. Normally I buffer the characters directly from the UART receive interrupt, but that's obviously not possible here.

How tight is the timing? Perhaps I'll have a go at implementing the software UART in C using interrupts there so I can buffer the bytes as they are received into the ring buffer.

- 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 29, 2009 - 04:03 AM
Raving lunatic


Joined: Aug 13, 2006
Posts: 6758
Location: Bellingham, WA - USA

Not directly related, but I've been having a look at the 1287 DFU bootloader (and the crypto application of the JAVAN kit) to see what they're doing and how the USB stuff works. I've deliberately not looked at LUFA just so when I do get to it I'll have a broader base of experience.

Anyway, I'm amazed that the 1287 DFU bootloader even works at all from some of the things I've seen in there. They write a lot of "reserved" bits and values into various I/O registers (like the PLL divisor), and at one point totally trash RAMPZ and then proceed to use it. I'm sure I'll find more as I continue sniffing around. The Butterfly bootloader likewise had its shortcomings, although nothing quite as gross.

Anyway, they should get Dean to develop a clean version for them. And I'll write up everything I found out in the next couple of weeks.

_________________
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
abcminiuser
PostPosted: Nov 29, 2009 - 04:06 AM
Moderator


Joined: Jan 23, 2004
Posts: 9878
Location: Trondheim, Norway

Quote:

Anyway, they should get Dean to develop a clean version for them. And I'll write up everything I found out in the next couple of weeks.


LUFA already contains my own version of a DFU bootloader, which compiles smaller than Atmel's. I haven't seen Atmel's DFU code because they haven't released the source code to my knowledge; do you have a download link?

For the record, here's the LUFA DFU bootloader source:

http://code.google.com/p/lufa-lib/sourc ... oaderDFU.c


- 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 29, 2009 - 04:08 AM
Raving lunatic


Joined: Aug 13, 2006
Posts: 6758
Location: Bellingham, WA - USA

Quote:
because they haven't released the source code to my knowledge

The old guys work from the hex files. Sad

_________________
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 29, 2009 - 06:40 AM
10k+ Postman


Joined: Mar 28, 2001
Posts: 20630
Location: Sydney, Australia (Gum trees, Koalas and Kangaroos, No Edelweiss)

Quote:
If the 1287 UART was directly connected to any of the xmega's eight uarts, you would have seamless communication.
It IS directly connected to one of the xmega's eight uarts, USARTC0.

The problem is with the 1287 and the soft usart it uses to communicate with USARTC0. There could also be "issues" with the way USB packets data I suspect but don't really know.

_________________
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
js
PostPosted: Nov 29, 2009 - 06:43 AM
10k+ Postman


Joined: Mar 28, 2001
Posts: 20630
Location: Sydney, Australia (Gum trees, Koalas and Kangaroos, No Edelweiss)

Hey Chuck you should really reveal the number you are holding against your chest in the mugshot. Laughing

Or else take another shot with a little smile...you can even assume a sophisticated, debonnaire look if you like...I won't sue you.

_________________
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
zbaird
PostPosted: Nov 29, 2009 - 07:06 AM
Raving lunatic


Joined: Aug 13, 2006
Posts: 6758
Location: Bellingham, WA - USA

Oh, all right. This fuzzy thing will have to do until I go out in the garage and find the one with the tutu on my head.

I rather enjoyed being the grumpy old man.

_________________
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
yopper
PostPosted: Nov 29, 2009 - 11:15 AM
Newbie


Joined: Nov 23, 2009
Posts: 4


Hi Dean,

Thanks for your answer.

Quote:

You need to short the AVR's /HWB pin to GND (I assume that's what that jumper is designed to do) while resetting the AVR. Try shorting the jumper while powering up the board.


Ok, I found a description of this now. Very confusing that the xplain hardware manual mentions PF4 needs to be shorted to ground instead. Also the HWB pin is not routed and shorting it does not seem to solve it. It just boots with the com port. Guess I'll try an SVF player with a generic JTAG adapter.

Quote:

I think I remember that some of the boards were supposed to have been released without a DFU bootloader installed on the AT90USB1287; perhaps you were unlucky enough to have received one of those.


My board is from Mouser. It looks like the board shown in the "minimizing power" doc8267.pdf. The board layout is different than the schematics in AVR1907. See attached pic.

<rant>
If anyone from Atmel is here: I've never done AVR and this xplain board is not helping much in this way. I've not experienced such a poorly launched dev board in some time. No source code, a manual with mistakes and undocumented boards being sold. I know it is cheap, but something done poorly is worse.
</rant>
 
 View user's profile Send private message  
Reply with quote Back to top
david.prentice
PostPosted: Nov 29, 2009 - 11:55 AM
10k+ Postman


Joined: Feb 12, 2005
Posts: 16545
Location: Wormshill, England

Your photo is very different to my XPLAIN board.

Do you have a serial# or any rev# ?

As far as I can remember you will get to the DFU bootloader by putting a jumper over pin #0,#1 of the J200 AT90USB1287 JTAG header. It explains in AVR1907.

David.
 
 View user's profile Send private message Send e-mail  
Reply with quote Back to top
david.prentice
PostPosted: Nov 29, 2009 - 12:02 PM
10k+ Postman


Joined: Feb 12, 2005
Posts: 16545
Location: Wormshill, England

I have changed the "uart_soft.S" file in the xplain_cdc LUFA project. This "uart_kbv.c" is an alternative soft UART that copes far better with heavy traffic.

The original design is from danni. It uses the hardware to set the OC2B pin for the TX. This ensues rock solid TX timing.

Code:

#include <avr/io.h>
#include <avr/interrupt.h>
#include "soft_uart.h"

#define BAUD   9600
#define BIT_TIME   (uint16_t)((F_CPU + BAUD/2) / BAUD)

#define SRX     PD0             // Tiny2313  INT0/INT1 PD2/PD3
#define SRXPIN  PIND            // Mega32    INT0/INT1 PD2/PD3
#define SRXPORT PORTD           // 90USB1287 INT0/INT1 PD0/PD1

#define STX     PD1             //PB2
#define STXPORT PORTD
#define STXDDR  DDRD

#define W(sfr, x)        {sfr ## H = (x) >> 8; sfr ## L = (x);}
#define R(sfr)        ((x16 = sfr ## L), x16 += (uint16_t)(sfr ## H) << 8)
#define ADD(dst, src, val) {x16=src##L;x16+=(uint16_t)src##H<<8;x16+=(uint16_t)(val);dst##H=x16>>8;dst##L=x16;}

volatile uint8_t srx_done, stx_count;
volatile uint8_t srx_data, srx_mask, srx_tmp, stx_data;

unsigned char Uart_tx_ready(void)
{
    return (stx_count == 0);
}

unsigned char uart_putchar(unsigned char c)
{
    while (stx_count);
    stx_data = ~c;
    stx_count = 10;
    return c;
}

unsigned char uart_test_hit(void)
{
    return srx_done;
}

unsigned char uart_getchar(void)
{
    while (!srx_done);
    srx_done = 0;
    return srx_data;
}

void uart_init(void)
{
    OCR2B = TCNT2 + 1;          // force first compare
    TCCR2A = (1 << COM2B1) | (1 << COM2B0);     // T1 mode 0
    TCCR2B = (1 << FOC2B) | (1 << CS21);        // CLK/8, T1 mode 0
    TIMSK2 = (1 << OCIE2B);     // enable tx and wait for start
    EICRA = (1 << ISC01);       // -ve edge
    EIMSK = (1 << INT0);        // enable INT0 interrupt

    stx_count = 0;              // nothing to send
    srx_done = 0;               // nothing received
    STXPORT |= 1 << STX;        // TX output
    STXDDR |= 1 << STX;         // TX output
    SRXPORT |= (1 << SRX);      // pullup on INT0
}

ISR(INT0_vect)                  // rx start
{
    OCR2A = TCNT2 + (BIT_TIME / 8 * 3 / 2);     // scan 1.5 bits after start
    srx_tmp = 0;                // clear bit storage
    srx_mask = 1;               // bit mask
    TIFR2 = 1 << OCF2A;         // clear pending interrupt
    if ((!(SRXPIN & (1 << SRX)))) {     // still low
        TIMSK2 = (1 << OCIE2A) | (1 << OCIE2B); // wait for first bit
        EIMSK &= ~(1 << INT0);
    }
}

ISR(TIMER2_COMPA_vect)
{
    if (srx_mask) {
        if (SRXPIN & (1 << SRX))
            srx_tmp |= srx_mask;
        srx_mask <<= 1;
        OCR2A += BIT_TIME / 8;  // next bit slice
    } else {
        srx_done = 1;           // mark rx data valid
        srx_data = srx_tmp;     // store rx data
        TIMSK2 = (1 << OCIE2B); // enable tx and wait for start
        EIMSK |= (1 << INT0);   // enable START irq
        EIFR = (1 << INTF0);    // clear any pending
    }
}

ISR(TIMER2_COMPB_vect)          // tx bit
{
    OCR2B += BIT_TIME / 8;      // next bit slice
    if (stx_count) {
        if (--stx_count != 9) { // no start bit
            if (!(stx_data & 1))        // test inverted data
                TCCR2A = (1 << COM2B1) | (1 << COM2B0);
            else
                TCCR2A = (1 << COM2B1);
            stx_data >>= 1;     // shift zero in from left
        } else {
            TCCR2A = (1 << COM2B1);     // START bit
        }
    }
}
 
 View user's profile Send private message Send e-mail  
Reply with quote Back to top
yopper
PostPosted: Nov 29, 2009 - 05:57 PM
Newbie


Joined: Nov 23, 2009
Posts: 4


david.prentice wrote:
Your photo is very different to my XPLAIN board.

Do you have a serial# or any rev# ?

Yes it has several numbers, but at the back bottom it says: A08-0551 Rev 2.

Note that the pictures is from an Atmel document about measuring power. The shunt resistor on the picture is on my board but not on the schematics.

david.prentice wrote:

As far as I can remember you will get to the DFU bootloader by putting a jumper over pin #0,#1 of the J200 AT90USB1287 JTAG header. It explains in AVR1907.

Yes, but then it still boots with the virtual com port. Not with the jungo interface needed by FLip.
 
 View user's profile Send private message  
Reply with quote Back to top
david.prentice
PostPosted: Nov 29, 2009 - 06:59 PM
10k+ Postman


Joined: Feb 12, 2005
Posts: 16545
Location: Wormshill, England

My XPLAIN has several stickers:

A08-0551 Rev A
A09-0560/02
SN0300000265

I am not using Flip at the moment. But surely it will boot into DFU if you Reset the board with pin#0=pin#1. You either cycle the power or bring the Reset pin #6 of J200 to GND.

David.
 
 View user's profile Send private message Send e-mail  
Reply with quote Back to top
js
PostPosted: Nov 29, 2009 - 09:13 PM
10k+ Postman


Joined: Mar 28, 2001
Posts: 20630
Location: Sydney, Australia (Gum trees, Koalas and Kangaroos, No Edelweiss)

You need to install 2 USB driver for the Xplain, 1 for the bridge and 1 for FLIP.

Revision 1 of the board does NOT have a booloader installed in the 1287.

David do you have a finihed hex file for the bridge and the updated soft usart?

_________________
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
yopper
PostPosted: Nov 29, 2009 - 10:02 PM
Newbie


Joined: Nov 23, 2009
Posts: 4


david.prentice wrote:
My XPLAIN has several stickers:

A08-0551 Rev A
A09-0560/02
SN0300000265

Mine are:

A08-0551, Rev 2
A09-0560/04
SN:0200004884
david.prentice wrote:
I am not using Flip at the moment. But surely it will boot into DFU if you Reset the board with pin#0=pin#1. You either cycle the power or bring the Reset pin #6 of J200 to GND.

Thanks for the tip about resetting on pin #6. Booting with pin#0=pin#1 and power cycling does nothing. But with resetting it now works!

With Flip my bootloader version for the AT90USB1287 is 1.F.0. I can't read the flash as it is protected.

Thanks for your help
 
 View user's profile Send private message  
Reply with quote Back to top
valusoft
PostPosted: Nov 30, 2009 - 12:28 AM
Raving lunatic


Joined: Jul 02, 2005
Posts: 6039
Location: Melbourne, Australia

yopper wrote:
david.prentice wrote:
My XPLAIN has several stickers:

A08-0551 Rev A
A09-0560/02
SN0300000265

Mine are:

A08-0551, Rev 2
A09-0560/04
SN:0200004884


Mine on the board are:

A08-0551, Rev 2
A09-0560/04
SN:0200000506

... and on the box
A09-0620/04
SN:0200000204
2009.07.17

Obviously the serial numbers have zero correlation with version numbers.

Why on your deity's little earth would anyone issue a "Rev A" and then (or not) a "Rev 2". Is "A" before "2" in any rational sequencing scheme? Sheesh ...

Waiting for the dust to settle before doing anything ...

Cheers,

Ross

_________________
Ross McKenzie
ValuSoft
Melbourne Australia
 
 View user's profile Send private message  
Reply with quote Back to top
abcminiuser
PostPosted: Dec 01, 2009 - 09:54 PM
Moderator


Joined: Jan 23, 2004
Posts: 9878
Location: Trondheim, Norway

Attached is a new build of the project, using the above C software UART. Depending on which version has the highest reliability, I'll see if I can use that in the final version of the bridge (once I get permission from all authors).

- 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: Dec 01, 2009 - 10:29 PM
10k+ Postman


Joined: Mar 28, 2001
Posts: 20630
Location: Sydney, Australia (Gum trees, Koalas and Kangaroos, No Edelweiss)

I put a 25k asm file through the new bridge and could not see any garbage on the screen.

Unfortunately the terminal program cannot send and receive a file as far as I can tell so I saved the screen buffer (uCon terminal, Hyperterminal could not keep up) to a file and then used fc in dos mode. There were differences but I suspect it was just the way screen capture works.

Eye capture Confused looks ok scrolling trough the screen buffer.

If I have some time later on I may try and send some project files and recapture the screen buffer, see if the project still compiles correctly.

_________________
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
zbaird
PostPosted: Dec 01, 2009 - 10:39 PM
Raving lunatic


Joined: Aug 13, 2006
Posts: 6758
Location: Bellingham, WA - USA

Speaking of permission, what do you do about VID/PIDs for LUFA and the DFU bootloader? Just curious...

_________________
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
abcminiuser
PostPosted: Dec 02, 2009 - 04:31 AM
Moderator


Joined: Jan 23, 2004
Posts: 9878
Location: Trondheim, Norway

Atmel have generously donated a block of 16 PIDs in their VID range for my LUFA project use -- they seem to realise that having a silly muppet put in all that work for free is a good thing, which they should support (at least in that way).

As for the DFU bootloader, I'm forced spoofing Atmels' DFU PID, since their crummy driver won't allow any other VID/PID pair to work. With any luck they won't notice or care Smile.

- 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: Dec 02, 2009 - 06:06 AM
Raving lunatic


Joined: Aug 13, 2006
Posts: 6758
Location: Bellingham, WA - USA

Quote:
With any luck they won't notice

Well, I'll keep your secret. That's great news about their support of LUFA.

_________________
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
wek
PostPosted: Dec 02, 2009 - 10:05 AM
Raving lunatic


Joined: Dec 16, 2005
Posts: 3094
Location: Bratislava, Slovakia

js wrote:
Unfortunately the terminal program cannot send and receive a file as far as I can tell so I saved the screen buffer (uCon terminal, Hyperterminal could not keep up)

Not really germane to this thread, but since you mentioned...

The only ready-made terminal program I came across so far, capable of capturing and saving inbound serial stream at any speed up to 115200Bauds, while correctly handling hardware handshake, was realterm (realterm.sf.net).

Has its quirks, though - besides a hard-to-get-used-to user interface - never use it to *send* a binary file, as it simply drops all 0x1A-s - found out the hard way, although it IS documented... Neutral

JW
 
 View user's profile Send private message Visit poster's website 
Reply with quote Back to top
abcminiuser
PostPosted: Dec 02, 2009 - 12:37 PM
Moderator


Joined: Jan 23, 2004
Posts: 9878
Location: Trondheim, Norway

David,

Are you able to release that software UART code under the MIT license for inclusion in LUFA? I'd want to include whichever software UART is the most reliable, so that it can benefit the largest number of users.


To all those with XPLAIN boards: fear not, I'm busy unwrapping the XPROG PDI protocol as we speak!

- 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
david.prentice
PostPosted: Dec 02, 2009 - 02:01 PM
10k+ Postman


Joined: Feb 12, 2005
Posts: 16545
Location: Wormshill, England

Yes. That is fine by me. But please mention Peter Danneger 'danni', because the method came from him.

As far as I can see, the PDI protocol is fairly straightforward at the lowest hardware level. But I have not come across any public code that writes the raw JTAG commands. They tend to interface with a JTAG-1 or JTAG-2 device rather than the raw TCK, TMS, TDI, TDO signals.

Obviously the first stage is to implement program upload. But eventually Studio would use the interface for full JTAG debugging.

Presumably the STK600 could function as a debugger if Atmel chose. After all it has the same connectivity as a JTAGICEmkII. And they could fit the code into the XPLAIN 1287 if they chose. It all depends on whether they want it to be an attractive evaluation kit for their Xmega devices.

David.
 
 View user's profile Send private message Send e-mail  
Reply with quote Back to top
abcminiuser
PostPosted: Dec 02, 2009 - 02:03 PM
Moderator


Joined: Jan 23, 2004
Posts: 9878
Location: Trondheim, Norway

Thanks, I'll add the code to the XPLAIN Bridge code now and remove John's (sorry John, but reliability is key!).

I've finished the AVRISP-MKII PDI unwrapping code, so now I just need to implement the low level PDI commands. I'd expect to have something ready for testing in only a few days.

- 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: Dec 02, 2009 - 08:58 PM
10k+ Postman


Joined: Mar 28, 2001
Posts: 20630
Location: Sydney, Australia (Gum trees, Koalas and Kangaroos, No Edelweiss)

Quote:
The only ready-made terminal program .... was realterm
uCon has no problems keeping up, just did not know how to send and capture at the same time.

These are the files used, sent: AVRA README.txt file (24K) echoed and captured: xplain_test.txt

The FC screen shot seems to show just 1 char difference but it may just be some incorrect setup as it is an extend character.

edit yep, it's a capture setting problem. The uCon screen shows the correct charater, so it's 100% correct with 24K.

_________________
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: Dec 02, 2009 - 09:10 PM
10k+ Postman


Joined: Feb 12, 2005
Posts: 16545
Location: Wormshill, England

John,

I can assure you that you can crash most soft UARTs + Terminal echo if you try hard enough.

Either by a massive load of regular text, or a massive load of fancy Terminal escapes. (as in the attached file)

In practice you are only going to send a human digestible quantity of text. In which case you will probably get no glitches.


David.
 
 View user's profile Send private message Send e-mail  
Reply with quote Back to top
nedward
PostPosted: Dec 03, 2009 - 08:20 AM
Hangaround


Joined: Jun 10, 2007
Posts: 475
Location: Auckland, NZ

Dean;
So what you're doing is getting the 1287 to program the Xmega and let the PC see it as a AVRISP-MKII, correct? Thats just awesome Smile if i'm ever in Oz or you're ever in NZ, i would like to buy you a beer Smile
 
 View user's profile Send private message  
Reply with quote Back to top
abcminiuser
PostPosted: Dec 03, 2009 - 08:41 AM
Moderator


Joined: Jan 23, 2004
Posts: 9878
Location: Trondheim, Norway

Quote:

Dean;
So what you're doing is getting the 1287 to program the Xmega and let the PC see it as a AVRISP-MKII, correct? Thats just awesome Smile if i'm ever in Oz or you're ever in NZ, i would like to buy you a beer Smile


Yes, exactly -- I'm doing what Atmel can't, apparently. I've already got a working AVRISP-MKII clone in my LUFA project which does ISP, but now that the latest AVRStudio can do PDI programming through the AVRISP-MKII, I'm using that as a base for the XMEGA programmer.

To remain compatible with the real XMEGA programmer I'll be using software PDI on the same pins as the real AVRISP-MKII, even through the XPLAIN board has it connected to the AVR's hardware USART. Once I get it going I'll probably make it automatically change over to the faster hardware UART when compiled for the XPLAIN board.

- 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: Dec 03, 2009 - 09:39 PM
10k+ Postman


Joined: Mar 28, 2001
Posts: 20630
Location: Sydney, Australia (Gum trees, Koalas and Kangaroos, No Edelweiss)

Suggestion from bootloader thread in case you miss it. Smile
Quote:
In order to switch between usart bridge and programmer the 2 pins near the SDRAM could be used (GND and PDI), if a link is fitted then go into programming mode otherwise usart bridge mode.

_________________
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: Dec 03, 2009 - 09:41 PM
Moderator


Joined: Jan 23, 2004
Posts: 9878
Location: Trondheim, Norway

Good idea. Once I get the AVRISP project working with PDI programming, I think I'll edit it into the XPLAINBridge project code to do just that.

- 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
very_new_user
PostPosted: Dec 06, 2009 - 05:10 PM
Rookie


Joined: Nov 24, 2009
Posts: 38


Reporting some more experiences with the Xplain board:

Communicating from windows with the Xmega via the usb1287 chip works well (at least with an Xplain rev.4 board) without the need to flash an alternate usb bridge. The usb-to-serial bridge has be installed first using the inf file supplied with the AVR1907 (11/9) zip file from Atmel's web site.

Flashing the usb1827 can be done easily, but be aware: After flashing the usb1287 chip as decribed at the end, I was not able to revert to the original USB bridge (maybe the freaks here can give a solution). I was stuck to use one of the usb bridges posted in this forum (and of course using the corresponding inf files for installing a suitable windows driver for communication with the usb1287 USART). Those drivers however seem to lose characters unlike the original factory supplied code which works very well at 32 MHz Xmega frequency using bsel=104 and bscale=1. The nasty thing with this driver however in contrast to the others posted in this forum is that after unplugging the usb connector and reconnecting it, the respective com port at the PC cannot be accessed unless flashing the Xmega with a code that does not use the USART (like a simple LED flashing code), and subsequently reflashing the Xmega with the code using the USART.

Anyway, I decribe here how I was able to program the usb 1827:
Using Atmel's Flip program, the 1287 can be programmed via usb. First put one of the supplied plugs across pins 1 and 2 of the upper left 10-pin post. Then connect the usb plug to the PC with this bridge in place. Windows will ask for a new driver. Follow the instructions up to point #7 as written p.7 of the AVR1907 pdf file. Flip then can be used to program the usb1287. For using the usb bridge for communication with the Xmega, the bridge across the pins 1 and 2 has to be removed and the usb cable be reconnected. Windows then uses the com port that has been installed from the 1907 zip file.

Flashing the Xmega through the usb1827 still waits for a solution.
 
 View user's profile Send private message  
Reply with quote Back to top
ArnoldB
PostPosted: Dec 06, 2009 - 06:57 PM
Raving lunatic


Joined: Nov 29, 2007
Posts: 3219


My experience with a Rev. 4 is different, as just summarized elsewhere yesterday.
 
 View user's profile Send private message  
Reply with quote Back to top
very_new_user
PostPosted: Dec 06, 2009 - 07:47 PM
Rookie


Joined: Nov 24, 2009
Posts: 38


ArnoldB wrote:
My experience with a Rev. 4 is different, as just summarized elsewhere yesterday.
ArnoldB, either there are sub-families of the Rev.4's or I am lucky to have a rare board with an usb-serial bridge functioning by design. It is no joke. As stated above Hyperterminal screen fills nicely with numbers on which I believe..javascript:emoticon('Very Happy'). The box tells me A09-0620/o6, SN..., 2009.10.16. Looking underneath the board is not so easy anymore since it is mounted on a plate. But I have another one, will test it maybe tomorrow.
 
 View user's profile Send private message  
Reply with quote Back to top
very_new_user
PostPosted: Dec 06, 2009 - 08:32 PM
Rookie


Joined: Nov 24, 2009
Posts: 38


Addition: I am trying to find out why there are so many users considering the factory-programmed usb-serial bridge to be totally faulty. Maybe it is because of this: It is very easy to lock the usb-serial channel irreversibly in one session (see my previous post), for instance by unplugging the usb during a transmission. On reconnecting the USB, the red LED next to the plug goes on and stays on, regardless of trying to reset either the hyperteminal or the usb1287, and Hyperteminal refuses to connect to the com port. Also, rebooting the PC does not help.

I repeat the sequence to be followed exactly to restore the transmission:
a) Disconnect Hyperterminal by pushing the hang-up button.
b) Flash the Xmega with some stupid stuff
c) Unplug USB.
d) Flash the Xmega with the USART addressing code (printf..)
e) Plug-in USB-connector
f) Press Connect-button in Hyperterminal.
g) Enjoy the printout to the terminal.

As long as the USB stays connected, the connection remains stable, and the Xmega can be flashed without doing harm.

Would be interesting to hear from others. But the problem might be, if one fiddles around with the usb1287 (flashing it) it might be difficult to revert to the original state, and then one needs a different usb-serial bridge such as posted in this forum.

Certainly, this behaviour, requiring to intermediately flash some nonsense stuff to the Xmega after unplugging the USB connector is a bug in the Xplain board software. I repeat that this behaviour is absent in those usb-serial bridges posted recently in this forum. But I was not able to achieve stable transmission using those. Avrfreaks should easily have an explanation for these observations?
 
 View user's profile Send private message  
Reply with quote Back to top
js
PostPosted: Dec 07, 2009 - 01:43 AM
10k+ Postman


Joined: Mar 28, 2001
Posts: 20630
Location: Sydney, Australia (Gum trees, Koalas and Kangaroos, No Edelweiss)

I programmed the usb-serial bridge supplied to me by Atmel and the results are lots of missing characters as shown on the 1st page of this thread.

The recent "home cooked" versions are very good.

I'm posting the Atmel supplied code you may want to try with your board. If it works well then we need to chase some hardware issues.

_________________
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
ArnoldB
PostPosted: Dec 07, 2009 - 05:33 PM
Raving lunatic


Joined: Nov 29, 2007
Posts: 3219


I am not so much interested in programming the xmega on the xplain, but the at90usb1287. I'll probably use the xmega only as a means to forward data to some LCD display.

Regarding programming the 1287 via the shipped bootloader, my experience is that the procedure as described in Atmel's application note 1907 doesn't work for me.

Under Windows with FLIP and under Linux with dfu-programmer I also needed to wire up the 1287 reset pin. Just placing the jumper on pin 1 and 2 did nothing for me.

However, with the additional pushbutton on the reset line I was able to download a blinking LED application and I could also later restore the original USB bridge (which I had read via JTAG before I started experimenting with the blinking LED application).
 
 View user's profile Send private message  
Reply with quote Back to top
david.prentice
PostPosted: Dec 07, 2009 - 05:46 PM
10k+ Postman


Joined: Feb 12, 2005
Posts: 16545
Location: Wormshill, England

Surely this is a common circumstance. You want to RESET an AVR with a certain hardware condition.

So you set up the hardware condition --- jumper pin#1,2 of XPLAIN J200. Then apply RESET --- touch RESET pin to GND.

This is what you have to do with any micro that I have ever come across. Most ready-made boards will have a push-button to apply the hardware condition and a push-button to apply the RESET.

Using the USART bootloader on an ARM or 8051 chip is achieved either by your fingers + two push-buttons or by the DTR/RTS pins of the RS232 connection.

If you have a JTAG connection, you can apply the RESET as a JTAG command without wearing down your fingers.

Of course the other alternative is for you to type a special character within a specified time. But there will be people who do not like that system either.

David.
 
 View user's profile Send private message Send e-mail  
Reply with quote Back to top
ArnoldB
PostPosted: Dec 07, 2009 - 07:01 PM
Raving lunatic


Joined: Nov 29, 2007
Posts: 3219


Only that Atmel claims in AVR1907 you don't have to do anything with the reset pin, just jumper pin 1 and 2 on J200 and unplug and replug the USB cable (which also supplies the power).

My xplain couldn't care less about unplugging and replugging the power. With or without jumper the 1287 never ends up in bootloader mode. With a jumper and reset it does.
 
 View user's profile Send private message  
Reply with quote Back to top
js
PostPosted: Dec 07, 2009 - 10:05 PM
10k+ Postman


Joined: Mar 28, 2001
Posts: 20630
Location: Sydney, Australia (Gum trees, Koalas and Kangaroos, No Edelweiss)

I don't have any problems with the jumper and unplugging and replugging the power, it works ok.

_________________
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: Dec 23, 2009 - 11:46 AM
Wannabe


Joined: Aug 01, 2007
Posts: 99


Blimey, I've been in the 'matrix' for a couple of weeks (sometimes i need to do some work!) and it looks like the problems with the serial port have all been sorted out.
Good stuff with the PDI programming too, will there be PDI debug support?
 
 View user's profile Send private message  
Reply with quote Back to top
abcminiuser
PostPosted: Dec 23, 2009 - 12:18 PM
Moderator


Joined: Jan 23, 2004
Posts: 9878
Location: Trondheim, Norway

Quote:

Good stuff with the PDI programming too, will there be PDI debug support?


Thanks! The code for PDI is now in the latest LUFA release package (as is the XPLAIN serial bridge) at http://www.fourwalledcubicle.com/LUFA.php. So far it's programming only, but only because that's all the host software will do while I pretend to be a AVRISP-MKII. I don't really want to have broken functionality by pretending to be a JTAG-MKII but only implement a few protocols, so no debugging as of yet. The code will support it pretty easily however, if someone writes a custom front-end for it.

I'm just about to start TPI protocol implementation, when Atmel releases the protocol information.

- 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
very_new_user
PostPosted: Dec 23, 2009 - 09:01 PM
Rookie


Joined: Nov 24, 2009
Posts: 38


Great!. But I am mostly interested in faster UART communication with the XMEGA rather than in flashing it through the USB port(bought an ISP MKII). But, prior to flashing the compiled hex file from the LUFA project (and being unsure on how to revert to the original state in case of problems), could you tell which Baud rate can be used?

In my previous post I had described the problems with the factory supplied usb bridge (I have Rev.4), but nevertheless it works reliably, however at much too slow 9600 Baud.

And, by the way, the locking of the com port (see my previous posts) can be avoided by delaying the first printf statement by 100ms.
 
 View user's profile Send private message  
Reply with quote Back to top
david.prentice
PostPosted: Dec 23, 2009 - 09:58 PM
10k+ Postman


Joined: Feb 12, 2005
Posts: 16545
Location: Wormshill, England

The USARTC0 can only run at 9600 baud. You would struggle to go much faster.

But with the Xplain board you can use USARTD0 and USARTD1 from the 10 pin header. These are obviously TTL levels so you would need to connect via a MAX2232 or a FT2232D chip.

Then you can run the USARTs as fast as you like.

David.
 
 View user's profile Send private message Send e-mail  
Reply with quote Back to top
very_new_user
PostPosted: Dec 28, 2009 - 01:27 PM
Rookie


Joined: Nov 24, 2009
Posts: 38


What causes the 9600 Baud constraint of USARTC0 on the Xplain board? The Xmega manual does not seem to specify differences between the USARTs.
 
 View user's profile Send private message  
Reply with quote Back to top
Bingo600
PostPosted: Dec 28, 2009 - 10:26 PM
Raving lunatic


Joined: Apr 25, 2004
Posts: 3817
Location: Denmark

ArnoldB wrote:
I could also later restore the original USB bridge (which I had read via JTAG before I started experimenting with the blinking LED application).


Arnold could you upload the "original bridge" ?

I kind if blew mine away .. including the flip loader , when i used the dragon for Deans code Embarassed

/Bingo
 
 View user's profile Send private message  
Reply with quote Back to top
abcminiuser
PostPosted: Dec 28, 2009 - 10:53 PM
Moderator


Joined: Jan 23, 2004
Posts: 9878
Location: Trondheim, Norway

Quote:

I kind if blew mine away .. including the flip loader , when i used the dragon for Deans code Embarassed


Is there still an ongoing issue with my bridge code? It should be functionally identical, and thus you should not need to use Atmel's.

- 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
ArnoldB
PostPosted: Dec 29, 2009 - 12:54 AM
Raving lunatic


Joined: Nov 29, 2007
Posts: 3219


Bingo600 wrote:
Arnold could you upload the "original bridge" ?
See attachment. It contains the complete flash of an rev. 4 - bridge and bootloader (and lots of FFs in between).

BTW, decoding the hex file gives

Code:

 00e0 000c0341 0054004d 0045004c 00260358  ...A.T.M.E.L.&.X
 00f0 0070006c 00610069 006e0020 00550053  .p.l.a.i.n. .U.S
 0100 00420020 00470061 00740065 00770061  .B. .G.a.t.e.w.a
 0110 00790012 03300030 00300030 00300030  .y...0.0.0.0.0.0
 0120 00300030 00040309 04180353 00650072  .0.0.......S.e.r
 0130 00690061 006c0020 0050006f 00720074  .i.a.l. .P.o.r.t
 0140 00200350 0072006f 00670072 0061006d  . .P.r.o.g.r.a.m
 0150 006d0065 00720020 0050006f 00720074  .m.e.r. .P.o.r.t
 0160 002a0008 01000000 08000001 ea0c00ff  .*..............
Interesting that Atmel talks about "Programmer" in the bridge code.
 
 View user's profile Send private message  
Reply with quote Back to top
Bingo600
PostPosted: Dec 29, 2009 - 09:38 AM
Raving lunatic


Joined: Apr 25, 2004
Posts: 3817
Location: Denmark

@Dean
No problem with your code , i just didn't use Flip to put it in , so i lost the "Original"
and just wanted to have it if possible

@Arnold
Thanx Smile

/Bingo
 
 View user's profile Send private message  
Reply with quote Back to top
david.prentice
PostPosted: Dec 29, 2009 - 09:59 AM
10k+ Postman


Joined: Feb 12, 2005
Posts: 16545
Location: Wormshill, England

very_new_user wrote:
What causes the 9600 Baud constraint of USARTC0 on the Xplain board? The Xmega manual does not seem to specify differences between the USARTs.


There is no limitation to the xmega USARTC0 as such. It is the same as any other xmega USART.

The limitation is only with the bridge code. i.e. the PC seeing a virtual COM port.

Since the Xplain hardware connects the xmega to the AT90USB1287 via bit-banging, a software UART is limited in speed. The software UART by itself will run perfectly at 115200 baud, and possibly faster. However the AT90USB1287 also has to service USB interrupts. It cannot manage all the interrupts involved in the software UART above a certain speed. In simple terms, a software UART has interrupts for each bit of TX and RX e.g 10 IRQs for each 8-N-1. A regular AVR hardware UART only interrupts when it has processed a full byte.

David.
 
 View user's profile Send private message Send e-mail  
Reply with quote Back to top
nedward
PostPosted: Jan 19, 2010 - 02:01 AM
Hangaround


Joined: Jun 10, 2007
Posts: 475
Location: Auckland, NZ

Sorry to bring this back up but is it possible to have deans programmer AND a working USART bridgeto be programmed onto the same AT90USB1287 and swap between them using a button/jumper or something?
 
 View user's profile Send private message  
Reply with quote Back to top
abcminiuser
PostPosted: Jan 19, 2010 - 05:41 AM
Moderator


Joined: Jan 23, 2004
Posts: 9878
Location: Trondheim, Norway

You'd be surprised how many people have asked that. I actually spent much of yesterday unsucessfully trying to make the Atmel Jungo driver bind to a specific interface in a composite device I created, but had no luck. Instead, I offer the newly changed XPLAINBridge firmware, attached here.

When inserted into a USB host, it will read the TDI pin of the USB AVR's JTAG port. If left high it will work as a USB to USART bridge, if pulled low it will act as a PDI programmer for the XMEGA.

The updated source code is located in the XPLAINBridge project of the LUFA SVN.

- 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: Jan 19, 2010 - 05:42 AM
10k+ Postman


Joined: Mar 28, 2001
Posts: 20630
Location: Sydney, Australia (Gum trees, Koalas and Kangaroos, No Edelweiss)

Already discussed http://www.avrfreaks.net/index.php?name ... 852#644852

But Dean is too busy boozing up with the other Melbourne freaks to do any work. Laughing
Quote:
Might want to edit
OK so it looks like he sobered up. Mr. Green

_________________
John Samperi
Ampertronics Pty. Ltd.
www.ampertronics.com.au
* Electronic Design * Custom Products * Contract Assembly


Last edited by js on Jan 19, 2010 - 06:04 AM; edited 1 time in total
 
 View user's profile Send private message Visit poster's website 
Reply with quote Back to top
abcminiuser
PostPosted: Jan 19, 2010 - 05:50 AM
Moderator


Joined: Jan 23, 2004
Posts: 9878
Location: Trondheim, Norway

Might want to edit that John after you read my post just above yours Wink.

- 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
nedward
PostPosted: Jan 19, 2010 - 06:00 AM
Hangaround


Joined: Jun 10, 2007
Posts: 475
Location: Auckland, NZ

Wow, Great stuff!

Will try it out next week when my boards finally arrive Smile ( i hate christmas break time )
 
 View user's profile Send private message  
Reply with quote Back to top
very_new_user
PostPosted: Jan 19, 2010 - 02:11 PM
Rookie


Joined: Nov 24, 2009
Posts: 38


Dean,
your work is really fantastic. As a very_new_user, I wonder how you freaks are able to type (?) hundreds of lines of code correctly....(which editor/compiler are you using?)

Anyway, is this XPlain_usb bridge also limited to those 9600 baud? Others, using the Silab USB-USART-Bridge CP2102 instead of Atmel's 1287 get much higher baud rates. Is it just a brand issue that the Xplain board uses the 1287?
 
 View user's profile Send private message  
Reply with quote Back to top
abcminiuser
PostPosted: Jan 19, 2010 - 02:21 PM
Moderator


Joined: Jan 23, 2004
Posts: 9878
Location: Trondheim, Norway

Thanks very_new_user!

Quote:

As a very_new_user, I wonder how you freaks are able to type (?) hundreds of lines of code correctly....(which editor/compiler are you using?)


Lots of practice - and trust me, lots of swearing and head-scratching. What you see here is the product of many hours of work (LUFA + AVRISP-MKII + XPLAINBridge) which a tiny HEX file doesn't really convey. I program using Programmers Notepad using the free avr-gcc compiler under Windows. Eric, another user here, helpfully packages all the required tools into a single package for you under Windows, called WinAVR.

Quote:

Anyway, is this XPlain_usb bridge also limited to those 9600 baud? Others, using the Silab USB-USART-Bridge CP2102 instead of Atmel's 1287 get much higher baud rates. Is it just a brand issue that the Xplain board uses the 1287?


Yes, it is limited to 9600 baud. This is a technical limitation because of a decision by Atmel. In theory, the onboard AT90USB1287 was supposed to do two jobs; act as a PDI programmer for the XMEGA, and act as a USB-to-Serial bridge for the XMEGA's USART. The problem with this is that the PDI programming interface of the XMEGA is encoded via USART framing as well, but the AT90USB1287 has only one hardware USART.

Since programming speed is more important than debug console speed (to the Atmel designers, anyway) they chose to hook the fast hardware USART to the PDI programming interface, and use a slower software USART for the debug channel. This is what limits the speed - the AT90USB1287 is only clocked at 8MHz. Clocking at 16MHz would increase the maximum software USART speed to 19200, so it's strange Atmel went with the lower clock.

Using another vendor's USB-to-Serial IC wouldn't help, as it would not be able to act as a PDI programmer for the XMEGA. If Atmel was unconcerned with making the board programmable without external hardware, then the AT90USB1287 could have acted as a very fast converter if the hardware USARTs were linked together.

- 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
very_new_user
PostPosted: Jan 19, 2010 - 03:19 PM
Rookie


Joined: Nov 24, 2009
Posts: 38


Dean,
thanks for your remarks on programming and on the 1287 issue. But, if you do a search for "XMEGA-A1-USB" you will find an XMega board employing the CP2102 that should work e.g. at 250kBit/s compared to the 9600 (should be bits/s, right?, not baud as I wrote, that's the reason why it feels that slow) with the 1287. And, there is also the USB programmer. One can switch between the Xmega UART bridge and the programmer by means of an utility ("Change MC-Module PID"). How can we understand that?

-very_new_user
 
 View user's profile Send private message  
Reply with quote Back to top
abcminiuser
PostPosted: Jan 19, 2010 - 10:09 PM
Moderator


Joined: Jan 23, 2004
Posts: 9878
Location: Trondheim, Norway

It's *possible* to do it with a FTDI or other chip, but you'd either need one with dual COM port functionality, or with user-controllable GPIO pins. However, the former would require quite a complex PC program to work, while the latter would require a complex PC program and be extremely slow.

I guess Atmel choose the USB1287 due to it being an Atmel chip, and because you can do many other things with it, like turn it into a Mass Storage device for the Dataflash. It would probably have been better if they chose the hardware USART for debugging for those that need such a high bitrate, but obviously they felt that programming speed was more important.

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