On Sat, Oct 30, 2010 at 01:44:14PM -0700, Kirk Wallace wrote: > > I had another look at the Atmel product line and the ATxmega's look > really interesting. Its funny how all the chips I have looked at so far > are in the $3 to $6 range, so getting too much capability isn't worth > worrying about.
I fell into that trap, mucking about with ATtiny15, ATmega16, and Atmega64. Now the ATxmega devices offer so much more that I'd rather gain experience with, and build up a code base for, the (seriously) fun devices. It's not worth saving a few device dollars, then spending a lot of time developing stuff that is not as portable as I'd like to the next challenge. (Which always is bigger. ;-) > For now, I am thinking about an EPP to analog output gadget. Since > EMC2's software stepping runs in the base thread, I know I can get > about ten packets into the gadget for each servo period, so realtime > functions could be done, though I am thinking of using the analog > output for a VFD, realtime would not be needed. The ATxmega16A4 has a > two channel DAC, five counters that may be used for PWM, a couple of > analog comparators, a fair amount of DIO left over, and other > features, so there is room to expand. I am most concerned about being > able to sort out the EEP, and handling the integration with EMC2 so > that EMC2 can monitor or configure every feature of the gadget. It's easier if you don't start from scratch. There is: http://www.atmel.com/dyn/products/app_notes.asp?family_id=607 Scroll/find your way to the AVR325 application note. ("AVR325: High-speed Interface to Host EPP Parallel Port") There's the PDF, and the source code (blue CD icon). (The code is in assembler, and written for an AVR 8515. Some constants will need to change for xmega. Also, back in 2001, Atmel only worried about source compatibility with the IAR compiler, so a small tidy-up might be needed to make it suitable for the gcc toolchain. (I can sort that out, if you go ahead.) It doubtless doesn't do everything you need, but it's usually easier to tweak than to start from scratch.) There's "AVR1301: Using the XMEGA DAC" there, as well. I found a good EPP specification document long ago. It may have been this: http://www.beyondlogic.org/epp/epp.htm which the "IEEE 1284" wikipedia page references. Nope, I'll keep looking. Without having looked at the EMC2 code, I'd guess that tweaks of its parport driver may be needed to query and configure any special stuff you need, unless that can be handled by the driver's caller, depending on how generic the driver is. It may be possible to just have HAL do writes to control addresses for configuration, and data writes to feed the DACs, if my vague recollection of EPP capabilities is anywhere near the mark. > Or... I may crack open a beer and sit in front of the TV. It's a lot of work to analyse the problem domain (work out all that EPP stuff), and find and choose suitable technology for a solution, then climb far enough up the learning curve to get all its peripherals doing what they should. You're right. There are easier ways to relax. :-) Erik -- No one really listens to anyone else, and if you try it for a while you'll see why. - Mignon McLaughlin ------------------------------------------------------------------------------ Nokia and AT&T present the 2010 Calling All Innovators-North America contest Create new apps & games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
