Skip to main content ↑ ↓
Topic: microchip usb stack (Read 11133 times) previous topic - next topic

Re: microchip usb stack

Reply #15 –
[quote author="honken"]The goal is to implement a bootloader based on the dfu class.[/quote]Great!  I have experience implementing DFU for PIC, so I hope I'll have time to look over your shoulder and perhaps review the code.

Be sure to let us know when you have DFU working...

Re: microchip usb stack

Reply #16 –
Quote
I got a little teaser, I just got my own usb stack running on pic18f4550.

Yeah! Please be sure to keep us updated. If you get stuck, consider dumping your code somewhere so we can work with it too :)
Got a question? Please ask in the forum for the fastest answers.

Re: microchip usb stack

Reply #17 –
Quote
Quote
TI is closed anyhow so only what comes with gcc is available and that's anyhow open source so with msp430 I also don't have a problem .. looks like my pic loving days are over
Quote
TI is not completely closed when it comes to some of their processors.  The TMS320VC55xx has some open source DSP routines called dsplib, although I've never found any contributions to the code outside TI.

I worked for TI for many many years.  I have used the TMS320C6xxx and TMS320F28xxx series DSP on a lot of projects.  TI does not seem to be bothered with you hacking up their code.  Again they would like some statement saying that you modified their code.  Who doesnt.  Besides spreading the blame around is always useful.  The issue with Microchip maybe that they dont understand what you are doing and need some assurance that you are not claiming the code to be your own.
"Too many projects, so little time"

Re: microchip usb stack

Reply #18 –
[quote author="honken"]
[quote author="tayken"]
Actually there are some open source projects being developed because of this situation.
[/quote]

I got a little teaser, I just got my own usb stack running on pic18f4550.
Only enumeration right now, I need to implement a class driver as well.
I have started looking at cdc-acm (usbserial).
And the api is in fast flux so I'm not ready to share just yet.

But probably soon I'll share a first version. Intention is CC-0 as I'm doing it just to challenge myself.
The goal is to implement a bootloader based on the dfu class.
[/quote]

enumeration is the hard part from the whole usb implementation, the remaining is a matter of filling and emptying buffers ;)

Good job!

Re: microchip usb stack

Reply #19 –
rsdio, I know the difference :D it's just that this thing with policies for libraries from mchip get's me in the bad mood so I want to get away from them (not really that simple as I have invested a lot into working with mchip - different programmers/debuggers, tools, paid for some compilers, simulators .. have a fairly good stock of different pic's at home.. ) and then I look at "competition". Now when I look at competition I look at global scale, not from the libraries pov only, as for all them I need to get both software and hardware tools from scratch (apart from mchip I have 2 programmers for msp430 and usbasp for atmel and that's it) so I look both how open/free are the tools (programmers, compilers, simulators ..) and of course how open the libraries are (so I don't move and find my self in same mess after few weeks)... that is why I talk about toolchain and libraries together for other brands ..

IPenguin, I have bin looking at them (xmos) for a while but the major issue I have with them is "availability" or "price". They don't have a distributor in this country so I'd have to order every tool, every chip via very expensive "3rd party rip off companies" (not easy to order stuff in also) so I leave them alone for now, but they do have some very interesting offer.

honken, have you seen this: http://dangerousprototypes.com/forum/in ... opic=577.0

Re: microchip usb stack

Reply #20 –
Yes I've seen it, but that thread was running a bit stale and I had just had some success when I read this thread and couldn't insist to reply with some comfort for the distraught minds over the microchip libraries.

But as soon as I have a working cdc-acm class implementation I'll post it up there to get some feedback on my decisions regarding api-abstractions,
which aren't working for my plan to use the stack as a preloaded lib for use by both the boot-loader and the app (via linker script).
Right now too much is hard coded and implemented at compile time. (I have a serious c preprocessor macro love)

Re: microchip usb stack

Reply #21 –
That's ok with me, I want the simplest CDC possible, not so much a stack. I'd like to do a CDC bootloader too for ease of interfacing from scripts.

We could all help if you were willing to post your code now :) Don't be shy, we're all coders here.
Got a question? Please ask in the forum for the fastest answers.

Re: microchip usb stack

Reply #22 –
[quote author="honken"]But as soon as I have a working cdc-acm class implementation I'll post it up there to get some feedback on my decisions regarding api-abstractions, which aren't working for my plan to use the stack as a preloaded lib for use by both the boot-loader and the app (via linker script).[/quote]Sharing the USB code between bootloader and app is a great goal.  I had success doing this when I implemented DFU for the PIC18.  Not only did I save space by avoiding the Microchip bootloader (which has a redundant, outdated, but smaller copy of the USB stack), but I also created a jump table so that the app firmware could override and update the USB stack as needed.

