Hi, Haven't touched that code in a long while, I don't remember if the echo demo used linker scripts or if the allocation is set with pragma. If so check in usb_stack.h and confirm that it includes the right file / define section for the 4550. It could be that there's nothing for this proc
Yes I've been restructuring for some 3 years now. A failed hard drive in my repo and two children doesn't help.
Current status is that even the cdc doesn't run any more, so no progress on hid from my part. Not mentioning any ports to other pics.
As for x8, I have only been disappointed of its performance. So I stick with c30 version .30 - something. It is a gcc compiler so the preprocessor does what I am used to. The bad thing is that even the most obvious optimizations are disabled.
My wish is for anybody to write a llvm backend for 16 bit pics.
If you used the free compiler from microchip that doesn't say anything, it so hampered even the most obvious optimization is disabled. It is actually not even running redundant code removal. Especially with the xc compiler. The only compiler to use is the gcc based 3.30, and even that is an insult if you look at the emmited assembly, but infinitely better then the hi-tech based xc series.
I have also changed from xml format to text, and then I can actually draw the QR non inverted with the most common case of white silkscreen on a "dark" board.
The urlencode part is very crude and "overdoes" things, ie encodes characters not necessary to encode, but without it it will break if you try to put an ampersand (&) or a space into the info you want in the QR-code.
Ahh, while I'm not sure what FFB is my guess is that you need to go to the HID Usage Tables (HUT) and construct your HID descriptor that describes the HID device you present. That descriptor also explain how messages between host and device are laid out, how frequent they are etc. There is a small program on usb.org for generating these descriptors.
Beware though, if your intended target host is win based you will be struggling to write a HID descriptor different from the example descriptors in the standard that doesn't blue-screen your host.
The [s:]Packet ID[/s:]USTAT can be used to determine a buffer descriptor pointer. That pointer points to a structure with two configuration "words" and a pointer (BDADDR) to the actual memory used as data buffer. The config words are who (user or sie) owns the buffer and bits about data toggle synchronization, as well as the byte count of the buffer.
The datasheet for your pic microprocessor of choice explains it better.
When it comes to memory management, all buffers are currently allocated at compile time as static variables, although it's hidden behind some c preprocessor magic. But there is almost nothing preventing you to dynamically allocate memory and update the BDADDR to point to it. The caveat is that at least the p18f require the buffer to be allocated within a special physical memory segment.
[EDIT] Sorry, that is the USTAT variable not the usb token (Packet ID) that gives witch buffer descriptor that is used.
Also, as hardware gets better/faster programmers have less and less incentive to write efficient programs. Instead of finding the right algorithm and implementation for a task they run with naive solutions since those run almost as fast as before on twice as fast hardware. But the users with the old generation hardware will suffer when the update comes.
Just found out that the male pins don't connect very well to the pickit3. Just got the pickit3 the other day and couldn't get it to work, thought it was a MAC/WIN issue. But it was just bad connection...
I have made previous cables with the same crimps that worked fine on the pickit2.