Hackaday 10th Anniversary: Jon McPhalen And The Propeller

[Jon] came out to our 10th anniversary mini-con to talk about the Propeller, and judging from his short introduction, his hacker cred is through the roof. He has a page on IMDb, and his first computer was a COSMAC. Around 1993, he heard of a small company introducing the BASIC Stamp, and like us with most new technology was incredulous this device could perform as advertised. He tried it, though, and for a few years after that, he was programming the BASIC Stamp every single day.

Having a lot of blinky light project under his belt, [Jon] was always struggling with interrupts, figuring out a way to blink an LED exactly when he wanted it to blink. A lot has changed over at Parallax since 1993, and now they’re spending time with the Propeller, an 8-core microcontroller where interrupts are a thing of the past. He showed off a huge, 10-foot tall bear from League of Legends, all controlled with a single Propeller, using 1000 LEDs to look like fire and flames.

[Jon] shared the architecture of the Propeller, and the inside of this tiny plastic-encapsulated piece of silicon is wild; it’s eight 32-bit microcontrollers, all sharing some ROM and RAM, controlled by something called a Cog that gives each micro access to the address, data, and IO pins.

When the Propeller was first released, there were a few questions of how the chip would be programmed. C isn’t great for multicore work, so Parallax came up with a language called Spin. It’s written for multicore microcontrollers, and from [Jon]’s little session in demo hell, it’s not that much harder to pick up than Python. Remember that hour or two where you learned the syntax of Python? Yeah, learning Spin isn’t a huge time investment.

Even though you can program the Propeller in C and C++, there’s a reason for Spin being the official language of the Propeller. It isn’t even that hard, and if you want to dip your toes in multicore microcontroller programming, the Propeller is the way to do it. It’s an open source chip as well so you can give it a try with an FPGA board.

