(03-12-2018 06:43 PM)grsbanks Wrote: [ -> ] (03-12-2018 04:37 PM)eulerfan Wrote: [ -> ]I just had a thought. I suppose the operating system (Free42 + device drivers) is also stored on that flash drive.
There are two flash ROMs in the DM42.
There is one of 1MB within the STM32L476 main CPU and there is an external 8MB QSPI chip.
The O/S and all the executable code is in the STM32L476. The QSPI chip is divided into a zone of 2MB and the remainder of 6MB. The 2MB portion contains tables used by the Intel Decimal Floating Point library and other bits of static data. The 6MB chunk is the flash drive that you see on your computer when you plug the DM42 into your USB socket and activate "FAT Disk mode".
Good to know, thanks. I searched for the STM32L476 and found its specifications here:
http://www.st.com/en/microcontrollers/stm32l476rg.html
That is one loaded chip! It seems the DM42 doesn't even need all the hardware features. I would be tempted to use things like the analog/digital converter if the battery were bigger.
Quote: (03-12-2018 04:37 PM)eulerfan Wrote: [ -> ]Is there a way to do a checksum or CRC on the OS to verify that it's intact?
Not on the O/S in the STM32L476, but a checksum of the QSPI's 2MB zone is performed at every machine reset to ensure that you have the right version of the QSPI contents to go with your version of the Intel library etc. If there is a mismatch then you are prompted to flash the correct QSPI version.
Great, it seems the designers anticipated my concerns. That's reassuring.
Quote: (03-12-2018 04:37 PM)eulerfan Wrote: [ -> ]Does the DM42 have a reset button that forces a reboot?
Look on the back of the calculator 
Makes me wonder if it's possible to download native ARM code into the DM42. I bet there's lots of room on the STM's 1 MB flash.
(03-13-2018 03:46 AM)eulerfan Wrote: [ -> ] Makes me wonder if it's possible to download native ARM code into the DM42.
It certainly is possible, all you need is a suitable compiler and an ST-LINK/V2 which can be had inexpensively if you shop around.
(03-13-2018 03:46 AM)eulerfan Wrote: [ -> ]That is one loaded chip! It seems the DM42 doesn't even need all the hardware features. I would be tempted to use things like the analog/digital converter if the battery were bigger.
Actually, the DM42 uses that already to measure battery voltage. That is actually accessible to the user in one of the virtual variables: RCL "Vbat"
(03-13-2018 03:46 AM)eulerfan Wrote: [ -> ]Makes me wonder if it's possible to download native ARM code into the DM42. I bet there's lots of room on the STM's 1 MB flash.
That 1MB flash is already about 85% full...
(03-13-2018 03:46 AM)eulerfan Wrote: [ -> ]Good to know, thanks. I searched for the STM32L476 and found its specifications here:
http://www.st.com/en/microcontrollers/stm32l476rg.html
That is one loaded chip! It seems the DM42 doesn't even need all the hardware features. I would be tempted to use things like the analog/digital converter if the battery were bigger.
It even has a true random number generator. Anybody knows if it is used in the RAN# function?
Regards.
As far as I know, it uses the RNG in Free42.
(03-13-2018 03:46 AM)eulerfan Wrote: [ -> ]Good to know, thanks. I searched for the STM32L476 and found its specifications here:
http://www.st.com/en/microcontrollers/stm32l476rg.html
How much documentation for a chip. I never looked around chips (well, only briefly) but having that much of a documentation for a product should be amazing (if the contents are useful).
Plus they even benchmark the thing themselves instead of leaving you in the dark. I did not know the coremark.
https://www.eembc.org/coremark//index.php . One has even quite some references in the benchmark, as there are well known cpu, as the pentium 100.
The pentium 100 for example has 213 coremarks vs the declared ~270 of the STM chip.
(03-13-2018 06:49 AM)grsbanks Wrote: [ -> ]As far as I know, it uses the RNG in Free42.
Yes. And since the Free42 RNG uses the same algorithm as the original HP-42S RNG, they probably won't want to change that. (Although exposing the hardware RNG could be made a user-selectable option.)
(03-13-2018 06:47 AM)emece67 Wrote: [ -> ]It even has a true random number generator. Anybody knows if it is used in the RAN# function?
I'm not sure how "true" the on-chip RNG is but I would be more likely to trust a well-tested PRNG algorithm such as Mersenne Twister or Xorshift.
I'd trust the built in RNG more but I'd still over sample and run the output through one of the built in cryptographic digests. The output would be very fast and likely completely random.
Pauli
(03-13-2018 06:49 AM)grsbanks Wrote: [ -> ]As far as I know, it uses the RNG in Free42.
Although presumably it would only use the hardware true RNG to generate the initial seed the software PRNG (when the user specifies 0 as the initial seed). I wonder if it waits for two values from the RNG since it takes a finite time to produce a 32-bit true random value, and the software PRNG seed is more like 46.5 bits (14 decimal digits)?
(03-14-2018 05:35 PM)ijabbott Wrote: [ -> ] (03-13-2018 06:49 AM)grsbanks Wrote: [ -> ]As far as I know, it uses the RNG in Free42.
Although presumably it would only use the hardware true RNG to generate the initial seed the software PRNG (when the user specifies 0 as the initial seed). I wonder if it waits for two values from the RNG since it takes a finite time to produce a 32-bit true random value, and the software PRNG seed is more like 46.5 bits (14 decimal digits)?
On 0 SEED, the DM42 seeds the RNG using the real-time clock. The hardware RNG is not used.
(03-13-2018 06:33 AM)grsbanks Wrote: [ -> ] (03-13-2018 03:46 AM)eulerfan Wrote: [ -> ]That is one loaded chip! It seems the DM42 doesn't even need all the hardware features. I would be tempted to use things like the analog/digital converter if the battery were bigger.
Actually, the DM42 uses that already to measure battery voltage. That is actually accessible to the user in one of the virtual variables: RCL "Vbat"
Good enough. I wasn't planning to use the A/D converter anyway, as keeping the calculator on would drain the battery.
Quote: (03-13-2018 03:46 AM)eulerfan Wrote: [ -> ]Makes me wonder if it's possible to download native ARM code into the DM42. I bet there's lots of room on the STM's 1 MB flash.
That 1MB flash is already about 85% full...
Darn. That idea goes out the window. I was hoping that function plotting would go faster in native code. (Yes, I saw the Youtube video of a 3D plot.... the speed wasn't great.)
(03-13-2018 04:06 AM)Craig Bladow Wrote: [ -> ] (03-13-2018 03:46 AM)eulerfan Wrote: [ -> ] Makes me wonder if it's possible to download native ARM code into the DM42.
It certainly is possible, all you need is a suitable compiler and an ST-LINK/V2 which can be had inexpensively if you shop around.
Hmmm... that's a thought. Thanks.
(03-15-2018 12:09 AM)eulerfan Wrote: [ -> ]I was hoping that function plotting would go faster in native code. (Yes, I saw the Youtube video of a 3D plot.... the speed wasn't great.)
You probably wouldn't get much of a speed-up anyway. The overhead from executing 42S programs is quite small, particularly when compared to CPU-intensive floating-point calculations.
The most effective ways to speed up that demo are: (1) plug in a USB power source to increase the CPU speed from 25 to 80 MHz, and (2) compile native code with single-precision binary floating point, which the CPU supports in hardware.
Of course (2) also requires extensions to the Free42 part of the firmware, to add support for loading and executing native code objects. Or some even more drastic change, like ditching the DM42 firmware altogether and running a minimal Linux instead.
(03-15-2018 12:30 PM)Thomas Okken Wrote: [ -> ] (03-15-2018 12:09 AM)eulerfan Wrote: [ -> ]I was hoping that function plotting would go faster in native code. (Yes, I saw the Youtube video of a 3D plot.... the speed wasn't great.)
You probably wouldn't get much of a speed-up anyway. The overhead from executing 42S programs is quite small, particularly when compared to CPU-intensive floating-point calculations.
Perhaps the plotting function could take an algebraic formula (like "x^2 + 5") and use hardware floating-point to evaluate it. That should be much faster than repeatedly executing a 42s program using decimal arithmetic.