HP Forum Archive 20

[ Return to Index | Top of Index ]

[WP34s] Emulator: Where does it get its rom? Message #1 Posted by Lode on 24 Aug 2011, 5:28 p.m. Hi, Does anyone know where the WP34s emulator loads the ROM from? There's no file that looks like a ROM in its directory, and after renaming calc.bin in the 'real' directory, the emulator still works so it's not loading that file. Regards, -Lode

Re: [WP34s] Emulator: Where does it get its rom? Message #2 Posted by Paul Dale on 24 Aug 2011, 5:31 p.m., in response to message #1 by Lode It doesn't load a ROM. It is a native compile of the firmware. - Pauli

Re: [WP34s] Emulator: Where does it get its rom? Message #3 Posted by Lode on 24 Aug 2011, 5:56 p.m., in response to message #2 by Paul Dale Ok, I see, thanks... The emulator program works really well in wine in linux. But it seems like all these developer tools and running the emulator with a different rom really are designed purely for visual studio and nothing else, no other C++ compiler, let alone another OS, can do anything useful at all with this :( Hard to create and debug a custom ROM without emulator of course, I mean, the calculator can only be flashed a few 1000 times... Edited: 24 Aug 2011, 5:58 p.m.

Re: [WP34s] Emulator: Where does it get its rom? Message #4 Posted by Paul Dale on 24 Aug 2011, 6:13 p.m., in response to message #3 by Lode Our builds are done on Windows. It is possible to compile the firmware on other operating systems using a gcc-arm tool chain but nobody I'm aware of has tried to flash such an image. There is a text console emulator that works on Linux and MacOS which is extremely useful for development and debugging -- better access to view much of the internal state. I use this for all of my development and debugging efforts. - Pauli

Re: [WP34s] Emulator: Where does it get its rom? Message #5 Posted by Marcus von Cube, Germany on 25 Aug 2011, 2:25 a.m., in response to message #4 by Paul Dale As Pauli stated, there is no attempt to emulate the hardware on the PC. We've just more than one environment to compile the sources for: The hardware, Windows and Unix (Mac, Linux). In order to debug the logic it's almost always enough to do this with the tools on the PC. I'm using Visual Studio 10 but the free Express edition will do in most cases. It's a pure Windows thing because the emulator is built upon the work of HP. The original sources are part of the 20b/30b SDK put together by Cyrille. The GUI part was written with the Microsoft Foundation Classes and is Windows only. I did a split between the GUI and the calculator engine by putting the GUI in a DLL. So it's perfectly possible to create a new GUI implementation that is no longer dependent on HP's Windows code. For the hardware port I added a JTAG connector to my development 20b. It's connected to my development system via an Olimex ARM-USB probe which allows source level debugging from within the Eclipse debugger. It's not as comfortable as the Windows debugger but for pure hardware stuff like interrupt handling it's the only choice.

Flash endurance Message #6 Posted by Eric Smith on 25 Aug 2011, 4:58 a.m., in response to message #3 by Lode Quote: the calculator can only be flashed a few 1000 times... The endurance spec is 10,000 times, with 10 year retention. This means that at 10,000 writes, the flash will still give valid data at all combinations of the chip's specifications, such as low voltage at low temperature, low voltage at high temperature, high voltage at low temperature, and at all process corners. And still meet the 10 year data retention specification. It doesn't mean that it will fail on the 10,001st write. In other words, there's a good chance that your calculator can be flashed a lot more than 10,000 times, because you probably only operate it at room temperature, and not at any temperature extremes (or high voltage extreme), and because Atmel is probably fairly conservative in specifying the endurance at 10,000, but if it does happen to fail on the 10,001st write, it's your problem and not Atmel's. If you were using a calculator based on this part for development (rather than a simulator), it would take quite a while to try 10,000 code images. The calculator isn't that expensive, so even if it does fail on the 10,001st write, you can buy a new one, and not feel like you didn't get your money's worth for the first one. I'm doing some firmware development now on a different vendor's ARM chip. I don't have a simulator. I might work 12 hours in a day on it, but I don't think I've ever reflashed it more than about 50 times in a day, and usually not nearly that many.

Re: Flash endurance Message #7 Posted by Paul Dale on 25 Aug 2011, 5:45 a.m., in response to message #6 by Eric Smith In my previous job I got tasked with stress testing some flash to destruction. I don't remember if it was rated to 10k or 100k erase/write cycles. Needless to say, we gave up testing before the first failure. This was well beyond the specified number of cycles. And as Eric wrote, a replacement calculator isn't expensive and 10k write cycles is a very long time. - Pauli

Re: Flash endurance Message #8 Posted by Marcus von Cube, Germany on 25 Aug 2011, 10:37 a.m., in response to message #7 by Paul Dale The limit gets in the way if you start storing more or less volatile data in the flash memory. We could easily create commands to store registers in flash if we wanted to. But this would probably stress the flash beyond specification. We have a (distant) plan to use flash for regular program storage and we need to implement some smart caching in order to avoid excessive writes to flash. (Don't do it for every program step input by the user!) Register storage will remain in SRAM but some file I/O (41C like) to flash seems possible.

Re: Flash endurance Message #9 Posted by Garth Wilson on 25 Aug 2011, 3:40 p.m., in response to message #8 by Marcus von Cube, Germany Although I'm not familiar with them, I know there have been wear-leveling algorithms developed for this reason. The idea is that if you keep writing small portions of the flash, rather than always writing them to the same pages and wearing those out while the rest of the flash has lots of life left in it, you move them around so the wear load is shared.

Re: Flash endurance Message #10 Posted by Marcus von Cube, Germany on 25 Aug 2011, 4:14 p.m., in response to message #9 by Garth Wilson This is the main task of the flash controllers built into flash memory cards. Special flash file systems are designed for embedded devices which have do do this in software.

Re: Flash endurance Message #11 Posted by Eric Smith on 25 Aug 2011, 9:55 p.m., in response to message #8 by Marcus von Cube, Germany Right. I interpreted the original point I was responding to as being about flashing firmware during development, which is a much different usage model than data storage. Using 10K-rated flash for user data storage requires a lot more care.

[ Return to Index | Top of Index ]

Go back to the main exhibit hall