> --
> 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.
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.
> 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
> --
> --
> 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.
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.
> 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
> --
> --
> 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.
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 ;-)
> 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.
