BS2 Programming environment for Mac OSX

Carlos Santiago

I am currently using MacBS2 to program my Basic Stamp and Boe-Bot. I found that it is limited in several ways. It does not support the DEBUGIN statement and it does not allow writes and reads to the EEPROM.

Is there another BS2 programming environment for Mac OSX that is fully featured?

Forrest

From the MacBS2 FAQ:
Q: Does MacBS2 support the DEBUGIN command?

A: Yes and no. While MacBS2 1.4 and later properly compiles code containing the the DEBUGIN command, you will need to use a different program (such as the venerable ZTerm, or, if you're on Mac OS X 10.3 or newer, goSerial works nicely) to do two-way communication using DEBUGIN.

Note that if you do use a different program to communicate with the Stamp over its progamming port, you can run into conflicts since both programs (MacBS2 and your communications program) will be trying to use the same serial port. The solution is not to have both running at the same time.

Don't understand the comment about EEPROM read/write access - it's fully supported AFAIK. Note on a BS2, your program AND data is all stored in the same 2KB EEPROM.

Mike Green

There is no other BS2 programming environment currently for MacOSX. The compiler (tokenizer) is available as a shared library (www.parallax.com/html_pages/downloads/tokenizer/tokenizer.asp) and you could make your own environment, but you'd have to do the work, maybe using something like XCODE or Eclipse as a base.

Carlos Santiago

My statement about writes and reads to EEPROM relate to the ability of MacBS2. The Windows software allows the user to display the BS2 memory using the Basic Stamp editor. I would like to have the same feature on MacBS2.

Carlos Santiago

I tried goSerial, and it works great. I was able to provide input for the DEBUGIN statement.

Thank You,
Carlos

Mike Green

The only way to get the memory map feature in MacBS2 would be to have a conversation with the author. The tokenizer library does supply the information needed for such a map, but MacBS2 doesn't make use of it.

Chris Savage

Carlos,

It seems you want to be able to read the memory locations you’ve written to at runtime from the BASIC Stamp but even the Windows Software cannot do that. When you look at the memory map that is strictly compile-time. If you program logs data to the EEPROM you cannot use the Memory Map to see what data was written. I’m going on the assumption that this is what you’re trying to do, of course. Now you could write your program to send this data to the PC (Mac) to be analyzed by external software. I hope this helps. Take care.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support

allanlane5

Agreed, the "Memory Map" feature of the PC IDE simply gives you a pre-view of what the PC will download to the eeprom. It does not actually read the eeprom.

And if you put in a pre-programmed BS2, the IDE does not allow you to upload the current contents of the EEPROM.

Tracy Allen

While this does not have specifically to do with OS X, and it is mostly useless for anything, I thought I'd post it anyway. The attached program is a hack that figures out at run time how much free memory is left unallocated between the program code and the data. The hack itself takes up about 200 bytes, but if you set it up right, the space occupied can later be used for WRITEs to eeprom.

I use MacBS2 too, and that is always the main issue, to know how much program is left. My thought is that if you keep this routine in a program, and have some trigger for it to execute, it can tell you where you stand on program size. At least up to the point where you need the 200+ bytes. Moreover, if you are using a cross-slot Stamp like the BS2pe, the test program can reside in its own slot and use the STORE command to probe the status of another slot. The memory dump program Chris suggested could go there too.

' {$STAMP BS2}
' {$PBASIC 2.5}
' Tracy Allen, EME Systems
' end of program hack
' finds the end of the BASIC program in eeprom and free memory
' last instruction in the program must be a dummy gosub
' and also last DATA statement must be referenced

x VAR Word
n VAR Nib
y VAR Byte
z VAR Word
i VAR Nib
lastData DATA 0   ' this has to be the last DATA statement in the program
top:
  DEBUG "this is my program",CR
  GOSUB freeMemory
main:
  DO
  ' more program
  LOOP
  END
 ' GOSUB top   ' alternate location for the dummy gosub

freeMemory:   ' this is the extraction routine
  READ $7fe , Word x ' program start address
  n = x.NIB3 >> 1  ' recover return address for last GOSUB
  x =$7ff - (x & $1fff >> 2)  ' address pointer for last return index
  READ x,y     ' recover last return index
  READ x+1, Word z
  x = z << n |(y >> (8-n))& $3fff  ' and parse to address of last GOSUB
  n = x >> 11
  x = x & $7ff
  z = x * 8 + n - 29
  n = z // 8       ' convert to byte address and offset
  x = z / 8
  x = $7ff - (z/8) - (n MAX 1) ' this is the byte address of  last free memory byte before the program code
  DEBUG CR,TAB, "last free:",IHEX x  , "   total free:", DEC x-lastData-1  ,CR
  RETURN

GOSUB top  ' dummy gosub, or alternatively use the one above before freeMemory
END

As written, it finds the end of the program after the hack. If you want to point to the end of the main program as it exists before the hack, then comment out the last "GOSUB top", and comment in the "GOSUB top" that precedes the freeMemory hack. The "GOSUB top" is a dummy statement that will never be executed and it is there as a marker, so that the IDE will create a pointer to the location that follows the GOSUB and will enter it in the returns table at the start of program memory.

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

Larry

Brilliant Tracy!!
sometimes the answer is so obvious you pass it right by.


This may have to go into my blank program template.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