Antedeluvian - I'm sorry to hear that your SX device experience kept you from seriously exploring the Propeller. The Propeller didn't borrow anything from SX- it's a completely different design where we set out to solve a lot of the problems we had experienced with various other microcontrollers; the main one being the inability to easily make a real-time system.
The Propeller has multiple cores specifically to support real-time needs; in fact, it's cores remove the need for interrupts and interrupt service routines all-together, since they parasitically drain processing time from an application's main code and make development more difficult. With the simple use of a core and the WAITxx instructions, the Propeller makes for a system that can easily perform a specific task at a timed interval, or in response to an asynchronous event, while essentially sleeping in-between; all deterministically timed. No jitter. It's the kind of platform that really makes the concept of virtual peripherals fly.
Need to generate PWM? Write the code and launch it into a core. Need two independent PWM's? Launch the same code into two cores with different parameters. Simple. Their timing doesn't interfere with each other, and you still have 6 other cores to do other simple or sophisticated high-speed or low-speed tasks completely independent of the others, but always with the ability to coordinate and collaborate in-system as needed.
The Propeller doesn't carry the baggage of the SX with it; it's truly a very different device that's worth looking at for its own merits. The flexibility it brings to the table makes it fun to work with and building sophisticated real-time systems becomes quite easy.
Antedeluvian - My next post on this will cover the hardware in use. I'm pretty intrigued by the concept, and it was a lot easier to get some simple code up and running in their simulator than I had expected.
One of the set of questions I have relates to fully utilizing the cores: If I have PWM on one core, an I2C on another, and sensor input on the other cores, where would it be most approproiate to put the computational code?
Can I split it between cores and still be able to manage the whole thing with peripheral performance? Will I need to dedicate one core to all of the computation?
Those are a couple of the questions I'm planning on answering.
I am interested in your opinion and how you make out. Years ago I worked with the Scenix SX28. Later they became Ubicom and Parallax was the source. It was an early Microchip 8 bit architecture and RISC based. The only peripheral it had was an 8 bit counter that incrmeneted with every instruction executed. The idea was that it was so fast (50MHz or even 100MHz) that you could implement every peripheral you wanted as software. I built a remote data acquisition system with the one device generating and receiving a Bell 202 modem signal as a PWM along with some external components to "analogise" the signals.
At the start I was sold on the concept, but by the end I was thoroughly disillusioned and never used it again, not least because of the instruction set which I have never managed to feel comfortable with (it is the same as the Microchip 16C series).
It seems to me that the Propellor borrowed much of the Scenix device and implemented it with several cores, but my scenix experience prevented me from going that direction, even to experiment.
Sounds much simpler that the device you are using, although there must be a point where you have to figure out how to integrate everything you have partitioned out.
Drones are, in essence, flying autonomous vehicles. Pros and cons surrounding drones today might well foreshadow the debate over the development of self-driving cars. In the context of a strongly regulated aviation industry, "self-flying" drones pose a fresh challenge. How safe is it to fly drones in different environments? Should drones be required for visual line of sight – as are piloted airplanes? Join EE Times' Junko Yoshida as she moderates a panel of drone experts.