What a crazy discussion this is. A P1 plus it's missing I/O and such made sense many years ago. That ship has sailed.
Chip is only one man. As smart as he is I think switching his mental context from where he is now to something else is a terrible idea.
Parallax is only one small company. The fact they are pursuing the PII is amazing. Having to design, build and support more Prop versions seems like a huge over stretch.
I think I said it before, the P1 code is out there. If you have the confidence, balls, and cash take it and make a chip out of it, with whatever enhancements you like.
I remember that Antti told a guy on HaD forum to order right away even if the quantity was showing zero on the web shop. But that was a few weeks ago, probably better to contact him and ask.
Also noticed that the board got a "standard" model number (TE0722) in Trenz catalog, so it seems like it's going to be produced regardeless of the P1V specific application.
I think I said it before, the P1 code is out there. If you have the confidence, balls, and cash take it and make a chip out of it, with whatever enhancements you like.
Only the regular PLL cell that makes the system clock. I believe all custom work on the Prop2 is restricted to the pad-ring area and, so far, only applies to I/O drive functions.
I forgot that the real P1 uses analog PLL's for video.
Aren't there PLL's in the P2?
If so, how did you make them? And if not, how did you get around the not having them?
An Analog PLL is a custom-cell, not Verilog.
( so too is the Crystal amplifier, & many MCUs have Gm control on their Crystal Amplifier, to support a range of Crystal brands and values. )
I've not seen info yet, on if the PLL, Crystal cells etc, that P2 will use, have been proven in OnSemi wafer runs ?
Only the regular PLL cell that makes the system clock. I believe all custom work on the Prop2 is restricted to the pad-ring area and, so far, only applies to I/O drive functions.
PLL's will be a high risk area in P2, because the FPGAs cannot quite emulate the P2 version, an even PLL register control is not run-time-live in a FPGA.
That means the Dividers & phase comparator & VCO
have low test coverage.
I'm assuming there is an option box to tick to have something so common as a proven system clock crystal PLL as a regular cell. It's just a question of placement after that, presumably right next to the crystal pins. There might have to be a gap in the custom part of the pad-ring layout to accommodate it. Or maybe Treehouse have that one down pat as something they've done a hundred times before.
I'm assuming there is an option box to tick to have something so common as a proven system clock crystal PLL as a regular cell. It's just a question of placement after that, presumably right next to the crystal pins. There might have to be a gap in the custom part of the pad-ring layout to accommodate it. Or maybe Treehouse have that one down pat as something they've done a hundred times before.
Ideally perhaps, but Analog is never quite as simple as 'common' and 'proven'.
[Crystal Amplifier + Bias resistor + buffer] should be a 'known' cell, but VCO and PLL dividers and phase comparators have a great many variables, so a standard solution is less likely there.
Finding a possible test VCO chain is not easy.
There are 'kitchen sink' parts with pretty much everything, (eg Si5351A, AK8140A, AK8142..) but they include a large number of i2c config registers, so do not 'clip onto' a FPGA verilog very well....
Currently, the PLL is being replaced by NCO circuits and clever uses of the counters to minimize jitter. Like add one to a repeating number with a lot of ones in it to push rollovers into the future where a jitter free or low jitter sequence can be managed in software.
Currently, the PLL is being replaced by NCO circuits and clever uses of the counters to minimize jitter.
That's PLLs, plural, there Potato. The old Prop1 counters, two per Cog, had PLL circuits that have been completely removed from the Prop2. However, the Prop2 will still end up with one, assumed generic cell based, PLL circuit to multiply up the main system clock.
In its own way, this is sort of becoming Groundhog-like as much as the P2.
Can we maybe stop these posts by requiring whomever posts them to first show proof of having $300-400K in liquid assets such that this might conceivable be more than a pipe dream?
Not aiming to offend, however this keeps coming up, and if Parallax doesn't see any financial merit in it, and they have actual sales figures upon which to base that view not sure why you believe you would know better.
And because the forum seems to be becoming a magnet for P1.5 threads, can any of the Mods start moving these over to General?
The making of a P1+ seems to be generally not well accepted by the forum. The principal reason for that seems to be fear for delay in completion of the P2. And I can well understand that. My full intent in wishing to pursue this development is that P2 development is not at all, or at most only trivially impacted. That is what I stated in my opening post.
Sure, I think what the P2 is, or is projected to be, will be a great leap forward over the P1. But there will be things about it that, for some applications, make it not as suitable as a P1..... that is a P1 with some more pins. And possibly some more speed. Some fuses/security on it would help commercial users, and that is where my application lies. A P2 is simply the wrong answer..... I need my (some of) my stuff to run for 3 years on a couple of D cells. And I am not interested in yet different architectures or C for that matter. I'm an assembly programmer and it has served me well. Spin is coming along too though.
Now, I am a total ignoramus when it comes to Verilog/VHDL, and don't well understand the limitations of using Chip's published "V" code to implement an enhanced P1. I don't follow the words that the code is uneditable. And I don't get the oscillator issues. My belief was that one could simply "marry up" enhancements and burn a new chip, albeit that appears more costly than I had thought, and now, perhaps not even possible.
IFFF it were possible to show that these things could in fact be achieved, AND an analysis on financial return could be vetted, I could be prepared to engage others -some forum members included perhaps- who are paid professionals and well versed in these things to implement this work outside the involvement of Parallax, other than on an advisory basis. Clearly, much money and effort can be saved by some well directed pointers from Chip, and that need not consume but the most minimal of his time.
But it will require the concurrence of Parallax in general, as I have no wish to develop and maintain a sales and distribution network to mimic Parallax. We would work that business together...... provided they are interested and agreeable. If I am going to put up a few hundred K, then I want to be assured I will see a return, and some profit for the risk. That IS the nature and purpose of business.
So, if technical issues can be readily dispensed with, I do intend to take the next step and do some analysis of reward vs risk and see if it makes sense. And if it does I plan to proceed.
AND I DON'T INTEND TO CONSUME CHIP IN THIS JOURNEY !!!!! He has plenty on his plate.
A P2 is simply the wrong answer..... I need my (some of) my stuff to run for 3 years on a couple of D cells.
Then a P1V may also be simply the wrong answer.
The OnSemi process targeted for P2, is very different than the one P1 uses.
You can expect a P1V+/- to have similar leakage and uA/MHz (scaled for die area) as P2
Now, I am a total ignoramus when it comes to Verilog/VHDL, and don't well understand the limitations of using Chip's published "V" code to implement an enhanced P1. I don't follow the words that the code is uneditable. And I don't get the oscillator issues. My belief was that one could simply "marry up" enhancements and burn a new chip,
The P1 uses manual design flows on an old process, so no, you cannot simply "marry up" enhancements and burn a new chip
In a simplest "burn a new chip" verilog flow, you will also lose a good many functions on P1.
Low Power RC osc is included with PLLs, crystal amplifier & bias & buffer & BOD.
If your primary focus is power, "I need my (some of) my stuff to run for 3 years on a couple of D cells." what is the activity profile of that design ?
ie what uA for what times, doing what broad tasks.
What P1 modes & support devices do you use now, to achieve that ?
Since you're using batteries of decent capacity, consider keeping a 'secure cog' alive to achieve the security needs. This means you need to disable hardware reset after loading code, before it leaves your factory. You can still use a supercap to hold supply up while the batteries are changed over.
As for the extra pins and speed, not so easy, but sometimes the problem looks different once one aspect is taken care of
It seems I need some education on the processes involved...... from what you are saying it appears that I am totally off base, and what I wish is not possible.
And yes, one of my products does exactly what I stated..... wakes up every second, takes some readings, does some math, stores some data; checks for cellphone messages once per hour; and transfers about 2K bytes via cellphone once per day. For 3 years, unattended. It also powers the embedded phone.
The current P1 lets me do that all in one cog. I just wish for some more port bits, some code security and, if possible, some more speed.
On P1 Chip made every polygon. All custom circuits. There is literally no library IP in the design. It's a one off, roll your own, completely manual.
The FPGA image is an emulation and would require the full process to be manufactured, and that includes at least one proof run to verify the process works as intended.
It seems I need some education on the processes involved...... from what you are saying it appears that I am totally off base, and what I wish is not possible.
I'd say not practical, rather than not possible,
Clearly with deep enough pockets and a large enough design team, almost anything is possible
And yes, one of my products does exactly what I stated..... wakes up every second, takes some readings, does some math, stores some data; checks for cellphone messages once per hour; and transfers about 2K bytes via cellphone once per day. For 3 years, unattended. It also powers the embedded phone.
The current P1 lets me do that all in one cog. I just wish for some more port bits, some code security and, if possible, some more speed.
Is this using an external RTC, or the RCSLOW ?
P1 was ahead of its time in power profile, but these days, you could add a small MCU and gain some valuable idle uA and also some security.
Port IO is not hard to add.
Well, I'll need some further delving into this, but by the sounds of it my wishes might not be commercially viable as the funds required from what you may be implying will be beyond my appetite. That said, not quite ready to give up yet.
Regarding my product, I use a 1Hz RTC to wake the unit up. Then, both RC slow and RC fast for work. At one point I use the RTC 28kHz to calibrate the RC fast clock to sufficient precision for comms. This all gets done in well under 1 millisec.
Regarding my product, I use a 1Hz RTC to wake the unit up. Then, both RC slow and RC fast for work. At one point I use the RTC 28kHz to calibrate the RC fast clock to sufficient precision for comms. This all gets done in well under 1 millisec.
I'd suggest something like an EFM8SB1/2 (from 47c 1k+) in the RTC place, which can do the 1Hz and add security.
You also get ADC and UART and SPI for free, and added IO from 16 to 24 pins. (minus link pins)
What about just using a small FPGA running P1v with only a single COG and adding security and extra pins? If that draws too much power, could you use a tiny PIC or AVR to wake up the FPGA when it needs to do some heavy lifting and leave it powered off most of the time?
What about just using a small FPGA running P1v with only a single COG and adding security and extra pins? If that draws too much power, could you use a tiny PIC or AVR to wake up the FPGA when it needs to do some heavy lifting and leave it powered off most of the time?
Small FPGA is a good idea, but Total Power Removal is likely to be the only 'uA-idle' P1V choice, which gets messy, as something else has to back up the variables, and that small MCU backup/restore time adds to the power profiles.
Lowest power FPGA of good resource is something like Lattice iCE5LP series, which specs Static Icc 25 °C ~71uA typ (no max),
which is a lot higher than a P1.
Or, you run all the variables and slow state code in the small MCU, and use the Prop as the wake-up co-processor.
@Evanh;
The product is outside in the wilderness... a multi thousand dollar helicopter ride to get access. No appreciable sun in the winter, but is being done by competitors' products at a much higher cost, and besides, hunters like to shoot the panels off. And loss of data is very costly.
@jmg;
That might be a good suggestion for the next incarnation. I'll check it out.
@David;
My idle current is approx 5 uA, and total average current, is about 1 mA. The radio draws 2 Amp peaks. Besides, I really don't like programming PICs, and don't want to learn another architecture or language. My success is with Propellers, and I'm sticking with that. Works for me!
@Heater;
I had not said the effort is trivial, but was expexting Chip's involvement to be sufficiently trivial so as not to impact the P2 delivery.
And just because it isn't being done does not imply it shouldn't be done. In fact, I believe IFFFFF (big IF) it makes commercial sense, then it should be done.
Everyone is free to make investments where they deem appropriate.
Peter,
Sounds cool. I was imagining open fields on a farm or similar.
More I/O can be done with extra chips. If you use 74HC series you don't have to worry about power up settle times nor any config. You could control the power to them then and still have instant simple I/O. Err, dropping power off the I/O chips may be problematic with power rail clamping.
Looks like speed is partly to do with only using RCFAST. I suspect the Prop1 crystal pins power down when when disabled. If so, then faster speed bursts should be achievable on the Prop1 without any more undue power drain.
I'm surprised you haven't said HubRAM is too small. That's probably the one limit that is most difficult to manage once hit.
Comments
https://wiki.trenz-electronic.de/pages/viewpage.action?pageId=20612048
So have many others...
Chip is only one man. As smart as he is I think switching his mental context from where he is now to something else is a terrible idea.
Parallax is only one small company. The fact they are pursuing the PII is amazing. Having to design, build and support more Prop versions seems like a huge over stretch.
I think I said it before, the P1 code is out there. If you have the confidence, balls, and cash take it and make a chip out of it, with whatever enhancements you like.
I remember that Antti told a guy on HaD forum to order right away even if the quantity was showing zero on the web shop. But that was a few weeks ago, probably better to contact him and ask.
Also noticed that the board got a "standard" model number (TE0722) in Trenz catalog, so it seems like it's going to be produced regardeless of the P1V specific application.
That made me smile a bit, Heater. Parallax - I try to avoid wearing my Product Manager hat on the forum, but beware the product designed by the feature requests of customers.
If so, how did you make them? And if not, how did you get around the not having them?
An Analog PLL is a custom-cell, not Verilog.
( so too is the Crystal amplifier, & many MCUs have Gm control on their Crystal Amplifier, to support a range of Crystal brands and values. )
I've not seen info yet, on if the PLL, Crystal cells etc, that P2 will use, have been proven in OnSemi wafer runs ?
PLL's will be a high risk area in P2, because the FPGAs cannot quite emulate the P2 version, an even PLL register control is not run-time-live in a FPGA.
That means the Dividers & phase comparator & VCO
have low test coverage.
Ideally perhaps, but Analog is never quite as simple as 'common' and 'proven'.
[Crystal Amplifier + Bias resistor + buffer] should be a 'known' cell, but VCO and PLL dividers and phase comparators have a great many variables, so a standard solution is less likely there.
Finding a possible test VCO chain is not easy.
There are 'kitchen sink' parts with pretty much everything, (eg Si5351A, AK8140A, AK8142..) but they include a large number of i2c config registers, so do not 'clip onto' a FPGA verilog very well....
That's PLLs, plural, there Potato. The old Prop1 counters, two per Cog, had PLL circuits that have been completely removed from the Prop2. However, the Prop2 will still end up with one, assumed generic cell based, PLL circuit to multiply up the main system clock.
Can we maybe stop these posts by requiring whomever posts them to first show proof of having $300-400K in liquid assets such that this might conceivable be more than a pipe dream?
Not aiming to offend, however this keeps coming up, and if Parallax doesn't see any financial merit in it, and they have actual sales figures upon which to base that view not sure why you believe you would know better.
And because the forum seems to be becoming a magnet for P1.5 threads, can any of the Mods start moving these over to General?
Sure, I think what the P2 is, or is projected to be, will be a great leap forward over the P1. But there will be things about it that, for some applications, make it not as suitable as a P1..... that is a P1 with some more pins. And possibly some more speed. Some fuses/security on it would help commercial users, and that is where my application lies. A P2 is simply the wrong answer..... I need my (some of) my stuff to run for 3 years on a couple of D cells. And I am not interested in yet different architectures or C for that matter. I'm an assembly programmer and it has served me well. Spin is coming along too though.
Now, I am a total ignoramus when it comes to Verilog/VHDL, and don't well understand the limitations of using Chip's published "V" code to implement an enhanced P1. I don't follow the words that the code is uneditable. And I don't get the oscillator issues. My belief was that one could simply "marry up" enhancements and burn a new chip, albeit that appears more costly than I had thought, and now, perhaps not even possible.
IFFF it were possible to show that these things could in fact be achieved, AND an analysis on financial return could be vetted, I could be prepared to engage others -some forum members included perhaps- who are paid professionals and well versed in these things to implement this work outside the involvement of Parallax, other than on an advisory basis. Clearly, much money and effort can be saved by some well directed pointers from Chip, and that need not consume but the most minimal of his time.
But it will require the concurrence of Parallax in general, as I have no wish to develop and maintain a sales and distribution network to mimic Parallax. We would work that business together...... provided they are interested and agreeable. If I am going to put up a few hundred K, then I want to be assured I will see a return, and some profit for the risk. That IS the nature and purpose of business.
So, if technical issues can be readily dispensed with, I do intend to take the next step and do some analysis of reward vs risk and see if it makes sense. And if it does I plan to proceed.
AND I DON'T INTEND TO CONSUME CHIP IN THIS JOURNEY !!!!! He has plenty on his plate.
Cheers,
Peter (pjv)
Then a P1V may also be simply the wrong answer.
The OnSemi process targeted for P2, is very different than the one P1 uses.
You can expect a P1V+/- to have similar leakage and uA/MHz (scaled for die area) as P2
The P1 uses manual design flows on an old process, so no, you cannot simply "marry up" enhancements and burn a new chip
In a simplest "burn a new chip" verilog flow, you will also lose a good many functions on P1.
Low Power RC osc is included with PLLs, crystal amplifier & bias & buffer & BOD.
If your primary focus is power, "I need my (some of) my stuff to run for 3 years on a couple of D cells." what is the activity profile of that design ?
ie what uA for what times, doing what broad tasks.
What P1 modes & support devices do you use now, to achieve that ?
Since you're using batteries of decent capacity, consider keeping a 'secure cog' alive to achieve the security needs. This means you need to disable hardware reset after loading code, before it leaves your factory. You can still use a supercap to hold supply up while the batteries are changed over.
As for the extra pins and speed, not so easy, but sometimes the problem looks different once one aspect is taken care of
It seems I need some education on the processes involved...... from what you are saying it appears that I am totally off base, and what I wish is not possible.
And yes, one of my products does exactly what I stated..... wakes up every second, takes some readings, does some math, stores some data; checks for cellphone messages once per hour; and transfers about 2K bytes via cellphone once per day. For 3 years, unattended. It also powers the embedded phone.
The current P1 lets me do that all in one cog. I just wish for some more port bits, some code security and, if possible, some more speed.
Cheers,
Peter (pjv)
The FPGA image is an emulation and would require the full process to be manufactured, and that includes at least one proof run to verify the process works as intended.
Clearly with deep enough pockets and a large enough design team, almost anything is possible
Is this using an external RTC, or the RCSLOW ?
P1 was ahead of its time in power profile, but these days, you could add a small MCU and gain some valuable idle uA and also some security.
Port IO is not hard to add.
Well, I'll need some further delving into this, but by the sounds of it my wishes might not be commercially viable as the funds required from what you may be implying will be beyond my appetite. That said, not quite ready to give up yet.
Regarding my product, I use a 1Hz RTC to wake the unit up. Then, both RC slow and RC fast for work. At one point I use the RTC 28kHz to calibrate the RC fast clock to sufficient precision for comms. This all gets done in well under 1 millisec.
Nice use of the RTC, btw.
You also get ADC and UART and SPI for free, and added IO from 16 to 24 pins. (minus link pins)
Lowest power FPGA of good resource is something like Lattice iCE5LP series, which specs Static Icc 25 °C ~71uA typ (no max),
which is a lot higher than a P1.
Or, you run all the variables and slow state code in the small MCU, and use the Prop as the wake-up co-processor.
As I have said, if it is so trivial to do why isn't there somebody out there doing it?
The product is outside in the wilderness... a multi thousand dollar helicopter ride to get access. No appreciable sun in the winter, but is being done by competitors' products at a much higher cost, and besides, hunters like to shoot the panels off. And loss of data is very costly.
@jmg;
That might be a good suggestion for the next incarnation. I'll check it out.
@David;
My idle current is approx 5 uA, and total average current, is about 1 mA. The radio draws 2 Amp peaks. Besides, I really don't like programming PICs, and don't want to learn another architecture or language. My success is with Propellers, and I'm sticking with that. Works for me!
@Heater;
I had not said the effort is trivial, but was expexting Chip's involvement to be sufficiently trivial so as not to impact the P2 delivery.
And just because it isn't being done does not imply it shouldn't be done. In fact, I believe IFFFFF (big IF) it makes commercial sense, then it should be done.
Everyone is free to make investments where they deem appropriate.
Cheers,
Peter (pjv)
Sounds cool. I was imagining open fields on a farm or similar.
More I/O can be done with extra chips. If you use 74HC series you don't have to worry about power up settle times nor any config. You could control the power to them then and still have instant simple I/O. Err, dropping power off the I/O chips may be problematic with power rail clamping.
Looks like speed is partly to do with only using RCFAST. I suspect the Prop1 crystal pins power down when when disabled. If so, then faster speed bursts should be achievable on the Prop1 without any more undue power drain.
I'm surprised you haven't said HubRAM is too small. That's probably the one limit that is most difficult to manage once hit.