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 .....
"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.