One for you Parallax Engineer types

Blackbird455

Is it at all possible for you to design a BS1 or BS2 with an expanded memory?· It would be great to have such a simple chip with a ton of memory, say as much as the BS2SX. I know people talk about it all the time.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Noli nothis permittere te terere

dandreae

The BS2pe is very similar to the standard BS2 regarding the timing of the commands, however, it has 32K of memory.· It has 16K for programming space and the other 16K is dedicated to data collection.



Dave

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Dave Andreae

Parallax Tech Support·

Blackbird455

And it only costs $26 extra per unit...........What about the question I asked?
Is it at all possible for you to design a BS1 or BS2 with an expanded memory?
I am asking this from the point of view of the OEM buyer.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Noli nothis permittere te terere

Ken Gracey

An OEM buyer wouldn't buy the modules, so it's not really $26 more per unit to get extra memory. They'd buy the PBASIC interpreter chip of their choice, a resonator, EEPROM and build their own onto a PCB if you are making more than a dozen units.

Ken Gracey
Parallax, Inc.

Blackbird455

Ok what resonator and EEPROM do you have available for purchase for this chip?

The question has still been avoided........" Is it at all possible for you to design a BS1 or BS2 with an expanded memory? "

Hmmmm..........???????

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Noli nothis permittere te terere

Mike Green

Really, the answer is no. You can't add additional program memory to any Stamp ... no way ... not at all. Even if you hooked it up, the PBasic interpreter would ignore it. On the other hand, you can hook up external data memory that's under Basic control. The Parallax memory stick data logger is one extreme example of how to attach gigabytes of data memory to any Stamp. You can also attach additional EEPROM or FRAM (Ferroelectric RAM), either I2C or SPI protocol based, and drive it using a few simple PBasic statements, but this won't expand your program.

With the Stamps that have more than one "slot" of program memory (all but the BS1 and basic BS2), it is also easy to read "overlays" from any kind of external memory and write them into a slot other than the one executing, then transfer control to the beginning of the slot just written. The only thing to be careful of is not to write too many times to the same memory locations (about 1 million times is max.) or you'll wear out that area of the memory.

Franklin

Mike, I'll go the other route. Yes it is possible to design a BS1 or BS2 with expanded memory and you are welcome to do it. (without the source code for the interpreter of course)

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

Mike Green

Ah! Yes, he did ask whether it is possible to design a BS1 or BS2 with an expanded memory. I stand (sit?) corrected. The problem is that you have to design the whole thing including the PBasic interpreter since you can't use the existing interpreter with expanded memory. It's certainly too much trouble for me. I'll use a Spin Stamp thank you and deal with the I/O voltage translation where needed.

Phil Pilgrim (PhiPi)

The BS2 uses the PIC16C57 as its controller. This chip has very limited RAM available, so there's definitely a hardware ceiling on the available variable space. Later Stamps use micros such as the SX, which have more RAM available for variables. But the P-code interpreter firmware has some addressing limits on how many bytes of variable space it can readily access. The word "readily" is key here.

The BS2p-series Stamps, for example, through the use of their GET and PUT commands, expand the amount of accessible, general-purpose RAM by a whopping 127 bytes, added to the original 26. These commands get translated into different P-codes than those used for normal variable access. But the point is that reading and writing these locations is possible using P-codes currently interpreted by the firmware. These P-codes are undoubtedly lengthier than those used for simple variable access, but they serve the same purpose: loading from, and storing to, RAM.

What this means is that the firmware is already capable of supporting a larger variable space. "All" that's required is a modification to the PBASIC compiler to handle the overflow of variables from normal into "scratchpad" RAM — or, better, a way of specifying that a particular variable or array should reside there. Then, for example, one could specify a large array in scratchpad RAM, using a new "extended variable" declaration (VAX), as follows:

i       VAR Byte
array   VAX Byte(64)

FOR i = 0 TO 63
  array(i) = array(i) + 55
NEXT

This would be equivalent to:

i       VAR Byte
acc     VAR Byte

FOR i = 0 TO 63
  GET i, acc
  PUT i, acc + 55
NEXT

Although one could certainly make do with the second version, as we currently must, the first version is much more readable and would be even more so, by comparison, if complicated expressions were involved. The capability for the first version exists now. The will and the resources to bring it about are, perhaps, another matter. Remember, it's not a simple undertaking, and you can't raise the "Mission Accomplished" banner when the programming is done. Manuals have to be updated and reprinted, support staff have to be brought up to speed, etc., etc.

