Hi Bob,
As far as I can tell, you have the ports for the red/blue LEDs
switched - Red is D6, Blue is D5. See also the schematic at
http://www.talpa.dk/Electronics/minimus32/minimus32/minimus32.pdf
Alan Burlison
Yeah, it has been pointed out to me.
Will fix it on monday.On Sep 29, 2012 7:13 PM, “Alan Burlison” alan.burlison@gmail.com wrote:
Hi Bob,
As far as I can tell, you have the ports for the red/blue LEDs
switched - Red is D6, Blue is D5. See also the schematic at
http://www.talpa.dk/Electronics/minimus32/minimus32/minimus32.pdf–
Alan Burlison–
You received this message because you are subscribed to the Google Groups
"HAC:Manchester" group.
To post to this group, send an email to hacman@googlegroups.com.
To unsubscribe from this group, send email to
hacman+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/hacman?hl=en-GB.
Yeah, it has been pointed out to me.
Will fix it on monday.
No worries, thanks for the diagram, I found it very useful 
Got
both stdio and an accurate timer working now, next thing is the USB
gubbins Eventual plan is to get avr-libc running over USB as
well.
Alan Burlison
If you look at the rfid code, I am using the USB-CDC bits in there,
and it is extremely simple.
The code here is a little out of date (it’s using a old version of the
lib) but should give you a bit of a idea.
https://github.com/drrk/minimus-weigand/tree/test
KimballOn 30 September 2012 01:26, Alan Burlison alan.burlison@gmail.com wrote:
Yeah, it has been pointed out to me.
Will fix it on monday.
No worries, thanks for the diagram, I found it very useful
Got
both stdio and an accurate timer working now, next thing is the USB
gubbins
well.–
Alan Burlison–
You received this message because you are subscribed to the Google Groups “HAC:Manchester” group.
To post to this group, send an email to hacman@googlegroups.com.
To unsubscribe from this group, send email to hacman+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/hacman?hl=en-GB.
If you look at the rfid code, I am using the USB-CDC bits in there,
and it is extremely simple.The code here is a little out of date (it’s using a old version of the
lib) but should give you a bit of a idea.
https://github.com/drrk/minimus-weigand/tree/test
Yes, looks simple enough, but the USART stdio stuff is entirely
interrupt-driven so you don’t have to have a driving loop to run it.
It doesn’t appear to be possible to make LUFA interrupt-driven, it
seems to force a poll loop onto your application.
Alan Burlison
Put the poll in a timer interrupt ;)On 30 September 2012 14:46, Alan Burlison alan.burlison@gmail.com wrote:
If you look at the rfid code, I am using the USB-CDC bits in there,
and it is extremely simple.The code here is a little out of date (it’s using a old version of the
lib) but should give you a bit of a idea.
https://github.com/drrk/minimus-weigand/tree/testYes, looks simple enough, but the USART stdio stuff is entirely
interrupt-driven so you don’t have to have a driving loop to run it.
It doesn’t appear to be possible to make LUFA interrupt-driven, it
seems to force a poll loop onto your application.–
Alan Burlison–
You received this message because you are subscribed to the Google Groups “HAC:Manchester” group.
To post to this group, send an email to hacman@googlegroups.com.
To unsubscribe from this group, send email to hacman+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/hacman?hl=en-GB.
Put the poll in a timer interrupt
Actually, I’ll probably just do it in the lowest-priority task in my
scheduler - but it’s still in effect polling, wherever possible I try
to avoid doing that 
Alan Burlison
I know. I do wonder why it is like that - as the SB is interrupt
driven itself. Maybe ask on to forums on avrfreaks, Dean is often on
there.On 30 September 2012 16:37, Alan Burlison alan.burlison@gmail.com wrote:
Put the poll in a timer interrupt
Actually, I’ll probably just do it in the lowest-priority task in my
scheduler - but it’s still in effect polling, wherever possible I try
to avoid doing that–
Alan Burlison–
You received this message because you are subscribed to the Google Groups “HAC:Manchester” group.
To post to this group, send an email to hacman@googlegroups.com.
To unsubscribe from this group, send email to hacman+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/hacman?hl=en-GB.
I know. I do wonder why it is like that - as the SB is interrupt
driven itself. Maybe ask on to forums on avrfreaks, Dean is often on
there.
From digging around it seems like there used to be an ISR-driven
interface, but at some point it was removed, no idea why. Also the
Atmel datasheet for the 32U2 says that “CONTROL endpoints should not
be managed by interrupts, but only by polling the status bits”
(section 21.12), perhaps that is the reason.
In addition, it appears that the framework allocates buffers for 16
endpoints whereas the 32U2 only has 4, resulting in a significant
waste of memory. I think part of the problem is that he’s trying to
support the 8-bit Atmels, the Xmegas and the 32-bit parts all in the
same library, but they have significantly different USB hardware.
Splitting the library into family-specific variants might be easier
than trying to do it all-in -one.
There’s a google group that seems to be where most of the questions
are asked - https://groups.google.com/forum/?fromgroups=#!forum/lufa-support
- I’ll ask over there.
Alan Burlison