I've got another proposed changed to LUFA to discuss, and I *really*
do want feedback from everyone on this one as it will affect everyone
using the library.
So far, a lot of the negative feedback against LUFA is that it is too
complex, made so by the use of so many obfuscating macros. My original
intention was to hide as much of the library's complexity behind
macros to give it a friendlier face, but it seems some people have
rejected this and as a result dumped the library as a whole.
One obvious part of this macro obfuscation is in the LUFA event
system, and - to a lesser extent - the descriptor comparator routines.
Currently the library uses a "simple" (in my eyes) set of
EVENT_HANDLER, HANDLES_EVENT, RAISES_EVENT and RAISE_EVENT macros to
hide how the event system actually works. However, people don't seem
to like this much, and I agree that hiding the event parameters from
the user makes the library more confusing as it makes many "magic
variables" inside events which appear from seemingly nowhere.
As a result, I'm proposing that the events system be revamped. Instead
of the current scheme, the user API will consist of only two macros;
RAISE_EVENT(), which will perform the same job as it does currently,
and HANDLES_EVENT(), which will link an event to a user handler
routine
The task of event prototypes will be performed by the library
internally, and so the old HANDLES_EVENT() and RAISES_EVENT() macros
will be removed. The HANDLES_EVENT() macro will be changed, and will
instead take in two arguments: the name of the event that will be
handled, and the name of the user handler for the event. This means
that the user event handler is now a standard function with the
correct parameters for an event as defined in the library
documentation.
Here's an example of the new system:
=== Some LUFA Source .h ===
#include <LUFA/Drivers/USB.h>
I never had a real problem with the old method since it feels fairly
similar to ISR declarations, but the new method certainly increases
the event parameter visibility, which is a good thing. Especially
with the new changes to UnhandledControlPacket, event parameters are a
bit of magic that can't always be understood merely by looking at code
examples, and this change will help that.
On the wider topic of library complexity, the only thing I worry about
is when the library does something automatically without really
telling the user. For example, I needed to look at the source code to
realize that LUFA automatically shuts down the PLL and USB clocks
whenever it gets a suspend interrupt. I don't mind that it does that,
but it's not documented anywhere. Maybe the event handling
documentation should include a description of what the library has
already done by the time an event gets to the user event.
Finally, a little irk that I've had with the new documentation. Is it
possible to add back the master global page of all
functions/defines/etc as a complete set? I like the split out modules
and directories and I think that should stay too, but there are times
I just want to remember what a function is called, and I don't
remember what module it came from. Having the master global page
beats grepping the whole library source every time.
Really great work, and overall I'm very happy with what I can do with
the library. For me, it's much better and simpler than using "raw"
code to do USB handling on the avr.
On Sun, May 17, 2009 at 1:23 AM, Dean Camera <abcminiu...@gmail.com> wrote:
> Hi all,
> I've got another proposed changed to LUFA to discuss, and I *really*
> do want feedback from everyone on this one as it will affect everyone
> using the library.
> So far, a lot of the negative feedback against LUFA is that it is too
> complex, made so by the use of so many obfuscating macros. My original
> intention was to hide as much of the library's complexity behind
> macros to give it a friendlier face, but it seems some people have
> rejected this and as a result dumped the library as a whole.
> One obvious part of this macro obfuscation is in the LUFA event
> system, and - to a lesser extent - the descriptor comparator routines.
> Currently the library uses a "simple" (in my eyes) set of
> EVENT_HANDLER, HANDLES_EVENT, RAISES_EVENT and RAISE_EVENT macros to
> hide how the event system actually works. However, people don't seem
> to like this much, and I agree that hiding the event parameters from
> the user makes the library more confusing as it makes many "magic
> variables" inside events which appear from seemingly nowhere.
> As a result, I'm proposing that the events system be revamped. Instead
> of the current scheme, the user API will consist of only two macros;
> RAISE_EVENT(), which will perform the same job as it does currently,
> and HANDLES_EVENT(), which will link an event to a user handler
> routine
> The task of event prototypes will be performed by the library
> internally, and so the old HANDLES_EVENT() and RAISES_EVENT() macros
> will be removed. The HANDLES_EVENT() macro will be changed, and will
> instead take in two arguments: the name of the event that will be
> handled, and the name of the user handler for the event. This means
> that the user event handler is now a standard function with the
> correct parameters for an event as defined in the library
> documentation.
> Here's an example of the new system:
> === Some LUFA Source .h ===
> #include <LUFA/Drivers/USB.h>
How many callback functions in total does the library potentially
expect to link against? Perhaps if it's not too many it would be
practical to pass all the callback function pointers in a structure
to the library init fcn... the advantage being one copy of the
library in the bootloader could be reused (init function would
have to have a well known address...)
J.
On May 17, 4:23 am, Dean Camera <abcminiu...@gmail.com> wrote:
> I've got another proposed changed to LUFA to discuss, and I *really*
> do want feedback from everyone on this one as it will affect everyone
> using the library.
> Here's an example of the new system:
> === Some LUFA Source .h ===
> #include <LUFA/Drivers/USB.h>
> I never had a real problem with the old method since it feels fairly
> similar to ISR declarations
I tried to use macros similar to ISRs, to try to retain a sense of
familiarity about them to new users. However, that backfired because
of the hidden parameters, and because people tried to understand the
complex LUFA code behind them and gave up rather than just reading the
documentation and using them as described. I could have altered them
to require the user to put in the parameters, but then what's the
point? Better to use normal functions like the GetDescriptor user hook
function already does.
> but the new method certainly increases the event parameter visibility, which is a good thing.
Exactly - I've done the same to the STREAM_CALLBACK and
DESRIPTOR_COMPARATOR macros so that now everything is standard
functions, with the user responsible for ensuring that they use the
correct parameters and names. I've ditched all the macros in the event
system entirely, so it's just a matter of defining a event function
signature identical to the one in the documentation.
> Especially
> with the new changes to UnhandledControlPacket, event parameters are a
> bit of magic that can't always be understood merely by looking at code
> examples, and this change will help that.
Funnily enough the latest release actually *removes* all the
parameters from that event, and instead provides the entire request
header in the global USB_ControlRequest struct. That makes things more
uniform between the host and device modes.
> On the wider topic of library complexity, the only thing I worry about
> is when the library does something automatically without really
> telling the user. For example, I needed to look at the source code to
> realize that LUFA automatically shuts down the PLL and USB clocks
> whenever it gets a suspend interrupt. I don't mind that it does that,
> but it's not documented anywhere. Maybe the event handling
> documentation should include a description of what the library has
> already done by the time an event gets to the user event.
Whoops! Fixed. Actually, that's the only thing of note in the events
system; everything else is self-explanatory. I've added in to the
events documentation information about the PLL management when the
USB_OPT_AUTO_PLL option is set, and fixed up a few other minor
glitches. See the latest SVN revisions.
> Finally, a little irk that I've had with the new documentation. Is it
> possible to add back the master global page of all
> functions/defines/etc as a complete set?
I was about to say that you're mistaken since I didn't remove it, but
you're right! Turns out that when I turned off the automated file
documentation (deprecated since the modules view is now what should be
used for the library) Doxygen kills the globals page too. I've re-
enabled it so that it's now back. Users will be able to use the Files
view instead of the Modules view if they wish in future releases, but
all the documentation will be heavily geared towards the more friendly
modules view. If you have Doxygen installed, just change the
SHOW_FILES value in LUFA/Doxygen.conf from NO to YES and regenerate
the documentation.
> Really great work, and overall I'm very happy with what I can do with
> the library. For me, it's much better and simpler than using "raw"
> code to do USB handling on the avr.
Thanks for the feedback! I appreciate constructive criticism as much
(if not more) than just praise, since it lets me know that people are
using the code enough to discover its flaws, and helps me make a
better library.
Cheers!
- Dean
On May 19, 4:48 am, Brian Dickman <brian.dick...@gmail.com> wrote:
> I never had a real problem with the old method since it feels fairly
> similar to ISR declarations, but the new method certainly increases
> the event parameter visibility, which is a good thing. Especially
> with the new changes to UnhandledControlPacket, event parameters are a
> bit of magic that can't always be understood merely by looking at code
> examples, and this change will help that.
> On the wider topic of library complexity, the only thing I worry about
> is when the library does something automatically without really
> telling the user. For example, I needed to look at the source code to
> realize that LUFA automatically shuts down the PLL and USB clocks
> whenever it gets a suspend interrupt. I don't mind that it does that,
> but it's not documented anywhere. Maybe the event handling
> documentation should include a description of what the library has
> already done by the time an event gets to the user event.
> Finally, a little irk that I've had with the new documentation. Is it
> possible to add back the master global page of all
> functions/defines/etc as a complete set? I like the split out modules
> and directories and I think that should stay too, but there are times
> I just want to remember what a function is called, and I don't
> remember what module it came from. Having the master global page
> beats grepping the whole library source every time.
> Really great work, and overall I'm very happy with what I can do with
> the library. For me, it's much better and simpler than using "raw"
> code to do USB handling on the avr.
> --
> Brian
> On Sun, May 17, 2009 at 1:23 AM, Dean Camera <abcminiu...@gmail.com> wrote:
> > Hi all,
> > I've got another proposed changed to LUFA to discuss, and I *really*
> > do want feedback from everyone on this one as it will affect everyone
> > using the library.
> > So far, a lot of the negative feedback against LUFA is that it is too
> > complex, made so by the use of so many obfuscating macros. My original
> > intention was to hide as much of the library's complexity behind
> > macros to give it a friendlier face, but it seems some people have
> > rejected this and as a result dumped the library as a whole.
> > One obvious part of this macro obfuscation is in the LUFA event
> > system, and - to a lesser extent - the descriptor comparator routines.
> > Currently the library uses a "simple" (in my eyes) set of
> > EVENT_HANDLER, HANDLES_EVENT, RAISES_EVENT and RAISE_EVENT macros to
> > hide how the event system actually works. However, people don't seem
> > to like this much, and I agree that hiding the event parameters from
> > the user makes the library more confusing as it makes many "magic
> > variables" inside events which appear from seemingly nowhere.
> > As a result, I'm proposing that the events system be revamped. Instead
> > of the current scheme, the user API will consist of only two macros;
> > RAISE_EVENT(), which will perform the same job as it does currently,
> > and HANDLES_EVENT(), which will link an event to a user handler
> > routine
> > The task of event prototypes will be performed by the library
> > internally, and so the old HANDLES_EVENT() and RAISES_EVENT() macros
> > will be removed. The HANDLES_EVENT() macro will be changed, and will
> > instead take in two arguments: the name of the event that will be
> > handled, and the name of the user handler for the event. This means
> > that the user event handler is now a standard function with the
> > correct parameters for an event as defined in the library
> > documentation.
> How many callback functions in total does the library potentially
> expect to link against?
Are you talking about just events? There are 18 events total in the
LUFA library when both Host and Device mode is enabled, plus the
GetDescriptor function when in device mode. I wouldn't want to make
the user provide the jump table for the same reasons I recommend
against compiling LUFA as a true library .a file; you lose the ability
to fine-tune it via the compile time options, and it would end up not
being able to fit into the 4KB maximum bootloader space if everything
was turned on in the bootloader code. However, thanks for the idea/
feedback, much appreciated.
- Dean
On May 19, 11:54 am, djd <djeffdio...@gmail.com> wrote:
> How many callback functions in total does the library potentially
> expect to link against? Perhaps if it's not too many it would be
> practical to pass all the callback function pointers in a structure
> to the library init fcn... the advantage being one copy of the
> library in the bootloader could be reused (init function would
> have to have a well known address...)
> J.
> On May 17, 4:23 am, Dean Camera <abcminiu...@gmail.com> wrote:
> > Hi all,
> > I've got another proposed changed to LUFA to discuss, and I *really*
> > do want feedback from everyone on this one as it will affect everyone
> > using the library.
> > Here's an example of the new system:
I tried to port LUFA to CodeVision and got it to compile without
errors but with lots of warnings and it never quite worked. A major
hurdle was trying to understand and translate the event macros. I am
keen to try again with these changes. Anyone else working with LUFA
and CodeVision?
The new system should be VERY easy to port, since it's all now just
regular functions. For Codevision, just remove the private section of
Events.h in the latest SVN revision to remove the GCC weak aliases.
You'll then be forced to provide event handlers for *every* event
since you won't have the benefit of the automatic aliases to the
internal event stub function if the function is unhooked in the user
application, but other than that it'll work the same.
- Dean
On May 19, 9:16 pm, Dense505crew <ian.gregg....@gmail.com> wrote:
> I tried to port LUFA to CodeVision and got it to compile without
> errors but with lots of warnings and it never quite worked. A major
> hurdle was trying to understand and translate the event macros. I am
> keen to try again with these changes. Anyone else working with LUFA
> and CodeVision?
How does everyone feel about layering the USB class implementations in
the demos? The biggest complaint I get is that the demos individually
are hard to process, since both the USB class implementation and the
actual demo functionality is tied together intimately. This makes
things hard to read, and makes old demos hard to upgrade as I fix bugs
in the class implementations.
I'm thinking of layering each class implementation, so that each demo
will consist of:
1) Any driver code needed for the demo (such as the Ethernet stack in
the RNDIS demo, etc.) in a Lib/ subfolder of each demo
2) USB class implementation of each demo in a Class/ folder of each
demo, with a documented interface for integrating it with a user
project
3) The main demo file(s), which uses the class implementation API and
specialist driver code in the demo root folder
Of course, the most logical extreme of this would be to move the class
drivers into the library proper, linked to the user code as needed.
That means that the AudioInput demo for example would have the main
loop of:
for (;;)
{
if (USB_AudioInput_IsReadyForNextSample() && (TIFR0 & (1 << OCF0A))
{
/* Clear the sample reload timer */
TIFR0 |= (1 << OCF0A);
/* Audio sample is ADC value scaled to fit the entire range */
int16_t AudioSample = ((SAMPLE_MAX_RANGE / ADC_MAX_RANGE) *
ADC_GetResult());
#if defined(MICROPHONE_BIASED_TO_HALF_RAIL)
/* Microphone is biased to half rail voltage, subtract the bias
from the sample value */
AudioSample -= (SAMPLE_MAX_RANGE / 2));
#endif
/* Write the sample to the buffer */
USB_AudioInput_WriteNextSample(AudioSample);
}
USB_USBTask();
}
Which is easier to read that the current code. Of course, this would
present some new problems, namely;
a) The user will have to hook all events required by the implemented
classes, and pass them to the class event handlers manually (so that
compound devices can be made with multiple classes)
b) Code size increase associated with any extra logic required
c) Slower code since the class APIs will need to be foolproof
What's everyone's opinion on this?
- Dean
On May 19, 9:20 pm, Dean Camera <abcminiu...@gmail.com> wrote:
> The new system should be VERY easy to port, since it's all now just
> regular functions. For Codevision, just remove the private section of
> Events.h in the latest SVN revision to remove the GCC weak aliases.
> You'll then be forced to provide event handlers for *every* event
> since you won't have the benefit of the automatic aliases to the
> internal event stub function if the function is unhooked in the user
> application, but other than that it'll work the same.
> - Dean
> On May 19, 9:16 pm, Dense505crew <ian.gregg....@gmail.com> wrote:
> > I tried to port LUFA to CodeVision and got it to compile without
> > errors but with lots of warnings and it never quite worked. A major
> > hurdle was trying to understand and translate the event macros. I am
> > keen to try again with these changes. Anyone else working with LUFA
> > and CodeVision?
On Wed, 2009-05-20 at 08:08 -0700, Dean Camera wrote:
> How does everyone feel about layering the USB class implementations in
> the demos? The biggest complaint I get is that the demos individually
> are hard to process, since both the USB class implementation and the
> actual demo functionality is tied together intimately. This makes
> things hard to read, and makes old demos hard to upgrade as I fix bugs
> in the class implementations.
> I'm thinking of layering each class implementation, so that each demo
> will consist of:
> 1) Any driver code needed for the demo (such as the Ethernet stack in
> the RNDIS demo, etc.) in a Lib/ subfolder of each demo
> 2) USB class implementation of each demo in a Class/ folder of each
> demo, with a documented interface for integrating it with a user
> project
> 3) The main demo file(s), which uses the class implementation API and
> specialist driver code in the demo root folder
> Of course, the most logical extreme of this would be to move the class
> drivers into the library proper, linked to the user code as needed.
> That means that the AudioInput demo for example would have the main
> loop of:
> for (;;)
> {
> if (USB_AudioInput_IsReadyForNextSample() && (TIFR0 & (1 << OCF0A))
> {
> /* Clear the sample reload timer */
> TIFR0 |= (1 << OCF0A);
> /* Audio sample is ADC value scaled to fit the entire range */
> int16_t AudioSample = ((SAMPLE_MAX_RANGE / ADC_MAX_RANGE) *
> ADC_GetResult());
> #if defined(MICROPHONE_BIASED_TO_HALF_RAIL)
> /* Microphone is biased to half rail voltage, subtract the bias
> from the sample value */
> AudioSample -= (SAMPLE_MAX_RANGE / 2));
> #endif
> /* Write the sample to the buffer */
> USB_AudioInput_WriteNextSample(AudioSample);
> }
> USB_USBTask();
> }
> Which is easier to read that the current code. Of course, this would
> present some new problems, namely;
> a) The user will have to hook all events required by the implemented
> classes, and pass them to the class event handlers manually (so that
> compound devices can be made with multiple classes)
> b) Code size increase associated with any extra logic required
> c) Slower code since the class APIs will need to be foolproof
> What's everyone's opinion on this?
> - Dean
> On May 19, 9:20 pm, Dean Camera <abcminiu...@gmail.com> wrote:
> > Ian,
> > The new system should be VERY easy to port, since it's all now just
> > regular functions. For Codevision, just remove the private section of
> > Events.h in the latest SVN revision to remove the GCC weak aliases.
> > You'll then be forced to provide event handlers for *every* event
> > since you won't have the benefit of the automatic aliases to the
> > internal event stub function if the function is unhooked in the user
> > application, but other than that it'll work the same.
> > - Dean
> > On May 19, 9:16 pm, Dense505crew <ian.gregg....@gmail.com> wrote:
> > > I tried to port LUFA to CodeVision and got it to compile without
> > > errors but with lots of warnings and it never quite worked. A major
> > > hurdle was trying to understand and translate the event macros. I am
> > > keen to try again with these changes. Anyone else working with LUFA
> > > and CodeVision?
So that everyone can see where I'm going with this, below is the Mouse
Device demo converted to the work-in-progress class driver (this
actually works under my unreleased library code, the only thing
missing is the descriptors which are unchanged):
Neat, eh? Each class driver will have a defined set of events/
callbacks/functions, which the user is to implement. This method
allows for the same class driver to be used on multiple interfaces of
the same class within the device (for example, two keyboards, or a
keyboard and a joystick) as well as for multiple different class
drivers to be used in the one compound device.
- Dean
On May 25, 5:14 pm, julien tous <jtous....@orange-ftgroup.com> wrote:
> On Wed, 2009-05-20 at 08:08 -0700, Dean Camera wrote:
> > How does everyone feel about layering the USB class implementations in
> > the demos? The biggest complaint I get is that the demos individually
> > are hard to process, since both the USB class implementation and the
> > actual demo functionality is tied together intimately. This makes
> > things hard to read, and makes old demos hard to upgrade as I fix bugs
> > in the class implementations.
> > I'm thinking of layering each class implementation, so that each demo
> > will consist of:
> > 1) Any driver code needed for the demo (such as the Ethernet stack in
> > the RNDIS demo, etc.) in a Lib/ subfolder of each demo
> > 2) USB class implementation of each demo in a Class/ folder of each
> > demo, with a documented interface for integrating it with a user
> > project
> > 3) The main demo file(s), which uses the class implementation API and
> > specialist driver code in the demo root folder
> > Of course, the most logical extreme of this would be to move the class
> > drivers into the library proper, linked to the user code as needed.
> > That means that the AudioInput demo for example would have the main
> > loop of:
> > /* Audio sample is ADC value scaled to fit the entire range */
> > int16_t AudioSample = ((SAMPLE_MAX_RANGE / ADC_MAX_RANGE) *
> > ADC_GetResult());
> > #if defined(MICROPHONE_BIASED_TO_HALF_RAIL)
> > /* Microphone is biased to half rail voltage, subtract the bias
> > from the sample value */
> > AudioSample -= (SAMPLE_MAX_RANGE / 2));
> > #endif
> > /* Write the sample to the buffer */
> > USB_AudioInput_WriteNextSample(AudioSample);
> > }
> > USB_USBTask();
> > }
> > Which is easier to read that the current code. Of course, this would
> > present some new problems, namely;
> > a) The user will have to hook all events required by the implemented
> > classes, and pass them to the class event handlers manually (so that
> > compound devices can be made with multiple classes)
> > b) Code size increase associated with any extra logic required
> > c) Slower code since the class APIs will need to be foolproof
> > What's everyone's opinion on this?
> > - Dean
> > On May 19, 9:20 pm, Dean Camera <abcminiu...@gmail.com> wrote:
> > > Ian,
> > > The new system should be VERY easy to port, since it's all now just
> > > regular functions. For Codevision, just remove the private section of
> > > Events.h in the latest SVN revision to remove the GCC weak aliases.
> > > You'll then be forced to provide event handlers for *every* event
> > > since you won't have the benefit of the automatic aliases to the
> > > internal event stub function if the function is unhooked in the user
> > > application, but other than that it'll work the same.
> > > - Dean
> > > On May 19, 9:16 pm, Dense505crew <ian.gregg....@gmail.com> wrote:
> > > > I tried to port LUFA to CodeVision and got it to compile without
> > > > errors but with lots of warnings and it never quite worked. A major
> > > > hurdle was trying to understand and translate the event macros. I am
> > > > keen to try again with these changes. Anyone else working with LUFA
> > > > and CodeVision?
This contains newer commits (from the private repository) than have
been made public; the public SVN revision represents the current
stable version, while this is a true work-in-progress. Yes, before
anyone starts yelling, I do plan on moving towards branches for future
unstable commits.
In any case, I'd like for LUFA users to download and take a look at
the new device demos. All the demos have now been completely converted
over to the proposed class drivers, meaning much simpler code and much
less work for the end-user. The class drivers aren't fully documented
yet, but the purpose of this is to gauge public opinion on the
changes. Host mode demos won't even compile currently due to the
removal of the pseudo-scheduler from the library - they will be
converted over in a similar manner as the device demos before the
release.
Incidentally, I now have two choices. The current public SVN revision
is stable, and reflects the final LUFA API. Another month has elapsed,
and my gut instinct is to release the public SVN commit as the 0906XX
release, since the previous release had several critical issues. A
release from the public SVN means everyone can start getting used to
the final LUFA APIs even without the new class drivers, which would
then be pushed back to next month.
The alternative to this is to delay this month's release, until I have
finished and documented all the device and host mode drivers. Does
anyone have an opinion on this? Do people want me to release the class-
driverless public stable commit as this month's release to get it out
early, or is everyone happy to wait for the class drivers to be
completed?
- Dean
On May 27, 11:20 pm, Dean Camera <abcminiu...@gmail.com> wrote:
> So that everyone can see where I'm going with this, below is the Mouse
> Device demo converted to the work-in-progress class driver (this
> actually works under my unreleased library code, the only thing
> missing is the descriptors which are unchanged):
> Neat, eh? Each class driver will have a defined set of events/
> callbacks/functions, which the user is to implement. This method
> allows for the same class driver to be used on multiple interfaces of
> the same class within the device (for example, two keyboards, or a
> keyboard and a joystick) as well as for multiple different class
> drivers to be used in the one compound device.
> - Dean
> On May 25, 5:14 pm, julien tous <jtous....@orange-ftgroup.com> wrote:
> > I think it would be a good move !
> > Julien
> > On Wed, 2009-05-20 at 08:08 -0700, Dean Camera wrote:
> > > How does everyone feel about layering the USB class implementations in
> > > the demos? The biggest complaint I get is that the demos individually
> > > are hard to process, since both the USB class implementation and the
> > > actual demo functionality is tied together intimately. This makes
> > > things hard to read, and makes old demos hard to upgrade as I fix bugs
> > > in the class implementations.
> > > I'm thinking of layering each class implementation, so that each demo
> > > will consist of:
> > > 1) Any driver code needed for the demo (such as the Ethernet stack in
> > > the RNDIS demo, etc.) in a Lib/ subfolder of each demo
> > > 2) USB class implementation of each demo in a Class/ folder of each
> > > demo, with a documented interface for integrating it with a user
> > > project
> > > 3) The main demo file(s), which uses the class implementation API and
> > > specialist driver code in the demo root folder
> > > Of course, the most logical extreme of this would be to move the class
> > > drivers into the library proper, linked to the user code as needed.
> > > That means that the AudioInput demo for example would have the main
> > > loop of:
> > > /* Audio sample is ADC value scaled to fit the entire range */
> > > int16_t AudioSample = ((SAMPLE_MAX_RANGE / ADC_MAX_RANGE) *
> > > ADC_GetResult());
> > > #if defined(MICROPHONE_BIASED_TO_HALF_RAIL)
> > > /* Microphone is biased to half rail voltage, subtract the bias
> > > from the sample value */
> > > AudioSample -= (SAMPLE_MAX_RANGE / 2));
> > > #endif
> > > /* Write the sample to the buffer */
> > > USB_AudioInput_WriteNextSample(AudioSample);
> > > }
> > > USB_USBTask();
> > > }
> > > Which is easier to read that the current code. Of course, this would
> > > present some new problems, namely;
> > > a) The user will have to hook all events required by the implemented
> > > classes, and pass them to the class event handlers manually (so that
> > > compound devices can be made with multiple classes)
> > > b) Code size increase associated with any extra logic required
> > > c) Slower code since the class APIs will need to be foolproof
> > > What's everyone's opinion on this?
> > > - Dean
> > > On May 19, 9:20 pm, Dean Camera <abcminiu...@gmail.com> wrote:
> > > > Ian,
> > > > The new system should be VERY easy to port, since it's all now just
> > > > regular functions. For Codevision, just remove the private section of
> > > > Events.h in the latest SVN revision to remove the GCC weak aliases.
> > > > You'll then be forced to provide event handlers for *every* event
> > > > since you won't have the benefit of the automatic aliases to the
> > > > internal event stub function if the function is unhooked in the user
> > > > application, but other
Apparently one person at least didn't read any of this, and was very
unhappy when they found out that the WORK IN PROGRESS version was not
representative of a PUBLIC RELEASE. I'll have to be more careful next
time.
In any case, I've pulled the WIP, and merged all the pending changes
from my private SVN into the public SVN, now that this month's release
has been made (without the class drivers, since they weren't ready at
the time). The new SVN revisions contain both the low level
schedulerless demos everyone's used to, as well as the same demos
implemented on the new class drivers, which are still a work in
progress. The host mode class drivers aren't done yet, and so the
Demos/Host/ClassDrivers directory currently won't build.
I've made some changes from the previous WIP in regards to the
different class APIs, to fix some shortcomings identified by myself
and others (for example, multiple reports in a single HID interface).
The current revision's device mode class demos are more polished and
should be quite close to the finished APIs for the next version.
- Dean
On Jun 4, 4:05 pm, Dean Camera <abcminiu...@gmail.com> wrote:
> This contains newer commits (from the private repository) than have
> been made public; the public SVN revision represents the current
> stable version, while this is a true work-in-progress. Yes, before
> anyone starts yelling, I do plan on moving towards branches for future
> unstable commits.
> In any case, I'd like for LUFA users to download and take a look at
> the new device demos. All the demos have now been completely converted
> over to the proposed class drivers, meaning much simpler code and much
> less work for the end-user. The class drivers aren't fully documented
> yet, but the purpose of this is to gauge public opinion on the
> changes. Host mode demos won't even compile currently due to the
> removal of the pseudo-scheduler from the library - they will be
> converted over in a similar manner as the device demos before the
> release.
> Incidentally, I now have two choices. The current public SVN revision
> is stable, and reflects the final LUFA API. Another month has elapsed,
> and my gut instinct is to release the public SVN commit as the 0906XX
> release, since the previous release had several critical issues. A
> release from the public SVN means everyone can start getting used to
> the final LUFA APIs even without the new class drivers, which would
> then be pushed back to next month.
> The alternative to this is to delay this month's release, until I have
> finished and documented all the device and host mode drivers. Does
> anyone have an opinion on this? Do people want me to release the class-
> driverless public stable commit as this month's release to get it out
> early, or is everyone happy to wait for the class drivers to be
> completed?
> - Dean
> On May 27, 11:20 pm, Dean Camera <abcminiu...@gmail.com> wrote:
> > So that everyone can see where I'm going with this, below is the Mouse
> > Device demo converted to the work-in-progress class driver (this
> > actually works under my unreleased library code, the only thing
> > missing is the descriptors which are unchanged):
> > Neat, eh? Each class driver will have a defined set of events/
> > callbacks/functions, which the user is to implement. This method
> > allows for the same class driver to be used on multiple interfaces of
> > the same class within the device (for example, two keyboards, or a
> > keyboard and a joystick) as well as for multiple different class
> > drivers to be used in the one compound device.
> > - Dean
> > On May 25, 5:14 pm, julien tous <jtous....@orange-ftgroup.com> wrote:
> > > I think it would be a good move !
> > > Julien
> > > On Wed, 2009-05-20 at 08:08 -0700, Dean Camera wrote:
> > > > How does everyone feel about layering the USB class implementations in
> > > > the demos? The biggest complaint I get is that the demos individually
> > > > are hard to process, since both the USB class implementation and the
> > > > actual demo functionality is tied together intimately. This makes
> > > > things hard to read, and makes old demos hard to upgrade as I fix bugs
> > > > in the class implementations.
> > > > I'm thinking of layering each class implementation, so that each demo
> > > > will consist of:
> > > > 1) Any driver code needed for the demo (such as the Ethernet stack in
> > > > the RNDIS demo, etc.) in a Lib/ subfolder of each demo
> > > > 2) USB class implementation of each demo in a Class/ folder of each
> > > > demo, with a documented interface for integrating it with a user
> > > > project
> > > > 3) The main demo file(s), which uses the class implementation API and
> > > > specialist driver code in the demo root folder
> > > > Of course, the most logical extreme of this would be to move the class
> > > > drivers into the library proper, linked to the user code as needed.
> > > > That means that the AudioInput demo for example would have the main
> > > > loop of:
New Alpha version uploaded to the files section, mirroring the latest
(594) SVN revision. This new ***INCOMPLETE ALPHA*** version shows the
finished - but not yet finalised - device mode class drivers, plus the
beginnings of the corresponding host mode class drivers. You can now
see how I'm planning on splitting these up; there will be a central
dispatch header in LUFA/Drivers/USB/Class/<Classname>.h which then
includes all the required private headers for that class and the
allowable USB modes in the source hierarchy. By having a common set of
class headers for both device and host, the user code is simplified
greatly.
Currently you can have a project with multiple different USB device
class instances (e.g. a HID driver and a Mass Storage driver) or even
a device with multiple instances of the same class. I'm trying to work
it so that the same class info structures can be used between the
device and host drivers of each class, so there'll only be one
configuration structure for each class regardless of USB mode.
Users should expect to be able to implement both device and host mode
class drivers (including multiples of each) in a single project with
minimal code from the next revision. I'm currently in the middle of
University exams and will be on a short holiday soon afterwards, thus
the next release will be somewhat delayed.
- Dean
On Jun 8, 6:48 pm, Dean Camera <abcminiu...@gmail.com> wrote:
> Apparently one person at least didn't read any of this, and was very
> unhappy when they found out that the WORK IN PROGRESS version was not
> representative of a PUBLIC RELEASE. I'll have to be more careful next
> time.
> In any case, I've pulled the WIP, and merged all the pending changes
> from my private SVN into the public SVN, now that this month's release
> has been made (without the class drivers, since they weren't ready at
> the time). The new SVN revisions contain both the low level
> schedulerless demos everyone's used to, as well as the same demos
> implemented on the new class drivers, which are still a work in
> progress. The host mode class drivers aren't done yet, and so the
> Demos/Host/ClassDrivers directory currently won't build.
> I've made some changes from the previous WIP in regards to the
> different class APIs, to fix some shortcomings identified by myself
> and others (for example, multiple reports in a single HID interface).
> The current revision's device mode class demos are more polished and
> should be quite close to the finished APIs for the next version.
> - Dean
> On Jun 4, 4:05 pm, Dean Camera <abcminiu...@gmail.com> wrote:
> > I've just uploaded a WIP version of the library to the files section:
> > This contains newer commits (from the private repository) than have
> > been made public; the public SVN revision represents the current
> > stable version, while this is a true work-in-progress. Yes, before
> > anyone starts yelling, I do plan on moving towards branches for future
> > unstable commits.
> > In any case, I'd like for LUFA users to download and take a look at
> > the new device demos. All the demos have now been completely converted
> > over to the proposed class drivers, meaning much simpler code and much
> > less work for the end-user. The class drivers aren't fully documented
> > yet, but the purpose of this is to gauge public opinion on the
> > changes. Host mode demos won't even compile currently due to the
> > removal of the pseudo-scheduler from the library - they will be
> > converted over in a similar manner as the device demos before the
> > release.
> > Incidentally, I now have two choices. The current public SVN revision
> > is stable, and reflects the final LUFA API. Another month has elapsed,
> > and my gut instinct is to release the public SVN commit as the 0906XX
> > release, since the previous release had several critical issues. A
> > release from the public SVN means everyone can start getting used to
> > the final LUFA APIs even without the new class drivers, which would
> > then be pushed back to next month.
> > The alternative to this is to delay this month's release, until I have
> > finished and documented all the device and host mode drivers. Does
> > anyone have an opinion on this? Do people want me to release the class-
> > driverless public stable commit as this month's release to get it out
> > early, or is everyone happy to wait for the class drivers to be
> > completed?
> > - Dean
> > On May 27, 11:20 pm, Dean Camera <abcminiu...@gmail.com> wrote:
> > > So that everyone can see where I'm going with this, below is the Mouse
> > > Device demo converted to the work-in-progress class driver (this
> > > actually works under my unreleased library code, the only thing
> > > missing is the descriptors which are unchanged):
> > > Neat, eh? Each class driver will have a defined set of events/
> > > callbacks/functions, which the user is to implement. This method
> > > allows for the same class driver to be used on multiple interfaces of
> > > the same class within the device (for example, two keyboards, or a
> > > keyboard and a joystick) as well as for multiple different class
> > > drivers to be used in the one compound device.
> > > - Dean
> > > On May 25, 5:14 pm, julien tous <jtous....@orange-ftgroup.com> wrote:
> > > > I think it would be a good move !
> > > > Julien
> > > > On Wed, 2009-05-20 at 08:08 -0700, Dean Camera wrote:
> > > > > How does everyone feel about layering the USB class implementations in
> > > > > the demos? The biggest complaint I get is that the demos individually
> > > > > are hard to process, since
|