Should it be done? Well, I'd vote "Yes, absolutely!", along with other suggestions I've made for enhancing PBASIC, but I'm not the one who'd be paying for it.

-Phil

Ken Gracey

Blackbird455:

Though it's possible, perhaps with a processor that has more RAM, it's not going to happen. This kind of device isn't in our product plans right now. I can say with certainty that we won't be making an extended·memory BS1 or BS2.·Instead, I'd suggest you take a look at the Propeller for your project. It's only twelve bucks, not to mention it has RAM, larger EEPROM, and growing support.

Not what you want to hear, but I'm close to the engineer and planning resources at Parallax so I can give you the straight scoop.

Ken Gracey

Blackbird455

Looks Like I stirred some folks up.........It was just a simple question, just wanted to know if it was possible, not if it was likely [noparse];)[/noparse]

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Noli nothis permittere te terere

allanlane5

Well, it helps to understand that newbies ask this question all the time. And some people respond quite crossly when told no.

And telling somebody that anything is possible is not usually a helpful answer, when the probability is vanishingly small.

And MANY people have wished to have the Parallax PBasic run-time engine, BUT have 500, 1000 bytes of RAM, and 8K, or 16K of program space, and run at 100,000 Instructions Per Second. But it hasn't happened yet.

Thus all this "oomph" tends to find its way into answers.

JSWrightOC

Let us not forget that the BS2e has the 16K of program space, yet runs at the same speed as the original BS2, and the module is only $4 more expensive than the BS2-IC. I think this qualifies as a "yes" to the question of "can you guys design a BS1 or BS2 that has more memory". Not only does it have the 16K of EEPROM it also has 64 bytes of scratch pad RAM, otherwise the PBASIC programming and execution rate is exactly the same as the original BS2. Basically it's a BS2sx without the steroids...I can think of plenty of applications where you might need more EEPROM or maybe more RAM space, yet not the extra speed and power consumption.

