Writing to Flash in SuperPRO, PROplus

[AMDlloydsp]

Bruce,
I have a quandry.

BASIC on a SuperPro:

I need to store a number of singles in flash so that my machine can resume where it left off after a power-failure.

The docs state that arrays may contain integers or singles. I have created arrays of singles, stored values to them, then read them back; and it confirms that the values stored are singles.

To test the flash write/read component, I experimented with creating (first) an array of integers, writing that to flash, then reading it back. That works fine.

When I dimension the array as single, I get a compiler error when it hits the write statement, saying that it expected an array or string as an argument.

Simply leaving off the 'as single' on the dims eliminates the error, but then stores and retrieves integers.

Obviously, I'm missing something here. (failing code below)

Thanks,
Lloyd
-----------------------------

#include "./lpc17xx.bas"

dim write_values(256) as single
dim read_values(256) as single

dim a_value as single
a_value=12345

for i=1 to 256
write_values(i)=a_value ' store all the values in the write array
next i
for i=1 to 256
print write_values(i) ' read them back to confirm they are singles, properly (this works)
next i

status=write(&H28000,write_values,256)
print status
fread (&H28000,read_values,256)

[basicchip]

We ran into this ourselves with the controller project we are doing and logging floating point data.

It is a simple compiler fix, that now allows you to pass a array of singles to FREAD/WRITE. We just haven't released that version yet, but if you want to be a guinea pig along with us I'll attach it below.

I believe the current release compiler would allow you to make the call using ADDRESSOF

WRITE (FlashAddr, ADDRESSOF SingleArray, size)

ARMbasic.exe

trial compiler version

(133.78 KiB) Downloaded 1505 times

[basicchip]

While it is also discussed elsewhere in the forum. BASIC does automatic type conversion such that

Integer = Single

will convert the single value to an integer before saving it. But you don't always want to do that. VB doesn't seem to have a method to get the actual hex value of a single variable. But as we have pointers and ADDRESSOF you can get to that by

Integer = *(ADDRESSOF Single)

Which will copy the hex value that represents Single to the Integer. This is useful if you want to see the exponent for instance, which is used in some of the floating point library.

[AMDlloydsp]

Thank you, Bruce!

Doing just a plain write with a singles array crashes my SuperPro when the write address is as in the above example

However, doing a write with ADDRESSOF in the parms succeeds, and an ordinary FREAD into a singles array retrieves the values!

(same rev number on the compiler, as what I had, I notice! I saved the old version, just in case.<G>)

Lloyd

[AMDlloydsp]

Bruce,
One thing I don't understand is that when I wish to stop the program, the new compiler requires that I press the button on the SuperPro and press stop -- and as it turns out, one must press the Reset button only a short tap, and the stop button quickly, or it requires to be done again.

My boards are built into sealed enclosures, so it cannot work in the field. Is this just a quirk in the trial version, or a 'new feature'?

Lloyd

[basicchip]

Did you somehow set the option,control, manual mode?

Change it back to normal.

[AMDlloydsp]

Thanks again.

No, I've never intentionally changed the reset control mode...except once, early on, when I was learning the tools. I entirely forgot there were different reset behaviors available.

Rarely (maybe twice in a 10 hour work day), BASICtools crashes, and must be re-started... sometimes it won't kill the process until the USB connector is disconnected. This began happening right after one of those crashes last evening while experimenting with writing arrays to flash, and I thought maybe the new compiler had written something to the board unique to its operation.

I guess it's possible to accidentally select that, but it takes three discreet mouse moves and two different clicks to set. I rarely even have to set the COM port, so I have few and infrequent reasons to use the options menu.

So, Yep and Nope... setting the control back to Normal fixed it... but, "...'twern't me, McGee!" <G>

Lloyd

[AMDlloydsp]

Never mind... I'll get back on this... thinking I have a declarations problem.

Thanks,
Lloyd

[basicchip]

I took a look at the help file, and the firmware code, which don't quite agree on what went wrong

The IAP return value is not returned to BASIC, but will be in some future firmware version.

in the current firmware (< 8.28)
-2 implies the first prep sector command before the sector erase failed, and that usually means the Flash address is wrong
-3 means the erase failed
-4 means the prep before the copy to Flash failed
-5 means the copy to Flash failed.

[AMDlloydsp]

Hmmm... must the status variable be single or integer?

I might have _created_ a ghost.

Lloyd