I currently have 2 in system programming (also acting as bootloaders) designs done up in 8051 assembly but would like to recode them in C. I'm unsure how one goes about doing this based upon the runtime constraints placed on the user when using C.
Erik, I think that there is still a tremendous need for "bootloaders" even with the plethora of ISP chips out there. The problem is the distinction between ISP (in SYSTEM programmable) and IAP (in APPLICATION programmable) implementations. For instance, ISP may just mean that a JTAG programmer could be connected and the chip could be programmed while soldered to the board, etc. This doesn't help the customer any if a software bug is found after the product's released. It's generally not good form to ship them a device programmer and have them handle the upgrade. Instead, if there's a very simple (and extensively tested) bootloader available along with the application, the user could be sent say, a simple PC utility that works in congress with the bootloader to upgrade the software without any unusual hardware. To say that this is a misapplication of the 8051 is to do the chip (and especially the IAP / ISP derivatives of it) a disservice as this only help the end user of the products designed with them.
"I think that there is still a tremendous need for "bootloaders" even with the plethora of ISP chips out there. ... To say that this is a misapplication of the 8051 is to do the chip (and especially the IAP / ISP derivatives of it) a disservice as this only help the end user of the products designed with them." That's for sure! Example: An ankle-worn RF transceiver that is hermetically sealed for water resistance (showering, swimming, etc.). Programming by cabled connection kind of compromises that seal whereas using the RF channel does not.
To say that this is a misapplication of the 8051 is to do the chip (and especially the IAP / ISP derivatives of it) a disservice as this only help the end user of the products designed with them. I am, in this respect referring to the "bootloader in ROM, application in RAM" syndrome, not IAP of flash. For instance, ISP may just mean that a JTAG programmer could be connected and the chip could be programmed while soldered to the board, etc. This doesn't help the customer any if a software bug is found after the product's released. Agreed, but there is a plethora of UART based ISP chips out there and I use FlashMagic canned with commandline execution in a .bat as "the simple PC utility that works in congress with the bootloader". Of course, if you are talking about JTAG based, e.g. SILabs, the development of IAP, NOT a "bootloader" ("bootloader" usually (always?) refer to program in RAM), will be almost mandatory if you want a lot of customers to update on their own. Erik, who loves ISP and IAP, but not bootloaders that load code in RAM.
Erik, Sure... those chips that already have a canned bootloader somewhere masked into the chip are pretty nice, and using FlashMagic is certainly alot easier than most alternatives, but there are still some nice designs that don't meet those criteria. For instance, the newish STMicro uPSD series of chips have an 8032 core along with DUAL flash banks. This means that I can ship a unit with a bootloader programmed into ONE flash bank and use it (via whatever channel) to update the application that's in the other flash bank without ever needing to load code to RAM. I could even (if I were very enterprising) do a two-stage bootstrap that burns a NEW bootloader to the application area, jumps to that, and then reprograms the actual bootloader area to allow for updates of any code on the chip. It's really pretty slick and helps to alleviate worries about adding future functionality to devices.
Dan, Good example... also nice is not having to enter the house of a mobster to attach wires to update the code on his house-arrest device. :)
Jay Watch your language :) I Think you are talking about IAP, not a bootloader (for the difference, see previous post) Erik
Watch your language :) I'm usually careful about my language. I use bootloader in the PC sense--namely, the program responsible for launching the application (or operating system). In the case of IAP, this program would also have to be the one to allow update of the application before its launch. I guess the semantics of it aren't important now that we all know what we're talking about. :)
"... ("bootloader" usually (always?) refer to program in RAM)" Nope, flash too. Right or wrong, it's a convention adopted by the industry.
"... house-arrest device" Good (and correct) guess!