BAP – A time paradox?
A minute ago, I came across a new LUFA project (product?), called BAP. It’s an incredibly tiny AT90USB162 based board, designed to be a micro-sized programmer for the USB AVRs.
Readers here will getting a sense of deja-vu at this point, which was my first reaction. Could someone have churned out a product based on only week-old firmware already? The answer is unfortunately a dull no, as the product was first announced back in June. Details on the programmer are frustratingly scarce (such as what firmware it uses) but one thing’s for certain; this would make a great candidate for my just-completed AVRStudio-compatible AVRISP project. If nothing else, the site provides the schematic which should give homebrewers the right idea for a level converter between the chip and the target board.
Work on the next release of LUFA is progressing, and will be coming to a close soon. Unfortunately due to realf-life time constraints I’ve had to move back the implementation of Host mode hub support, but this next release will bring new Host mode class drivers for the main few standard classes, plus a bunch of bug fixes and new features. One of these new features is only a day old, added in response to this discussion thread, and centres on the HID report parser. Basically, someone had an issue where the HID report parser was using up all their available RAM, storing the parsed and processed attributes to all the items in the attached device’s HID report descriptor. That made me realise how big of a waste that is, so I’ve changed the parser to now use a user-callback to determine which items are to be stored, and which ones to discard. That will allow for the host application to save a lot of RAM typically, as it can then tell the parser which items it will be interested in later on, and which ones the parser can throw away.
One issue I’ve identified is in the HID host class driver (and the existing LowLevel HID parser demos as well), and I’m going to need a week or so to nut it out. There exists the problem of the host not knowing how many bytes of data are to be read out from the host for each report. The official HID standard instructs the system to calculate this per-report by adding up the size of the elements in each report, which is what I’ll probably end up doing, but it means added complexity when the darn standard could have just added a length parameter and wasted the small amount of bandwidth required to transfer the additional two bytes. It’s a headache which I’ve wanted to avoid (and have side-stepped so far by assuming that all reports are less than the IN endpoint bank in size, but that doesn’t always hold true). Fixing that and the remainder of the Still Image Host class driver is going to really take up all my free time for the next little while if I want to make the scheduled release by late next week.
