...encouraged Chip to consider adding an ARM core to the P2 to serve as an "application processor"
When I first saw this suggested I thought the world had gone mad but can now see a huge amount of logic behind it. An ARM core with 16 very-capable soft-peripherals around it would be an amazing chip.
When I first saw this suggested I thought the world had gone mad but can now see a huge amount of logic behind it. An ARM core with 16 very-capable soft-peripherals around it would be an amazing chip.
I think so but this may have to wait until Parallax releases the RTL for the P1 and someone makes a new chip using it. Since that would be quite expensive, it will probably never happen but there might be some attempts on FPGA.
uMiteBASIC is probably badly named.. In short, it's a type of terminal interface between the Propeller and the uMite chip that allows it to control the more interesting parts of the video object.
Jeff
Did you design a new board with both a Propeller and a MicroMite chip on it? Where can I order one?
When I first saw this suggested I thought the world had gone mad but can now see a huge amount of logic behind it. An ARM core with 16 very-capable soft-peripherals around it would be an amazing chip.
An ARM core with eight P1 cores as is with the exception that another 32 I/O pins were added would be a great chip. Let the ARM take care of the heavy lifting, let the P1 take care of all of the I/O.
An ARM core with eight P1 cores as is with the exception that another 32 I/O pins were added would be a great chip. Let the ARM take care of the heavy lifting, let the P1 take care of all of the I/O.
Here is why that might not work. My understanding is that the process that Parallax is using for the P2 doesn't allow on-chip flash memory. The ARM would have to have a big chunk of flash and at least some SRAM to be useful. I guess that would require another probably much more expensive process. I guess the ARM could run from off-chip memory but then that takes a bunch of pins. Of course, if the ARM could share the 512k of hub memory with the COGs then maybe it would be possible.
An ARM core with eight P1 cores as is with the exception that another 32 I/O pins were added would be a great chip. Let the ARM take care of the heavy lifting, let the P1 take care of all of the I/O.
That's next! As soon as I get a few more software details worked out.
If you build a board could you please also provide an interface that allows the PIC32 to be reprogrammed? Someone (me maybe) might want to use the hardware for something other than running MicroMite.
If you build a board could you please also provide an interface that allows the PIC32 to be reprogrammed? Someone (me maybe) might want to use the hardware for something other than running MicroMite.
You may need to socket the PIC. The PIC32 used in the Maximite gets a bootloader so it can load new versions of MMBasic. The original programming of UMite BASIC into the uMite PIC32 is done via a PICKit3, I believe. If Jeff provides a socketed spot for the PIC32, then it will be more flexible...or if the board can support ICSP for the PIC but I'm not sure what all that may entail.
You may need to socket the PIC. The PIC32 used in the Maximite gets a bootloader so it can load new versions of MMBasic. The original programming of UMite BASIC into the uMite PIC32 is done via a PICKit3, I believe. If Jeff provides a socketed spot for the PIC32, then it will be more flexible...or if the board can support ICSP for the PIC but I'm not sure what all that may entail.
PICkit 3 support would be nice although I only have a PICkit 2 at the moment.
If you build a board could you please also provide an interface that allows the PIC32 to be reprogrammed? Someone (me maybe) might want to use the hardware for something other than running MicroMite.
I'm purchasing a PICKit3 programmer. When I get to the hardware side of the project, I'll make sure we have chips for it that will work.
If you go off and get some new toys, just make sure you are having fun and or doing something you need to get done. Doing it as a protest isn't likely to be all that productive. Try to feel good about your fun time Brian.
I can't speak for Brian but I have been collecting and tinkering with such toys since the Motorola 6800s and Intel 8051's and such. The Propeller is just a little diversion along the way. The P1 is a gem of a design. Not the biggest, fastest thing in the world but simple, elegant, flexible, useful.
The dream was the P2 would be built in the same way. Only a bit faster, a bit more RAM a few more pins. Ah well.
@Brian,
When I first saw this suggested I thought the world had gone mad but can now see a huge amount of logic behind it. An ARM core with 16 very-capable soft-peripherals around it would be an amazing chip.
Yes. Perhaps it was my suggestion you saw some years ago. An ARM for running Linux and handling all the ethernet, video, USB stuff and a Propeller for handling all that other interesting bit twidling of real world interfaces. As you see Bill Henning is now pursuing this idea with his Propeller for Raspberry Pi boards.
Here is why that might not work. My understanding is that the process that Parallax is using for the P2 doesn't allow on-chip flash memory. The ARM would have to have a big chunk of flash and at least some SRAM to be useful. ...
Flash also slows things down.
FTDI's new FT900 is another 32b core, and that uses RAM for code, to boost speed.
It's not clear if the FLASH loaded from, is a stacked die, or same die, but it does not need to be fast parallel flash.
I went this way because the mmBASIC is already VERY complete. All of the functionality I never had room for is already onboard plus a lot more. Strings, DATA/READ, etc. Combining this with the power of the Propeller will allow me to have my cake and eat it too.
Jeff
Another thing you might consider is that you have to add a PIC32 chip to make this Propeller+MicroMite system. If instead of the PIC32 chip you had added a SPI flash chip you could have achieved something similar without having to add another MCU. Using PropGCC in XMMC mode, the SPI flash would give you lots of space for an onboard editor and compiler and you could still get good runtime performance for the user code by using the PASM VM. Also, you could have used a lot of the 32k of hub memory for the user program. I'm not saying ebasic3 is anywhere near the language that mmBasic but there might be a better Basic available that would run on the Propeller in XMMC mode where lots of code space is available.
Here is why that might not work. My understanding is that the process that Parallax is using for the P2 doesn't allow on-chip flash memory. The ARM would have to have a big chunk of flash and at least some SRAM to be useful. I guess that would require another probably much more expensive process. I guess the ARM could run from off-chip memory but then that takes a bunch of pins. Of course, if the ARM could share the 512k of hub memory with the COGs then maybe it would be possible.
I can't speak for Brian but I have been collecting and tinkering with such toys since the Motorola 6800s and Intel 8051's...
For me it was 6502 -> Z80 -> 8051 -> AVR at home as 'serious' chips with all sorts of others, like ADSP2100, to play with. Work was 8085 family -> 8051 -> 8086 -> AVR ->....
I still get a buzz out of it, especially when one of my systems, doing its thing, makes the papers...
[and the relevance is that my pyro firing system has got a P1 in it doing VGA duties]
Isn't it against forum guidelines to revive old threads? This thread was started 2.5 years ago, and the last post was 2 years ago. An automated forum moderator would have put John Abshier on probation for such an infraction. But then an automated moderator wouldn't have realized that the thread subject has been ongoing for 10 years, and will still be ongoing for God knows how long.
Isn't it against forum guidelines to revive old threads? This thread was started 2.5 years ago, and the last post was 2 years ago. An automated forum moderator would have put John Abshier on probation for such an infraction. But then an automated moderator wouldn't have realized that the thread subject has been ongoing for 10 years, and will still be ongoing for God knows how long.
In your comment you lamented the lack of high level language discussions. But Dave Hein has already posted a C compiler for P2, Peter Jakacki has ported Tachyon Forth to P2, and I've posted my Spin to P2 Asm compiler (fastspin). I think that's a pretty good start, considering that we don't even have silicon yet.
Of course I was being facetious about the forum guidelines thing. I think it's valid to continue to lament the fact that the P2 is here yet. As far as Spin and C support, I would like to see an official effort on Parallax's part to begin developing C and Spin compilers for the P2. It appears that the core set of instructions have been stable for over a half year, and most of the P2 work is focused around Smart Pins. Eric's work on the Spin-to-assembler compiler is amazing, and it should be useful for the P2. The "C" compiler that I played around with was just an educational exercise for me, and it will probably never be developed into a full C compiler.
The P2 really needs to have the Gnu gcc compiler ported to it. I don't understand why Parallax hasn't spearheaded the development of PropGCC for the P2. In my opinion, this is a crucial piece that will be needed the day the P2 silicon is ready. I have to admit I really don't understand Parallax's business plan concerning the P2, or whether they even have a business plan.
My only lament is Leon's many years of persistent antagonism of Parallax and forum members by promoting other competing products. Why is this allowed year after year? It annoys me to no end.
My only lament is Leon's many years of persistent antagonism of Parallax and forum members by promoting other competing products. Why is this allowed year after year? It annoys me to no end.
While I understand your frustration, I believe this thread is not the place to address it. Besides, Parallax can certainly address the issue if they were so inclined. And I don't believe you can speak for all forum members, as I certainly don't see Leon's emails the same way you do.
PS. Hard to believe that I have been watching Prop 2 development for over 10% of my life.
Edit: I am now 69. Latest time sink de jour is LUT sharing. I am bothered that I see nothing about development of HLLs. I would prefer Spin, but would settle for FORTRAN, C, LUA, Python, or others.
This LUT sharing discussion is pretty much over, now. I'm implementing it today and I'll be getting a new (final?) release out very soon.
Many of us will start working on tools as soon as things stop changing.
This Prop2 project has been 23% of my life, so far. There are still years of software work to engage in, which is the really fun part.
Comments
When I first saw this suggested I thought the world had gone mad but can now see a huge amount of logic behind it. An ARM core with 16 very-capable soft-peripherals around it would be an amazing chip.
An ARM core with eight P1 cores as is with the exception that another 32 I/O pins were added would be a great chip. Let the ARM take care of the heavy lifting, let the P1 take care of all of the I/O.
XMOS already has a device like that: http://www.xmos.com/products/silicon/xa-series
https://www.xmos.com/download/public/xCORE-XA-Product-Brief%281.2%29.pdf
That's next! As soon as I get a few more software details worked out.
PICkit 3 support would be nice although I only have a PICkit 2 at the moment.
I'm purchasing a PICKit3 programmer. When I get to the hardware side of the project, I'll make sure we have chips for it that will work.
The dream was the P2 would be built in the same way. Only a bit faster, a bit more RAM a few more pins. Ah well.
@Brian, Yes. Perhaps it was my suggestion you saw some years ago. An ARM for running Linux and handling all the ethernet, video, USB stuff and a Propeller for handling all that other interesting bit twidling of real world interfaces. As you see Bill Henning is now pursuing this idea with his Propeller for Raspberry Pi boards.
I think you will be pleasantly surprised by how easy the P2 is to work with and code for... It just sounds complex in the making of it.
FTDI's new FT900 is another 32b core, and that uses RAM for code, to boost speed.
It's not clear if the FLASH loaded from, is a stacked die, or same die, but it does not need to be fast parallel flash.
Perhaps this is only practical for BGA chips, but apparently there's at least one chip out there from a major company that has on-chip, but not on-die flash. http://hackaday.com/2011/05/25/extracting-secured-firmware-from-freescale-zigbee-radios/
For me it was 6502 -> Z80 -> 8051 -> AVR at home as 'serious' chips with all sorts of others, like ADSP2100, to play with. Work was 8085 family -> 8051 -> 8086 -> AVR ->....
I still get a buzz out of it, especially when one of my systems, doing its thing, makes the papers...
[and the relevance is that my pyro firing system has got a P1 in it doing VGA duties]
John Abshier
Being that John was the OP, we will let it slid.
He is presenting facts.
The P2 really needs to have the Gnu gcc compiler ported to it. I don't understand why Parallax hasn't spearheaded the development of PropGCC for the P2. In my opinion, this is a crucial piece that will be needed the day the P2 silicon is ready. I have to admit I really don't understand Parallax's business plan concerning the P2, or whether they even have a business plan.
While I understand your frustration, I believe this thread is not the place to address it. Besides, Parallax can certainly address the issue if they were so inclined. And I don't believe you can speak for all forum members, as I certainly don't see Leon's emails the same way you do.
LMAO! I love wry humor.
This LUT sharing discussion is pretty much over, now. I'm implementing it today and I'll be getting a new (final?) release out very soon.
Many of us will start working on tools as soon as things stop changing.
This Prop2 project has been 23% of my life, so far. There are still years of software work to engage in, which is the really fun part.