We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
I want to write 2 C51 programs, and they don't not run simulanesouly. One of the hex will reside at CODE area, the other will locate at XDATA area. Because the two hex file have some common functions. I want to save XDATA area space, how could I link some functions in XDATA HEX program to the CODE HEX program ? Is it possible or not? Thank for your reviewing .....
"run the program in XDATA area." No that is not possible! One more time: The 8051 architecture cannot execute code from XDATA! You will need some sort of "clever trick" in your hardware (whether integral to the particular microcontroller, or in your external memory system) that allows that area of physical memory to be "switched" between XDATA and CODE (or, maybe, to be simulataneously present in both XDATA and CODE spaces). "If we put all the program in ROM, that would be some risk when production." Are you trying to make your product updatable in the field, or are you just talking about production programming? Either way, have you considered an in-system programmable Flash part? As Stefan says, there are plenty of derivates with built-in bootloaders.
The 8051 architecture cannot execute code from XDATA! Andrew is right in this point certainly. BUT: Antony probably meant "external RAM" instead of "XDATA"? Therefore, it is possible to load (or "program") code into external RAM (as XDATA with MOVX @DPTR,A) and execute it as a program memory after bankswitching from EPROM/Flash to external RAM. It is the task of glue-logic (e.g. GAL) to realize this. Is it thus, Anthony? Martin
"Therefore, it is possible to load (or 'program') code into external RAM (as XDATA with MOVX @DPTR,A) and execute it as a program memory after bankswitching from EPROM/Flash to external RAM." Yes, that's exactly what I said: "You will need some sort of 'clever trick' in your hardware (whether integral to the particular microcontroller, or in your external memory system) that allows that area of physical memory to be 'switched' between XDATA and CODE (or, maybe, to be simulataneously present in both XDATA and CODE spaces)."
"You will need some sort of 'clever trick' in your hardware (whether integral to the particular microcontroller, or in your external memory system) that allows that area of physical memory to be 'switched' between XDATA and CODE (or, maybe, to be simulataneously present in both XDATA and CODE spaces)." Exactly, this is what I want to do. I hope the user can download new firmware from Internet, and update the system easily. (The bootload would built in such function). Or the retailer would have big effors on firmware update. Now I have a solution, In my second Hex Program, I would also compiler the first Hex Program(Bootloader). The Second hex program start it's address at 0x4000, and than generate a hex file. I seperate the second Hex program into 2 parts. One is bootloader, and the other is firmware by address 0x4000. Writing the firmware part to NOR flash. In bootcode, it would load the firmware from NOR to a specail XDATA range, and change the special XDATA range to CODE area. In firmware, because I compiler it with Bootloader, so it would know where is the common functions it want to call. This is just my draft thinking. I havn't implement it yet. Maybe it work or not? I am not quiet sure. Thanks for everyone's help .....
Stefan said: "Are you aware that there are a number of 8051 derivatives available with built-in bootloaders that allow you to easily change the firmware without removing the microcontroller from the circuit?" and you just ignore the ready made superb, tested and free solution and barge on with your "how do I make" reply please Erik
"I hope the user can download new firmware from Internet, and update the system easily. (The bootload would built in such function)." That means your bootloader needs to include a TCP/IP stack. You also need to think about how you can be 101% absolutely and totally sure that the download is correct & error-free before you comit to blowing away the previous firmware... And what happens if the power fails part-way through loading the new firmware...? Online firmware updates are wonderful for the user, but a nightmare for the programmer...!
Online firmware updates are wonderful for the user, but a nightmare for the programmer...! which usually end up with it being a nightmare for the user. I refuse to update PC software where the software is "updated". If I can not install the new version and keep the old I do not update. In the embedded world the problem is that, invariably, some user will use the program in a way that discloses a previously unknown problem with the new release. Such a costomer will then install the previous rel and go on. How are you going to do that with "automatic updates"? Erik I am planning a system for updating a network of '51s and the means will be an USB disk. That way the user can start over (since this has been forseen) if the update fails. If there is a problem with the new SW, the customer can just reinstall the previous.
Online firmware updates are wonderful for the user, but a nightmare for the programmer...! which usually end up beig a nightmare for the user Erik I am posting this piecemeal since I saw in another thread that when I reposted a post that "did not take" it suddenly appeared.