My Take on the Propeller
Sal Ammoniac
Posts: 213
I’ve been using the Propeller now for only a few weeks, but I am using it for a real-world project, so I thought I’d offer my observations as an “outsider” in the hopes that they’ll be useful to people still sitting on the fence concerning use of the Propeller in their projects.
First, some background. I’m a professional firmware engineer with more than 25 years experience. I’ve worked with everything from custom bit-sliced processors, 8-bit general purpose CPUs and microcontrollers (8080, Z80, 6502, 64180), 16/32 bit processors (68000 primarily), and the latest generation of 32-bit MCUs (ARM, AVR32, among others). I’ve “retired” from active firmware development professionally and have moved into management, where I’m trying not to become a PHB
All of my current work with embedded processors and firmware is at the hobby level, which has the advantages of no schedules, no customers, and no boss breathing down my neck.
When I first looked at the Propeller a few years ago, I was initially enthused, but quickly dismissed it as having no memory to speak of, no JTAG or other means of in-circuit debugging, no C compiler, and no integrated peripherals. I’ve since implemented several medium-size projects using ARM Cortex-M3 processors from Luminary. These are well-supported by development environments (I use Rowley CrossWorks), have reasonable amounts of on-board RAM and FLASH, a plethora of integrated peripherals, and JTAG debug support.
My latest project is an automated weather station. I’ve have a weather station at home for the past 30 years, but it’s not automated and requires me to trudge out nightly in all weather conditions to the instrument shelter at the back end of my garden and manually read and record the data from the instruments. I wanted something that would transmit sensor data (temperature, barometric pressure, relative humidity, rainfall, wind speed, etc.) wirelessly to a computer in the house that would log, display, and graph the data in real-time.
I started this project with a Luminary ARM processor and as a first step ported my own real-time OS that I’d written 20 years ago for the 68K. I was about half way through coding the firmware when I read an article about the Propeller and decided to shift gears and reimplement my code and hardware on the Propeller. Since this is a hobby effort with no schedules and no boss, I didn’t need to justify the change in direction to anyone.
I ordered a Prop USB Proto Board from Parallax, and it arrived the next day (I live about an hour’s drive from Parallax headquarters in Rocklin). My first impression was somewhat less that positive. When I plugged the board into my PC and wrote the ubiquitous “blink an LED” program in Spin, I found that it would execute for only a few seconds before stopping. The power LED on the board gradually decreased in brightness until it eventually went out. I checked the voltages on the board and saw that the 5v and 3.3v rails would start at their nominal values and then sag over about a ten second period. I thought the problem might be the wimpy 200mA wall-wart I was using to power the board, so I wired up a 9v battery to a power connector and plugged it into the board. As I was watching the voltages on the DMM display, I heard a sizzle and turned around to watch one of the 10uF tantalum caps on the board fry itself in a cloud of smoke. Either the cap was bad or installed backwards. I quickly replaced the charred remains with a new cap and the board has worked fine ever since.
Now that I had a working board, I built up the hardware on a solderless breadboard and started writing code. I was surprised how quickly I was able to write Spin code to read the sensors. I was expecting the lack of integrated peripherals to be a bottleneck, that turned out not to be the case. I started with an SCP1000 pressure sensor, which has an SPI interface. There might be an object for this in the Propeller object exchange, but since I prefer to write all of my own code, I didn’t bother to look. It took me about 15 minutes to get code working to bit-bang the SPI interface. It took me several times as long just to read and understand the Luminary datasheet to figure out how to use the integrated SPI peripheral on the ARM chip. I’ll admit that having a logic analyser certainly helps debugging this type of code, but I’m sure it wouldn’t have taken much longer without one.
Writing driver code for the HD44780 parallel LCD and the I2C sensors didn’t take much longer. It’s nice having eight cogs available to divide up the hardware tasks and not have to worry about interrupts, race conditions, and apportioning processor resources appropriately. I was able to complete the code in two days of effort and it’s been running on the bench for two weeks now without problems.
Working with a multi-core processor certainly made partitioning of the hardware-specific tasks easier. I just took each major subsystem and assigned it to its own cog. With other processors, I would have written interrupt-driven drivers and would have had to worry about resource contention and determinism. My current project does not impose too many concerns about these issues, but the fully deterministic nature of the independent cogs would certainly make this easier. Not having to debug interrupt-driven code is also a plus.
I thought not having a debugger with breakpoints, the ability to single-step code, and instruction trace would be a problem, but it wasn’t. This harks back to my early days as an embedded developer when I worked for companies that couldn’t afford in-circuit emulators and other hardware debugging tools and had to debug in much the same way I did with the Propeller. Don’t get me wrong, however—I’d still like to see a JTAG debug interface on the Propeller follow-on, but one can certainly get by without it.
Another criticism I’ve seen is the fact that you’re almost required to write self-modifying code when programming in PASM. In fact, PASM has three instructions to facilitate this: movi, movd, and movs. I didn’t have an issue with this because I’ve often resorted to this technique in the past when trying to write high-performance assembly language for slow processors with inadequate memory space. The fact that one can write all but the most performance-sensitive code in Spin certainly helps mitigate this criticism.
The lack of a C compiler was one of my early reasons to avoid the Propeller, but even though one is now available, I find that Spin is actually quite a nice language and haven’t even looked at the C compiler. It only took me a day or two to learn enough to write significant amounts of code. As a long-time user of Python, I don’t have any issue with indentation as a means of defining code blocks, which I often hear as a criticism of Spin. In fact, I like this as it forces you to impose some structure to your code.
The only thing I really missed was native support for floating point in the language. Spin only supports floating point in constant expressions and everything else has to be done manually. There are floating point objects available in the library, but they’re tedious to use (result := F.FMul(F.FDiv(a,b), F.FADD(c,d)), well, you get the picture). I ended up converting everything to fixed-point math, which also saved a lot of execution time over the floating point libraries.
Designing the hardware for my project was almost trivial given the simplicity of the Propeller. Just 32 pins for the ports, a few more for power and ground, a crystal, and a reset input makes things very easy. The availability of the Propeller in a 40-pin DIP package is also a real plus in these days of 512 pin BGA parts. This is my first hardware design (my long-term collaborator on past projects who used to do the hardware design for me has gotten into amateur acting in a big way and no longer has time to work with me on these projects.)
Overall, I’m glad I made the switch from the ARM to the Propeller. I’d estimate I saved a few weeks of development time by making the switch. All of the initial concerns I had about the Propeller turned out to be easily worked around and the ease of code development more than made up for switching horses in mid stream. I’d recommend the Propeller to anyone developing embedded applications that require a reasonably fast processor with multiprocessing capabilities.
First, some background. I’m a professional firmware engineer with more than 25 years experience. I’ve worked with everything from custom bit-sliced processors, 8-bit general purpose CPUs and microcontrollers (8080, Z80, 6502, 64180), 16/32 bit processors (68000 primarily), and the latest generation of 32-bit MCUs (ARM, AVR32, among others). I’ve “retired” from active firmware development professionally and have moved into management, where I’m trying not to become a PHB
All of my current work with embedded processors and firmware is at the hobby level, which has the advantages of no schedules, no customers, and no boss breathing down my neck.When I first looked at the Propeller a few years ago, I was initially enthused, but quickly dismissed it as having no memory to speak of, no JTAG or other means of in-circuit debugging, no C compiler, and no integrated peripherals. I’ve since implemented several medium-size projects using ARM Cortex-M3 processors from Luminary. These are well-supported by development environments (I use Rowley CrossWorks), have reasonable amounts of on-board RAM and FLASH, a plethora of integrated peripherals, and JTAG debug support.
My latest project is an automated weather station. I’ve have a weather station at home for the past 30 years, but it’s not automated and requires me to trudge out nightly in all weather conditions to the instrument shelter at the back end of my garden and manually read and record the data from the instruments. I wanted something that would transmit sensor data (temperature, barometric pressure, relative humidity, rainfall, wind speed, etc.) wirelessly to a computer in the house that would log, display, and graph the data in real-time.
I started this project with a Luminary ARM processor and as a first step ported my own real-time OS that I’d written 20 years ago for the 68K. I was about half way through coding the firmware when I read an article about the Propeller and decided to shift gears and reimplement my code and hardware on the Propeller. Since this is a hobby effort with no schedules and no boss, I didn’t need to justify the change in direction to anyone.
I ordered a Prop USB Proto Board from Parallax, and it arrived the next day (I live about an hour’s drive from Parallax headquarters in Rocklin). My first impression was somewhat less that positive. When I plugged the board into my PC and wrote the ubiquitous “blink an LED” program in Spin, I found that it would execute for only a few seconds before stopping. The power LED on the board gradually decreased in brightness until it eventually went out. I checked the voltages on the board and saw that the 5v and 3.3v rails would start at their nominal values and then sag over about a ten second period. I thought the problem might be the wimpy 200mA wall-wart I was using to power the board, so I wired up a 9v battery to a power connector and plugged it into the board. As I was watching the voltages on the DMM display, I heard a sizzle and turned around to watch one of the 10uF tantalum caps on the board fry itself in a cloud of smoke. Either the cap was bad or installed backwards. I quickly replaced the charred remains with a new cap and the board has worked fine ever since.
Now that I had a working board, I built up the hardware on a solderless breadboard and started writing code. I was surprised how quickly I was able to write Spin code to read the sensors. I was expecting the lack of integrated peripherals to be a bottleneck, that turned out not to be the case. I started with an SCP1000 pressure sensor, which has an SPI interface. There might be an object for this in the Propeller object exchange, but since I prefer to write all of my own code, I didn’t bother to look. It took me about 15 minutes to get code working to bit-bang the SPI interface. It took me several times as long just to read and understand the Luminary datasheet to figure out how to use the integrated SPI peripheral on the ARM chip. I’ll admit that having a logic analyser certainly helps debugging this type of code, but I’m sure it wouldn’t have taken much longer without one.
Writing driver code for the HD44780 parallel LCD and the I2C sensors didn’t take much longer. It’s nice having eight cogs available to divide up the hardware tasks and not have to worry about interrupts, race conditions, and apportioning processor resources appropriately. I was able to complete the code in two days of effort and it’s been running on the bench for two weeks now without problems.
Working with a multi-core processor certainly made partitioning of the hardware-specific tasks easier. I just took each major subsystem and assigned it to its own cog. With other processors, I would have written interrupt-driven drivers and would have had to worry about resource contention and determinism. My current project does not impose too many concerns about these issues, but the fully deterministic nature of the independent cogs would certainly make this easier. Not having to debug interrupt-driven code is also a plus.
I thought not having a debugger with breakpoints, the ability to single-step code, and instruction trace would be a problem, but it wasn’t. This harks back to my early days as an embedded developer when I worked for companies that couldn’t afford in-circuit emulators and other hardware debugging tools and had to debug in much the same way I did with the Propeller. Don’t get me wrong, however—I’d still like to see a JTAG debug interface on the Propeller follow-on, but one can certainly get by without it.
Another criticism I’ve seen is the fact that you’re almost required to write self-modifying code when programming in PASM. In fact, PASM has three instructions to facilitate this: movi, movd, and movs. I didn’t have an issue with this because I’ve often resorted to this technique in the past when trying to write high-performance assembly language for slow processors with inadequate memory space. The fact that one can write all but the most performance-sensitive code in Spin certainly helps mitigate this criticism.
The lack of a C compiler was one of my early reasons to avoid the Propeller, but even though one is now available, I find that Spin is actually quite a nice language and haven’t even looked at the C compiler. It only took me a day or two to learn enough to write significant amounts of code. As a long-time user of Python, I don’t have any issue with indentation as a means of defining code blocks, which I often hear as a criticism of Spin. In fact, I like this as it forces you to impose some structure to your code.
The only thing I really missed was native support for floating point in the language. Spin only supports floating point in constant expressions and everything else has to be done manually. There are floating point objects available in the library, but they’re tedious to use (result := F.FMul(F.FDiv(a,b), F.FADD(c,d)), well, you get the picture). I ended up converting everything to fixed-point math, which also saved a lot of execution time over the floating point libraries.
Designing the hardware for my project was almost trivial given the simplicity of the Propeller. Just 32 pins for the ports, a few more for power and ground, a crystal, and a reset input makes things very easy. The availability of the Propeller in a 40-pin DIP package is also a real plus in these days of 512 pin BGA parts. This is my first hardware design (my long-term collaborator on past projects who used to do the hardware design for me has gotten into amateur acting in a big way and no longer has time to work with me on these projects.)
Overall, I’m glad I made the switch from the ARM to the Propeller. I’d estimate I saved a few weeks of development time by making the switch. All of the initial concerns I had about the Propeller turned out to be easily worked around and the ease of code development more than made up for switching horses in mid stream. I’d recommend the Propeller to anyone developing embedded applications that require a reasonably fast processor with multiprocessing capabilities.
Comments
That's a thoroughly honest and forthright evaluation. Thanks for taking the time to post it here. I'm glad that you were able to persevere beyond your intitial impressions to see the Prop's true value revealed. Welcome to the club!
-Phil
A PhD student in my lab recently started using the propeller, with his own initiative plus some guidance (and a little code) from me (and I am no expert) he has made a system that monitors three quadrature encoders running at about 1Mhz, double buffers position information to hub ram and then writes that to an SD card. It also provides triggers to a PIV (partical imaging velocimetry) system for the cameras and laser heads. The point is that he has an aeromechanical background, has done just a little C and matlab programming and no electronics in the past. Development time was about three weeks and might have been less if parts had been more available. On other processors I think it would have been far more difficult.
And I really like propeller assembly despite self modification confusion [noparse]:)[/noparse]
Graham
Your post implies that there are no debuggers that allow breakpoints, single step, instruction trace.
ViewPort supports those and more. If you miss Visual Studio type debugging in a future project, or want to use fuzzy logic, OpenCV vision processing, or need to control/monitor your program- check it out, there's a review in my sig. Other forum members have also written debuggers and simulators...
Hanno
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Co-author of the official Propeller Guide- available at Amazon
Developer of ViewPort, the premier visual debugger for the Propeller (read the review here, thread here),
12Blocks, the block-based programming environment (thread here)
and PropScope, the multi-function USB oscilloscope/function generator/logic analyzer
but once you play with it, you see what a very easy yet powerful language it actually is!
And the lack of interrupts is one of it's many positive features, especially when it comes to generating tv or vga displays, as on other controllers, you add interrupts, and you're performance is going to drop, then you add keyboard, it's gonna drop more, but with the prop, it stays solid [noparse]:D[/noparse]
by the way, yes, I know we're biased here, but that's the reason we're here!
PS, like others have said, I'm glad you stuck to it and are now enjoying it!
Baggers.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
That is a most excellent review of the propeller.
It pretty much describes the road I followed with the Prop. After years of embedded systems, RTOSs, fighting with interrupt handlers etc. I can't count the number of times I skipped over the Propeller page in the catalog of our local distributor ELFA. Some how it just did not look "serious" enough or "big" enough.
I'm not sure now what it was that finally prompted be to order one for a trial run but I'm really glad I did. Perhaps it was the lure of easy video or perhaps it was the frustration of having built yet another failed PIC programmer.
Having made the jump it was a pleasant surprise to find such a well thought out, elegant, regular, easy to assimilate architecture. Where so many of the "right way" to do things had been thrown out resulting in something an order of magnitude easier to use. For example, no interrupts and breaking the taboo of "no self-modifying code".
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
(eventually my "old" boss will awake from his dsp stupor and shoot himself for not listening to me, partially why I no longer work there, don't ignore the suggestions of your layout engineer, especially if he is telling you that you can save THOUSANDS on part costs and pcb space)
"but its not a 400mhz processor, its only 80mhz, it can't do it..." says the boss.
LOL (perhaps thats why I am the engineer and your not), says me.
Your fired, says the boss..
Good riddance, says I.
Using the propeller as a replacement for currency isn't so far fetched.
The last sentence in my signature.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
TERMS OF USE: MIT License
"Permission is hereby granted, free of charge, to any pers...........................
..............................OMITTED FOR FORUM...............................................
.................. OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. "
The dsp/fpga king is dead, long live the prop.
Post Edited (Clock Loop) : 12/4/2009 11:41:20 PM GMT
We are all biased here and love our props. Unfortunately, it is often missed by designers, or skipped because they don't grash the prop's concepts.
BTW Did you inform Parallax about your cap problem? They would really like to know if there are any problems - a really great company
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
With the prop it does seem to be easy to make things happen, I've hooked up two 16 bit SPI DAC's, wrote some assembler and found I could generate sawtooths with ease.
What still concerns me about the prop is the lack of memory - does seem awfully tight if I start declaring buffers for processing audio blocks.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
That's one of the initial concerns I had about the Propeller. I haven't come close to the memory limit yet, but I can see how this would be an issue if you have lots of data to move around. One solution is to keep the data in the larger space of hub RAM, but that's only 32K and you incur the performance penalty of moving it to and from cog RAM. This will not be an easy issue to address in future versions of the propeller because every single bit is already used in the encoding of instructions. There's only 9 bits available for the word addresses of source and destination cog memory locations (the reason for the 512 word cog memory limit) and no free bits for expansion.
I think the coolest way to extend cog memory addressing would be to make the cogs full-blown 64-bit processors with a 64-bit instruction word. That would take care of the cog memory size limit issue once and for all, and it would make doing fixed-point math for certain types of applications even easier with the larger word size.
Also means needing a 48 bit wide HUB I guess.
rdbyte, rd, word, rdlong, rdwhat?
Has the benefit that a lot of HUB RAM is then rd/wr able with literal addresses.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Ray
@heater: a 48 bit micro...seems like an oddball size. One would think that by the time Parallax is in a position to contemplate a prop3 (or whatever they'd call it) that a 64 bit architecture would be well within reach of the uC market.
@Sal: my Propeller experience has been a lot like yours: "it just works". Re: hub RAM. The extra pins on the prop 2 should open up some breathing room to make a nice, wide bus to external memory, of which you could have many megabytes.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
There have been other machines with oddball word sizes that are not powers of two such as the Control Data machines designed by Cray, which had 60-bit words, and the Dec-10 and Dec-20, which had 36-bit words.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
-Phil
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
They found the multi-core hardware and pasm software quite interesting.
They were amazed that something costing 8 dollars and running at so slow a speed could perform
such precision real-time tasks.
It was a version of my remote terminal project rigged up to display info somewhat similar
to what is processed and displayed by modern avionics. A second prop was creating the
data that was processed by the terminal.....took only 2 days to create and seemed to make a good impression.
I don't think they ever saw anyone bring in a live demo to an interview before.
Doing something useful for little money always makes for a good show
The prop is much more than a toy!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"Where am I? Where am I going? Why am I in a handbasket?"
Did you get offered the job?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Please keep us up to date on your job acquisition progress. It would be totally cool if a Propeller project helped you land a job that you want!
-Phil
Heh, I've used my little 1lb battle bot the same way and it's just radio control [noparse]:D[/noparse]. ( www.youtube.com/watch?v=gG3g8EQPldw mine's the one with the jaws and cool dance moves) Because it's an odd shape it just *happens* to live on top of my bag and I can't get to anything in my bag until it's put on a table nearby.
Lawson
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Lunch cures all problems! have you had lunch?
I was hooked. I now have chips and boards scattered all over the place. One setup as a new home thermostat with features my old stat was lacking and I hope to have that in a case and on the wall in a few months. My next idea comes as I study CNC control for the new X2 Mill I have ordered. I got to looking at some of the stepper driver chips out there and the driver circuits built on them. Many are based on PICs to provide the basic logic translation to drive the steppers and perform micro-stepping and they are pretty used up in that role. I was thinking it would be fairly easy to design a driver board to run all three of the mill axises with a prop and have some brain left over to also implement some manor of manual power drive with digital readout based on the steps manually executed. Doing that with a conventional controller is probably out of my depth but the prop really makes some things easy to do. Anyway, I have really enjoyed working with it.
I do miss the capabilities that the other chips can have built in. An ADC on-board would have gone a long-long way to making things even easier but everything is a compromise in some area. Any time I think of getting into the PICs I realize I'm OK with the trade-offs that the Prop involves. It really is a gem I think.
Can't wait to see what the PropII has in store!
Long live the Prop!
MacGeek
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
BS2: $49
SX48 Protoboard: $10
Propeller Protoboard: Priceless
www.apple.com
www.parallax.com
www.goldmine-elec.com
www.expresspcb.com
www.jameco.com
Yes, I was offered the job.
Seems they need people who have practiced the strange art of intercepting a stream of data
and then modifying it and sending it on its way again...in real time. That is mostly what I have
been coding. That is what my demo did. It intercepted a data stream from the 2nd prop board
and then made swift modifications to it and injected it back for 3 other cores to work with. The
remote term just displayed what was happening to the data. The fake data was a simulation of
tracking data from an IR system following a target. The modification of the data was an attempt to
add filtering to improve accuracy. This sort of thing lets you modify how a system works when you
don't have full access to the hard and software.
I am thinking it over, it's a big move...and involves Israeli citizenship and friends and family are
worried I would be in a sort of war zone.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"Where am I? Where am I going? Why am I in a handbasket?"
I understand your families and friends concerns. Our daughter is living/teaching in Singapore, but that is safe. We see her regularly and talk on skype.
Unfortunately, it is a decision you must make. I wish you the best in making the right decision, whatever that may be.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm