Using the Generate Object Code option in the Basic Stamp IDE.

Mike Cook

Hopefully this does not sound too confusing………………….

Observation:· When using this option to generate an object code file (see attached for configuration), no matter what size the basic stamp code (BS2) is,· the file generated is 19,400 bytes.


Questions:·

1. Is there any way to make this file smaller, without writing an utility to strip out just the object code?
2. If this is not an IDE bug, what is the logic behind having this large of a file?
3. Is there a document describing·the *.obj·file's structure?

I’ve looked through several documents and have not found the answer to this yet, unless I skimmed over it. I’ve loaded the file up in a HEX editor and have figured out what needs to be extracted, from this file, so this data can then be sent to a BS2. However I would like to skip this step.

Background:

1.·I would like to be able to use the current Basic Stamp IDE to modify code for a BS2 (Scribbler).·
2.·Then save the code as an *.obj file.
3.·Then transmit this file, via XMODEM, to a Propeller Chip configured with XBEE, XMODEM, SD, and an additional serial port connected directly to the BS2 (Scribbler)

Transmitting a 19,400 byte file @ 9600 baud, when the code is·less than·2K seems to be a bit wasteful. Trying to use off the shelf software and really don’t want to write a utility to extract just the code required. Hopefully I've missed an option that's built into the Basic Stamp IDE.

Thanks in Advance!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Mike

allanlane5

Wowee, you want to 'update' a BS2 from a Propeller chip?

You know, you'll have to 'emulate' the programming cycle from the Propeller to the BS2, right? Including toggling the DTR line, etc.

Unless, you can figure out the software sufficiently that you can write a small 'loader' on the Scribbler (in PBasic) that will properly load the code tokens in the right places in eeprom, then 'GOTO' the starting location.

I think you're going to have to 'massage' the generated object code in any event.

Why do you want to go through all this trouble? Reprogramming the scribbler from scratch for everything you want it to do is a pretty stone-age approach. Is it not possible to program into the scribbler some 'primitives', then download to the scribbler a 'program' it should store in its eeprom which will tell it which 'primitives' to run? By "primitives" I mean "TurnLeft", "TurnRight", "Forward", "WaitAPeriod", "Stop".

Changing code on-the-fly is going to be a difficult proposition no matter what approach you take. You'll still want to minimize the necessary effort.

Mike Cook

Programming a BS2 outside of the Basic Stamp IDE·is documented on the Parallax and on Tracy Allen’s web site. A Propeller Chip should be able to program a BS2.

I have written a XMODEM receive routine for the Propeller Chip and it will receive the file using an XBEE radio and then save the file to a SD card. I could do the conversion on the Propeller (and will probably try that next), but was concerned with transmitting all the unnecessary stuff. The Scribbler is being used as a test platform and in all reality the code should not have to be updated too often. Working on a project along the lines of http://www.roboteducation.org , but would like to substitute a propeller processor for their ‘Fluke’ board.

Since this is a project that will ‘evolve’ over time I’m not quite sure of the end result!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Mike

Post Edited (Mike Cook) : 10/29/2008 9:33:18 PM GMT

allanlane5

Yes, the process needed is well documented by Parallax and Tracy, so it's do-able, in theory anyway.

Jeff Martin

Hi Mike,
It is a fixed size because 1)·it was decided that a 19k-sized file is of little effect on today's and future's storage system (hard drives, thumb drives, etc.) especially when, in most cases, they'd be integrated into a single executable that contains both the loader and the object data, and 2) it is much easier to implement a fixed-size object code reader/verifier, than a variable sized one.
There's no feature in the software to store it in any different format.
Here's the format for version 1.3 (of the object file: created by Stamp Editor v2.2.7 and later).

BASIC Stamp Object Code File Format (v1.3):
Address:                Name:          Description
---------------------   ------------   ----------------------------------------------------------------------------------
0          (1 byte)     HeaderSize     Size of header string
1-23       (23 bytes)   Header         Text header describing data "BASIC Stamp Object Code"
 
24         (1 byte)     Version        Object Code File Format Version Number (current v1.3, $13)
 
25         (1 byte)     ModuleType     Target BASIC Stamp Module Type.  1=BS1, 2=BS2, 3=BS2e, 4=BS2sx, 5=BS2p, 6=BS2pe, 7=BS2px
 
26         (1 byte)     CompanySize    Size of Company string
27-76      (50 bytes)   Company        Company Name
 
77         (1 byte)     ProductSize    Size of Product string
78-127     (50 bytes)   Product        Product Name
 
128        (1 byte)     FirmwareSize   Size of Firmware string
129-178    (50 bytes)   Firmware       Firmware Version
 
179-186    (8 bytes)    CompileDate    Date of compile
 
187        (1 byte)     Intro1Size     Size of IntroMessage1 string
188-437    (250 bytes)  IntroMessage1  Introduction Message (all three make up a single 750 character message)
 
438        (1 byte)     Intro2Size     Size of IntroMessage2 string
439-688    (250 bytes)  IntroMessage2  
 
689        (1 byte)     Intro3Size     Size of IntroMessage3 string
690-939    (250 bytes)  IntroMessage3  
 
940        (1 byte)     HideSlotIDs    Show (0) program slot IDs during download, or Hide (-1) slot IDs during download.
 
941        (1 byte)     NumberOfProgs  Total number of actual programs in Programs array (1 for BS1 and BS2, 1 or more for rest)
 
942        (1 byte)     SlotID         Slot ID for this program slot (target slot in BASIC Stamp)
943        (1 byte)     PacketCount    Number of packets in this program slot
944-3248   (2305 bytes) PacketBuffer   Actual object code packets for this program slot
 
3249-19397 ((1+1+2305)*7)              Additional SlotIDs, PacketCounts and PacketBuffers for program slots 1 through 7
 
19398-19399(2 bytes)    Checksum       Checksum

For your purposes, all you need to do is extract bytes from 943+, where byte 943 contains·the number of 18-byte packets (following it) that are valid code.· Simply transmit those 18-byte packets, in tact, to the Propeller Chip to have it download them.

Also, there should be no reason a Propeller Chip can't program a BASIC Stamp module; in fact, we've considered making in-house testers in the same way.

Take care,

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Jeff Martin

· Sr. Software Engineer
· Parallax, Inc.

Post Edited (Jeff Martin (Parallax)) : 11/3/2008 7:05:32 PM GMT

Mike Cook

Jeff,

Thanks for the info!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Mike

Tracy Allen

Yes, Jeff, thanks. Two hacks I want to try: 1) Skip slots, for example, to skip slot 0 and 1, leaving them be, and then load slots 2 to 7. 2) load data into slots 8 to 15 of a BS2pe (send slot numbers greater than 7). At present I can do those things with the Stache. Certainly if the SX processor in the Stache can do it, the Prop can too!

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

Unsoundcode

Hi Mike, I did something similar to what you are trying to achieve using the Parallax Tokenizer documentation and Tracy Allen's detailed description on his web page.

In my case I used a BS2px to program a BS2. The BS2px would read a tokenized file from a datalogger, the file was a CSV file.

Without going into detail my biggest problem was getting the object code into the CSV file, seeing the format of the object file that Jeff Martin posted was really enlightening and I was able to modify a small utility program that I was using. The utility may be of no use to you but it has made my task of porting the obj over to the CSV 100 times easier.

If you care to check it out here it is, a requirement is the latest version of Microsoft .Net Framework V3.5 which can be downloaded at http://www.microsoft.com/downloads/details.aspx?FamilyId=333325FD-AE52-4E35-B531-508D977D32A6&displaylang=en

My usage was single slot programming so that is all the utility is capable of reading.

Jeff T.

Carl Hayes

Why not load your program in, say, Slot 1, leave it there, then load Slot 0 with a program that would read the EEPROM of Slot 1 and send it to something that could write it as a 2K file? You'd have to do this on a BS2PX, I think, in order for the code in Slot 0 to look at the EEPROM in Slot 1.

Then you could develop a program that runs in, say, Slot 2, to receive that 2K file and write it in Slot 0 (or wherever) in the Stamp that was on the receiving end. The Slot 2 program could be "run" by a goody in Slot 0 that then got overwritten.

I'm just brainstorming, but is there any reason why that wouldn't work? It looks to me like it'd be extremely easy to do.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
· -- Carl, nn5i

Carl Hayes

Wups, just checked the manual. Actually any BS2P, PE, or PX can do that. See READ, WRITE, and STORE.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
· -- Carl, nn5i