Data Tables

HighwayRob · 2010-10-21 10:02

First Post. First Propeller program. Hopefully I got the correct forum. So..here goes...

Our company purchased and is using Propeller Tool for programming of a monitoring board we have developed, called AIU. The AIU program uses a couple of DAT tables to set array values that the program acts upon. These values need to be changed depending on the site we are installing our monitoring system. I would prefer not to give our source code to our technicians, but they need to be able to alter the table as needed. I would rather have a PC GUI based program prompt the technician for the desired values and have that program, using the USB interface, download the new values into the EProm at the correct location.

Here is the data data.

DAT
Active Byte 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0 '1 for Active Alarm and 0 for non active
AlmState Byte 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0 '1 if state of alarm is high, 0 if low
AlmOut Byte 1, 2, 2, 2, 3, 3, 3, 4, 4, 4, 15, 15, 15, 15, 15, 15, 15, 15 'Sets the pattern for the output relays
AlmDel Byte 1, 1, 1, 1, 10, 1, 10, 10, 10, 10, 0, 0, 0, 0, 0, 0, 0, 0 'Sets a time delay before the alarm sets

What are the options to accomplish this?
Sample code anywhere posted?
I can easily create a comma delimited table on the PC, but how would I read it in and commit it to the proper memory location of the Eprom?

How would I control the address of where the DAT tables reside? We are using a 24LC256 Motorola Eprom.

Looking forward to some help.

Thank you,

Rob Sobol
RSobol@HilightsInc.Com

Phil Pilgrim (PhiPi) · 2010-10-21 10:15

Probably the easiest method would be to create a .binary or .eeprom file from the original source and stuff the new data into it. There is one checksum in the file that you would also have to modify. The reason I say "easy" is that you can then upload the binary file using Propellent, rather than having to write a serial protocol for the data, along with drivers on both ends to accomplish the transfer.

The downside of this method is that the location of the data in the binary file will change each time you modify other aspects of the program.

-Phil

Mike Green · 2010-10-21 10:22

The best way for you to do this would be to build the operation into your program in some fashion. Typically, you'd have a jumper (to ground) on your board that would be connected to a spare I/O pin (with a pullup to Vdd). During your program's initialization, if the I/O pin is low, your program would execute an initialization routine that would communicate with the PC over the USB programming port. The PC would send the table data using some kind of encoding, like "@" for zero, "A" for one, etc. and maybe a checksum at the end. This routine would store the data in the EEPROM. There are existing routines in the OBEX for serial I/O (like Simple_Serial) and I2C EEPROM (like Basic I2C Driver) that you could use.

You'd have to use some kind of custom program on the PC side or maybe just a serial terminal emulator depending on how sophisticated your technicians are.

HighwayRob · 2010-10-21 10:54

Wow...sounds like I got options. I will research these posted options.

My short fix is going to be having the techs use a spreadsheet that will output a syntax correct file that the compiler can Include in the source code. This might keep them from messing with the source code if all they have to do is edit the spreadsheet, save the file, load the compiler and source code, connect the cable and press F11.

Wish the compiler had a Command Line Option, I would have the spread sheet invoke the compiler and do the F11 thing.

In the mean time I welcome more suggestions.
Thank you for your thoughts.

Rob

Mike Green · 2010-10-21 11:05

Parallax has Propellent which is a command line Spin compiler/assembler/downloader and there are two free 3rd party Spin compiler/assemblers (BSTC and HomeSpun) that come in command line versions.

HighwayRob · 2010-10-21 11:27

LOL....I should of known.

Thank you for your patience with these Neanderthal questions from this new user.

Phil Pilgrim (PhiPi) · 2010-10-21 11:35

Rob,

I wasn't sure just how insulated from the source you wanted to keep the techs. When advocating the binary approach, I was assuming the max, i.e. that the source would be locked away somewhere completely inaccessible.

If that's not the case, take a look at the FILE pragma in the Spin manual. It allows you to put a data table in a completely separate file from the rest of your source code. Your GUI front-end could then populate that file and invoke Propellent to re-upload the entire program.