My goal was to save space by sharing the USB code, but retain the ability to upgrade the USB code in the app.  Apart from finishing the testing, this was successful.  Unfortunately, the client could not afford the work, so it was never completed.

[quote author="ian"]That's ok with me, I want the simplest CDC possible, not so much a stack. I'd like to do a CDC bootloader too for ease of interfacing from scripts.[/quote]While it might seem tempting to just develop a monolithic firmware which specifically implements CDC only, USB has already been designed in a layered fashion.  It's really best to maintain separation of those layers in the code, because each layer is reusable that way.

If you look at Microchip's CDC source, you can see that CDC for them is a fairly simple layer on top of their USB stack.  There really is no advantage to collapsing all of these functions into one mess, because you need to reuse them in multiple ways even just to implement CDC.

In other words, I think 'honken' is on the right track.

I do agree that a CDC bootloader might be a good short cut, though.  I don't think it would hurt to start with that and then keep working on a DFU bootloader in parallel.  So I don't want to rush 'honken' before the CDC-ACM Class is working, but I would like to see the API a.s.a.p. after that, before the bootloader code is started.  Just my opinion on the steps needed :-)

Re: microchip usb stack

Reply #23 –
[quote author="rsdio"]
[quote author="honken"]But as soon as I have a working cdc-acm class implementation I'll post it up there to get some feedback on my decisions regarding api-abstractions, which aren't working for my plan to use the stack as a preloaded lib for use by both the boot-loader and the app (via linker script).[/quote]Sharing the USB code between bootloader and app is a great goal.  I had success doing this when I implemented DFU for the PIC18.  Not only did I save space by avoiding the Microchip bootloader (which has a redundant, outdated, but smaller copy of the USB stack), but I also created a jump table so that the app firmware could override and update the USB stack as needed.

My goal was to save space by sharing the USB code, but retain the ability to upgrade the USB code in the app.  Apart from finishing the testing, this was successful.  Unfortunately, the client could not afford the work, so it was never completed.

[/quote]

That jumptable is a good idea, but you need to be sure at least the minimal USB functionality/stack resides in the protected area. Which is cumbersome to update (I assumed you was talking about the bootloader)

[quote author="rsdio"]

[quote author="ian"]That's ok with me, I want the simplest CDC possible, not so much a stack. I'd like to do a CDC bootloader too for ease of interfacing from scripts.[/quote]While it might seem tempting to just develop a monolithic firmware which specifically implements CDC only, USB has already been designed in a layered fashion.  It's really best to maintain separation of those layers in the code, because each layer is reusable that way.

If you look at Microchip's CDC source, you can see that CDC for them is a fairly simple layer on top of their USB stack.  There really is no advantage to collapsing all of these functions into one mess, because you need to reuse them in multiple ways even just to implement CDC.

In other words, I think 'honken' is on the right track.
[/quote]

AFAIK CDC is just three endpoints, one to receive data, one to send, and one for flowcontrol. I agree on having a real stack.

Re: microchip usb stack

Reply #24 –
[quote author="Sjaak"]
[quote author="rsdio"]Sharing the USB code between bootloader and app is a great goal.  I had success doing this when I implemented DFU for the PIC18.  Not only did I save space by avoiding the Microchip bootloader (which has a redundant, outdated, but smaller copy of the USB stack), but I also created a jump table so that the app firmware could override and update the USB stack as needed.

My goal was to save space by sharing the USB code, but retain the ability to upgrade the USB code in the app.  Apart from finishing the testing, this was successful.  Unfortunately, the client could not afford the work, so it was never completed.[/quote]That jumptable is a good idea, but you need to be sure at least the minimal USB functionality/stack resides in the protected area. Which is cumbersome to update (I assumed you was talking about the bootloader)[/quote]Thanks for the support.  Here are some more details on my design and the considerations behind them:

* I carefully analyzed several versions of the USB stack, as well as several versions of the Microchip bootloader.  Not only did I notice that they had to fix the same bugs in both branches, but the bootloader USB stack was quite limited.  I think they implemented the minimal USB code for the bootloader and just froze it there, while the main USB stack grew over time and left the bootloader USB behind except for some late bugs fixes that were rolled in.

* It is not possible to build a full USB device from the bootloader code, so sharing that USB code with the main application firmware is not very successful.

* When I implemented a bootloader based upon a full USB stack, the protected area grew larger in size.  This seems like a loss until you realize that you can reuse the USB code.