The only other suggestion I have is to use an external EEPROM chip for non-programming storage. A perfect example would be for storage of text string values - using DEBUG "Hello World" style commands eats a LOT of EEPROM space. Another tip is to consider your program writing style. I can fit a complex program in the minimal space allowed on a BS2 simply by restructuring my program to make as much use of GOSUB instructions and loops. Any time I have a set of instructions that I re-use more than once, I put it in a GOSUB routine. Lastly, use GOSUB routines and a simple DO...LOOP to read text strings out of EEPROM a byte at a time and DEBUG it. This is mentioned somewhere in the BASIC Stamp manual (I can't remember where off the top of my head, but I can post code examples), and you use DATA directives to put text in the EEPROM at the top (low value) of the memory range. I was amazed at how much space this saved over using discrete DEBUG "Your Text Here" commands. This method could also be adapted to read the text out of the external EEPROM, if desired.

allanlane5

Well, ok, it DOES have 16K of eeprom space, BUT you still have to use 'bank switching' to run code out of it in 2K 'chunks'. Not a show-stopper, and better than nothing, so thank you for bringing it up.

You STILL only have 26 bytes of 'working' ram, but using the scratchpad is very helpful too.

Gadgetman

Phil, there's a few problems with your assumptions...

1. Those P-codes that allows use of the scratchpad doesn't have anything to do ith P-code fetches from the EEPROM.
after all, the interpreter loads the P-codes 'as needed' from EEPROM, then executes them.

2. Even IF they did, the Interpreter is hardcoded with a 'ceiling' of 2KB in the EEPROM. This is the point where it finds the first P-code to be executed. All following p-codes are stored at lower addresses.
To get past this part they'd have to completely rewrite the interpreter to handle a larger addressing scheme, which would also mean a rewritten compression algorithm and a new(and wastly modifed) version of the IDE...

<Thinking out loud>
The BS1 and BS2 are marvellous designs, and do EXACTLY what they need to do, with a minimum of fuzz.
80% of those who 'need' more program space haven't grasped the concept of programming ofr them, and writes really bad code. of the rest most should be able to either get their program running using Banked programs, or will run into other and more serious limitations(like speed).
The few who isn't helped by using a BS2sx/e/p/pe/px should lok at alternative solutions, like the Propeller or SX/B.
And those who aren't helped by them should seriously reconsider their design...
</thinking>

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don't visit my new website...

Phil Pilgrim (PhiPi)

Gadgetman,

The original poster requested "expanded memory". "Memory" encompasses both program space (EEPROM) and variable space (RAM). My suggestion was confined to variable space and a way to include the scratchpad RAM in that space, which could be done without rewriting any firmware. It wouldn't increase the Stamp's capabilities one iota*, but it would make the extra RAM less cumbersome to use. You are right that nothing can be done to desegment the EEPROM without rewriting the firmware interpreter.

-Phil

*This isn't entirely accurate. The GET command requires a variable as an argument, making it impossible to use within an expression, viz.: a = GET(i) + b. I'm assuming that, internally, the P-code for GET pushes the retrieved data onto the stack, which would allow use within an expression. Given that, programs that would otherwise use GET could be compiled more compactly.

PJAllen

Can we please not fight?

···

Blackbird455

yeah , memory, thaaat would be greaaaat if you could do that. (Memory)= the stuff that you put lines of code into.......................well ,thats how I look at it at least
I guess I had a bit too much Hendricks Gin ( very ,very botanical) when I was thinking "Wow , it sure would be nice to be able to write 1600 lines of code into such a beautifully simple creation like a BS1". Without the expen$$e of Lets say a BS2px....................Lets not throw punches...........Can't we all just get along?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Noli nothis permittere te terere

kelvin james

In defense of Parallax for all their products

---

know the product for its' limitations before you commit to it, then you cannot turn around and say " you should have made it better ". This relates to anything in life, i wish i would have had this wisdom before i married my now ex-wife.

Phil Pilgrim (PhiPi)

The entire BASIC Stamp family really shines in the vast selection of macro functions (e.g. SERIN/OUT, FREQOUT, I2CIN/OUT, etc.) available to the programmer. It's obvious that a lot of thought was put into the choice of functions to include by someone who really understands their customers' needs. Without a lot of experience, one can sit down and whip out a program to deal with multiple peripherals of various flavors, which would take days or weeks if programming a microcontroller in assembler. Frankly, I've never wanted for memory (RAM or EEPROM) in my Stamp apps, especially when using the p-series Stamps. There always seem to be ways around any limitations encountered.

But "ways around" often suggest "ways within" that would make PBASIC even more elegant without changing the Stamps themselves. These are the kinds of things I try to document in the forum — not to criticize the way things are, but to suggest new ways of thinking about the language and how things could be expressed in it. Hopefully, in the fullness of time, some of these seeds of change will take root and bear fruit. But without altering a thing, the BASIC Stamps are timeless in their sheer utility, with many years more of useful life to look forward to. Combining that with Parallax's legendary support, how can you lose?

-Phil

Gadgetman

PJ Allen said...
Can we please not fight?

Fight?

Who's fighting?

We're just having a technical discussion with slightly different starting points.

I've programmed on a lot of different platforms(from the Sinclair ZX Spectrum, Digital PDP11-750, PC, assorted microcontrollers, PDAs, assembler on 8bit micros), and the most difficult part is ALWAYS the interfacing to peripherals.
On a Stamp, that's not even an issue.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don't visit my new website...

Tracy Allen

The improvement in PBASIC that came with version 2.5 is I think the kind of enhancement Phil is talking about. For example, before PBASIC 2.5 we had only
IF conditions THEN label
There were no options for GOSUB after the THEN, nor could there be an expression like x=x/2 there, nor were there options for multiple line statements or any support for ELSE or ELSEIF. That was added to the compiler with no change whatsoever in the Stamp. The compiler effectively takes the new statements and generates the hidden labels and statements in the form {IF conditions THEN label} compatible with the actual instruction set of the Stamp,. But all that is transparent to the user. It makes programs a lot easier to write, document and maintain. There were other instructions that were enhanced at the same time, plus addition of the truly new instructions for the BS2p series. And that meant a larger manual to explain the options. The BASIC Stamp manual version 1.9 takes 100 pages for the BS2 instruction set. In the version 2.0 manual with more examples, it was up to 260 pages.

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

StampNut2

You guys amaze me, You are all so knowledgeable in programming. I just wish I could program full stop. It's not for the want of trying.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never give up when things go wrong.

robosapienv2-4mem8.page.tl/

Blackbird455

Yeah, Kelvin.......... I know the limitations.......... I bumped into that wall several weeks ago , the wall that wouldn't let me put any more lines of code into my BS1......Thats why I experienced my ephiphany........wanting more code space........BTW I am using the most condensed forms of code that are possible, and yes it should seem strange that I can fill one up (read my history of posts).

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Noli nothis permittere te terere

kelvin james

Don't feel bad, i could not put what i wanted into 8 slots on a bsp24. And it turned out not to be fast enough to execute the code to my liking anyway. But i conquered a mountain in the process, and would say it was one of the best learning experiences i have lived through. Ram space is a major problem/ hurdle.