Just give me a P2 that can host a web pages and can do Ajax with a web browser and I will be happy to put back all my Linux boards in the drawer. It would be a big plus if we can find a way to remote flash the Prop eeprom too.
I know this has been done before with the P1, but I think it now has to be an out of the box experience (cheap and easy to get going). A bit like how easy it was to hook-up a keyboard, mouse and TV to P1.
The P2 has to be ready for IoT.
This is running on P1 as is right now although we are testing Ajax extensions Forth style but the EEPROM and everything is totally accessible. Check out one of my videos.
edit: I see MJB has answered!
Well it has plenty of spare cogs but doesn't need an extra one to run WS2812s at high speed either on top of a whole range of sensors. BTW, I use the Prop a lot in my own industrial PLC style products although I mostly program these in Tachyon Forth these days for good reason.
I bought an Intel Edison as soon as I could get my hands on one. What appealed to me was the fact that it was a Dual Core Atom + Quark MCU. It took several months before they unlocked the MCU. I tried it and it is Smile. It does not even run bare metal and is not fast enough to drive a strip of WS2812 LEDs. In the end, I need to add a dedicated microcontroller for that task!
The newest Edison variants claim to have a 100MHz 32b Microcontroller - as well as the Dual Core quark.
Were you able to drill down far enough to get at that microcontroller ?
Info on that sub-section seems sparse, but I guess it is similar to their recent 32MHz D2000 ?
It is true that the forum seems less active since 1 or 2 years. The P1 chip is still capable, but I think that the when the P2 will come out, it will generate a lot of interested and the new stuff will attract newcomers in the forum. Maybe some people that left the forum will come back.
Just give me a P2 that can host a web pages and can do Ajax with a web browser and I will be happy to put back all my Linux boards in the drawer. It would be a big plus if we can find a way to remote flash the Prop eeprom too.
I know this has been done before with the P1, but I think it now has to be an out of the box experience (cheap and easy to get going). A bit like how easy it was to hook-up a keyboard, mouse and TV to P1.
The P2 has to be ready for IoT.
With a lot of USB ports, the P2 can easily become a smart-hub.
What do you mean by newest Edison variant? I did not know that there are more than one.
To access the MCU, I followed this tutorial : https://software.intel.com/en-us/node/545142
I hooked up my oscilloscope to it to see what it was capable of. I made some tests to toggle the IO at the fastest speed possible, and it was slow (50kHz). For some unknown reason, different outputs had different max speed at which I could toggle them.
For sure, adding companion chips to the P2 will enhance its capabilities but I would like a P2 board with minimum part count so that if I design a PCB with the P2 on it, it would not be too complex. The free version of diptrace I use is limited to 300 pins!
What do you mean by newest Edison variant? I did not know that there are more than one.
To access the MCU, I followed this tutorial : https://software.intel.com/en-us/node/545142
I hooked up my oscilloscope to it to see what it was capable of. I made some tests to toggle the IO at the fastest speed possible, and it was slow (50kHz). For some unknown reason, different outputs had different max speed at which I could toggle them.
hmmm, sounds like you have found latest info there, strange it has such a low limit.
Has anyone at Intel confirmed that is fundamental feature/bug ? - almost like the GPIO is serial ?
For sure, adding companion chips to the P2 will enhance its capabilities but I would like a P2 board with minimum part count so that if I design a PCB with the P2 on it, it would not be too complex. The free version of diptrace I use is limited to 300 pins!
P2 will not need many companion chips.
The EXAR example was more for how they arranged the USB-stack.
I would suggest any P2 Eval Board does include the Quad Exar part, but that is because you need multiple high speed links to the PC for serious P2 development (a single FT231x is just too feeble) - in final PCB designs, P2 would be more stand alone.
How could I buy your module? Is it open source hardware? How much does it cost? Do you think it will be easy to port to P2 when it will come out?
David Price @D.P had some stock of these modules so you can check with him. I believe I can ship a small package of these for around $2US if the modules are not stacked as this keeps the package to within 20mm for the cheap padded envelope rate.
Honestly though Chip, if you want the prop to succeed in the mcu industry it needs to bring something to embedded computing that you can't find in any other mcu. And although I wish an MMU would be a good business decision, the main benefit of using the prop is that it makes multi-core computing *easy*.
The right path for the prop is to keep increasing the cores, and keep adding new features to the hub/inter-cog communication, while making it more and more easy. The big fad right now is "STEM" products, which just means computers so easy to use a 5yo could program it.
So, to succeed, you need to do the following, in order of importance:
1: make a GUI IDE for the prop
2: make the hardware EASIER to understand and program, while giving more flexibility
3: increase core count
4: increase RAM/CPU frequency
Unfortunately right now Parallax seems to be going with the opposite order. Time to switch if you want a bigger audience.
The defining idea of an MCU is that it has everything required to run software and control stuff on a single chip. Program store, RAM, UART, timers, GPIO, an ever increasing list of other stuff.
As opposed to a micro-processor which is only the CPU and needs surrounding memories, support chips and peripherals.
As such MCU's don't have huge amounts of memory and an MMU is not required.
Further, an MMU can protect tasks from upsetting each others memory. However in an embedded system, those systems micro-controllers are designed for, this memory protection is not much use. If you code is misbehaving like that it's probably going to crash or produce some bad output. Having the MMU trap that does not help, your machine has failed already.
"Real operating systems" for micro-controllers include such things as Free RTOS. They do not use an MMU. They are all about real-time task scheduling.
Given all that I wonder what m00tykins wants. Sounds like a Raspberry Pi or other Linux capable processor would do whatever it is better.
Edit: Given the traditional idea of a micro-controller, we see the Prop is not an MCU. It requires an external program store device.
The merry-go-round is up and spinning again I see ... There's no point in attempting another ARM competitor. Parallax wouldn't have a show of competing. Hell, even Intel isn't getting very far on that front.
Heater,
I definitely class the Prop as a MCU. The lack of a generic external system bus is enough for me. And as such, programs are exclusively executed from internal program store. It just happens to be volatile storage is all.
There's no point in attempting another ARM competitor.
I agree and have said so many time here.
Except....
If Parallax could bang out a RISC-V processor. Base level instruction set, possibly with the FP extensions, multi-core, with Chip's smart pin magic.
I seriously think there are many around the world who would be all over that. RISC-V being a free and open source instruction set architecture is quite likely to unseat ARM in many areas. Especially academic and educational.
There are quite a few open source RISC-V designs available and waiting to be blown into silicon already.
There's no point in attempting another ARM competitor.
I agree and have said so many time here.
Except....
If Parallax could bang out a RISC-V processor. Base level instruction set, possibly with the FP extensions, multi-core, with Chip's smart pin magic.
I seriously think there are many around the world who would be all over that. RISC-V being a free and open source instruction set architecture is quite likely to unseat ARM in many areas. Especially academic and educational.
There are quite a few open source RISC-V designs available and waiting to be blown into silicon already.
Good idea, but the snag is you need most of the current Prop2 instructions for controlling the smart pin and other hardware. Perhaps a combination of one or more riscv cpu's and 8/16 propeller cores with a large shared memory on one chip would be better.
Good idea, but the snag is you need most of the current Prop2 instructions for controlling the smart pin and other hardware. Perhaps a combination of one or more riscv cpu's and 8/16 propeller cores with a large shared memory on one chip would be better.
Then you end up with what Freescale and TI have done with their PowerPC and ARM core SOC solutions. You have a powerful main CPU and maybe 2-4 small RISC engines with local memory that handle all the PWM and fast I/O.
You can see this with the BeagleBone Black and it's PRU's.
They however avoid the shared memory situation and the complexity/performance hits that brings.
You may have a point about the complexity and performance hit of shared memory. One or more registers per cog might be a better way to communicate between the riscv and prop cores. The riscv could address them as registers or as part of it's low memory address space while the cogs would see them as special registers like they do now on the P1.
Why ?
There is already a shipload of choices of MPUs that can run 'a real OS', just choose any of those, and use the Prop to do what it excels at.
Many seem to think ONE processor is the holy grail, but the market trend is actually in quite the opposite direction.
More and more Microcontrollers are being deployed into systems, many used as intelligent peripherals.
That 'real OS' you think is so important to have, is cumbersome and hopelessly slow, for some tasks, so it certainly will need something to help it along.
Well the CA lottery is 314 million tonight, maybe that should be where they spend their R&D budget to do RISV-V.
Other than that Parallax has no where near the resources to do their own RISC-V chip. Maybe when one of those big players in that organization builds one, they could hop on the band wagon, but that doesn't seem to be their direction.
Come on guys, I said myself in that post it's not a good business decision for parallax to put an mmu on it. I like mmus because I like running an internet-capable OS on stuff, that's all.
And although I LOVE the idea of a risc-v prop, that goes far outside the prop's target market. Maybe for another cpu product? Let's call it the rocket.
I like mmus because I like running an internet-capable OS on stuff, that's all.
An MMU is not necessary to write an internet-capable OS, if all code is known to not have any memory-related bugs. The only reason it's useful is because it makes virtual memory easier (your compiler doesn't have to worry about it), and because it's good (but not great) for catching bugs.
For example, you could write a compiler on the P2 (which has no MMU) for JS or Lua or something, that emits perfectly safe (memory-wise) code with checks for all memory accesses. A fancy (and probably hard to get right) optimizer could remove checks that it can prove will never fail. You could also have that compiler automatically insert code to manually swap stuff in from external memory as necessary, since 512KB isn't enough for all applications. You could then write a perfectly safe web browser on top of that.
Good idea, but the snag is you need most of the current Prop2 instructions for controlling the smart pin and other hardware.
There are a couple of ways around that:
The RISC-V standard allows for custom instruction set extensions. Such smart pin instructions could be added as an extension. The idea behind this is that you get to use the same RSIC-V compiler and other tools as everyone else saving a lot on tool development.
Or, as you say, combine RISC-V and Propeller cores. That's how imagined such a device originally but on reflection I think it gets too complex. Now we have two architectures, two tool chains to use, two instruction sets to learn. It's not at all elegant.
@brucee
Well the CA lottery is 314 million tonight, maybe that should be where they spend their R&D budget to do RISV-V.
Other than that Parallax has no where near the resources to do their own RISC-V chip. Maybe when one of those big players in that organization builds one, they could hop on the band wagon, but that doesn't seem to be their direction.
No doubt development would be required. As far as I can tell we are nearly at the point where open source RISC-V implementations exist that are waiting to be used in FPGA and real silicon.
By the way everyone, I'm not all suggesting that Parallax drop the P2 and switch to start building RISC-V. That would be crazy. This is all just idle speculation of a far a way future, prompted by evanh's very valid observation that "There's no point in attempting another ARM competitor."
...
By the way everyone, I'm not all suggesting that Parallax drop the P2 and switch to start building RISC-V. That would be crazy. This is all just idle speculation of a far a way future, prompted by evanh's very valid observation that "There's no point in attempting another ARM competitor."
Everytime a new iteration is done on RISC-V, it moves closer to ARM in specs.
eg the latest code compression iteration addresses the issue of less efficient code, and it now can use a smaller subset, (just like ARM)to give Code Size that comes in .... just like ARM's.
It was in jest. As was my earlier shot at Leon. Leon has been accused by others of promoting the XMOS, possibly as an aspirational design target. You've seemingly gone the next step, suggesting abandoning the Cog processor altogether.
Every time a new iteration is done on RISC-V, it moves closer to ARM in specs.
That is kinda, sorta true. However there are significant and important differences.
1) The RISC-V instruction set is a Free and Open Source specification. Anyone can use it for anything. This is certainly not true of the ARM ISA.
2) The RISC-V guys don't want any "iterations". That base instruction set for example is intented to be the minimal instruction set needed to keep compilers happy. It's integer only, it has no multiply or divide, no floating point, no caches, no virtual/protected memory. It is intended that once spec'ed out and agreed by everyone involved it never changes.
3) Rather than "iterations" there are extensions. Like mul/div, float, VM etc etc. All optional. All to be cast in stone when consensus is reached.
All of this is unlike ARM which has more instruction sets than one can shake a stick at.
Certainly RISC-V gets more ARM like features. It has to. People want floating point for high speed math, they want virtual memory for running operating systems, they want compressed code on small systems, and so on. Point is if you don't need those features you don't build them in. You are still a RISC-V compatible machine.
Remember that ARM was inspired by the development of the RISC ideas back in the early 1980's. Some of the guys behind RISC-V are the original creators of RISC.
Okay, I'll play devils avocate with the Prop then - The Hub is a central (No pun intended) feature of the Propeller. It defines the Propeller to quite a large extent. It dictates the fact that Cogs natively execute code from their own general register set, and by extension the large number of those registers.
Following that line of thought: Looking at a more regular processor with a somewhat smaller register set - The HubExec FIFO could be further extended all the way to full-on caches (As an aside, which presumably runs hotter than direct mapped RAM) so that something like a RISC-V core could make easy use of HubRAM as it's primary code space without any significant re-engineering.
However, the determinism becomes brittle when relying solely on caches to replace CogRAM's space. Maybe special cache management instructions would be good enough? dunno.
Comments
This is running on P1 as is right now although we are testing Ajax extensions Forth style but the EEPROM and everything is totally accessible. Check out one of my videos.
edit: I see MJB has answered!
Well it has plenty of spare cogs but doesn't need an extra one to run WS2812s at high speed either on top of a whole range of sensors. BTW, I use the Prop a lot in my own industrial PLC style products although I mostly program these in Tachyon Forth these days for good reason.
Did you ever look at doing IEC-61131-Instruction List ?
Google finds this :
https://iec61131.wordpress.com/2014/10/01/whats-in-a-bytecode/
( 'byte code' here is actually 16 bits, and it shows a good list of 1,8,16,32,64b types )
and this
https://iec61131.wordpress.com/author/iec61131/
and some postings from about 1 year ago
https://bitbucket.org/rob_au/61131
How could I buy your module? Is it open source hardware? How much does it cost? Do you think it will be easy to port to P2 when it will come out?
What do you mean by newest Edison variant? I did not know that there are more than one.
To access the MCU, I followed this tutorial : https://software.intel.com/en-us/node/545142
I hooked up my oscilloscope to it to see what it was capable of. I made some tests to toggle the IO at the fastest speed possible, and it was slow (50kHz). For some unknown reason, different outputs had different max speed at which I could toggle them.
For sure, adding companion chips to the P2 will enhance its capabilities but I would like a P2 board with minimum part count so that if I design a PCB with the P2 on it, it would not be too complex. The free version of diptrace I use is limited to 300 pins!
Has anyone at Intel confirmed that is fundamental feature/bug ? - almost like the GPIO is serial ?
P2 will not need many companion chips.
The EXAR example was more for how they arranged the USB-stack.
I would suggest any P2 Eval Board does include the Quad Exar part, but that is because you need multiple high speed links to the PC for serious P2 development (a single FT231x is just too feeble) - in final PCB designs, P2 would be more stand alone.
David Price @D.P had some stock of these modules so you can check with him. I believe I can ship a small package of these for around $2US if the modules are not stacked as this keeps the package to within 20mm for the cheap padded envelope rate.
Use this link here to check on configuration and ordering.
They're getting enough RAM to do real work now
- What's bad/frustrating about them?
NO MMUS!!! WHYYYYY ;n;
- What directions have they trended in?
ARM. High frequency. High RAM capacity. Internet access.
- Are things generally opening up or closing tighter?
ARM is starting to take over the market, so I'd say closing.
- Is there an increasing sense of liberation using modern microcontrollers, or do you sense a long arm of increasing control?
"long arm". heh. Yes ARM is taking over a bit too much of the market.
- Are they fun?
if they can RUN A REAL OS CUZ THEY HAVE AN MMU. then yes
This was all mostly tongue-in-cheek, tho I am feeling a little buttmad about the mmu thing. Hopefully in prop3 (or prop 2.5?) we'll get to see it.
I want a real OS to run on it.
Honestly though Chip, if you want the prop to succeed in the mcu industry it needs to bring something to embedded computing that you can't find in any other mcu. And although I wish an MMU would be a good business decision, the main benefit of using the prop is that it makes multi-core computing *easy*.
The right path for the prop is to keep increasing the cores, and keep adding new features to the hub/inter-cog communication, while making it more and more easy. The big fad right now is "STEM" products, which just means computers so easy to use a 5yo could program it.
So, to succeed, you need to do the following, in order of importance:
1: make a GUI IDE for the prop
2: make the hardware EASIER to understand and program, while giving more flexibility
3: increase core count
4: increase RAM/CPU frequency
Unfortunately right now Parallax seems to be going with the opposite order. Time to switch if you want a bigger audience.
As opposed to a micro-processor which is only the CPU and needs surrounding memories, support chips and peripherals.
As such MCU's don't have huge amounts of memory and an MMU is not required.
Further, an MMU can protect tasks from upsetting each others memory. However in an embedded system, those systems micro-controllers are designed for, this memory protection is not much use. If you code is misbehaving like that it's probably going to crash or produce some bad output. Having the MMU trap that does not help, your machine has failed already.
"Real operating systems" for micro-controllers include such things as Free RTOS. They do not use an MMU. They are all about real-time task scheduling.
Given all that I wonder what m00tykins wants. Sounds like a Raspberry Pi or other Linux capable processor would do whatever it is better.
Edit: Given the traditional idea of a micro-controller, we see the Prop is not an MCU. It requires an external program store device.
I definitely class the Prop as a MCU. The lack of a generic external system bus is enough for me. And as such, programs are exclusively executed from internal program store. It just happens to be volatile storage is all.
Except....
If Parallax could bang out a RISC-V processor. Base level instruction set, possibly with the FP extensions, multi-core, with Chip's smart pin magic.
I seriously think there are many around the world who would be all over that. RISC-V being a free and open source instruction set architecture is quite likely to unseat ARM in many areas. Especially academic and educational.
There are quite a few open source RISC-V designs available and waiting to be blown into silicon already.
http://riscv.org/
https://www.youtube.com/results?search_query=risc-v
Good idea, but the snag is you need most of the current Prop2 instructions for controlling the smart pin and other hardware. Perhaps a combination of one or more riscv cpu's and 8/16 propeller cores with a large shared memory on one chip would be better.
Heap Heater in with Leon.
Then you end up with what Freescale and TI have done with their PowerPC and ARM core SOC solutions. You have a powerful main CPU and maybe 2-4 small RISC engines with local memory that handle all the PWM and fast I/O.
You can see this with the BeagleBone Black and it's PRU's.
They however avoid the shared memory situation and the complexity/performance hits that brings.
I think it's a pretty good solution.
You may have a point about the complexity and performance hit of shared memory. One or more registers per cog might be a better way to communicate between the riscv and prop cores. The riscv could address them as registers or as part of it's low memory address space while the cogs would see them as special registers like they do now on the P1.
There is already a shipload of choices of MPUs that can run 'a real OS', just choose any of those, and use the Prop to do what it excels at.
Many seem to think ONE processor is the holy grail, but the market trend is actually in quite the opposite direction.
More and more Microcontrollers are being deployed into systems, many used as intelligent peripherals.
That 'real OS' you think is so important to have, is cumbersome and hopelessly slow, for some tasks, so it certainly will need something to help it along.
Well the CA lottery is 314 million tonight, maybe that should be where they spend their R&D budget to do RISV-V.
Other than that Parallax has no where near the resources to do their own RISC-V chip. Maybe when one of those big players in that organization builds one, they could hop on the band wagon, but that doesn't seem to be their direction.
And although I LOVE the idea of a risc-v prop, that goes far outside the prop's target market. Maybe for another cpu product? Let's call it the rocket.
An MMU is not necessary to write an internet-capable OS, if all code is known to not have any memory-related bugs. The only reason it's useful is because it makes virtual memory easier (your compiler doesn't have to worry about it), and because it's good (but not great) for catching bugs.
For example, you could write a compiler on the P2 (which has no MMU) for JS or Lua or something, that emits perfectly safe (memory-wise) code with checks for all memory accesses. A fancy (and probably hard to get right) optimizer could remove checks that it can prove will never fail. You could also have that compiler automatically insert code to manually swap stuff in from external memory as necessary, since 512KB isn't enough for all applications. You could then write a perfectly safe web browser on top of that.
The implication is that Leon and I express some opinions that you disagree with.
I'm sure Leon and I have points of view in common. I'm also sure we can find a lot to disagree about.
So what is it that prompted that off hand remark?
I'm not sure I want to be "heaped" anywhere.
The RISC-V standard allows for custom instruction set extensions. Such smart pin instructions could be added as an extension. The idea behind this is that you get to use the same RSIC-V compiler and other tools as everyone else saving a lot on tool development.
Or, as you say, combine RISC-V and Propeller cores. That's how imagined such a device originally but on reflection I think it gets too complex. Now we have two architectures, two tool chains to use, two instruction sets to learn. It's not at all elegant.
@brucee No doubt development would be required. As far as I can tell we are nearly at the point where open source RISC-V implementations exist that are waiting to be used in FPGA and real silicon.
By the way everyone, I'm not all suggesting that Parallax drop the P2 and switch to start building RISC-V. That would be crazy. This is all just idle speculation of a far a way future, prompted by evanh's very valid observation that "There's no point in attempting another ARM competitor."
eg the latest code compression iteration addresses the issue of less efficient code, and it now can use a smaller subset, (just like ARM)to give Code Size that comes in .... just like ARM's.
1) The RISC-V instruction set is a Free and Open Source specification. Anyone can use it for anything. This is certainly not true of the ARM ISA.
2) The RISC-V guys don't want any "iterations". That base instruction set for example is intented to be the minimal instruction set needed to keep compilers happy. It's integer only, it has no multiply or divide, no floating point, no caches, no virtual/protected memory. It is intended that once spec'ed out and agreed by everyone involved it never changes.
3) Rather than "iterations" there are extensions. Like mul/div, float, VM etc etc. All optional. All to be cast in stone when consensus is reached.
All of this is unlike ARM which has more instruction sets than one can shake a stick at.
Certainly RISC-V gets more ARM like features. It has to. People want floating point for high speed math, they want virtual memory for running operating systems, they want compressed code on small systems, and so on. Point is if you don't need those features you don't build them in. You are still a RISC-V compatible machine.
Remember that ARM was inspired by the development of the RISC ideas back in the early 1980's. Some of the guys behind RISC-V are the original creators of RISC.
Following that line of thought: Looking at a more regular processor with a somewhat smaller register set - The HubExec FIFO could be further extended all the way to full-on caches (As an aside, which presumably runs hotter than direct mapped RAM) so that something like a RISC-V core could make easy use of HubRAM as it's primary code space without any significant re-engineering.
However, the determinism becomes brittle when relying solely on caches to replace CogRAM's space. Maybe special cache management instructions would be good enough? dunno.