Loading data into BS2 memory without re-loading the whole program

davejames

Hi All,

After too long of a lull, it's time to get busy on the current project.· However I've hit a snag.

I have the need to load user-derived data into BS2 memory that the program will use.· Is there a way to "push" data into memory while leaving the previously loaded program intact?

The software interface on the computer that facilitates this hasn't been defined yet.· I'm just trying to figure out if it's feasable, or if I have to put the user interface on the project itself (which will eat up a lot of resources).

Trusting that I haven't missed a poignant page in the manual,

DJ


·

Mike Green

There's no way to do this using the Stamp Editor, but you can add the capability to your program by using the READ and WRITE statements. Read the sections in the manual on the READ / WRITE / DATA statements.

davejames

Mr. Green

DATA, READ/WRITE - yes, understood.· But they operate from the program.· I was curious about inseting data into the BS2 memory from an outside source.

If I went with DATA, then the project's source code would be open to the user and that's something I'd like to avoid (for various reasons).

Am I facing the possibility that performing *any* kind of data load into BS2 memory will force a full re-write of all memory locations?

Thanks much,

DJ

Mike Green

1) There is no way to do an externally controlled "data" load into a Stamp that doesn't overwrite the program as well.

2) An externally controlled "data" load does not rewrite all memory locations, only those required by the program being downloaded.

3) Adding a feature to your program that allows data to be stored to the EEPROM does not open the source code to the user.

4) What's stored in the EEPROM is a compiled version of your program, not the source code. None of the variable names or labels are stored in the EEPROM and many of the statements (like DO LOOP) are translated into simpler forms. The program is in a difficult to decode, highly compressed format for which there is no public documentation.

davejames

...hmmmm.· Maybe I need to elaborate on my project.

//Ramble On...

I have built a 10 X 10 relay matrix, with all associated drivers and decode logic so's not to load the BS2 outputs inappropriately.

I've written the code to READ specific BS2 memory locations that contain the information used to define which relays in the matrix are to be closed.· And all works just hunky dory.

My snag is having the user define and input which relays to close.

Using DATA directives and the Stamp editor, I can easily download a specific set of relays to close.· But that appears to reload the whole program...and being in the editor, the user can view the source code.

I've been spending some time in creating a user interface within the BS2 program and I can input the data that describes which relays to close.· However, the interface is a bit cumbersome as it involves setting a bunch of toggle switches and pressing a 'load' button (kinda like loading the bootstrap program on the old PDP-8 computers).· Yes, adding an LCD and keypad would ease the 'cumbersome-ness' but would increase the level of complexity.· I'll go that route if I *must* after exhausting other alternatives.

Another possibility would be to have an external routine that runs on a PC (coded in VBasic, C, or whatever) that would allow the user to define which relays to close, and then download *just that* set of data...hopefully not disturbing the program already loaded in the BS2.· Going this route would allow the potential of a "feature rich" user interface.

I've read that there is a way to produce just the tokenized output of a PBasic source file that can be downloaded without the use of the Stamp editor.· Maybe there's a way of 'poking' into certain locatons of this tokenized output file?

//Ramble Off...

Later,

DJ





Post Edited (davejames) : 11/11/2008 9:41:43 PM GMT

stamptrol

DJ,
Presumably, the operator will have access to a terminal of some sort. One angle is to use the DEBUGIN command to let the Stamp receive the information. That way, the Stamp program keeps running and only the DEBUG screen pops up at the appropriate time to receive the new data.
Alternatively, you have the Stamp periodically listen to the serial port and take in whatever data is coming at it from a terminal program.

Cheers,

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tom Sisk

http://www.siskconsult.com
·

Franklin

You can use the tokenizer anyway you want. You could write a program that takes the program in in an encrypted form, un encrypts it, combines it with your new code and then tokenizes it.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- Stephen

davejames

Mr. Sisk,

