Gabotronics

Protocol Sniffer: Use the K1 button to start/stop data capture, so that the buffer can be analyzed at leisure.

Implemented in version 1.34

Pads for an FTDI uart-to-usb chip. The US$5 FT232RL in the 28-SSOP package (7x10mm) would be relatively easy for the user to solder on and it requires no external components. The free FTDI drivers in my experience work well on all platforms.

Jumper pads with solder bridges could be used to route tx and rx directly to the usb connector in the absence of the chip. With the chip you could also patch an external uart in through the forthcoming 6 pin connector, breaking the traces to the xmega if necessary but possibly just tristating the uart output through a menu page (which also could toggle among baud rates).

Amazing what you have packed into the xmega32. For use as a development board the 64 or better the 128 would be worth the extra cost (could even be cheaper!). If they ever become available.

That should be possible with the existing hardware, as the logic pins brought out to a protoboard include the port C spi pins. If you get a microSD card with SD adapter you can solder a strip of pins with 0.1 spacing so that the adapter plugs into the protoboard for jumpering to the port C pins. That then acts as the socket for the microSD card. 

I assume the petitFS library can be built for the xmega32a4. I used the read-only version on an ATTiny85, using it to open a file and position at each sector, then calling my own sector write routine. The files were preallocated using Windows, e.g. Log1.csv, Log2.csv,... each containing 10MB of spaces. .The '85 does not have enough RAM to read or write a 512 byte sector, so I had to use the non-buffered directory read routines. For writing, 16 bit ints were  expanded to comma separated ascii which allowed filling the 512 byte sector using only a 128 byte buffer. Probably such tricks would not be needed for the xmega32 as far as RAM goes. But it uses 7.5K of program flash, don't know how much existing stuff you would have to take out to get that to fit.

http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=645296

I can dig out the code if anyone is interested in modifying it for the xmega.

One very important feature is the ability to display samples before the trigger (pre-trigger). Until now, the Xprotolab detects the trigger and then captures the data. I have the pre-trigger working and will be ready for the next update (1.25), I will make it available in the next few days. This is a major update since it changes the core sampling algorithm, so I need to test it extensively. In addition to the pre-trigger, the Xprotolab will also be able to capture data long after the trigger has occurred (up to 65535 samples later). This compensates for the relatively short sample buffer of 256 samples. And for the many other features on this thread, they will require the upcoming ATXMEGA64A4 which has twice the program memory. I will consider the hardware request for my next board spin.

Pre and Post Trigger implemented in version 1.25

Pulse counter (rising edge, falling edge, both). Basically the frequency meter, minus the time domain, plus the edge selection.