Driver and firmware status for atusb
stefan at datenfreihafen.org
Thu Jun 16 02:56:19 EDT 2011
On Wed, 2011-06-15 at 18:26, Werner Almesberger wrote:
> Stefan Schmidt wrote:
> > Six atusb sticks should be on the way to me now and will hopefully
> > arrive end of this week or early next week. :)
> Whee, you're fast ! :)
Sure, tight schedule, as usual. :D
> > Have a, say dirtpan with ssh, connection between a
> > linux pc and a atben been tested already?
> No, the kernel doesn't support atusb yet.
OK, so I did read the commit history right and did not miss something
> > What I have seen from the git repo there have been work for a
> > platform-specific reset function and some groundwork for the split,
> > but no actual code that lets me drive the atusb board. Is there any
> > git/patch I mised?
> I'm at the moment cleaning up things that would only get in the way
> later, in case anyone else is tracking changes to the driver. So
> far, I haven't gotten a reaction to my patches, much as I expected.
> so I time out after waiting a polite amount of time before moving
> ahead to the next one, reduce the politeness delay a little, etc.
Yeah, I need to clean up some of my cc2420 patches and send them out
as well. Maybe with a small note asking for the status of the 2.6.38
patches getting merged...
> I just wish we had sponsorship for that work. Then I could commit to
> beating that whole stack into shape, along with 6LoWPAN, take charge,
> and overall move a lot swifter.
I can only second that. Sadly this is a kind of vendor independent
task where its hard to find funding for. We might ask Jon Smirl about
the reaction from CELF to his proposal.
Other candidates would be big player from the 6lowpan IETF task force
like cisco or such. No idea what their plans are and if there is
interest from this side to have support in the linux kernel for it.
> I'll send a patch for the RX/TX race today. Then the path should be
> clear for splitting the driver tomorrow. After that, Richard should
> have all the groundwork ready for merging in his USB skeleton. I
> hope he has time :)
/me hopes that as well :)
I'm pretty happy to test any patch you guys throw at me btw. I should
be able to speed some good amount of time on the sticks when they
arrive here. I would just want to avoid hacking on the firmware side
as never did avr before and just not want to start with it now. :)
Helping to ebug the kernel driver is not a problem though.
> This still won't produce a usable driver, because of the missing
> interrupt EP code in the atusb firmware, which is next on my list.
> If things go well, it all should work early next week.
That might be perfect timing. :)
More information about the discussion