Well - I guess I didn't read all the pages in the software manual after all!· I now see that DEBUGIN may have high potential.· If I understand the manual correctly, issuing a DEBUGIN command from the program in the BS2 will open a Debug window within the Stamp editor allowing the user to input data.· Whereas SERIN would require the construction of an application on the PC to handle the input from the user and then serially pass this to the BS2.

Any idea how Parallax would feel about distributing the Stamp editor with a charged-for product?· Methinks that would be a tad touchy.· Obiously this will work for first-go prototypes that only I use.· I'll probably investigate the SERIN approach for the final release stuff.

I'll go away now and think about everyone's inputs.· I'm sure there will be more questions when it comes time to construct the PC-based user interface.

Thanks everybody - I'm calling this request for help closed.

DJ

Mike Green

The Stamp Editor is available for free for anyone who wants to go to the trouble of downloading and installing it on their computer. For you it's more an issue of customers accidentally compiling an empty program and overwriting what's pre-programmed into their Stamp. You don't have to use the Stamp Editor to talk to DEBUGIN. Any terminal program would do. On older versions of Windows (like XP) there's a program called HyperTerm that will work. There are other such programs, some of which are open source and free for downloading.

davejames

Mr. Green - thanks again.

Obviously I am misunderstanding the DEBUGIN description in the manual on page 171 that states:

"Function
Accept information from the user via the Debug Terminal within the BASIC Stamp Editor program."

BUT, if you tell me that I can use any terminal window for use with DEBUGIN I'll solicit more information. You've been at this way longer than I and I'm a listenin'.

And, yes, I understand what you mentioned about the possiblity of a user compiling/loading an empty program. Definitely NOT what I would want them to do!

DJ

Tracy Allen

Maybe it will help if you understand a little bit more about how the Stamp programming algorithm works. The BS2 eeprom is 2048 bytes, but it is orgainized into 128 pages of 16 bytes. When the Stamp IDE programs the Stamp with the RUN command, it only sends blocks of 16 bytes that actually contain program or DATA. You can set aside a block of 16 bytes and have the IDE update only that block with the RUN.

For example, if you want to send only 16 bytes of data that define how the relays work, you can write,

DATA @16,$00,$a1,$b2,$03,$54,$f5,$22,$c7,$19,$33,$00,$00,$57,$d4,$00,$ff

If the above line is the only code in the updater program, then the only bytes sent will be ones shown, the block from 16 to 31. The rest of the program already in the Stamp and other blocks of data will not be touched. I wrote in the @16 to show that you can set a starting point and also to emphasize that the 16 bytes have to be aligned modulo 16 as an eeprom address.

Another option you have would be to compile the settings into an object file. You will find this option in the IDE under the file menu/Generate Object Code. You could send the update to your customer as an email attachment. It is standalone, and they do not have to see the program or open the IDE.

If you have a multislot stamp like the BS2pe, you can set an option in the editor to only update one slot, leaving the other slots untouched.


I don't know how much interaction you want the end user to have with the IDE. There is a definite down side to that. Multi-slot Stamps give you a lot more program space to develop a user interface. Like Mike says, the user interface can operate through any terminal program, not just through the Stamp Debug window.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com

Post Edited (Tracy Allen) : 11/11/2008 10:39:35 PM GMT

davejames

Mr. Allen,

Yes - I've played around with the DATA directive and it works as advertised (even used the offset aspect as you described).

I dismissed using DEBUGIN due to what the manual states.· BUT as I mentioned to Mr. Green, you guys have been at this a lot longer than I and obviously have found out that any terminal window will work.

Along that line, I poked around my XP-based laptop here at work (shame on me) and found the HyperTerm program Mr. Green had mentioned.· It will even allow saving a ".ht" file that contains all the settings suitable for communicating with the BS2.· This.is.cool.

I will continue down the HyperTerm path for the next stage of development.

Thanks everyone - your assistance is greatly appreciated!

DJ