* Based on the fact that Microchip seems content with an underfeatured USB implementation in their bootloader, I decided to specifically give up on the possibility to upgrade the USB code in the bootloader itself.  In other words, the DFU code pretty much has to be perfect (maybe not to spec, but it has to work without bricking the hardware).  Once that step is complete, the bootloader can be set in stone and the USB code will never change.  Thanks to the USB jump-table, though, the main application firmware can either reuse the entire USB code from the bootloader, patch it partially, or replace it completely.

* Although the jump table sounds elaborate, I only found a few meaningful entry points into the USB stack.  The jump table, therefore, turned out to be rather small.  To reiterate the previous item, the bootloader skips the jump table and calls direct, as a protection against bricking.  Only the main application firmware uses the jump table to reach into the bootloader and reuse the USB code there.  This saves the user from needing a library or other binary for the bootloader to link in, and the resulting main firmware image does not include the protected bootloader area of Flash memory.  In other words, the jump table is part of the bootloader in protected memory, and merely serves to shift the entry points for various functions to predictable offsets that will never change.

* The Microchip bootloader places the interrupt and reset vectors in the protected area.  That's fine for reset, since nobody counts cycles that finely during startup.  However, the interrupt vector jumps waste cycles because they always insert an addition jump with every interrupt.  When you are trying to implement high-performance firmware with super-high interrupts rates, those wasted cycles can be a make-or-break situation.  I moved the protected area to high memory to solve this, which conveniently combines the bootloader with the configuration registers on certain PIC models, and also has the nice side effect that the main application firmware always loads at address 0, meaning it can run completely without the bootloader (sort of).

* I came up with some clever techniques (inspired by BSD FFS journaling) in the DFU to prevent completely bricking the PIC.  Even in the event of a failure during upgrade, the bootloader should still be able to function for additional upgrades attempts, although the main application firmware will no longer work once erased until it is successfully upgraded.  I won't get into the details of those tricks here, in case they're valuable techniques.  In fact, consider the above to be my initial publication, in the event that any of this is copyrightable or patentable.

Quote
AFAIK CDC is just three endpoints, one to receive data, one to send, and one for flowcontrol. I agree on having a real stack.
I sometimes forget that I really hate USB because it is so crippled compared to other technologies.  But, at the same time, there are a few aspects of the USB design which were really done well.  The compartmentalization of the functionality makes it very easy to write both reusable device firmware and host class drivers.  In other words, if you follow good programming design for reusability and avoid wasting code memory space with redundant function source code, you're almost forced to write a real stack that is modular.

Re: microchip usb stack

Reply #25 –
[quote author="rsdio"]
In fact, consider the above to be my initial publication, in the event that any of this is copyrightable or patentable.
[/quote]

Just FYI: (1) You can't copyright ideas, only the expression of them; (2) It is important to apply for a patent before your idea is publicly exposed to avoid the dreaded "premature public disclosure" and loss of protection because the idea is no longer "new" (though Australia allows you a grace period of 12 months, other countries may differ).

(Disclaimer: To the best of my knowledge, the law in these fields is pretty much the same in Australia and the US, enforced to a large extent by the harmonisation of laws we downunder were subjected to as the price for the Australia-US Free Trade Agreement.)

Re: microchip usb stack

Reply #26 –
[quote author="Trev"]Just FYI: (1) You can't copyright ideas, only the expression of them; (2) It is important to apply for a patent before your idea is publicly exposed to avoid the dreaded "premature public disclosure" and loss of protection because the idea is no longer "new" (though Australia allows you a grace period of 12 months, other countries may differ).

(Disclaimer: To the best of my knowledge, the law in these fields is pretty much the same in Australia and the US, enforced to a large extent by the harmonisation of laws we downunder were subjected to as the price for the Australia-US Free Trade Agreement.)[/quote]Thanks for the comment.  I naively thought there was some benefit to "publishing" as proof of being the first.  There is no benefit in terms of securing a long patent/trademark/copyright, but there is a benefit if your publication predates all others.  But I admit that I really need to learn the distinction between non-obvious inventions and obvious combinations of existing inventions.

Any pointers for outside reading?  Feel free to PM rather than tie up this thread...

Re: microchip usb stack

Reply #28 –
[quote author="arhi"]so you want to create another non-gpl stack? that will help how?[/quote]Remember that copyleft is still a copyright.  Same with Creative Commons and GPL.  If you develop anything, and someone else copyrights it first, then you still lose.  I am not a lawyer, but my understanding is that you still have to pursue and protect a copyright just as thoroughly, even if you want it to be open.

If you've been following the press lately between RIAA and EFF, you'll hear RIAA claiming that EFF is "anti-copyright," which is not true.  EFF understands that the only way to protect open source is by strong copyright laws which honor the intent of the creator.  But EFF can explain this better than I can.