62 thoughts on “Hackaday 10th Anniversary: Jon McPhalen And The Propeller

  1. I was never a huge fan of Parallax back in the day. The Basic Stamp was competent but always struck me as too expensive for what it did. Which is probably why I gravitated towards ARM chips when I started to get into electronics. The difference in price was just something that I couldn’t ignore. I want to say I recall basic stamps weighing in at around somewhere between $30-50+ where as an ARM chip weighed in somewhere between $2-5+. All the Arduino really did was simplify things by baking in a bootloader which cut the cost of entry even further by letting people skip building or buying a dedicated programmer.

    That said I remember the day I heard about the Propeller, my first thought was something along the lines of “Parralax, whelp this is going to be needlessly expensive” loaded up the page and was pleasantly surprised that it was both a really interesting design and very reasonably priced. If memory serves I ordered two that very day :)

  2. Wow scuffles, you got farther than I did….. The day I first heard about the Propeller, I said to myself: “Oh great, some more overpriced crap from Parallax” and I didn’t even bother looking it up or thinking about it again until today when I read this article.

    It seems that one of the key ideas is to forego the normal process of “interrupting” the program code execution while servicing an interrupt by instead using one of several separate cores to handle the “interrupt” code….. This allows the ‘normal’ program execution to continue undisturbed while handling timing and interrupt execution in a MUCH more discrete and predictable fashion.

    I like the idea, and it’s obvious how this kind of hardware structure could be extremely useful for many kinds of application.

    I found this to be an interesting and appropriate Hackaday article and I enjoyed it much more than the usual kid-3D-prints-an-arduino stories that flood the site lately.

    1. It would have been nicer if the interrupt feature was optional. Now, when the peripheral core is done with handling the ‘interrupt’, it has no good way to inform the other cores.

      1. One can always use a cog (processor) to handle the “interrupt” condition. That cog can inform the other (if required) by writing to a shared RAM location in the hub.

        Again, I’m not advocating against interrupts, but they can be very hard on newcomers and this was something Chip wanted to avoid. I think the Propeller is a great tool for one’s diverse kit.

        1. Sure you can write in RAM, but that means the other cogs need to poll the RAM to figure out that there was an interrupt. And if you have any concern for confusion by newcomers, then the easy solution would be to start the chip with all interrupts disabled, not to remove the entire interrupt system.

          1. We don’t need to interrupt ANYTHING. For example, the cog handling serial I/O does that ONLY. Each time a character comes in, the cog stuffs it into the buffer. The cog wanting that character just goes to the buffer, and the next character is always there. The cog that wants to send something out just writes to the out buffer, and that serial I/O cog makes sure it goes out. This makes the prop deterministic to the speed of the clock, I.e. we can handle events down to 12.5 ns.

            It is difficult if not impossible to achieve these result on an interrupt driven system of the same clock speed.

          2. If all you need is unattended memory transfer, DMA works well too. Pretty much most of the ARM Cortex M4 and (?) M3 has it. A little less deterministic because it has to arbitrate for RAM, but close enough for most stuff. The fancy ones can do circular buffers (modulus the address) and works with on chip peripherals. There is also DMA chaining and scatter load. Not much processing they can do though. Sometime you get CRC or encryption engine on higher models. Wish there were an ALU peripheral to work with DMA.

            Once you removed the bottleneck, the rest isn’t too difficult to do. Not that the serial port (or even SPI) is going to chock an ARM chip. With the huge memory FLASH and RAM, you can tackle much larger projects.

          3. @prof braino: instead of only thinking about UARTs, take for example a controller for a switch mode power supply. You have a cog that does PWM, and you have a central controller, and you have a cog that measure voltage, a cog that measures current, and a cog that checks failure conditions. Now, when the failure condition happens, you may want to shut down the PWM right away. Here is where an interrupt would be very useful. Without an interrupt, the PWM cog has to continuously check the shared memory for a status update from the fail-control cog, which takes precious time away from its job to make a precise waveform.

          4. @trui, the outputs of cogs are logically ORed. If a failure is detected, the failure cog sets the PWM pin permanently high, PWM cog has no effect until the failure is addressed.

            I’d be more interested in how to break out of bad code that ends up in an infinite loop. Reset button, perhaps? I think I’ll head to their website & do some research.

          5. @Alan: yes, that will take care of simple on/off things, but maybe you don’t want to shut down the PWM mid-cycle, but instead just reduce the output by a bit. My point is that adding interrupt capability would have been fairly cheap in the sense of the amount of logic required, and that it would only add to the capabilities.

          6. Actually, if you would be familiar with Propeller programming, it would all make a lot more sense. Adding interrupt handling would not be easy because there is no stack. There also aren’t any registers in the normal sense, basically all 512 memory locations are registers and that’s how the Propeller GCC sees them too.

            If you think about it, interrupts can be regarded as a compromise: they are used in situations where a CPU needs to do multiple things at once. A “normal” processor interrupts its normal work to switch context and handle the interrupt, then continues where it left off. Then when the main task needs the information gathered during the interrupt service routine, it gets it from a shared memory location.

            On the Propeller, you have 8 cogs, and even for simple tasks it’s easy enough to just dedicate one cog to poll for unexpected input and not do anything else (unlike processors such as the x86, it’s not going to catch fire running around in circles). The “main program cog” can just do its work and get the data from the input cog whenever it needs it.

            It takes a bit of getting used to, but it really works great and it makes many issues that are normally involved with multi-tasking programming simply go away: Timing is always deterministic and cogs can be synchronized fairly easily. One example that Jon mentioned is a VGA driver that uses two cogs that are exactly in sync; one reads the data for a scan line from the hub while the other puts the data on the VGA output. During the next scan line, the roles are reversed. This fixes the problem that reading and writing to and from the hub is much slower than reading and writing from the cog, but cogs can’t reach each other’s memory areas, they have to communicate through the hub.

          7. The Propeller can do subroutine calls. It would be simple to upgrade the same mechanism to support interrupts as well.

            And your argument that you can dedicate one of the cogs to handle ‘interrupts’ ignores my objections I’ve stated earlier in the thread, namely that you often want to notify other parts of the system (like a central controller) of the interrupt condition. Without interrupts, you would have to resort to polling.

          8. You can probably modify the state variable that control the duty cycle in the PWM cog in the share memory. It is a mess, but that’s one way of doing it. Not sure if Propeller has any ADC. Probably need to make a sigma-delta converter with a cog again.

            Propeller are like the old PIC16C series. No peripherals, nor interrupts either. I think that’s the path I would go if I want non-standard peripherals, I would pick PSoC. It has programmable logic and additional hard cells ALU and other stuff to implement peripherals.

            Not a fan of doing power supplies in regular uC when I can get analog chips that do a couple of MHz PWM switching frequency with linear feedback loops. Analog PWM doesn’t suffer the trade offs between frequency vs resolution that a digital PWM has. You can pick higher frequency or higher resolution, but not both at the same time. (Analog PWM doesn’t have that limit and has much higher analog bandwidth than your ADC too) What you ended up is a power supply that have high ripples and/or huge inductors & caps to compensate for the low switching frequency and slow transient respond. Also analog PWM chip either have build-in power stage or proper MOSFET drivers. Can’t really drive a power MOSFET with huge gate capacitance with the puny 20mA uC driver at high switching frequency without lowering power supply efficiency or burning the driver out.

      2. The thing about the Propeller is you have to change the way you think and code. Although I haven’t tried a Prop yet, I know three ways to accomplish a cross-core “interrupt” on it, only the first of which has been mentioned so far:

        1) Polling an address in shared memory.
        2) A core can be disabled, and enabled by another core.
        3) Self modifying code. If a core is executing code from main memory, that code can be changed at any time, by any core. So if that core is executing a loop, instead of adding an explicit poll in the loop like in #1, you could have another core alter an instruction in the loop to jump to the address of your “interrupt” service routine – which puts back the original instruction and resumes when it’s done. Typically the modified instruction would be an existing jump that is frequently executed, but you could get fancy; pause the core and modify the very next instruction if you prefer.

        I’d say there’s plenty of options available to make interrupts completely unnecessary.

        I have a PIC project which takes more than a few cues from the Propeller. It has a multiple core simulation engine, for the purpose of providing virtual peripherals. The engine runs pseudocode, much like the Prop runs SPIN. It runs as the highest level interrupt, co-existing with traditional code. While it can’t offer true parallel execution or deterministic timing like the Prop, it comes close enough in many cases. For example, I recently did a stress test running 4x virtual PWMs simultaneously at 40,009, 30,011, 19,997, and 10,007 hz. It’s a particularly nasty test due to how those prime number frequencies shift timings in relation to each other, yet the maximum signal jitter is a reasonable 4us. The pseudocode interpreter needs to be *tight* to perform this well, every cycle I can shave off helps, and it’s sometimes more efficient to modify the pseudocode on the fly (technique #3) when it means I can skip a repeated comparison or conditional jump in the native code. Knowing how a Prop works can help even if you’re not using a Prop. ;)

        1. Two more communication methods.

          4) locks. The Hub has 8 hardware locks that can be used to communicate as well.

          5) Spare IO pins. Since all cores have equal access to the IO pins, spare pins can be used as inter process flags as well.

          Really though “1) shared ram” is what I use most of the time. I usually write out a time stamp once a core has finished updating it’s output data. It’s then easy for multiple cores to read the data and stay in sync.

      1. Hmm I’ll have to check out my local shack next time in town, Which will mean I will have visited twice in one year, a new record high but seeing as last time they didn’t have any CdS cells I’m not going to hold out much hope :P

    1. Cores call kill each other, much as Linux process run as the same user can. For mission critical applications, a core programmed as an advanced watchdog timer can kill and restart other cores, or the entire processor, if they are not properly performing their functions.

    1. For me it really comes down to how threadable you can make the app. A very large number of embedded apps only really need a single threaded while loop to drive the system. But if you want the reconfigurability, or need the tasking then it becomes invaluable.

      I would also suggest people take a look at the XMOS processors. Very similar to the propeller in terms of having multiple core and soft peripherals. However XMOS (depending on the chip you are using) can access more memory, and can have more than just 8 cores.

      You can develop for XMOS in C and C++ but they also have their own language called XC which makes parallelizing your code easier. Short of having an Occam compiler the XMOS feels a lot like the transputer… and it should since it shares an architect ;)

      1. I don’t think there’s that much difference with a regular CPU running an RTOS. The real difference is that the propeller has “soft” peripherals, and the microcontroller has hard peripherals. For most typical cases, the hard peripherals work just as well, or better, and big microcontrollers have typically more peripherals than the propeller has cogs. For a few cases where you want something new, with accurate timing, the propeller works better.

        1. Well the differences are that there are a lot of choices on ARM too.

          But I think in that case i’d use, and do use. the Cypress PSOC. Their tools are really good. The chips are great, and they’re cheap as , well chips. They’re $1 in one’s at the moment, and $4 for the dev kits.

          I’ve got the XMOS stuff too, but never really got into it, they’re interesting for sure.

          Unfortunately i just don’t see anything unique or enticing enough to try it outside defcon.

  3. I used it for my electric skateboard. One cog to handle the serial IO, one cog to handle driving the motor, one cog to handle the deadman and other safety features, once cog to handle display and output. I think it’s great, esp. after I got away from Spin and could code in C again. Timers were always a crutch to fake multiple processes. Now I don’t have to do that. All I do is have each cog feed or read from a global variable.

  4. I often put a Propeller on my ARM project boards. I also sometimes combine it with an AVR. You still end up with an inexpensive project and you get so much out of the Prop. I use it often to handle precision timing, VGA output and audio output.

    You can think of the Prop as a cheap Video/audio chip that is easily added to most any project. I have one in a small case that has a VGA cable on one side and inputs for I2C. one-wire and serial on the other…. I use it with small AVR projects for debugging. It’s nice to be able to get video out on a measly Tiny85.

  5. I think the Propeller is a brilliant chip, I just wish there were more SKUs of it. The problem now is that you are effectively limited to either a DIP component or a QFP component of a single fixed size.

    There aren’t units with fewer cogs and/or pins. There aren’t units with more cogs and/or pins. There aren’t cheaper units, there aren’t more expensive units. There aren’t [insert any variation you might like]

    Now we can hope that now that the Propeller is Open Source someone else might make these variations, but that has yet to happen as far as I know.

    I have wanted to use the Propeller on a couple of projects, but it was impossible to justify the cost when I could get AVR, Pic, or ARM cores that were powerful enough for much less.

  6. I think a lot of people underestimate how easy this chip is to work with. I find Spin to be one of the easiest HLLs to wrap your head around (including, IMO, BASIC while being substantially more capable), and besides for a few traps and getting to grips with self-modifying code, the Propeller’s assembly language is very simple while being powerful. That said, there’s a bunch of other languages that this device supports as well.

    For makers who want to whip up projects (and aren’t concerned with using the cheapest uC possible) the flexibility of having soft peripherals can’t be understated. How often do you have to purchase yet another dev board that has all the peripherals you need for a given project because the pile you already have is unsuitable? With the propeller, you can implement exactly what you need deterministically in software (with many of the functions you’ll need such as VGA, SPI, I2C, etc. etc. already written and available online from the Parallax Object Exchange) and reconfigure it from project to project. You’ll be hard pressed to find another chip that can do that for the price and ease of use.

  7. I just wish parallax would market it differently and remove the stupid nerd cap with a lame propeller on top… It is so stupid and gives the impression that it is only intended to nerd apprentices and toy applications and not for something more serious and powerful. Bad marketing…

  8. I had zero interest in trying a propeller until I got one with my defcon badge. It was a ton of fun to program. I am really impressed with how easy they made getting the cores up and running and running independently or cooperatively.

  9. Hello Jon, and you too David. I must say this is a well written article concerning the amazing device that the Propeller happens to be. I’m still trying to find the right idea to make my Prop projects, ah, take flight. Most of them are grounded…… Every time I visit a Micro Center and see people studying all of them I try to steer them towards the Prop or the Basic Stamp. One pair, (father and son) were thinking of buying that Ard**** device, I suggested the Prop explaining that it was easier to program. It worked.

  10. Great video. Usually I skip videos because they force upon me the “reading pace”, a thing I hate.

    But I really enjoyed this one — and it got me interested in this unusual architecture.

    A nit: Indentation wasn’t first in Python. Occam (another unusual programming language for an unusual processor architecture, the Transputer) was earlier, afaik. Credit where credit is due.

      1. Hi, Jon

        thanks for your reply. I didn’t imply that you implied… uh. You get the idea.

        Still, I thought the parallel to Occam/Transputer is interesing, since that architecture was way ahead of its time, back then.

        — tomás

      1. My COBOL is quite rusty (yes, I’m *that* old), but AFAIR indentation wasn’t relevant in the sense it is on Occam or Python.

        There were just some columns (the first 8? 12?) with a special meaning (more or less like FORTRAN). A tribute due to the punched card.

        Whithin the “normal” area you could indent at will.

        Still, take this with a fist of salt.

  11. The thing that soured me on Parallax and the Basic Stamp (mainly the 2e, because that was my first foray into microcontrollers) was the proprietary nature of the system, which ended up biting me.

    I use Linux almost exclusively here at home (actually, it’s more or less exclusively, unless I have something unique – recently, to test and setup a SICK LMS-291 I bought off Ebay, I needed to set up an NT4 system for the test suite of software SICK provides – fun), and have done so for more than a decade now. So back then I needed a way to develop for the Basic Stamp 2e (BS2e) using Linux.

    Parallax at the time had a compiler written for Linux, for their Basic Stamp line which worked well; I got it set up, compiled some simple programs – got my LEDs to blink. But not too long after that, I ran into a large wall…

    Basically what happened is that I needed to do a “forced upgrade” of my workstation because the motherboard died. I decided at the time that I would jump into the 64-bit world at the same time – so I set up my whole Linux system with a 64-bit kernel, etc – everything was working great, until I got to the Basic Stamp portion of things.

    That’s when I found out some interesting news: Parallax’s Stamp compiler for Linux was statically linked against other 32-bit libraries. This meant that it was impossible to use the IA32 wrappers (or anything else) to allow you to use the compiler on a 64-bit system. To add insult to injury, Parallax confirmed this, then after some conversation I found that they had lost track of the original programmer of the compiler, and that they didn’t have any of the source code to it, either (so that I could compile it myself). I was basically dead in the water, unless I wanted to go back to a 32-bit system.

    This ultimately made me jump to the Arduino due to it’s open-source nature of the IDE and use of gcc for compiling. I basically dumped Parallax at that point. It just seemed to me that they didn’t really care to support (or at the minimum help those who could support) open-source software development for their products. I didn’t want to be “stuck” again with hardware I couldn’t make full use of.

    That said, today it’s a different game. Parallax seems to have seen the light of open-source, or at least they aren’t as stuffy about it, as there exists tools for Propeller development using gcc, and binary tools by third-parties for Spin under Linux (which kinda irks me – that basically says that in some manner there is third-party support and/or some kind of description of how to implement a Spin compiler available, but it still remains proprietary or something – so in theory if you use those tools, you might find yourself “stuck” again – ugh). I have also found resources for the Basic Stamp under Linux since that time that are more “open” in nature (but I haven’t tried them). Finally, there’s always the option today to run a 32-bit environment under a VM or similar.

    I’m just of a more cautionary nature today, having been bitten too many times in the past by proprietary solutions for which support has been pulled out from under me, simply because I either chose to upgrade, or because I chose to stay with an old platform and the vendor chose not to support it anymore (or worse, went out of business).

    1. > Parallax seems to have seen the light of open-source

      Going by the Wikipedia page, Parallax has gone as far as very few in this direction because they’ve released Verilog and VHDL files for the Propeller P8X32A under the Gnu GPL. This puts them on the ranks of OpenRISC and RISC-V, which is pretty cool.

    2. Parallax is a VERY small company (smaller than you think) and just didn’t have the resources in the past to do cross-platform tools, even with a lot of us crowing about it (I did when I was an employee there). Nothing stays the same. Parallax has come to the table because they’ve found a way to partner with resources that they can work with and count on — this is critical for them being able to support what they provide, even when it’s open source.

      You can program the Propeller in Spin on Windows, Mac, or Linux with PropellerIDE. It’s new, but coming together nicely. Or you can use C/C++ on those OSes (it comes from the same dev team. Want Forth? No problem, there are a couple versions available (Tachyon seems to be getting the most attention, though I think PropForth is closest to ANSI). There’s PropBASIC, too, but I think it’s only a Windows tool that runs via SimpleIDE. The point is you have choices with the Propeller.

      The past is just that: the past. Open source is common place now and you can expect more in that regard from Parallax.

      Now… let’s see if Atmel steps up and releases a Verilog image of the ATMEGA328. :)

      1. Jon

        Why should Amtel open source their AVR series? They are making money off them as opposed to Parallax who has no real design wins of note for the Propeller even after 8 years.

        Parallax used to have game so to speak. Now they are running behind and on their name. Their offerings are ancient and overpriced like the BS1 & BS2 lines and their competition – namely the Arduino along with it’s variants is making large inroads among hobbyists and makers. I don’t know what to make of a company that has refused to update it’s product lines to stay competitive.

  12. I’ve found these comments interesting, I was unaware of the “cogs” architecture in the Propeller, and how it can multithread or run multiple processes, or run without interrupts.
    I also learned about the XMOS startKIT, and about Parallax going with Open Source.
    I do know that the Parallax board that I bought at RadioShack didn’t seem to work when I hooked it up (according to the directions).

  13. The Propeller chips comes in ONE variant (other than 3 package types: DIP 40, QFP 44, QFN 44).
    With that one chip family, you can have as many basic peripherals as you have IO pins (32). All the peripherals are soft and consume a cog(s) (where a cog is a 32bit processor core).
    You can take a pre-canned software object and add it to your project for a specific peripheral(s).

    So, you can have 16 UARTS (just TX & RX pairs) with big buffers. There are objects for 1 UART in a cog/core and another with 4xUARTs in a cog/core. So you can have 16 UARTs all active together at say 115,200 baud utilising 4 cores. You now have 4 cores left to do whatever processing you require with those 16 UARTs. And, they can be on any of the 32 IO pins.
    Now take the same chip (not another one from the PIC, AVR, etc family of chips) and instead have 8x UARTs (16 IO) and 8x I2C buses (16 IO).
    Same chip again, 4x UARTs (8 IO), 4x I2C (8 IO), 1x SPI bus with 5x CS (8 IO), 1x VGA (8 IO), 1x PS2 Keyboard (2 IO but I have done it with 1 IO).
    Same chip again, 1x VGA (8 IO), 1x TV (composite video NTSC/PAL with color) (3 IO), 2x PS2 (keyboard and mouse) (4 IO), 1x SPI (SD Card) (4 IO), 1x I2C (2 IO), 1x UART (2IO), and still have 9x IO pins remaining.

    The soft peripherals are not just plain old peripherals… Take the humble old UART for example. The software object that lives in it’s own cog/core drives the IO pins and places any characters received into a common/hub RAM buffer and increments a pointer in common/hub RAM. The user cog/core has it’s own cog/core pointer which it increments when it takes a character from the buffer. The buffer can almost be any size (we often use a power of 2 because its simpler), and it’s a cyclic buffer acting as a FIFO. The same buffer concept is used (in reverse) for transmitting characters. The users program just puts characters into the tx buffer and increments a pointer. There are no interrupts to deal with. When the user program is ready with nothing of higher priority, it polls the pointers. There is no UART registers for the user to deal with. If you want to run a complex protocol on the UART, the peripheral cog/core can handle this outside the normal program. The same applies to RTS/CTS for stalling transmission if required.

    There are all sorts of objects available, including objects to interface to SD Cards with FAT16/32 support. There are drivers for various LCD panels, various I2C and SPI chips such as RTC (clock chips).

    There are 8 cogs (32bit processor cores), each with it’s own 2KB dedicated RAM for registers and program space. Each runs at 80MHz with instructions taking 4 clocks (a few exceptions) gives 8x 20 MIP 32-bit CPUs. I regularly overclock to 104MHz !!! 96MHz and 100MHz are fairly common also. Each cog/core has access to hub/common 32KB of RAM and 32KB of pre-coded ROM (SIN, LOG, FONT tables plus boot and spin interpreter code).

    I have just taken a few simple examples here to outline some of the Propellers features.

  14. Here is an example Retro Computer project done on the Propeller…

    There are two Z80 emulations written for the Propeller. One is called ZiCog and is written by heater. With these we can run CPM2.2, with up to 8x 8MB HDDs emulated on an SD Card. I have written a Propeller OS (derived from other’s work too) that will launch the Z80 & CPM2.2. It runs most CPM programs including MSBASIC, editors, compilers, games, etc, etc.

    I run this on my hardware design called a RamBlade which has 512KB of SRAM and a microSD card connected to the Propeller Chip and runs at 104MHz. This is approximately equivalent to the old Z80 at 4MHz.

    Others have successfully run other emulations such as 6502. Some use the Propeller to interface to real legacy chips such as the Z80 (Dr_Acula, N8VEM, and others) and the 6502 (Vince Briel). The Propeller chip is used for data/address bus decoding and ROM emulation, peripherals, etc.

    The Propeller chip is extremely versatile. And we only need ONE chip in our parts bin.

    Note: The Propeller P8X32A (affectionately known as the prop on the forum) is 3V3 (same as the Raspberry Pi).
    Program code can be downloaded from a PC via USB-to-serial (PropPlug or equivalent) to the prop, and then run. It is not necessary to program an EEPROM to test code, so its faster to develop code.
    Unfortunately the prop requires an external 32KB EEPROM to store final code. Usually 64KB is fitted, although we rarely use the extra 32KB. In my PropOS, the EEPROM just stores boot code to the FAT16/32 SD Card based OS, so code can be copied to the SD card instead.

    I hope this demonstrates some further uses of the versatile prop.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.