There are already min. 3 ways to program the P2 in C/C++:
- Dave Heins "Translater" fom P1-PropGCC to P2
- Erics ZPU Interpreter
- Erics RISC-V Emulator
Except full fleshed out C/C++ support. But I will keep nagging there.
Enjoy!
Mike
The sources for the P2-Hot version of PropGCC are in the Parallax GitHub account. You can download them and help with a P2 version of GCC. :-)
Sadly I can't. The longest C program I ever wrote fits for sure on one or two pages if you print it.
Some COBOL programs I work on, on the other hand might not be printable at all, with printers available to me.
Over the last decade I got quite fluent in C#, but never had a employment needing me to use C/C++. And just playing around with a Language - hmm- never gets you to understand it even partially. Not like if you are working daily over weeks/month/years/decades with it.
For me PropGCC will just be a tool to get COBOL programs running on the P2. I think some features of COBOL would fit quite nicely for stuff I am doing on MCs.
The SCREEN SECTION for example. Nice TUI interfaces, easy defined. Same for the REPORT SECTION. Nice Reports with Groups and all that, easy defined. DB access build into the language if you can live with ISAM or relative/sequential/dynamic files. Sorting, filtering all build in.
And since GnuCobol translates to C/C++ interfacing C or other languages is not so complicated.
Did we really have PropGCC for the P2-Hot? I don't remember how far we got before we switched to the P1. Did P2-Hot have hub exec at that time? If so, maybe it's just a matter of updating GAS and the linker. For the most part, PropGCC uses a small subset of the P2 instruction set. It's mostly just rdxxxx, wrxxxx, mov and the basic ALU instructions. The code generator probably wouldn't need a lot of changes.
The library can be copied from the latest P1 PropGCC version. Maybe this is doable by mere mortals. The linker probably needs a lot of work given the variety of instruction formats used by the P2. Someone that understands the ELF format would need to do that work.
I think it's more in practice than your COBOL plans...
@Ariba,
yes, sadly. I tried with P1 and PropGCC but my C-fu and Linux-fu is underdeveloped.
The GnuCobol Project is mostly supported by Linux guys, and I have already a hard time to run it on Windows.
But I am confident to get there. And I am in no hurry, because I do not need it at all, its just for fun.
I think it's more in practice than your COBOL plans...
And you have to speak 'Theoretically' in that Russian accent, like in the movie.
Actually someone got a GnuCobol generated C Program running on some Arduino, with some 'Mesa' Build System and replacing XXX.h files and then he lost me in his description.
Did we really have PropGCC for the P2-Hot? I don't remember how far we got before we switched to the P1. Did P2-Hot have hub exec at that time? If so, maybe it's just a matter of updating GAS and the linker. For the most part, PropGCC uses a small subset of the P2 instruction set. It's mostly just rdxxxx, wrxxxx, mov and the basic ALU instructions. The code generator probably wouldn't need a lot of changes.
The library can be copied from the latest P1 PropGCC version. Maybe this is doable by mere mortals. The linker probably needs a lot of work given the variety of instruction formats used by the P2. Someone that understands the ELF format would need to do that work.
We had GCC for P1 before we had it for P2-hot. No, there was no hub exec at the time but we did support LMM code. I don't think I ever did XMM although that's pretty much been deprecated by Parallax even for P1. You're right that a big first step will be updating GAS. I've started on that by creating a program that reads Chip's instruction spreadsheet to create tables that GAS can use to parse P2 instructions. I just haven't had time to go much beyond that because of having several other paying contracts to work on.
I have not thought about making the RESn pin an I/O.
There are already the natural 64 io, so where would this map ?
It have not to map to anything. It will be useful that by issuing an internal software reset, beside the prop, the external hardware can be reset also. to bring the external peripherals to their default state.
It's not often mentioned, but the nRES pin on the Prop1 is an open-drain output, when nBOE is grounded, in addition to being an active-low reset input. So on power-up, it gets pulled down and can be used to reset external devices. It's a good system, and the same could be done on the P2.
It's not often mentioned, but the nRES pin on the Prop1 is an open-drain output, when nBOE is grounded, in addition to being an active-low reset input. So on power-up, it gets pulled down and can be used to reset external devices. It's a good system, and the same could be done on the P2.
-Phil
Yes, I know this, but is not of much help. After power-up nearly every external part is initialized on its default state. Unfortunately this is not true after an internal software reset eg because of the watchdog timeout.
... and enabling BOE enables its mechanism which resets the prop under certain voltage level which is some times not desirable eg on battery powered devices that can run the application below the voltage threshold.
T7 would need to handle the normal current load of the Propeller with an appropriate gain.
That's quite an approach! I never thought of dropping GND. I think it would mess up ADC and DAC performance, though, even if you did have a jumper to apply for normal use. For brief instances during normal operations, multiple amps might flow through GND. That would cause voltage shifts on GND and make the analog noisy. I thought about just scaling the 1.44um fuse length by 3.3V/5V (width = 0.18um) to make the impedance lower, so that 3.3V would have the same effect as 5V, but all these fuses in different technologies seem to keep an 8:1 length:width ratio. There must be some need for that. At least, it's deemed most reliable.
I though lots more pins was the primary, number one, most important, essential requirement for the P2. It was certainly the most sought after feature by P1 users.
Second most important requirement is then more RAM.
Third being more performance. In terms of clock rate, cores and execute from HUB.
All else is just fluff.
Whilst I'm here. I consider the fuses to be an anti-feature. Years ago I ended up with a pile of AVR's that I could no longer use as their fuses had been set wrong [1]. In frustration I looked for something else. And that's how I found the Propeller.
[1] Yeah I know. Mostly my fault for insisting on using my own home made programmer hardware and opensource programming tools on Linux. But still.
I though lots more pins was the primary, number one, most important, essential requirement for the P2. It was certainly the most sought after feature by P1 users.
Another approach to 'more IO pins' would be for Parallax to offer an IO Expander, along with a Library for P1.
Choices could be a modest MCU, or a small CPLD.
Cheapest 44 pin MCU I can find is AT89LP51-20MU, 62c/100 for under 2c/io, that can link using SPI to a COG.
For more pins, or faster links, the LAMXO256C-3TN100E (TQFP100) shows as being $1.75/100 with 78 I/O, or just over 2c/io
The LAMXO256C-3TN100E price shows at many Disti, and on Lattice website, but other family members are more $, - perhaps that's the preferred item, tho not stocks are huge ?
LCMXO256C-3TN100C shows at $2.20/1k, and LCMXO2-256HC-4SG48C is $2.75/1k
I meant more pins as more than the 32 on the P1. Especially as the P1 was all set to get 64 pins in some future version which never happened.
I/O expanders are great and all. But then you lose the tight coupling between processor and I/O which is one of the Propellers unique selling points. I have certainly wanted to bit bang more than 32 pins with the speed and ease that that the Propeller can do.
I though lots more pins was the primary, number one, most important, essential requirement for the P2. It was certainly the most sought after feature by P1 users.
Another approach to 'more IO pins' would be for Parallax to offer an IO Expander, along with a Library for P1.
Choices could be a modest MCU, or a small CPLD.
Cheapest 44 pin MCU I can find is AT89LP51-20MU, 62c/100 for under 2c/io, that can link using SPI to a COG.
For more pins, or faster links, the LAMXO256C-3TN100E (TQFP100) shows as being $1.75/100 with 78 I/O, or just over 2c/io
The LAMXO256C-3TN100E price shows at many Disti, and on Lattice website, but other family members are more $, - perhaps that's the preferred item, tho not stocks are huge ?
LCMXO256C-3TN100C shows at $2.20/1k, and LCMXO2-256HC-4SG48C is $2.75/1k
That was considered some years ago on this forum and went nowhere. Lots of talk then silence.
The problem is if you scaled up the CPLD/FPGA just a bit, the P1 was no longer necessary. Since all the FPGA vendors provide their own soft MCU cores that range from 8 to 32bits with real time options - all you had to do is roll in a couple of those cores into your VHDL or Verilog code and you have your own homebrew P1 alternative and don't have to worry if the P2 never gets made. which may be the case now,
The other issue was, if the P1 needed that much help, maybe it's time to consider another more modern MCU that has the I/O lines.
I meant more pins as more than the 32 on the P1. Especially as the P1 was all set to get 64 pins in some future version which never happened.
I/O expanders are great and all. But then you lose the tight coupling between processor and I/O which is one of the Propellers unique selling points. I have certainly wanted to bit bang more than 32 pins with the speed and ease that that the Propeller can do.
Of course, there is no free lunch, there is some speed penalty for IO.
A quick napkin test, suggests AT89LP51-20MU can do a 32b Read and Write in just under 20us, clocked from P2 5MHz, consumes 3 SPI pins to do so.
Plenty of IO tasks are fine with 20us R&W, (keyboards, LEDs, relays, Power control etc) and those that do need highest speed you map on the P1, not the IO expander.
We currently buy around a 100 propeller chips a year, and if the learning curve is not too difficult and the advantages manifest, we would begin to switch over to propeller 2. In a few years we would like to be buying 1000's.
XMOS aquired setem http://www.eedesignnewseurope.com/news/xmos-acquires-setem-technologies-further-develops-voice-hmi-focus
I just read an article on beam forming to follow speakers in a crowd. P2 with all the analog input capabilities could be the base for such a solution that can detect signal sources due to the fact, that more mikes can be attached and the phase relations between different signals could be determined by the parallel working cogs.
I noticed that the "Firsties" (FIRST Robotic Competitors) don't always use their sponsors products.
Perhaps it is time for some of that business to come back to Parallax.
Thank you for the recognition. Truthfully, I think there are valid reasons for many to switch over to Parallax. Organized travel and competition isn't really one of them (which is a strength of FIRST) but the following reasons are:
- parallel Blockly/C tutorials means every student has something of interest
- Propeller Multicore support with a focus on electronics, sensors and programming
- free tutorials and assessment material for elementary through high school
- a one robot per student model at less than $200/kit (with ActivityBot); every student gets experience
- plenty of add-ons (ultrasonic scanning sensors, line followers) for in-class competitions
- the most complete (and free) Blockly system
- Chromebook support
- a product line with depth, allowing students forward progression to product development
We're currently noticing an increase in our business. Professional development courses around the country are filled; we're out of ActivityBots; new customers are asking many questions and switching over from other platforms. We haven't seen this kind of activity in years so it's encouraging.
We're currently noticing an increase in our business. Professional development courses around the country are filled; we're out of ActivityBots; new customers are asking many questions and switching over from other platforms. We haven't seen this kind of activity in years so it's encouraging.
Wow! That's great news. Congratulations! Finally people seem to be seeing the value of your excellent products and support.
Coming back to the original question of this thread, asking for Prop II applications:
We are using the Prop 1 in small quantities as main processor in a measurement instrument for several years now.
It works fine and is reliable, software maintenance is easy (Spin + ASM).
For the Prop II (which I hope, will come into my hands before my retirement) I see the best application as very, very intelligent I/O processor
as realtime slave of an ARM XXX running with Linux or similar. We have such project/board in our drawer for years, realized with the Prop I as prototype,
but still waiting for the Prop II. By the way: will the Prop II also be produced in Austria?
Regards
Markus
I raised the same question earlier, but I'm at a loss to trace where that idea came from. It does seem that AMS was mentioned at one time as a possible fab, though.
Comments
- Dave Heins "Translater" fom P1-PropGCC to P2
- Erics ZPU Interpreter
- Erics RISC-V Emulator
Andy
Sadly I can't. The longest C program I ever wrote fits for sure on one or two pages if you print it.
Some COBOL programs I work on, on the other hand might not be printable at all, with printers available to me.
Over the last decade I got quite fluent in C#, but never had a employment needing me to use C/C++. And just playing around with a Language - hmm- never gets you to understand it even partially. Not like if you are working daily over weeks/month/years/decades with it.
For me PropGCC will just be a tool to get COBOL programs running on the P2. I think some features of COBOL would fit quite nicely for stuff I am doing on MCs.
The SCREEN SECTION for example. Nice TUI interfaces, easy defined. Same for the REPORT SECTION. Nice Reports with Groups and all that, easy defined. DB access build into the language if you can live with ISAM or relative/sequential/dynamic files. Sorting, filtering all build in.
And since GnuCobol translates to C/C++ interfacing C or other languages is not so complicated.
Enjoy!
Mike
The library can be copied from the latest P1 PropGCC version. Maybe this is doable by mere mortals. The linker probably needs a lot of work given the variety of instruction formats used by the P2. Someone that understands the ELF format would need to do that work.
I forgot about it, YES, eric did already a ZPU emulator, so GCC can already run on a P2.
Theoretically.
Mike
I think it's more in practice than your COBOL plans...
Elsewhere, more pins was also mentioned as a goal.
@Ariba,
yes, sadly. I tried with P1 and PropGCC but my C-fu and Linux-fu is underdeveloped.
The GnuCobol Project is mostly supported by Linux guys, and I have already a hard time to run it on Windows.
But I am confident to get there. And I am in no hurry, because I do not need it at all, its just for fun.
@bobjr,
YES, thank you!
That was what I was referring to.
And welcome to the forum.
Enjoy!
Mike
And you have to speak 'Theoretically' in that Russian accent, like in the movie.
Actually someone got a GnuCobol generated C Program running on some Arduino, with some 'Mesa' Build System and replacing XXX.h files and then he lost me in his description.
Mike
It have not to map to anything. It will be useful that by issuing an internal software reset, beside the prop, the external hardware can be reset also. to bring the external peripherals to their default state.
-Phil
Yes, I know this, but is not of much help. After power-up nearly every external part is initialized on its default state. Unfortunately this is not true after an internal software reset eg because of the watchdog timeout.
... and enabling BOE enables its mechanism which resets the prop under certain voltage level which is some times not desirable eg on battery powered devices that can run the application below the voltage threshold.
Would a Charge pump approach work if the Charge pump itself were integrated into the programmer?
See Schematic link below:
bscircuitdesigns.com/Misc/Propeller_2_Fuse_Programmer_Charge_Pump_Approach.pdf
T7 would need to handle the normal current load of the Propeller with an appropriate gain.
That's quite an approach! I never thought of dropping GND. I think it would mess up ADC and DAC performance, though, even if you did have a jumper to apply for normal use. For brief instances during normal operations, multiple amps might flow through GND. That would cause voltage shifts on GND and make the analog noisy. I thought about just scaling the 1.44um fuse length by 3.3V/5V (width = 0.18um) to make the impedance lower, so that 3.3V would have the same effect as 5V, but all these fuses in different technologies seem to keep an 8:1 length:width ratio. There must be some need for that. At least, it's deemed most reliable.
That's correct. Additional I/O is also a common request.
Second most important requirement is then more RAM.
Third being more performance. In terms of clock rate, cores and execute from HUB.
All else is just fluff.
Whilst I'm here. I consider the fuses to be an anti-feature. Years ago I ended up with a pile of AVR's that I could no longer use as their fuses had been set wrong [1]. In frustration I looked for something else. And that's how I found the Propeller.
[1] Yeah I know. Mostly my fault for insisting on using my own home made programmer hardware and opensource programming tools on Linux. But still.
Another approach to 'more IO pins' would be for Parallax to offer an IO Expander, along with a Library for P1.
Choices could be a modest MCU, or a small CPLD.
Cheapest 44 pin MCU I can find is AT89LP51-20MU, 62c/100 for under 2c/io, that can link using SPI to a COG.
For more pins, or faster links, the LAMXO256C-3TN100E (TQFP100) shows as being $1.75/100 with 78 I/O, or just over 2c/io
The LAMXO256C-3TN100E price shows at many Disti, and on Lattice website, but other family members are more $, - perhaps that's the preferred item, tho not stocks are huge ?
LCMXO256C-3TN100C shows at $2.20/1k, and LCMXO2-256HC-4SG48C is $2.75/1k
I/O expanders are great and all. But then you lose the tight coupling between processor and I/O which is one of the Propellers unique selling points. I have certainly wanted to bit bang more than 32 pins with the speed and ease that that the Propeller can do.
That was considered some years ago on this forum and went nowhere. Lots of talk then silence.
The problem is if you scaled up the CPLD/FPGA just a bit, the P1 was no longer necessary. Since all the FPGA vendors provide their own soft MCU cores that range from 8 to 32bits with real time options - all you had to do is roll in a couple of those cores into your VHDL or Verilog code and you have your own homebrew P1 alternative and don't have to worry if the P2 never gets made. which may be the case now,
The other issue was, if the P1 needed that much help, maybe it's time to consider another more modern MCU that has the I/O lines.
A quick napkin test, suggests AT89LP51-20MU can do a 32b Read and Write in just under 20us, clocked from P2 5MHz, consumes 3 SPI pins to do so.
Plenty of IO tasks are fine with 20us R&W, (keyboards, LEDs, relays, Power control etc) and those that do need highest speed you map on the P1, not the IO expander.
I just read an article on beam forming to follow speakers in a crowd. P2 with all the analog input capabilities could be the base for such a solution that can detect signal sources due to the fact, that more mikes can be attached and the phase relations between different signals could be determined by the parallel working cogs.
Perhaps it is time for some of that business to come back to Parallax.
Thank you for the recognition. Truthfully, I think there are valid reasons for many to switch over to Parallax. Organized travel and competition isn't really one of them (which is a strength of FIRST) but the following reasons are:
- parallel Blockly/C tutorials means every student has something of interest
- Propeller Multicore support with a focus on electronics, sensors and programming
- free tutorials and assessment material for elementary through high school
- a one robot per student model at less than $200/kit (with ActivityBot); every student gets experience
- plenty of add-ons (ultrasonic scanning sensors, line followers) for in-class competitions
- the most complete (and free) Blockly system
- Chromebook support
- a product line with depth, allowing students forward progression to product development
We're currently noticing an increase in our business. Professional development courses around the country are filled; we're out of ActivityBots; new customers are asking many questions and switching over from other platforms. We haven't seen this kind of activity in years so it's encouraging.
But I work at Parallax, so it's best heard from an educator https://www.parallax.com/news/2017-07-13/customers-applaud-blocklyprop-fall-semester-promises-be-most-exciting-ever-our
Thank you again for the plug.
Ken Gracey
We are using the Prop 1 in small quantities as main processor in a measurement instrument for several years now.
It works fine and is reliable, software maintenance is easy (Spin + ASM).
For the Prop II (which I hope, will come into my hands before my retirement) I see the best application as very, very intelligent I/O processor
as realtime slave of an ARM XXX running with Linux or similar. We have such project/board in our drawer for years, realized with the Prop I as prototype,
but still waiting for the Prop II. By the way: will the Prop II also be produced in Austria?
Regards
Markus
-Phil