Slightly off-topic, but I think we need to keep the concept of "parallel processing" separate from the concept of "multitasking".
The propeller has parallel processing baked into the chip (and at an unusually high and easily accessible level), but not multitasking.
There are basically two types of multitasking - preemptive and cooperative. And "real" multitasking (i.e. preemptive) requires time slicing. Without time slicing, the Propeller is either limited to just 8 parallel "tasks", or would have to use cooperative multitasking (with its attendant problems).
Of course, the great thing about the Propeller is that because it fully implements parallel processing, it can do both, either, or neither of these types of multitasking with equal facility, and at the same time. And they all have their place.
I think the full potential of using the Propeller - both the P1 and the P2 - as an education platform for exploring parallel processing has not yet been fully realized. We all seem to spend too much time trying to emulate other processors that are bigger, faster and better at other tasks, and lose sight of what the Propeller is best at!
We all seem to spend too much time trying to emulate other processors that are bigger, faster and better at other tasks, and lose sight of what the Propeller is best at!
Ross.
Probably because the Propeller processors are much better at this kind of thing than us humans are.
You could use a timer interrupt to preemptively multitask. Some care would have to taken around the FIFO and streamer, though, unless they were being used by only one task.
You could use a timer interrupt to preemptively multitask. Some care would have to taken around the FIFO and streamer, though, unless they were being used by only one task.
That's what I do on the P2 (on the P1 I count instructions).
I will have to add a note of caution about using the streamer and FIFO - thanks!
I see no need to try to restrict the possible P2 market by limiting memory expansion options early and I'm certainly going to continue doing what I'm doing. The P2 can still shine in multiple areas and there is nothing here stopping it from doing so.
I never meant to stop anybody from doing anything. I'm just a bit worried about the right marketing strategy. I remeber the downfall of the Commodore Amiga which was IMHO a consequence of marketing failure. The Amiga was widely known only as gaming platform. I have used it for machine control because it had a powerful real-time multitasking OS. It has instant reaction and guaranteed response time while on Windows or Linux you sometimes have to wait for 10s until something happens after you clicked a button. But nobody noticed because it was never advertised. The PC catched up with graphics and gamers abandonned the Amiga. This wouldn't have happened (or not as early) if it was used for more serious applications.
Playing videos on the P2 is a nice demontration of what can be done if you want to. But it's not the main strength of the P2.
For education there might even be a market for standalone "PC replacement" computers based on the P2. But there's also the risk that the audience gets this in the wrong throat and sees the P2 meant as "retro emulator" chip.
(and BTW, sorry about the confusion of "multitasking" vs. "parallel processing". For me it's often difficult to find the right words)
The new nvidia Jetson nano for $59 may have just killed any standalone PC replacement opportunity for the P2. That is if it isn’t already taken by R-Pi. It’s going to be hard to compete with these two.
The nano offers a 64bit quad core ARM A57 @ 1.47GHz, a 128 core nvidia Maxwell GPU, and 2GB DRAM, Wifi (via USB dongle included in some markets), USB, HDMI, Ethernet, etc. it supports real python programming as well as most everything else. There are robot kits, CSI camera port for AI, and lots of existing open sourced software. Scores 8x to 73x RPi4. And there is a 40pin GPIO connector (RPi compatible???). Runs Ubuntu.
I still think there’s a self hosting micro market that doesn’t have a bloated OS. Programming simple things with the multi core P2 still has plenty to offer.
I thought the initial idea was to replace PC with a P2 based development system just for the P2 native development and not general computing. In that sense nvidia jetson or any other OS based SBC is irrelevant. Am I wrong with this initial assumption ?
I thought the initial idea was to replace PC with a P2 based development system just for the P2 native development and not general computing. In that sense nvidia jetson or any other OS based SBC is irrelevant. Am I wrong with this initial assumption ?
I don't really understand the desire to have a P2 native development system. It seems about as sensible as saying you want an FPGA development system ... but it must run on an FPGA
We've stolen this thread, apparently.
Let's continue there. In case of the P2 I think it's feasible and cost effective. Not so much (if at all) with the FPGA so I understand your point. It was just an idea of Peter, which I like.
I did not intend to discourage any dev with my comment. Personally, I will use extra RAM in the future. By all means build it, and they will come, in my opinion.
What I did intend was to point out where anyone finds it can make sense to develop lean and mean objects, that's also a good thing. The more of that we have, the less important the extra RAM question is, also IMHO.
A prime example would be USB keyboard / mouse vs PS2. The former is current and desirable. The latter takes very little RAM, and is an adapter away from being very usable.
Bringing some of the good P1 stuff forward should also further marginalize the question.
A prime example would be USB keyboard / mouse vs PS2. The former is current and desirable. The latter takes very little RAM, and is an adapter away from being very usable.
Yeah, PS/2 is kinda more desirable from a programmer's point of view - on P2 you could reasonably run the entire PS/2 driver interrupt driven in another cog, consuming literally 0 cycles when there's no key being pressed. PS/2 also supports infinite rollover as opposed to 6 + modifiers rollover on USB boot protocol, but most keyboards are too crappy to be able to decode that many keys in the first place, so oh well.
I myself like the p2 for what I does without any additional hardware.
If I need more video,ram,sound,usb,whatever i will get a chip that does it.
But the p2 offers me a simple way to have real parallel processing without an os that gets in my way.
Real smart pins that have no annoying northbrige usb whatever timing restrictions
Real flat 512 kB of ram to work with, like sram.
I see the problem in not having a good Hal or call it kernel for this. So if the community develops anything it will exist in thin air.
It seems as if the p2 does everything, but nothing is written down. Hyperram is on heck of an interesting thing, but als long as we do not have some memory mapping component for p2 it will only be ingesting for very special needs.
I have developed digital video hardware some decades ago, clearly having high res high Color hdmi video will be nice, but als long I do not have some gpu like acceleration it will only be good as framebuffer. I see no application that needs only still picture output.
I need more like a vga or svga output to give out parameters fast
Please forgive my bad English, it is not my first language and my iPad insists on writing some words wierd
...Where are the robots? These little wheelie things that run around on the floor? How are these even considered robots?
Here we have an absolute killer of an industrial controller and only a handful of us seem to recognise this.
Powerful words. I'm still trying to absorb the weight they carry.
Well, the wheeled devices are regarded as AGVs (automatic guided vehicles) whereas robots do material-handling, welding, paint spraying, etc.
Education should involve forward/inverse kinematics and closed-loop servo theory and this is what could set Parallax apart from the crowd.
As I have stated many times; Chip has unwittingly created, potentially the most powerful motion-control device, ever.
One possible application for P2 and external RAM: audio synth with samples involved.
The P2 has (1) ADCs -audio input (2) DACs - audio output (3) DSP power (4) easy to implement MIDI in/out (5) vga/hdmi to visualise things
but then 512 kB RAM is too few for samples.
I thought of adding a Pi Zero (bare metal initialized) to P2 via its GPIO as a... 0.5 GB of aditional RAM
Now I am waiting for a P2 board to experiment with, but I can still try connect a Pi Zero to P1 and check if the idea works (=how fast can a Pi deliver bytes using a hyperram-like protocol).
In the demos supplied with my P2 HyperRAM driver I have a very simple example where it plays audio from a buffer read from external memory. But you could just as easily play from HUB and just copy/mix samples there from HyperRAM/HyperFlash too. Lots of ways to use it.
In very high performance applications with video streamed in parallel to multi-channel audio the HyperRAM latency may begin to become an issue if you are reading individual samples one at a time. But if you can transfer more than one audio sample at a time it helps solve that type of problem. Rule of thumb @250MHz is HyperRAM access latency is in the order of ~1us per read. But you can transfer at 250MB/s using sysclk/1.
The way I'd attempt it would be use a concurrent cog for mixing waveform chunks and feeding DACs.
So then there can be easy concurrent buffering, within hubRAM, between reading of hyperRAM and outputting of samples. Also, any synth generation from a third cog can also be mixed via same chunk buffer mechanism.
I'm thinking that it'll be an either/or program arrangement for recording vs playback. Either load in the playback code or the recording code. That'll keep the hubRAM space as free as possible for chunk buffers.
The way I'd attempt it would be use a concurrent cog for mixing waveform chunks and feeding DACs.
The mixing cog should be able to work at 16-bit using the smartpin 16-bit dither mode. I believe that mode is buffered so therefore can accept software jitter of up to a full sample interval without it impacting the DAC timing. This allows the using of interrupts for sample output timing, while the main loop is doing the mixing and chunk fetching.
Are any of you guys that are against adding HyperRam to the P2 also at the same time in favor of adding an ESP32 for WiFi? My guess is that the P2 can do radio just fine by itself with just some passives and some wire for an antenna. It might not do 2.4GHz, but 80 to 108MHz FM could deliver 512KB of code to the P2 just fine too right?
The thing that I like about having big ram on the P2 is to leverage already existing code, and also having a stand-alone self hosting environment. Sure, the Pi already does this, but it is quite bloated and doesn't do real-time deterministic multi processing. Of course I am not against marrying a Pi to a P2, but miss the days of simpler, less bloated system.
As for P/S2, I favor them for keyboards as I have some good quality SGI ones that are 20+ years old, but I favor USB for mice because of features of the newer mice.
We desperately need the USB that GarryJ wrote made in to a proper object now. Again, adding external USB chips just doesn’t cut it these days.
So is the external USB2Serial board on your RetroBlade2 board relies on just a stop-gap measure until the USB drivers are ready? It's probably not going to happen to put USB drivers in ROM right?
I think the concern is a matter of optics - a lot of people look at a dev-board as a minimally complete application example. If the minimal app examples has extra ram, it makes it look like that's a requirement for most applications.
Sure, but for the P1 we had both the PropellerDemo board and several dev boards, including a bare-bones ones like the Propeller Project Board and the Propeller Protoboard. The Propeller DemoBoard and the Manual that went with it were my favorites, but then I'm not the kind of customer that produced products containing propellers and driving lots of sales. I do have over a dozen P1 boards though.
So is the external USB2Serial board on your RetroBlade2 board relies on just a stop-gap measure until the USB drivers are ready? It's probably not going to happen to put USB drivers in ROM right?
External USB parts are ROM compatible, and ensure you never have a bricked system.
A P2-flash-supported USB device has minimalist appeal, but you will need to somehow program that flash initially, and take care to not corrupt that 'operating system' level code.
Volumes would need to be quite high, for that trade off and increased risk to be worth while.
It may be possible to have a USB-device on P2, but so far all the P2 USB development has been USB-host for Mice/Keyboards.
Of course, doing that will swallow more COGs if both Host and Device are needed, and then you need to factor in what those COGS have actually cost you.
A P2 will be ~ $1.50 per COG, so the external USB bridge that some sniff at, is actually a more cost-effective solution
The EFM8UB3 MCU used in P2D2 & variants, handles reset, adds watchdog and system Temp and Voltage monitoring via i2c, and gives intelligent boot control, via PC pulse widths.
A vanilla solution, with limited features, is possible with a dedicated bridge part like CH340E in MSOP10.
We desperately need the USB that GarryJ wrote made in to a proper object now. Again, adding external USB chips just doesn’t cut it these days.
So is the external USB2Serial board on your RetroBlade2 board relies on just a stop-gap measure until the USB drivers are ready? It's probably not going to happen to put USB drivers in ROM right?
Not going to happen in ROM - too expensive for another rev, and too risky too. And it depends on there being at least one spare COG - can it be done in one???
So is the external USB2Serial board on your RetroBlade2 board relies on just a stop-gap measure until the USB drivers are ready? It's probably not going to happen to put USB drivers in ROM right?
External USB parts are ROM compatible, and ensure you never have a bricked system.
A P2-flash-supported USB device has minimalist appeal, but you will need to somehow program that flash initially, and take care to not corrupt that 'operating system' level code.
Volumes would need to be quite high, for that trade off and increased risk to be worth while.
It may be possible to have a USB-device on P2, but so far all the P2 USB development has been USB-host for Mice/Keyboards.
Of course, doing that will swallow more COGs if both Host and Device are needed, and then you need to factor in what those COGS have actually cost you.
A P2 will be ~ $1.50 per COG, so the external USB bridge that some sniff at, is actually a more cost-effective solution
The EFM8UB3 MCU used in P2D2 & variants, handles reset, adds watchdog and system Temp and Voltage monitoring via i2c, and gives intelligent boot control, via PC pulse widths.
A vanilla solution, with limited features, is possible with a dedicated bridge part like CH340E in MSOP10.
If it's on the board it will add in probably ~$1.50 for the chip fitted/tested.
If it's off board, at least the ~$1.50 for the CP2102 board versions. At least that much for a EFM8U based pcb too.
However, it could be programmed into the Flash in production (some small incremental cost as part of the test software).
If a microSD/SD socket is present, then it could be user loaded, either as part of the SD boot sequence, or a program in the SD to copy it to the Flash (if present) for subsequent booting.
But at present AFAIK we don't have a USB slave/device driver that can connect to a PC, so this option is currently moot.
Currently, I am not finding any problems with lack of hub RAM. That doesn't mean that I may sometime in the future, but for now I am very happy with the 512KB. I would have been happy with a P1 with 2x speed and 64+KB of hub ram, a few years ago.
One possible application for P2 and external RAM: audio synth with samples involved.
The P2 has (1) ADCs -audio input (2) DACs - audio output (3) DSP power (4) easy to implement MIDI in/out (5) vga/hdmi to visualise things
but then 512 kB RAM is too few for samples.
I thought of adding a Pi Zero (bare metal initialized) to P2 via its GPIO as a... 0.5 GB of aditional RAM
Now I am waiting for a P2 board to experiment with, but I can still try connect a Pi Zero to P1 and check if the idea works (=how fast can a Pi deliver bytes using a hyperram-like protocol).
This sound's like an excellent idea. You can use it for file service also. What OS were you thinking of running on the Pi to serve the P2? y
Comments
Slightly off-topic, but I think we need to keep the concept of "parallel processing" separate from the concept of "multitasking".
The propeller has parallel processing baked into the chip (and at an unusually high and easily accessible level), but not multitasking.
There are basically two types of multitasking - preemptive and cooperative. And "real" multitasking (i.e. preemptive) requires time slicing. Without time slicing, the Propeller is either limited to just 8 parallel "tasks", or would have to use cooperative multitasking (with its attendant problems).
Of course, the great thing about the Propeller is that because it fully implements parallel processing, it can do both, either, or neither of these types of multitasking with equal facility, and at the same time. And they all have their place.
I think the full potential of using the Propeller - both the P1 and the P2 - as an education platform for exploring parallel processing has not yet been fully realized. We all seem to spend too much time trying to emulate other processors that are bigger, faster and better at other tasks, and lose sight of what the Propeller is best at!
Ross.
Probably because the Propeller processors are much better at this kind of thing than us humans are.
That's what I do on the P2 (on the P1 I count instructions).
I will have to add a note of caution about using the streamer and FIFO - thanks!
I never meant to stop anybody from doing anything. I'm just a bit worried about the right marketing strategy. I remeber the downfall of the Commodore Amiga which was IMHO a consequence of marketing failure. The Amiga was widely known only as gaming platform. I have used it for machine control because it had a powerful real-time multitasking OS. It has instant reaction and guaranteed response time while on Windows or Linux you sometimes have to wait for 10s until something happens after you clicked a button. But nobody noticed because it was never advertised. The PC catched up with graphics and gamers abandonned the Amiga. This wouldn't have happened (or not as early) if it was used for more serious applications.
Playing videos on the P2 is a nice demontration of what can be done if you want to. But it's not the main strength of the P2.
For education there might even be a market for standalone "PC replacement" computers based on the P2. But there's also the risk that the audience gets this in the wrong throat and sees the P2 meant as "retro emulator" chip.
(and BTW, sorry about the confusion of "multitasking" vs. "parallel processing". For me it's often difficult to find the right words)
The nano offers a 64bit quad core ARM A57 @ 1.47GHz, a 128 core nvidia Maxwell GPU, and 2GB DRAM, Wifi (via USB dongle included in some markets), USB, HDMI, Ethernet, etc. it supports real python programming as well as most everything else. There are robot kits, CSI camera port for AI, and lots of existing open sourced software. Scores 8x to 73x RPi4. And there is a 40pin GPIO connector (RPi compatible???). Runs Ubuntu.
I still think there’s a self hosting micro market that doesn’t have a bloated OS. Programming simple things with the multi core P2 still has plenty to offer.
Let's continue there. In case of the P2 I think it's feasible and cost effective. Not so much (if at all) with the FPGA so I understand your point. It was just an idea of Peter, which I like.
I did not intend to discourage any dev with my comment. Personally, I will use extra RAM in the future. By all means build it, and they will come, in my opinion.
What I did intend was to point out where anyone finds it can make sense to develop lean and mean objects, that's also a good thing. The more of that we have, the less important the extra RAM question is, also IMHO.
A prime example would be USB keyboard / mouse vs PS2. The former is current and desirable. The latter takes very little RAM, and is an adapter away from being very usable.
Bringing some of the good P1 stuff forward should also further marginalize the question.
Parallax is focused on the education market and "robotics" is a big part of this.
My problem: Where are the robots? These little wheelie things that run around on the floor? How are these even considered robots?
Here we have an absolute killer of an industrial controller and only a handful of us seem to recognise this.
Yeah, PS/2 is kinda more desirable from a programmer's point of view - on P2 you could reasonably run the entire PS/2 driver interrupt driven in another cog, consuming literally 0 cycles when there's no key being pressed. PS/2 also supports infinite rollover as opposed to 6 + modifiers rollover on USB boot protocol, but most keyboards are too crappy to be able to decode that many keys in the first place, so oh well.
Seriously!
We are still in tool up stage. I think plenty of people recognize the industrial control aspect. But it remains early.
Powerful words. I'm still trying to absorb the weight they carry.
If I need more video,ram,sound,usb,whatever i will get a chip that does it.
But the p2 offers me a simple way to have real parallel processing without an os that gets in my way.
Real smart pins that have no annoying northbrige usb whatever timing restrictions
Real flat 512 kB of ram to work with, like sram.
I see the problem in not having a good Hal or call it kernel for this. So if the community develops anything it will exist in thin air.
It seems as if the p2 does everything, but nothing is written down. Hyperram is on heck of an interesting thing, but als long as we do not have some memory mapping component for p2 it will only be ingesting for very special needs.
I have developed digital video hardware some decades ago, clearly having high res high Color hdmi video will be nice, but als long I do not have some gpu like acceleration it will only be good as framebuffer. I see no application that needs only still picture output.
I need more like a vga or svga output to give out parameters fast
Please forgive my bad English, it is not my first language and my iPad insists on writing some words wierd
Well, the wheeled devices are regarded as AGVs (automatic guided vehicles) whereas robots do material-handling, welding, paint spraying, etc.
Education should involve forward/inverse kinematics and closed-loop servo theory and this is what could set Parallax apart from the crowd.
As I have stated many times; Chip has unwittingly created, potentially the most powerful motion-control device, ever.
The P2 has (1) ADCs -audio input (2) DACs - audio output (3) DSP power (4) easy to implement MIDI in/out (5) vga/hdmi to visualise things
but then 512 kB RAM is too few for samples.
I thought of adding a Pi Zero (bare metal initialized) to P2 via its GPIO as a... 0.5 GB of aditional RAM
Now I am waiting for a P2 board to experiment with, but I can still try connect a Pi Zero to P1 and check if the idea works (=how fast can a Pi deliver bytes using a hyperram-like protocol).
In the demos supplied with my P2 HyperRAM driver I have a very simple example where it plays audio from a buffer read from external memory. But you could just as easily play from HUB and just copy/mix samples there from HyperRAM/HyperFlash too. Lots of ways to use it.
In very high performance applications with video streamed in parallel to multi-channel audio the HyperRAM latency may begin to become an issue if you are reading individual samples one at a time. But if you can transfer more than one audio sample at a time it helps solve that type of problem. Rule of thumb @250MHz is HyperRAM access latency is in the order of ~1us per read. But you can transfer at 250MB/s using sysclk/1.
So then there can be easy concurrent buffering, within hubRAM, between reading of hyperRAM and outputting of samples. Also, any synth generation from a third cog can also be mixed via same chunk buffer mechanism.
I'm thinking that it'll be an either/or program arrangement for recording vs playback. Either load in the playback code or the recording code. That'll keep the hubRAM space as free as possible for chunk buffers.
The mixing cog should be able to work at 16-bit using the smartpin 16-bit dither mode. I believe that mode is buffered so therefore can accept software jitter of up to a full sample interval without it impacting the DAC timing. This allows the using of interrupts for sample output timing, while the main loop is doing the mixing and chunk fetching.
The thing that I like about having big ram on the P2 is to leverage already existing code, and also having a stand-alone self hosting environment. Sure, the Pi already does this, but it is quite bloated and doesn't do real-time deterministic multi processing. Of course I am not against marrying a Pi to a P2, but miss the days of simpler, less bloated system.
As for P/S2, I favor them for keyboards as I have some good quality SGI ones that are 20+ years old, but I favor USB for mice because of features of the newer mice.
Sure, but for the P1 we had both the PropellerDemo board and several dev boards, including a bare-bones ones like the Propeller Project Board and the Propeller Protoboard. The Propeller DemoBoard and the Manual that went with it were my favorites, but then I'm not the kind of customer that produced products containing propellers and driving lots of sales. I do have over a dozen P1 boards though.
External USB parts are ROM compatible, and ensure you never have a bricked system.
A P2-flash-supported USB device has minimalist appeal, but you will need to somehow program that flash initially, and take care to not corrupt that 'operating system' level code.
Volumes would need to be quite high, for that trade off and increased risk to be worth while.
It may be possible to have a USB-device on P2, but so far all the P2 USB development has been USB-host for Mice/Keyboards.
Of course, doing that will swallow more COGs if both Host and Device are needed, and then you need to factor in what those COGS have actually cost you.
A P2 will be ~ $1.50 per COG, so the external USB bridge that some sniff at, is actually a more cost-effective solution
The EFM8UB3 MCU used in P2D2 & variants, handles reset, adds watchdog and system Temp and Voltage monitoring via i2c, and gives intelligent boot control, via PC pulse widths.
A vanilla solution, with limited features, is possible with a dedicated bridge part like CH340E in MSOP10.
If it's on the board it will add in probably ~$1.50 for the chip fitted/tested.
If it's off board, at least the ~$1.50 for the CP2102 board versions. At least that much for a EFM8U based pcb too.
However, it could be programmed into the Flash in production (some small incremental cost as part of the test software).
If a microSD/SD socket is present, then it could be user loaded, either as part of the SD boot sequence, or a program in the SD to copy it to the Flash (if present) for subsequent booting.
But at present AFAIK we don't have a USB slave/device driver that can connect to a PC, so this option is currently moot.
Currently, I am not finding any problems with lack of hub RAM. That doesn't mean that I may sometime in the future, but for now I am very happy with the 512KB. I would have been happy with a P1 with 2x speed and 64+KB of hub ram, a few years ago.