Unfortunately, this pragma is very poorly documented in the manual. Left to the reader's imagination are such important details such as the data types (BYTE, WORD, LONG) that can be imported, the file's syntax, and whether labels in the file are incorporated into the source code.

If the pragma's limitations turn out to be an issue, you could also jsut put the DAT table in a separate object with a PUBlic method that reutrns its address.

-Phil

HighwayRob · 2010-10-21 11:49

Well once again you experts are one step ahead of me. I have the following DAT statement (where RelayTable is in the same directory as my source code).

DAT
File "RelayTable"

And the contents of RelayTable are as follows:

Active Byte 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0
AlmState Byte 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0
AlmOut Byte 1, 2, 2, 2, 3, 3, 3, 4, 4, 4, 15, 15, 15, 15, 15, 15, 15, 15
AlmDel Byte 1, 1, 1, 1, 10, 1, 10, 10, 10, 10, 0, 0, 0, 0, 0, 0, 0, 0

and I get 'unexpected variable' error message as soon as the compiler tries to reference
byte[@AlmState][index]

and the quick fix is????

Heater. · 2010-10-21 12:02

HighwayRob,

The file included with the "file" statement is not more Spin code or data definitions that is compiled with the Spin tool. It is just the binary content of the file. A "binary blob" of whatever data that file contains. Therefore whilst you have included the text of your file into the Spin the labels "AlmState" are not recognized by the compiler.

The "syntax" or layout of the data in your file is entirely up to you and you must write Spin code to handle it.

The simplest case is just to create a file containing all your byte parameters as actual 8 bit binary values and the access those parameters as an array.

As Phil points out the "file" statement just includes a bunch of bytes into your DAT section. Problem is the data type is undefined so when your access data you may not get what you think.

If you have:

DAT
'Other dat bytes, words, longs 
parameters file "parameters.bin"

What doe this do in Spin?

something := parameters[7]

I deal with this by using file in the following way:

DAT                     org 0
parameters              byte         ' Force parameters to be BYTE type.
parameters_file         file "paramaters.bin"

Then use the "parameters" label to access the content.

something := parameters[4]

Of course one can use WORD or LONG as the type of parameters instead.

Ariba · 2010-10-21 12:08

The file data type is not undefined, it is BYTE. So you can access the data like a byte array.

If you change the content of the RelayTable file to just the binary data:
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0 ....

then you can do something like that:

CON
  Active   = 0
  AlmState = 18
  AlmOut   = 36
  AlmDel   = 54  

DAT
RelTbl  file "RelayTable"


' Access:
  val := RelTbl[Active + index]
  val := RelTbl[AlmState + index]
  val := RelTbl[AlmOut + index]
  val := RelTbl[AlmDel + index]

Phil Pilgrim (PhiPi) · 2010-10-21 12:11

Per Heater's suggestion, try something like this:

DAT

Active   File "Active.bin" 
AlmState File "AlmState.bin" 
AlmOut   File "AlmOut.bin"
AlmDel   File "AlmDel.bin"

The .bin files apparently have to be packed binary -- not comma-separated values.

-Phil

Heater. · 2010-10-21 12:53

Hmm... Ariba seems to be right. The data type of the label on a file statement is BYTE.

Still, you might want to treat that data as an array of LONGs (or WORDs) as so:

DAT
  parameters    long
  parameters__  file "parameters.bin"

PUB start
  ser.hex(parameters[2], 4)

Prints the LONG from byte offset 8 in the data rather from offset 2.

Now I just have to remember why I felt the need to force the type to BYTE for the bytecodes in my Zog interpreter and for the Z80 opcodes in ZiCog before that.

max72 · 2010-10-21 13:21

As an alternative you can have the table in a file on a Secure Digital card.
If you need to modify the table simply plug it on the PC and copy your new table file to the card.
There is a lot of SD stuff, a regexp object and a lot of other stuff.
You could make the propeller update its eeprom table, or simply read it every time, it depends on your needs.

In theory if you go for high volumes you could also contact Parallax and have a code protected solution.

Massimo

Data Tables

Comments