Running programs from an external EEPROM
Robert Schwartz
Posts: 141
Is it possible to write a program to an external EEPROM and have the SX run it?
Robert Schwartz
Posts: 141
Comments
...Ok, ok, I'll give you a hint: You didn't ask what language you could write the program in.
In short, you can't execute SX machine code from external memory. You must write an token interpreter that fits INSIDE the SX and then you can put the tokens in the EEPROM.
Read about "token interpreter", XPL0, "BASIC STAMP", "byte-code interpreter"
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
---
James Newton, Host of SXList.com
james@sxlist.com 1-619-652-0593 fax:1-208-279-8767
SX FAQ / Code / Tutorials / Documentation:
http://www.sxlist.com Pick faster!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax
Dallas, TX· USA
I am curious why several people are expressing questions along these lines. Microcontrollers were never meant to replace the functionality of full processors, they are designed for embedded systems which require complex logic to operate but are limited in thier scope and function (and hence a full processor is overkill and too much cost), perhaps you should be looking for an embedded 386 system or rabbitcore.
Post Edited (Paul Baker) : 3/22/2005 3:21:14 AM GMT
I guess what I'm getting at: ever since I've started using micros, my friends (mostly coders, like me) always love to look at my hardware, but then jump to the question "how much memory does it have" - I try to explain that this isn't a computer- that the tasks being dealt with are different in scope than what I would use a PC for. I guess it is all a matter of selecting the proper tool for the job (or in this case uController)- and the ability to do *that* properly comes with experience...
Honestly how often has running out of code space been a problem for people with their Stamps? SXes? I would really love to hear some feedback about this.
Ryan
Post Edited (Robert Schwartz) : 3/22/2005 11:43:27 PM GMT
And Jon has written some very complex programs.
I will go out on a limb and state that efficient programming is the key, and efficient programming is far easier said than done.
Now to address the point of this thread; in my mind a 'usefull' robot has to have some sort of 'navigation' aspect, ie - mappping of an area, remembering objects that were encountered, and ability to return back to the charging station before the batteries run dry, to name a few items. All of the above mentioned would have to have access to some fast memory. And their is code examples for doing all this to be considered.
I was thinking on going the route of an SX52 with access to a lot of eeprom (or something simillar), but I think that would have a very limited capability. I purchased a xx386 SBC with an I/O expansion card. I was thinking of having that be the 'brains', and interface to some SX chips that would do the 'grunt' work. The BIG problem, interfacing of the two, and not having to make a sacrifice in the comunication speed between the two 'systems'.
So the best solution that I can envision is Parallax comming up with a 'computer' chip, 32 bits of course, at a very reasonable cost (less than a $100), that would be able to interface to the SX chips, smoothly, and access mass storage, and/or other things. Have the same language to work with between the two (probably both assembly and SX/B). How about that for a wish list.
In the mean time my project has stalled, the wrong decission could end up costing a lot of time and money which would not have been well spent. So I guess I am open for some ideas.
Unless there is a reason why GPS cannot be used ???
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"SX-Video Display Module" Available Now.
www.sxvm.com
"A problem well defined, is a problem·half solved."
·
I thought about GPS. Lets explore, GPS will tell the robot, in real time, within a couple of feet, where it is. Now, do I plan to map out objects, especially the edges, in numbers that the robot can understand. So everytime you move a chair, you have to have a seperate GPS module to tell you the location, then you have to feed the information to the robot. This falls in the premapping or prelearning scenario. This has to be consired if you want the robot to do some usefull things, and not just spend its time moving around and mapping 24/7.
The other aspect is, lets say an SXxx chip does this, is their example code that is readilly available to achieve this(SX/B preferrably)? And once it starts getting all this data, how and where does it put it. From what I have read about the GPS systems, for BS2's at least, they are quite difficult to work with.
I am sort of leaning in the direction of, via an IR remote control, you walk a robot through some designated path, and have the robot remember the path. In order to do this I am thinking some simple devices like a compass with 1 degree graduations, a sonar unit, and some IR/detect units. I have recently learned that Intel, in the near future, will have some laser technology that will be used for measurng distances. Something like that could replace the IR/detct unit, and the sonar. The IR, and sonar could be interfaced via I2C fairly quickly, again I like to work in basic when I am doing prototype work. GPS could become a unit of choice if the afermentioned problems could be overcome quickly and cheaply. I hope my drift is becomming apparent, QUICKLY and CHEAP for prototype work.
So, you need a fast interface between the 'slave' BS2 (or SX) and the 'master' x386. You can use RS-232 for that, or even RS-485. I believe the SX can support 115 KBaud -- which can do a lot if you've defined your communication protocol correctly (simply, that is).
But it's way overkill to expect Parallax to leave their niche market -- small, battery powered, very simple to use processors -- and ask them to build a 32-bit, lots of RAM, lots of EEPROM processor just for you. There are many vendors out there (ok, more than 20) building small processor boards using '386, '486 or larger chips. The Rabbit boards are quite capable using a super-Z80.
If you've already got an x386 single board processor in there, why not use DOS or Linux and do the real-time extensions on top of that? Use each piece for what it is good for, is my advice.
Oh, and this WAS Bob Schwartz thread, I think.· I don't know who this other guy is.
And Bob, the 'bootloader' approach that can be used in the 16F876 family of PIC processors (and later) -- I'm not sure if it is supported by the SX52, but you would think it would be.· It depends on a feature of the PIC processors that allow a 'protected' area of Flash to write to another area of Flash.· I'm not sure if this hardware feature is in the SX family.
Post Edited (allanlane5) : 3/23/2005 5:21:42 PM GMT
I do not think the SX supports bootloading, I've read and re-read the specs to the SX, and I would have remembered seeing this feature. Now, you could mimic what the SX-Key does so that a boot loader controller would program the SX from an external EEPROM, but this seems like it would be more hassle than it is worth.
Post Edited (Paul Baker) : 3/23/2005 5:29:47 PM GMT
One of the scenarios that I was looking into, a few weeks ago, was just that, using an SX52 as the brains, and that would be linked with maybe two to three SX28's. In fact in a previous thread I brought up the topic of networking the SX's. My chief concern is the 'memory' aspect, once you run out, out goes what is left of my hair. I try to keep to the 'KISS' principal as much as possible.
Since Paralax is going to be presenting an SX52 tech board, I may have to reconsider that scenario. What I need right now is a lot more info about the new SX52 tech board, I already saw the 'teaser' a week or so ago. The other thing that I have to consider is a multitasking element for the "brains', hopefully the person that developed the RTOS is thinking 'public domain', and if that RTOS is robust enough to do what I need it to do.