|
|
|
Re:USB Bootloader
|
|
Date: 2006/07/21 17:11
|
By: Burzredion
|
Status: Visitor
|
|
|
|
|
|
|
Can I use this bootloader with PIC18F2550??
thanks.
Bytes.
|
|
|
|
|
Re:USB Bootloader
|
|
Date: 2006/07/21 17:43
|
By: Mat
|
Status: Admin
|
|
|
Karma: 7  
|
|
| Posts: 211 |  | |
|
No reason why not, I havnt tested it, but you should just be able to change the linker files and change the target device and go.
Mat
|
|
|
|
|
|
Re:USB Bootloader
|
|
Date: 2006/08/23 02:19
|
By: evandude
|
Status: Visitor
|
|
|
|
|
|
|
since you're interested in making agreements for commercial use for your bootloader DLL, I assume you probably don't want to be giving away your secrets, but I feel compelled to at least ask: any chance you'll ever write up a tutorial about what makes the bootloader tick?
It kill me that microchip gives out the PDFSUSB.exe demo program that bootloads, but no source code so I can see what it takes and try to understand how to implement it in C#... I find the concept of bootloading pretty fascinating, and I'm sad to see how little information there is on the web on how it's actually implemented on the USB PICs.
Anyway, I also wanted to say thanks for your USB articles; they've gotten me off to a good start with USB. Your bootloader DLL has been a great help, and I hope that someday I can get familiar enough with everything to try writing my own.
|
|
|
|
|
Re:USB Bootloader
|
|
Date: 2006/08/23 10:12
|
By: Mat
|
Status: Admin
|
|
|
Karma: 7  
|
|
| Posts: 211 |  | |
|
I may write one eventually, but not for the time being. The problem is there is a fair amount of code in the DLL, it has to be able to load and interpret hex files as well, which in its self can be fairly tricky and would take a long time to explain.
There is practically no information online, I worked it all out by reverse engineering the PIC bootloader code, that took a while 
Mat
|
|
|
|
|
|
Re:USB Bootloader
|
|
Date: 2006/08/31 01:56
|
By: evandude
|
Status: Visitor
|
|
|
|
|
|
|
Following your lead, I've spent quite a few hours this past week doing the reverse-engineering thing, and as of today I have a working bootloader interface that can erase, read, write, and verify the PIC, and load and save HEX files.
Thanks for the inspiration!
|
|
|
|
|
|
Re:USB Bootloader
|
|
Date: 2006/10/20 13:09
|
By: fatih
|
Status: User
|
|
|
Karma: 0  
|
|
| Posts: 2 |   | |
|
thanks for the great job which format of hex files does it take? Because microchip's demo tool takes intel hex 32, and the compiler I'm working with produces intel hex 8.
|
|
|
|
|
Re:USB Bootloader
|
|
Date: 2006/10/20 13:24
|
By: Mat
|
Status: Admin
|
|
|
Karma: 7  
|
|
| Posts: 211 |  | |
|
It takes intel hex 32 files, as it was designed as a replacement for the microchip tool.
Sorry if that isnt much use to you,
Mat
|
|
|
|
|
|
Re:USB Bootloader
|
|
Date: 2006/10/20 15:30
|
By: fatih
|
Status: User
|
|
|
Karma: 0  
|
|
| Posts: 2 |   | |
|
well, it works with intel hex 8M, as well. you designed it as a replacement, but I think that it works better But there is one thing... I don't know if it's a bug, but when I upload a hex file it succees first time, but at second time when I upload a (same o different) hex file, it says "programming failed". And when I restart the program and upload the same file, it works.
|
|
|
|
|
Re:USB Bootloader
|
|
Date: 2006/10/20 15:44
|
By: Mat
|
Status: Admin
|
|
|
Karma: 7  
|
|
| Posts: 211 |  | |
|
Thanks,
That sounds like a bug to me, I've probably forgotten to clear one of the buffers or something. Not got time to look into it now though,
Mat
|
|
|
|
|
|
Re:USB Bootloader
|
|
Date: 2006/11/15 21:09
|
By: NAB
|
Status: Visitor
|
|
|
|
|
|
|
Thanks for your articles/projects, they are very educational. We paid for firmware development on the 18f4550 and intended to add USB functionality at a later date. I took over the firmware customization on a basic level and have tweaked it to suit our needs. One thing the guy told me was that the program couldn't get too big or it would occupy a specific portion of RAM that had to be reserved for USB functionality. Is this true?
If so, how do I find out what RAM I am using now or how do I manipulate what RAM our firmware uses. Because when I try using your bootloader, I assume that the RAM our firmware currently uses will be shifted over to allow the bootloader to reside in the specific memory it has to occupy.
|
|
|
|
|
Re:USB Bootloader
|
|
Date: 2006/11/15 21:26
|
By: Mat
|
Status: Admin
|
|
|
Karma: 7  
|
|
| Posts: 211 |  | |
|
Hi NAB, Firstly welcome to the site, and i'm glad you've found the articles helpful!!
You guy is correct the USB requires a proportion of the RAM to operate and without this life gets very difficult if not impossible. So you have to keep an eye on the RAM usage, the amount you will need will be affected by how well the USB functionality is written, and what type of data you are transporting via the USB.
The easiest way to find out how much ram is being using is by using the memory gauge in MPLAB (its under the view menu), least this is where I remember it being off the top of my head.
One thing I should probably warn you about though is that adding USB functionality later could prove very difficult. USB cannot be treated like RS232 and added in where required, the very nature of USB means that it needs constant monitoring and therefore I would recommend organizing the firmware to cope with these additions as soon as possible, otherwise you will create larger issues later on.
I have just setup an embedded consulting company, Wakari Limited. If you need any software or circuitry developing for embedded systems, especially for USB coding, then do not hesitate to contact me and I will happily provide you with a quote.
Hope that helps,
Mat
|
|
|
|