Whats a good next step chip after the BS2? & What is Scratch Pad RAM?
SteveWoodrough
Posts: 190
While I cannot say that I have mastered the my BS2 chip I am writing applications that could use more memory and maybe more variable space.·I'm considering just going to the BS2e but I will consider going larger if there is a true quantum leap in performance with the·"bigger" chips.
What is Scratch Pad RAM and how is it used?
Thanks for your input!
Steve·
What is Scratch Pad RAM and how is it used?
Thanks for your input!
Steve·
Comments
Here is a simple example, where the motor speeds are stored in Scratch Pad RAM. The idea is that you don't take up "normal" variable space for anything but absolute essentials, leaving most of your space as "work" space....
IRdet PIN 1 ' an IR detector ML PIN 2 ' servo MR PIN 3 ' servo buffer0 VAR Byte ' temp. work byte buffer VAR buffer0 ' alias to use as 3 element array buffer1 VAR Byte ' ditto buffer2 VAR Byte ' ditto -- note that these 3 variables can also be an array: buffer(0), buffer(1), buffer(2) MotorLeft CON $10 ' the "address" or index of the Scratch Pad register for this motor speed MotorRight CON $11 ' ditto MotorRamp CON $12 ' ramp speed Main: ' here's my "behavior" code.... IF IRdet = 0 THEN GET MotorLeft, buffer0 ' load work vars with last known motor values GET MotorRight, buffer1 ' so we can do stuff to 'em GET MotorRamp, buffer2 ' ditto buffer0 = buffer0 + buffer2 ' add motor ramp to left motor buffer1 = buffer1 - buffer2 ' subtract motor ramp from right motor (we're turning) PUT MotorLeft, buffer0 PUT MotorRight, buffer1 ' save the values ENDIF ' then who knows, lots more code here, reams and reams of it.... ' then at the end, after all the main code has "massaged" the motor speed values, we dump them to output.... GET MotorLeft, buffer0 GET MotorRight, buffer1 PULSOUT ML, buffer0 PULSOUT MR, buffer1There's lots of ways to load/save/parse SPRAM -- you can save/load arrays, or Words, or byte streams from serial/i2c commands, etc. The only thing you can't really do directly is bit or nibble operations; for those you need to load the SPRAM register(s) into regular variables, then use aliases or nib/bit assignements for the normal variables, i.e.
GET 10, ioByte ' load address 10 into ioByte IF ioByte.BIT4 = 1 THEN ' do something ENDIF▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST
1uffakind.com/robots/povBitMapBuilder.php
1uffakind.com/robots/resistorLadder.php
2) Scratchpad RAM is just a section of memory available on most Stamp models other than the BS2. Its contents go away when the power goes off and you access it using the GET and PUT statements (see the manual for details). The input statements (like SERIN) can read a string of bytes directly into scratchpad RAM, but that's pretty much all the built-in support it has. It's handy for some programs that have to process long strings of characters like from a GPS receiver.
3) The biggest increase in capability is with the BS2p/pe/px models because of the additional statements. The BS2px adds some additional flexibility in how you can configure I/O pins as well as speed. I don't know whether I'd consider that a "quantum leap". It's certainly a substantial incremental improvement.
4) My bias "after the BS2" is to consider the Propeller. It is definitely a "quantum leap" in terms of capability and raw speed. It's quite different from the Stamps and not as easy to use, but there's quite a bit now of tutorials on its use and many of the functions done by Stamp statements can be done using subroutine calls with the "BS2 Compatibility Library".
Mike, you mentioned something particularly interesting: I take from your first comment that I will not really get 8 times more programming space in the sense that the EEPROM memory map will not get 8 times bigger.
With that in mind: I'm a big fan of subroutines. I have no formal training writting code so essentially what I do is write a bunch of subroutines. Below is the main code that takes input from a TV remote, and directs the bot in several modes. Sub routines lead to sub routines containing LOOPS, CASE, RCTIME etc. The program is small (see below) its the subroutines that take up all the room.
Question: Will that type of program structure work if the main program is in 1 slot and the subroutines are distributed in the other slots?
If anyone has a link to the Nuts and Volts article Mike mentioned I would appreciate it.
Thanks, Steve
'
[noparse][[/noparse] Main Routine ]
Main:
DO
speed = 0
GOSUB GetModeData
IF mode = 1 THEN
GOSUB GetSpeedData
GOSUB Roaming
ELSEIF mode = 2 THEN
GOSUB RemoteControl
ELSEIF mode = 3 THEN
GOSUB DirectionDistance
ELSE
SEROUT LCD, 84, [noparse][[/noparse]148, "Enter Valid Mode"]
PAUSE 1000
ENDIF
LOOP
END
P.S. -- Mike is probably right about the Prop
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST
1uffakind.com/robots/povBitMapBuilder.php
1uffakind.com/robots/resistorLadder.php
Post Edited (Zoot) : 2/27/2009 4:08:42 AM GMT
Attached is a draft of the code to date.· It's not fully commented and still only half baked but I have a hard time seeing a good way to separate out· the subroutines into discrete slots.· Each mode controls the bot in a different way.· One using the IR sensors, 1 using the TV remote, one using the compass module, etc.· Each mode relies on commonly used subs.· There is some junk in here I can delete but I had more functions and modes planned.· Perhaps there are more efficient ways to write the code.
THANKS!! Steve
Also consider switching to the SX. I've found the move from a plain BS2 to an SX to be fairly easy using SX/B.
Note that almost all the forum guys will recommend you learn assembly, but for most applications that a newbie/moderate will use a microprocessor for, SX/B works fine.
After learning SX/B you'll find a whole new world of posibilities opening up to you.
If you do continue with the BASIC Stamp, go with one in the p/pe/px series. They have more ScratchPad RAM than the BS2e or 'sx, and they also have the STORE command that lets your program easily access data that is stored in slots other than the currently running one. Those resources are invaluable for developing multislot programs. They also have additional i/o commands such as for I2C and OneWire.
I use the following scheme to call and return to routines that lie within other slots. The important thing is to have a systematic mechanism in place for doing this. It is possible to do it ad-hoc, but being systematic pays off as the plot thickens.
# a) routine in one slot needs to call a routine that resides in another slot. It PUTs a return index into a location "back" set aside in scratchpad, and sets a special variable to point to the target routine in the other slot. These two pointers both have the same format,
NIB1 is the slot number from 0 to 7 of either the origin or target slot, and
NIB0 is an index from 0 to 15 that points to a specific routine in the origin or target slot.
In the origin slot, the program issues a RUN command to the slot stored in NIB1: RUN bss.NIB1
# b,c) execution commences in the target slot. At the top of that slot is a BRANCH instruction looks up the index in NIB0, which takes program execution to a the specified target routine: BRANCH bss.NIB0,[noparse][[/noparse]myb0, myb1, myb2, myb3] ' up too my15 if needed
# d,e) the target routine executes, then GETs the return index and bank number from the location "back", and RUNs back to the origin slot: GET back,bss : RUN bss.NIB1
# f,g) execution recommences in the origin slot, where another BRANCH resolves return location: BRANCH bss.NIB0,[noparse][[/noparse]mya0, mya1, mya2]. The overall mechanism is completely symmetric for both targets and return points.
# h) the program resumes execution where it left off, or wherever the return mechanism needs it to be.
Caveats and tips:
-- Can't do from within a subroutine, has to be from top level (RUN trashes the return stack)
-- Can't do from within FOR-NEXT loop (RUN trashes FOR:NEXT pointer, use DO:LOOP instead)
-- This uses a single level return stack for cross-slot. Deeper stack is possible, but requires more overhead and bug potential.
-- Minimize the number of cross-slot calls. They are relatively slow. It is better to duplicate some low level code.
-- You can GET location 127 in order to determine the current running slot, in order to make code portable from slot to slot.
-- The index that goes into NIB0 can be named systematically in relation to the routine in the other slot.
mya1x CON $01 ' mya1x is return point #1 in slot 0, to a label mya1:
myb3x CON $42 ' myb2x is routine 2 in slot 4, to label myb3:
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
Post Edited (Tracy Allen) : 2/27/2009 6:36:23 PM GMT
A few parting questions regarding SPIN and using a Propeller:
Can I put all my code in one place (slot) and focus on the project task?
Do I have to learn Assembly?
Can I still easily control servos?
Send and receive signals to my Parallax Servo Controller?
Accept IR data from a TV remote?
Use IR sensors to detect objects?
Easily read the PING sensor?
Easily read the Compass module and accelerometer?
What can I not do in SPIN that I can easily do in PBasic?
Thank You
No, you don't need to learn assembly.
One of the forum members has a saying "It's harder to do the easy stuff with the propeller, and easier to do the hard stuff". Yes, you can control servos, but it will take a bit more initial work.
See last answer.
See last answer.
See last answer.
The compass module has code provided in assembly, but you should be able to create a Spin routine. That's one of the things on my project list, anyway (along with the required arctan function).
You can't work easily with bit or nibs.
See this link: http://forums.parallax.com/showthread.php?p=765086