We will have prototypes back in September. If it works, we will get more dice packaged, so that we can get people started.
Glad to "hear" that, Chip! I can't wait to get my hands on one, to calculate prime numbers. It would be nice to see a C/C++ tool too, although I can't contribute even to that. It is unfortunate, though, that a 16 core version was not possible, but that's understandable. Cores and smartpins take die space, and you can't have both.
IMHO, it is a matter of time that someone builds a multipurpose lab tool (oscilloscope, waveform generator, network analyzer, etc) around this Chip. Probably, I'm not that one (or perhaps I will), because I have many projects to finish. Seeing the specs, this chip begs for it. I hope the DACs have good specs for it. I'm not planning to use the PWM in that context, by the way.
I've probably bought 100-200 Prop 1 boards and usually keep 20 or so in stock for different projects.
I'll for sure buy several Prop2 boards to play with soon as it's released. If it proves to be as ground breaking as the Prop 1 was back in 2006, I'll use it some new projects. Many projects I do, don't even begin to push the limits of the Prop1.
For really simple projects I sometimes use a PIC, but many projects I reach for Propeller Proto board, Prop Mini or Prop FLiP because projects are so easy to get up and running using the Propeller Spin.
I probably won't ever be a volume user, but you never know.
Sorry, I have to admit that haven't read the P2 forum for a long time. I gave up after the P2 release date was delayed for so many times. Now, I saw by chance that there is hope that the P2 will finally make it into real silicon this autumn. Very good news!
I will surely buy a few to play around. I also have a product that might benefit from the P2. It currently uses the P1 (what else?) but due to memory constraints there is not much room for improvements. It is a CNC controller of which I sell 500 to 1000 units per year. If the P2 is not too expensive I consider migration to the P2. More memory and speed would allow more buffer capacity and therefore finer interpolation time slices and also new features like high speed laser engraving which is not supported so far.
However, I fear I will hesitate to start completely new projects on the P2. The main reason are not the capabilities of the chip itself but the programming tools. I like the propeller and it's surely the processor where programming is the most fun! But I have to complain that I wasted a lot of time for debugging, because there is no really user friendly debugger. In the Intel or ARM world we are spoiled with IDEs that support breakpoints, single stepping, variable dumps or even real time monitoring. On the propeller we are used to manual prints to the serial terminal.
I think the success of the P2 will mainly depend on the tools suporting it.
I've been itching to make the best stepper motor controller with the P2 for our business. Using cell-phone chips like the ARM's just aren't quite good enough. The P1 was always too tight on the math loop for me to be comfortable. I've been trying to be as patient as possible the past few years.... so yes, I'll be buying a few.
... It is a CNC controller of which I sell 500 to 1000 units per year. If the P2 is not too expensive I consider migration to the P2. More memory and speed would allow more buffer capacity and therefore finer interpolation time slices and also new features like high speed laser engraving which is not supported so far.
P2 Price indications have it easily inside the CNC Controller application area....
However, I fear I will hesitate to start completely new projects on the P2. The main reason are not the capabilities of the chip itself but the programming tools. I like the propeller and it's surely the processor where programming is the most fun! But I have to complain that I wasted a lot of time for debugging, because there is no really user friendly debugger. In the Intel or ARM world we are spoiled with IDEs that support breakpoints, single stepping, variable dumps or even real time monitoring. On the propeller we are used to manual prints to the serial terminal.
What software do you use now, on P1 ?
P2 does have additional debug hardware, but not to the extent of a custom Debug-link, it uses a smart pin instead.
There are already examples of how the Debug HW can be supported.
Now, I saw by chance that there is hope that the P2 will finally make it into real silicon this autumn. Very good news!
...
I think the success of the P2 will mainly depend on the tools suporting it.
That's true of almost all chips, to some extent, but Ardunio made it a surprisingly long way with quite poor debug support.
I'd say the P2 Software is already in quite good shape. Look into a few threads and you'll find Assembler/Compilers/Simulators... all being tested
Nah, the Crow guys are just shipping a bunch of parts in a nice box. They are riding on the coat tails of the 20 million sales and fame of the Raspberry Pi-
But a P1 or P2 might be a nice part for their box. I thought there were a bunch of people here who were into having a self contained system like this for the Prop. Maybe electronics enthusiasts would be into it as well. I think that it's part of the appeal of a system like the Piper Minecraft box. If you stick a prop in the box then you can use all of the educational materials that Parallax has already developed - maybe with some doc tweaks if a PC isn't in the loop.
...I thought there were a bunch of people here who were into having a self contained system like this for the Prop.
I am most definitely one of them! But I've always fancied header boards. My uses are often obscure, atypical, or inflexible. It usually works out best if I provide the ancillary hardware.
Count me in for at least 1. I have over a dozen p1's in various forms, and although I have been away for a while, I am glad to see that the P2 is finally coming out.
I am most definitely one of them! But I've always fancied header boards. My uses are often obscure, atypical, or inflexible. It usually works out best if I provide the ancillary hardware.
I will probably buy a few... if the cost per P2 + header board (with any SMT components already soldered but leaving the header positions unpopulated) is in the $20-$25 range. Is that too little?
My reason for joining the Propeller world was to write an IBM 1130 emulator (still a work in progress, but almost done )
I think a reasonable System/360 emulator could be done on the P2.
I already have P1 code for emulating the 1403 printer and 2501 card readers. There should be enough ram available to support a 256K machine.
The big issue I had with the 1130 was disk emulation. Using flash memory turned out to be an issue due to wear. I'm currently using SPI memory chips (8 x 128k) for the disk... but that's only one megabyte. Fine for the 1130 but I'm looking into what I can do for emulating the much larger drives on the 360.
This would allow for COBOL to be run on the P2. (Yes, COBOL did run on the 1130. But I never found a disk image that would work, all of the ones provided required 1132 printer support).
Walter
...
The big issue I had with the 1130 was disk emulation. Using flash memory turned out to be an issue due to wear. I'm currently using SPI memory chips (8 x 128k) for the disk... but that's only one megabyte. Fine for the 1130 but I'm looking into what I can do for emulating the much larger drives on the 360.
ISSI have 2M and 4M SPI SRAMS, The 2M (IS62WVS2568GB = 45MHz) are already stocked and 4M show as coming at mouser next month. (initially in 20MHz)
I also see Digikey have more esoteric options in stock at 4M,
IC ReRAM 4M SPI 5MHZ 8SOP
IC FRAM 4M SPI 108MHZ 16SOP
IC MRAM 4M SPI 50MHZ 8DFN
IC FRAM 4M SPI 40MHZ 8TDFN
...
The big issue I had with the 1130 was disk emulation. Using flash memory turned out to be an issue due to wear. I'm currently using SPI memory chips (8 x 128k) for the disk... but that's only one megabyte. Fine for the 1130 but I'm looking into what I can do for emulating the much larger drives on the 360.
ISSI have 2M and 4M SPI SRAMS, The 2M (IS62WVS2568GB = 45MHz) are already stocked and 4M show as coming at mouser next month. (initially in 20MHz)
I also see Digikey have more esoteric options in stock at 4M,
IC ReRAM 4M SPI 5MHZ 8SOP
IC FRAM 4M SPI 108MHZ 16SOP
IC MRAM 4M SPI 50MHZ 8DFN
IC FRAM 4M SPI 40MHZ 8TDFN
By "much larger" drives I'm referring to the ~29Mb "2314" drives (~29x larger).
The 4M SPI chips hold 4 megabits each = 512K bytes, so I would need ~58 chips to emulate a single drive. Don't have pricing yet.
The 2M SPI chips hold half of that, so I'd need ~116 chips. At $3 each (quantity price) that's well over $300. Ouch. Granted, that's much cheaper than a real 2314 drive cost
I also have looked at the FRAM chips at Mouser, but they're far more expensive @ $19 and up.
Unless you've concerns about using BGA packages, if you intend to finalize your P1 project and have almost no pins to spare, there is a low-cost solution for your (~29 MB), 2314 drive simulation.
ISSI is already mass producing IS66WVH16M8BLL, a 16M x 8, 3.0V I/O, 11 signaling lines (12 if you intend to have their RESET# line under software control) Hyperram chip. Mouser has it available at US$ 6.58 in single quantities.
For a full 32 MBytes you'll need two of them and just another P1 (to achieve , simultaneously, a low pin count and your prefered serialized kind of interface, among the ones P1 is already capable to shine).
Apart from the extra passive components (caps and perhaps some resistors too), to achieve an independent card simulation, another crystal or cmos oscillator, a voltage regulator and an EEprom would be needed.
Differential line drivers/receivers at both ends, some lenght of twisted cable, and you could even run your own external disk drive unit.
Other than some layout concerns (not too hard to do, since you'll don't even tackle the limits of Hyperbus speeds, using a P1), each newly added 16 MB will cost only a single output pin, to control CE#s independently.
Two memory chips, running at the same time, could share single CE#, RESET# and CK control lines, thus giving you a total of 16 paralleled bits in each bus transaction. This aproach would consume 21 I/O lines (You'll need two RWDS-dedicated I/O lines, due to Hyperbus interface requirements) for each full drive simulation, with 3 MBytes of spare (hidden, system, your choice of) 'disk' space.
There are also some hard/soft examples, crafted by Richard Morrison (@RJSM), so you don't have to start from scratch:
How much is the shelf price of the P2 going to be, after the initial release? I notice that things like the P2 go down in price after a while, presumably because the costs of creation and initial marketing are covered. Given the enormity of the P2, no doubt there will be an initial "surge", after which units will go down in price.
How much is the shelf price of the P2 going to be, after the initial release? I notice that things like the P2 go down in price after a while, presumably because the costs of creation and initial marketing are covered. Given the enormity of the P2, no doubt there will be an initial "surge", after which units will go down in price.
Quote from Chip:
Not sure, but probably $8..$10, qty 1. Maybe $6 at 1k.
Unless you've concerns about using BGA packages, if you intend to finalize your P1 project and have almost no pins to spare, there is a low-cost solution for your (~29 MB), 2314 drive simulation.
ISSI is already mass producing IS66WVH16M8BLL, a 16M x 8, 3.0V I/O, 11 signaling lines (12 if you intend to have their RESET# line under software control) Hyperram chip. Mouser has it available at US$ 6.58 in single quantities.
Hi Henrique -
Thanks for the information.
There's a bit of confusion here. My 1130 project is mostly done, just cleanup code (random hangs when using the console printer, for example). My 1130 will run on a single disk (2315), 1MB capacity. I even managed to provide support for the 1627 plotter*.
It's the future System/360 emulation project that needs the larger disk drive(s). The 1130 emulator runs on a single P1**; the System/360 is far more complicated (registers, addressing modes, character string handling, etc.) and will require the P2's increased memory size (for ram) and hub execution (or whatever it's called now) for the CPU emulation.
And yes, I do have concerns about BGA packages. If it's not DIP or certain SMT packages, there's no way for me to solder them. Basically, it has to be breadboard-friendly or at least have an adapter board available to convert it to DIP spacing.
Thanks,
Walter
*I write out the plotter's commands as text to an SD card and then use a C# program to create a bitmap from the output. Since the 1627 was a drum plotter, it could create output as long as the paper roll itself.
**Yes, the console printer itself (an altered electronic typewriter) has its own P1 for printing and reading the keyboard independently of the typewriter's controller circuitry. But that won't change for the 360; both used the same type of printing mechanism.
Unless you've concerns about using BGA packages, if you intend to finalize your P1 project and have almost no pins to spare, there is a low-cost solution for your (~29 MB), 2314 drive simulation.
ISSI is already mass producing IS66WVH16M8BLL, a 16M x 8, 3.0V I/O, 11 signaling lines (12 if you intend to have their RESET# line under software control) Hyperram chip. Mouser has it available at US$ 6.58 in single quantities.
Hi Henrique -
And yes, I do have concerns about BGA packages. If it's not DIP or certain SMT packages, there's no way for me to solder them.
If you are happy with PS-SDRAM, (ie refresh/timing rules) then there is also this one in So8 - ( 64Mb), so you need 4 for 32MB, but price is quite good.
Looks to define CSW < 8us and CSH > 18ns https://www.electrodragon.com/product/2pcs-ipus-ips6404-iot-ram/
Hi
I got all excited when I saw TWO 64Mbit rams for £1.25! (uk money)
I had been playing with 23lc1024's truely static rams but they only have small capacity - 1Mbit.
I downloaded data sheet and saw the significance of your remark 'Looks to define CSW < 8us and CSH > 18ns'
Now- if I understand this correctly the chip works as follows-
to read or write start with lowering chip select.
then clock in command- 8 bits, and address 24 bits, then (maybe 8 clocks wait cycles in fast mode)
then data.
So- 8 + 24 + (8 in fast mode) + (8*number of bytes to read/write). 32 clocks before data sent/received
Raise chip select terminates the operation and allows the chip to do a refresh.
I'll ignore fast mode....
CSW < 8us means the longest time CS can be low is 8us in order that the ram can refresh
The refresh time required is only CSH 18ns and then another command can be executed.
In that 8 us the command, address,and data must be communicated.
'Say' the prop could send/receive spi at 5 Mbits/sec (20M ips @ 4 instructions per data bit? (a guess))
In 8 us thats 40 bits, just enough to send/recieve ONE byte!!! (8 + 24 + 8 = 40)
Of course thats just single spi
for quad spi then (8+24)/4 + 2 per byte= 16 bytes (40 bits window - 8 for cmd+data = 32/2=16)
or put another way-
at 4 bits/clock thats ((8/4)=2 + (24/4)=6) = 8 +(2 per byte). So clocks left for data is 40-8=32 and at 2 per bye = 32/2 = 16 bytes
CSH of 18ns is less than one prop instruction (4 clocks=50ns=20 mips) so for simplicity will ignore that, the CS hi/ CS lo takes longer than that.
So you end up in a tight loop CS low, cmd, address + 1 (or 16) bytes sent/received, CS hi.
At single spi thats 1 byte in 8 us (128 KB/s)
in quad spi thats 16 bytes in 8 us (2 MB/s)
Are those numbers about right, or are my sums/assumptions amiss?
(prepares to be shot down in flames..)
I got all excited when I saw TWO 64Mbit rams for £1.25! (uk money)
I had been playing with 23lc1024's truely static rams but they only have small capacity - 1Mbit.
There are also variant parts, like this LY68L6400SLIT that seems to have dropped in price since I last checked.
...
Are those numbers about right, or are my sums/assumptions amiss?
Very close, there is also a WAIT slot for READ, but that's clocks only, not data, so can deliver a little faster.
basically, the higher the MHz the better, and a 96MHz prop can do more than a 80MHz one. QUAD mode is pretty much mandatory.
On parts that are not DDR based, a design might choose to add a XNOR-Schmitt (1G57 etc), to allow a clock-pulse per edge, shaving one opcode.
You might also find a timer could be carefully phased to generate some clocks ?
Because these parts force frequent CSH to allow auto refresh, it's a shame they forgot to allow a continue read opcode, which would have shaved clocks off by skip of address-re-write.
Probably this was vaguely answered, but I can't find it. Anyway, here it goes my silly question: is there any planning for a C/C++ compiler tool chain in the near or far future, for the P2? It would be important for me to have P2 supported in C and C++, and this may affect my decision on doing projects around the P2 or not. However, I don't want to push this boat into a given direction.
As for Chip's generous offer, I think I have failed to show my gratitude in the best way. I can't wait to buy one, but it will probably next year.
Probably this was vaguely answered, but I can't find it. Anyway, here it goes my silly question: is there any planning for a C/C++ compiler tool chain in the near or far future, for the P2? It would be important for me to have P2 supported in C and C++, and this may affect my decision on doing projects around the P2 or not. However, I don't want to push this boat into a given direction.
As for Chip's generous offer, I think I have failed to show my gratitude in the best way. I can't wait to buy one, but it will probably next year.
Kind regards, Samuel Lourenço
There is no concrete plan for C tools for the Prop2 at this time.
But you do plan on having C tools at some point, right? Just like there is not a concrete plan for Spin tools for the Prop2, but you do plan on supporting Spin, correct?
But you do plan on having C tools at some point, right? Just like there is not a concrete plan for Spin tools for the Prop2, but you do plan on supporting Spin, correct?
Of course. We just don't have an actionable plan and money to make it happen.
Comments
OBC, where have you been? Missed you!
IMHO, it is a matter of time that someone builds a multipurpose lab tool (oscilloscope, waveform generator, network analyzer, etc) around this Chip. Probably, I'm not that one (or perhaps I will), because I have many projects to finish. Seeing the specs, this chip begs for it. I hope the DACs have good specs for it. I'm not planning to use the PWM in that context, by the way.
Kind regards, Samuel Lourenço
I'll for sure buy several Prop2 boards to play with soon as it's released. If it proves to be as ground breaking as the Prop 1 was back in 2006, I'll use it some new projects. Many projects I do, don't even begin to push the limits of the Prop1.
For really simple projects I sometimes use a PIC, but many projects I reach for Propeller Proto board, Prop Mini or Prop FLiP because projects are so easy to get up and running using the Propeller Spin.
I probably won't ever be a volume user, but you never know.
P2 is Propeller 2 Multicore Microcontroller
Look at this forum area
https://forums.parallax.com/categories/propeller-2-multicore-microcontroller
and P2 DOCs are linked in first post of
https://forums.parallax.com/discussion/162298/prop2-fpga-files-updated-2-june-2018-final-version-32i/p1
I will surely buy a few to play around. I also have a product that might benefit from the P2. It currently uses the P1 (what else?) but due to memory constraints there is not much room for improvements. It is a CNC controller of which I sell 500 to 1000 units per year. If the P2 is not too expensive I consider migration to the P2. More memory and speed would allow more buffer capacity and therefore finer interpolation time slices and also new features like high speed laser engraving which is not supported so far.
However, I fear I will hesitate to start completely new projects on the P2. The main reason are not the capabilities of the chip itself but the programming tools. I like the propeller and it's surely the processor where programming is the most fun! But I have to complain that I wasted a lot of time for debugging, because there is no really user friendly debugger. In the Intel or ARM world we are spoiled with IDEs that support breakpoints, single stepping, variable dumps or even real time monitoring. On the propeller we are used to manual prints to the serial terminal.
I think the success of the P2 will mainly depend on the tools suporting it.
-Parsko (I'm still around!)
What software do you use now, on P1 ?
P2 does have additional debug hardware, but not to the extent of a custom Debug-link, it uses a smart pin instead.
There are already examples of how the Debug HW can be supported.
That's true of almost all chips, to some extent, but Ardunio made it a surprisingly long way with quite poor debug support.
I'd say the P2 Software is already in quite good shape. Look into a few threads and you'll find Assembler/Compilers/Simulators... all being tested
just some examples:
https://forums.parallax.com/discussion/161755/p2-simulator
https://forums.parallax.com/discussion/164187/fastspin-compiler-for-p2#latest
https://forums.parallax.com/discussion/166470/cant-wait-for-propgcc-on-the-p2#latest
https://forums.parallax.com/discussion/168693/spin2#latest
and the BOOT ROM was 'filled up'...
https://forums.parallax.com/discussion/167868/taqoz-tachyon-forth-for-the-p2-boot-rom#latest
https://forums.parallax.com/discussion/168406/p2-monitor-debug-for-possible-inclusion-in-the-rom#latest
https://forums.parallax.com/discussion/168337/p2-sd-boot-code-v32#latest
Not compilers, but a good silicon-exerciser example :
https://forums.parallax.com/discussion/163830/usb-testing#latest
https://www.kickstarter.com/projects/elecrow/crowpi-lead-you-go-from-zero-to-hero-with-raspberr/posts/2203148
I wonder if someone could catch Elecrow's attention with the P1 or P2? Parallax's education courses have so much information already developed.
My reason for joining the Propeller world was to write an IBM 1130 emulator (still a work in progress, but almost done
I think a reasonable System/360 emulator could be done on the P2.
I already have P1 code for emulating the 1403 printer and 2501 card readers. There should be enough ram available to support a 256K machine.
The big issue I had with the 1130 was disk emulation. Using flash memory turned out to be an issue due to wear. I'm currently using SPI memory chips (8 x 128k) for the disk... but that's only one megabyte. Fine for the 1130 but I'm looking into what I can do for emulating the much larger drives on the 360.
This would allow for COBOL to be run on the P2. (Yes, COBOL did run on the 1130. But I never found a disk image that would work, all of the ones provided required 1132 printer support).
Walter
I also see Digikey have more esoteric options in stock at 4M,
IC ReRAM 4M SPI 5MHZ 8SOP
IC FRAM 4M SPI 108MHZ 16SOP
IC MRAM 4M SPI 50MHZ 8DFN
IC FRAM 4M SPI 40MHZ 8TDFN
The 4M SPI chips hold 4 megabits each = 512K bytes, so I would need ~58 chips to emulate a single drive. Don't have pricing yet.
The 2M SPI chips hold half of that, so I'd need ~116 chips. At $3 each (quantity price) that's well over $300. Ouch. Granted, that's much cheaper than a real 2314 drive cost
I also have looked at the FRAM chips at Mouser, but they're far more expensive @ $19 and up.
Unless you've concerns about using BGA packages, if you intend to finalize your P1 project and have almost no pins to spare, there is a low-cost solution for your (~29 MB), 2314 drive simulation.
ISSI is already mass producing IS66WVH16M8BLL, a 16M x 8, 3.0V I/O, 11 signaling lines (12 if you intend to have their RESET# line under software control) Hyperram chip. Mouser has it available at US$ 6.58 in single quantities.
For a full 32 MBytes you'll need two of them and just another P1 (to achieve , simultaneously, a low pin count and your prefered serialized kind of interface, among the ones P1 is already capable to shine).
Apart from the extra passive components (caps and perhaps some resistors too), to achieve an independent card simulation, another crystal or cmos oscillator, a voltage regulator and an EEprom would be needed.
Differential line drivers/receivers at both ends, some lenght of twisted cable, and you could even run your own external disk drive unit.
Other than some layout concerns (not too hard to do, since you'll don't even tackle the limits of Hyperbus speeds, using a P1), each newly added 16 MB will cost only a single output pin, to control CE#s independently.
Two memory chips, running at the same time, could share single CE#, RESET# and CK control lines, thus giving you a total of 16 paralleled bits in each bus transaction. This aproach would consume 21 I/O lines (You'll need two RWDS-dedicated I/O lines, due to Hyperbus interface requirements) for each full drive simulation, with 3 MBytes of spare (hidden, system, your choice of) 'disk' space.
There are also some hard/soft examples, crafted by Richard Morrison (@RJSM), so you don't have to start from scratch:
https://forums.parallax.com/discussion/166850/boost-your-propellers-memory-256x-from-32kb-8mb#latest
https://forums.parallax.com/discussion/166802/hyperram-solutions-for-p2-and-p1/p1
Hope it helps a bit
Henrique
Quote from Chip: https://forums.parallax.com/discussion/166686/p2-cost/p1
But we will not know until the actual chip is produced. The price would have to be set based on yields, packaging, world economy, tarrifs and such.
Hi Henrique -
Thanks for the information.
There's a bit of confusion here. My 1130 project is mostly done, just cleanup code (random hangs when using the console printer, for example). My 1130 will run on a single disk (2315), 1MB capacity. I even managed to provide support for the 1627 plotter*.
It's the future System/360 emulation project that needs the larger disk drive(s). The 1130 emulator runs on a single P1**; the System/360 is far more complicated (registers, addressing modes, character string handling, etc.) and will require the P2's increased memory size (for ram) and hub execution (or whatever it's called now) for the CPU emulation.
And yes, I do have concerns about BGA packages. If it's not DIP or certain SMT packages, there's no way for me to solder them. Basically, it has to be breadboard-friendly or at least have an adapter board available to convert it to DIP spacing.
Thanks,
Walter
*I write out the plotter's commands as text to an SD card and then use a C# program to create a bitmap from the output. Since the 1627 was a drum plotter, it could create output as long as the paper roll itself.
**Yes, the console printer itself (an altered electronic typewriter) has its own P1 for printing and reading the keyboard independently of the typewriter's controller circuitry. But that won't change for the 360; both used the same type of printing mechanism.
If you are happy with PS-SDRAM, (ie refresh/timing rules) then there is also this one in So8 - ( 64Mb), so you need 4 for 32MB, but price is quite good.
Looks to define CSW < 8us and CSH > 18ns
https://www.electrodragon.com/product/2pcs-ipus-ips6404-iot-ram/
I got all excited when I saw TWO 64Mbit rams for £1.25! (uk money)
I had been playing with 23lc1024's truely static rams but they only have small capacity - 1Mbit.
I downloaded data sheet and saw the significance of your remark 'Looks to define CSW < 8us and CSH > 18ns'
Now- if I understand this correctly the chip works as follows-
to read or write start with lowering chip select.
then clock in command- 8 bits, and address 24 bits, then (maybe 8 clocks wait cycles in fast mode)
then data.
So- 8 + 24 + (8 in fast mode) + (8*number of bytes to read/write). 32 clocks before data sent/received
Raise chip select terminates the operation and allows the chip to do a refresh.
I'll ignore fast mode....
CSW < 8us means the longest time CS can be low is 8us in order that the ram can refresh
The refresh time required is only CSH 18ns and then another command can be executed.
In that 8 us the command, address,and data must be communicated.
'Say' the prop could send/receive spi at 5 Mbits/sec (20M ips @ 4 instructions per data bit? (a guess))
In 8 us thats 40 bits, just enough to send/recieve ONE byte!!! (8 + 24 + 8 = 40)
Of course thats just single spi
for quad spi then (8+24)/4 + 2 per byte= 16 bytes (40 bits window - 8 for cmd+data = 32/2=16)
or put another way-
at 4 bits/clock thats ((8/4)=2 + (24/4)=6) = 8 +(2 per byte). So clocks left for data is 40-8=32 and at 2 per bye = 32/2 = 16 bytes
CSH of 18ns is less than one prop instruction (4 clocks=50ns=20 mips) so for simplicity will ignore that, the CS hi/ CS lo takes longer than that.
So you end up in a tight loop CS low, cmd, address + 1 (or 16) bytes sent/received, CS hi.
At single spi thats 1 byte in 8 us (128 KB/s)
in quad spi thats 16 bytes in 8 us (2 MB/s)
Are those numbers about right, or are my sums/assumptions amiss?
(prepares to be shot down in flames..)
Dave
There are also variant parts, like this LY68L6400SLIT that seems to have dropped in price since I last checked.
Very close, there is also a WAIT slot for READ, but that's clocks only, not data, so can deliver a little faster.
basically, the higher the MHz the better, and a 96MHz prop can do more than a 80MHz one. QUAD mode is pretty much mandatory.
On parts that are not DDR based, a design might choose to add a XNOR-Schmitt (1G57 etc), to allow a clock-pulse per edge, shaving one opcode.
You might also find a timer could be carefully phased to generate some clocks ?
Because these parts force frequent CSH to allow auto refresh, it's a shame they forgot to allow a continue read opcode, which would have shaved clocks off by skip of address-re-write.
Probably this was vaguely answered, but I can't find it. Anyway, here it goes my silly question: is there any planning for a C/C++ compiler tool chain in the near or far future, for the P2? It would be important for me to have P2 supported in C and C++, and this may affect my decision on doing projects around the P2 or not. However, I don't want to push this boat into a given direction.
As for Chip's generous offer, I think I have failed to show my gratitude in the best way. I can't wait to buy one, but it will probably next year.
Kind regards, Samuel Lourenço
There is no concrete plan for C tools for the Prop2 at this time.
Of course. We just don't have an actionable plan and money to make it happen.