Xmega based design?

I'm just starting out building my first printer. I plan on using a RAMPS board as I put together my own Arduio 2560 mega board using a bare board off ebay and some samples from Atmel.
Now I'm wondering about porting the firmware to the xmega processors which can be run at twice the speed (or a bit more overclocked). The atxmega128A1U has built in USB (but since the
LUFA library may not be fully operation with xmega yet, I'd have to use Atmel's own usb libraries). Certainly this is a "for later" idea as I want to get my printer running first, but is anybody interrested
in this? The xmega 100 pin devices can be expanded to over a megabyte of static ram off chip which would allow for a large 'look ahead' buffer.

If the built in USB is using LUFA, IMO it's most likely emulated USB.

This means it'll be using much of that extra speed to talk to the PC, rather than running the machine. If you only intend to use the machine stand-alone (dump a file over USB, then disconnect) that would make sense. Otherwise a lot of your extra horsepower is just not going to get used for what you want.

Note: I've seen slower processors with on-chip USB (Leonardo-based design) trying to run movement on a Cartesian 2 axis bot, and the stuttering at the start of any action as they tried to do USB and even slow movement was not nice.

If you're making yourself a prototype, I'd look at making sure there is a serial port header exposed somewhere you can fall back on (using an external USB serial cable eg: FT232) if you intend to drive it a lot using USB.

You cant put a ramps on a xmega, Ramps is designed for 5v, xmega is 3.3volt

This is why ramps-fd was developed, for the 3.3v Due.

Edited 1 time(s). Last edit at 02/11/2014 02:58AM by Dust.

Yes, I am very interested. They seem to offer great performance for the price. I am a hardware guy with very limited software skills so I cheer you on instead

Do you think it would suffice with the 64-pin A3U or 44-pin A4U? No sdram support but simpler HW.

I know that the xmega is 3V, but all of the logic on the RAMPS can be made to run at 3V with no problem (simple re-design). Makes supporting an SD card easier in fact since no level converter is needed. And you CAN drive most 5V lcd's with 3V logic since they are write only. The step sticks are all 3-5 volt logic compatible. I wasn't thinking of using an existing RAMPS, but rather designing a new board like RUMBA with everything on one board.
The ATxmega128A3U has 8K of sram, the same as the atmega2560 so it will work fine, just can't implement large caches. The built in USB is no slower than the Tensy2.0+++ used on the current makerbot boards, and I'm not talking about LUFA, but Atmel's own USB library (which is also open source BTW,but NOT GPL. It's still free for Atmel chip users.)
The 64 pin chip still has more available I/O than the atmega1284, though not as much as the Arduino Mega (though the Mega board leaves out about 14 I/O pins from the cpu that go nowhere to available connectors).

Quote

If the built in USB is using LUFA, IMO it's most likely emulated USB.

LUFA is not a software USB stack. It always uses the USB hardware. You can have LUFA manage the endpoint interrupt, or the user can call USB_Task() at a time when the cpu is not busy. Maybe the stuttering you saw was due to executing the USB endpoint ISR (which will happen when new data arrives)? Use the task-based method in this case. The ISR does not take much cpu time though, so I suspect the problem lies elsewhere. Arduino Leonardo uses a different USB stack anyway. When receiving data, the Arduino core will copy a block of USB endpoint data from the dedicated dual-ported endpoint DPRAM to a buffer in main SRAM. I guess they did this for compatibility with the Serial methods (especially Serial.peek()), but it wastes cpu time to copy a block of data from one buffer to another. Instead, the data could be read directly from the endpoint DPRAM. Additionally, IIRC, Arduino does not use double-banked DPRAM buffers. The dual-porting allows simultaneous access to the DPRAM by the USB hardware and the cpu (but different endpoints). However, using double-banked buffers allows simultaneous access to the same endpoint (but different banks). The USB hardware on the USB Mega/AT90USB AVRs and XMEGAs should allow for less cpu intervention per byte transferred than when compared to the USART, mainly due to the serial RX interrupt being called much more frequently (the USART has only a 2 byte hardware RX buffer). An exception to this would be if the USB host (computer) is sending only one (or few) bytes per packet, resulting in both a slower throughput and greater cpu processing time. This should not happen with a properly written host program. The XMEGA additionally has DMA. This can greatly reduce cpu time if copying to a SRAM buffer is required. XMEGA support in LUFA is new though, but I will be trying it out soon. I am using an ATxmega128a4u to control NEMA17 stepper motors in a 3-axis CNC conversion I use to mill enclosures. I am not using USB yet, but will be adding support soon. Also, if larger buffers are required, the ATxmega256x3xx has 16KB, and the ATxmega384c3 has 32KB of SRAM.

---

USB AVR dev boards