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.
What runtime constraints do you believe would be an impediment?
What would be the benefit of re-coding in 'C'?
Is there some hard timing constraint that has to be met with regard to the code you have to generate? If so, that's one of C's only true stumbling blocks for that sort of thing. Generally, however, if you take the time to look at the sort of code the compiler generates for a given C construct in given circumstances, you can have a pretty good idea about the underlying assembly it will create for your application.
Today, when there is a plethors of ISP chips, why even consider putting ANY effort into a "bootloader" which, anyhow, is a misapplication of the '51 Erik
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. :)
What runtime constraints do you believe would be an impediment? Just the runtime setup... I'd need another startup file then I need to make sure all my code is in a location in code space that does not get ERASED. Last I tried using C, I recall having an issue with the tools finding ?CSTART label when I did SRC output and assembly. Everything is polled while the device is runing ISP code. And there are no interrupts as these are vectors are in the place I'm programming for normal operating code. What would be the benefit of re-coding in 'C'? I'd find it easier to come back to at a later date and make changes. Especially if I start doing other 8051 work. Is there some hard timing constraint that has to be met with regard to the code you have to generate? There are hard timing constraints but these should not be an impediment. "why even consider putting ANY effort into a "bootloader" ?" Okay, I'm refering more to ISP/IAP. I still use bootloaders (although one could also refer to them sort of as overlays) on other processors so that ram can be loaded with different firmware/data/cpld & fpga configurations depending on the modality needed. some rationale -So the end product is field upgradeable from a common user interface this also reduces depenencies I have no control over. Also, the system contains a total of 11 different processors (only 5 of which are '51 microcontrollers). -Communication bus used is not supported by the ISP for the device selected. -End user might not have access to a computer able of running the manufacture's ISP software. -There is limited access(to varying degrees) to the device which limit how I can use manufacturers' ISP/bootloader. -There are a limited number of pins I can access the device with through a particular connector. -I need to maintain a consistent protocol to the devices in the system. The manufacturers' ISP is not consistent with the protocol I use. -The time spent developing has saved development time and will save time if firmware changes are required. -There is extra hardware to program the device using manufactures' ISP. -The most important mark is my boss wants it. -And cause I like monkeying around.
Jay Watch your language :) I Think you are talking about IAP, not a bootloader (for the difference, see previous post) Erik
Tim, I think you, like Jay call IAP a "bootloader". That particular name (of PDP-8 origin, I believe) refer to getting a different program loaded into a computer so it will run a different task after the program is loaded. IAP, in contrast refer to loading something that will make the same task be performed better. Thus using a "bootloader" is for those that play with the '51, ISP/IAP is for updating code that actually serves a purpose. So, can we agree: a "bootloader" load into RAM, IAP load into flash. If we can, this discussion will be so much easier. 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. :)
Just the runtime setup... I'd need another startup file then I need to make sure all my code is in a location in code space that does not get ERASED. Last I tried using C, I recall having an issue with the tools finding ?CSTART label when I did SRC output and assembly. It's certainly easy enough to send a CODE() directive to Keil's linker to make it place a certain segment at a given location in code space. Just check the manual. The warning about C_START probably comes in if you monkey around with the startup sequence in assembly and something in Keil's STARTUP.A51 or INIT.A51 gets broken. As just a general note of encouragement, my last '51 project design implemented a bootloader (or IAP, whatever) in C that works quite well, so it's certainly doable.
"... ("bootloader" usually (always?) refer to program in RAM)" Nope, flash too. Right or wrong, it's a convention adopted by the industry.