Maybe don't sell the ES chips in quantity 1, have a minimum of 5, or whatever makes sense. And definitely make your money back on the dev boards. There will be cheaper options popping up later for the mass adoption phase. [8^)
We've talked about making the pricing curve for P2 fairly flat - starting with single units in the $12.50 range and volume pricing maybe 25% less.
We have not determined how to sell the 800 (+/-) engineering samples yet. I'd like to be able to support customers with their prototype needs in a reasonable way (5 -10 units max) per customer. More on this later after you post all of your ideas. The crowd usually leads us to the right answer.
I think you should have a deep talk with @"Peter Jakacki". His P2D2 is a very nice module, @jmg even added a RasPi pinout, that would really make sense for mass production.
What I like on Peters module is the use of a second MCU to act as watchdog, temperature measurement, (I think even USB/boot), and RTC.
If Parallax would produce this and STAY at that form factor, everyone could design boards around it where on just could plug in a P2D2.
My most valuable thing I ever bought from Parallax was the Professional Development board for the P1. Gosh I LOVE that thing. Having something like that to plug a P2D2 in and I will be in heaven...
Dittos on the PPDB. I honestly haven't used mine a lot, but there have been a few times I was only able to finish a project in a timely manner because I had it. One of the moments that truly caused me to grok the power of the P1 was when I realized I needed to ship some debug info, my user interface was very busy, and I just plopped an RCA jack breakout and a couple of resistors onto the breadboard to make a secondary NTSC video feed. I was like, did I just do that?
For P2 I'd skip the overly complicated pin-eating 15-segment LED displays and sub HDMI and USB. Actually the P2 has enough pins that the ES form factor with its Spin Studio-esque adapter boards is also an attractive form factor, even if not as pin-efficient. Maybe an ES accessory that is an actual breadboard linked by a ribbon cable to the ES header would be a good idea...?
Anyone in the industry looking at pre-Production samples is not going to blink at $20+ for a unit.
It may be more expensive than the Production ones, however the higher price is part and parcel of getting in early.
One's cheaper competitors not willing to shell out an extra fin or sawbuck are going to end up behind by waiting for mass availability.
Pre-production pricing should not be done at a loss, you can easily add verbiage that actual Production is expected to be cheaper at xxx, which should help allay anyone's concerns.
And, why not add $ to the price, and seriously consider a Bounty/Reward to ersmiths for work which has and will continue to have a great impact to Parallax and its customers.
Also, hopefully someone is already on the ball with an Amiga Boing Ball type of demo showcasing the P2.
Show the P2 doing something with those 8 cores that blows the socks of an ARM.
And then add the Cherry on top, and point out that the Cores are all programmed with C, Assembler, Python, BASIC, and Spin....
+9000 for making the form factor compatible with the Pi.
I know, some people want the world smallest PCB, and that could be an option with one of the R2D2's.
However piggybacking off of the Pi would at least get the attention of 90% of Pi users, which even a small attachment rate would see Parallax needing to hire more mailroom staff.
Ken,
I think for engineering samples the price should be a little higher, and I would recommend no one actually use them in shipped products.
They can use them for designing products that will ship once actual production chips are available.
I also think that ersmiths compiler stuff is something you should get behind. Spin2 is not going to be as relevant for P2 as Spin was for the P1. I'd even go so far as to say most people will not use Spin2 for coding the P2. I know there are folks here that don't like to hear that (and may even cry foul here), but I think it's the truth you need to accept. C/C++, Python, and to a point BASIC will see more use on P2 (of course with PASM mixed in as needed for drivers).
..
+9000 for making the form factor compatible with the Pi.
I know, some people want the world smallest PCB, and that could be an option with one of the R2D2's.
However piggybacking off of the Pi would at least get the attention of 90% of Pi users, which even a small attachment rate would see Parallax needing to hire more mailroom staff.
You can have both small PCB and Pi compatible
The P2D2Pi, is the same size as P2D2, only the pinout shuffles to become Pi compliant & both 40 pin connectors change to have the same pinout.
Pinout mapping was attached here
Oh cool!! Externally clocked ADC bitstream smartpin mode! You kept that one quiet Chip.
No, Jmg insisted it be there. It's just never been tested with an external ADC.
Well, I've finally got my code together enough to compare the AD7400 running synchronously vs not. I don't understand why but running it unsync'd is really bad in comparison to running sync'd. I figured with it over-sampled it would be fine, but not so. There is a signal but the noise I hadn't counted on being so bad. It's just full spectrum.
And counter-intuitive to me, if I sample roughly at the MDAT bit rate then the noise is very low indeed. I'm wondering if I've missed a detail.
Oh cool!! Externally clocked ADC bitstream smartpin mode! You kept that one quiet Chip.
No, Jmg insisted it be there. It's just never been tested with an external ADC.
Well, I've finally got my code together enough to compare the AD7400 running synchronously vs not. I don't understand why but running it unsync'd is really bad in comparison to running sync'd. I figured with it over-sampled it would be fine, but not so. There is a signal but the noise I hadn't counted on being so bad. It's just full spectrum.
And counter-intuitive to me, if I sample roughly at the MDAT bit rate then the noise is very low indeed. I'm wondering if I've missed a detail.
I'm sure glad JMG insisted anyway.
The design supposition was that there'd be an external clock signal that was driving both the AD7400 and Pin B of the smart pin. How have you got it set up?
Yeah, that is the most likely deployed config, and the AD7401 is built to work that way.
The AD7400, on the other hand, generates its own MCLK as an output along side the MDAT. Works fine with just its MDAT feeding an analogue filter on its eval board I purchased. Which is why I figured there wouldn't be any hassle treating it as an async modulator by oversampling the bitstream.
Here's a photo showing MDAT on pin8 and MCLK on pin10 of the prop2 eval board.
PS: In the photo you can see I've left the designated MDAT pad empty and instead taken it from the AD7400 directly. For some odd reason the designated pad is on the filter side of the voltage translation buffer. I didn't want to interfere with the analogue filter's performance and the AD7400 is conveniently operating at 3.3V as well.
As for how I'm getting the noisy asynchronous sampling, I simply flip from the revB synchronous smartpin mode (%11001) to the revB asynchronous one (%11000). This naturally shifts the bitstream sampling rate to whatever the prop2 sysclock is. Impressively I don't even have to do any DIRL/H or setup of X and Y smartpin registers to flip back and forth.
EDIT: Here's the relevant keyboard source code
cmp key, #" " wz 'toggle sync/async MDAT
if_nz jmp #adcloop
bitnot hw_rev, #31 wcz 'sync/async state bit for external ADC bitstream
if_nz wrpin ##SPM_ADC_ISINC | P_REGD, #BITPIN 'MDAT + asynchronous SINCx smartpin in v33 hardware
if_nz loc pa, #asyncstr
if_z wrpin ##SPM_ADC_ESINC | P_REGD | BF_PLUS2NOT, #BITPIN 'MDAT + synchronous SINCx smartpin in v33 hardware
if_z loc pa, #syncstr
call #puts
jmp #adcloop
Oh cool!! Externally clocked ADC bitstream smartpin mode! You kept that one quiet Chip.
No, Jmg insisted it be there. It's just never been tested with an external ADC.
Well, I've finally got my code together enough to compare the AD7400 running synchronously vs not. I don't understand why but running it unsync'd is really bad in comparison to running sync'd. I figured with it over-sampled it would be fine, but not so. There is a signal but the noise I hadn't counted on being so bad. It's just full spectrum.
And counter-intuitive to me, if I sample roughly at the MDAT bit rate then the noise is very low indeed. I'm wondering if I've missed a detail.
I'm sure glad JMG insisted anyway.
If I'm following this, I would expect an issue with simply clock-ignored sampling (unsync'd?), of a part that produces a clock.
On those parts, the sample point will drift, and so long as it gets clean data, the average will be 'somewhat ok' but imagine if it drifts to sample right on an edge ?
Now, you have added uncertainty of seeing a 1 or 0, to any noise that was there before.
ie the Externally clocked ADC bitstream smartpin mode is needed to get full performance from those ADCs that generate clocks.
It has similarities to the serial port testing. Asynchronously, sysclock of 10 MHz and 20 MHz is working but goes down hill at 15 MHz and 25 MHz. From 30 MHz up, asynchronous progressively has a rising noise floor.
Synchronous needs 30+ MHz on sysclock to be clear of noise itself but does clean up at exactly 20 MHz sysclock. At 20 MHz there isn't much difference in noise between sync vs async. Async 10 MHz looks a match really. The AD7400 MCLK must be stable and bang on 10 MHz. If it drifts then async would get noisy.
Oh, doh! I forgot about the time period per sample. In async, higher sysclock shortens the period if not compensating with more clocks per decimation sample. I do need to adjust those X/Y smartpin registers ... time for some more testing ...
SINC2 Sampling Mode (%00) seems to be broken. Even with max gain parameters there is almost nothing in the data. Maybe a very slight signal.
SINC2 Filtering Mode (%01) and SINC3 Filtering Mode (%10) are working.
EDIT: And yep, upping the decimation timer (retaining the period) was the key to making async clocking work at higher sysclock rates. So the whole problem earlier was just the rising noise floor because of the shortening decimation period.
EDIT2: That said, the 10 MHz multiples are still the lowest noise with the 5 MHz intermediaries adding about 10 to 15 dB of noise.
SINC2 Sampling Mode (%00) seems to be broken. Even with max gain parameters there is almost nothing in the data. Maybe a very slight signal.
SINC2 Filtering Mode (%01) and SINC3 Filtering Mode (%10) are working.
EDIT: And yep, upping the decimation timer (retaining the period) was the key to making async clocking work at higher sysclock rates. So the whole problem earlier was just the rising noise floor because of the shortening decimation period.
Mode %00 works. Maybe my documentation is off.
For 8-bit samples, do a 'WXPIN #7,pin'. Then, RDPIN returns samples. No need for any subtractions.
For 8-bit samples, do a 'WXPIN #7,pin'. Then, RDPIN returns samples. No need for any subtractions.
Not for an external bitstream. I can wind up from 50% to 100% pulse density with a pot on the input to the AD7400 and there is basically no response from the smartpin unless I'm up around WXPIN #13,pin. Even then the response is tiny - about 8000 counts end to end - and that's without any numerical truncation.
Oh!!! It's a SINC1 not SINC2. Yeah, small documentation correction needed.
I think I see the problem. It looks like in externally-clocked mode, you can only change modes when DIR=0 (smart pin is in reset state). Could that be it?
No, that's not the case. I don't see what the problem is, yet.
I'm editing my source code and reassembling/reloading when changing between those modes. It all makes sense now though. I was expecting large >16-bit data from RDPIN. But as you already mentioned, X = 7 is only meant to produce 8-bit data. Which is correct for a plain SINC1 filter - where it simply tellies up the pulses received per decimation.
I'm editing my source code and reassembling/reloading when changing between those modes. It all makes sense now though. I was expecting large >16-bit data from RDPIN. But as you already mentioned, X = 7 is only meant to produce 8-bit data. Which is correct for a plain SINC1 filter - where it simply tellies up the pulses received per decimation.
Right, but it's really SINC2. It just looks like SINC1 after the sample is boiled down. The differentiation was done in the smart pin.
You'll see that you are getting an 8-bit sample every 128 clocks with X=7.
..
SINC2 Filtering Mode (%01) and SINC3 Filtering Mode (%10) are working.
Sounds good, what bandwidth / settling time do you see, post filter ?
I see ADI have a new ADUM7703. that has much higher dV/dT isolation, much lower drift and I think less degrade on the 8-pin version.
That claims ~ 14bits and lower Icc.
Comments
No worries! Plenty of us will do the expo. (Long overdue)
You buy P2's, and phone it in. Everyone wins!
File all this under: Nice Problems To Have
Maybe someone will set up an east coast simulcast/satellite of the event.
Jonathan
We have not determined how to sell the 800 (+/-) engineering samples yet. I'd like to be able to support customers with their prototype needs in a reasonable way (5 -10 units max) per customer. More on this later after you post all of your ideas. The crowd usually leads us to the right answer.
Ken Gracey
I think you should have a deep talk with @"Peter Jakacki". His P2D2 is a very nice module, @jmg even added a RasPi pinout, that would really make sense for mass production.
What I like on Peters module is the use of a second MCU to act as watchdog, temperature measurement, (I think even USB/boot), and RTC.
If Parallax would produce this and STAY at that form factor, everyone could design boards around it where on just could plug in a P2D2.
My most valuable thing I ever bought from Parallax was the Professional Development board for the P1. Gosh I LOVE that thing. Having something like that to plug a P2D2 in and I will be in heaven...
Enjoy!
Mike
Seconded. That board is excellent. Love the plug in idea. Let's say I plugged more than a couple DIP P1 chips into mine...
For P2 I'd skip the overly complicated pin-eating 15-segment LED displays and sub HDMI and USB. Actually the P2 has enough pins that the ES form factor with its Spin Studio-esque adapter boards is also an attractive form factor, even if not as pin-efficient. Maybe an ES accessory that is an actual breadboard linked by a ribbon cable to the ES header would be a good idea...?
Mike
It may be more expensive than the Production ones, however the higher price is part and parcel of getting in early.
One's cheaper competitors not willing to shell out an extra fin or sawbuck are going to end up behind by waiting for mass availability.
Pre-production pricing should not be done at a loss, you can easily add verbiage that actual Production is expected to be cheaper at xxx, which should help allay anyone's concerns.
And, why not add $ to the price, and seriously consider a Bounty/Reward to ersmiths for work which has and will continue to have a great impact to Parallax and its customers.
Also, hopefully someone is already on the ball with an Amiga Boing Ball type of demo showcasing the P2.
Show the P2 doing something with those 8 cores that blows the socks of an ARM.
And then add the Cherry on top, and point out that the Cores are all programmed with C, Assembler, Python, BASIC, and Spin....
+9000 for making the form factor compatible with the Pi.
I know, some people want the world smallest PCB, and that could be an option with one of the R2D2's.
However piggybacking off of the Pi would at least get the attention of 90% of Pi users, which even a small attachment rate would see Parallax needing to hire more mailroom staff.
You can have both small PCB and Pi compatible
The P2D2Pi, is the same size as P2D2, only the pinout shuffles to become Pi compliant & both 40 pin connectors change to have the same pinout.
Pinout mapping was attached here
And counter-intuitive to me, if I sample roughly at the MDAT bit rate then the noise is very low indeed. I'm wondering if I've missed a detail.
I'm sure glad JMG insisted anyway.
The design supposition was that there'd be an external clock signal that was driving both the AD7400 and Pin B of the smart pin. How have you got it set up?
The AD7400, on the other hand, generates its own MCLK as an output along side the MDAT. Works fine with just its MDAT feeding an analogue filter on its eval board I purchased. Which is why I figured there wouldn't be any hassle treating it as an async modulator by oversampling the bitstream.
Here's a photo showing MDAT on pin8 and MCLK on pin10 of the prop2 eval board.
PS: In the photo you can see I've left the designated MDAT pad empty and instead taken it from the AD7400 directly. For some odd reason the designated pad is on the filter side of the voltage translation buffer. I didn't want to interfere with the analogue filter's performance and the AD7400 is conveniently operating at 3.3V as well.
EDIT: Here's the relevant keyboard source code
On those parts, the sample point will drift, and so long as it gets clean data, the average will be 'somewhat ok' but imagine if it drifts to sample right on an edge ?
Now, you have added uncertainty of seeing a 1 or 0, to any noise that was there before.
ie the Externally clocked ADC bitstream smartpin mode is needed to get full performance from those ADCs that generate clocks.
Synchronous needs 30+ MHz on sysclock to be clear of noise itself but does clean up at exactly 20 MHz sysclock. At 20 MHz there isn't much difference in noise between sync vs async. Async 10 MHz looks a match really. The AD7400 MCLK must be stable and bang on 10 MHz. If it drifts then async would get noisy.
SINC2 Filtering Mode (%01) and SINC3 Filtering Mode (%10) are working.
EDIT: And yep, upping the decimation timer (retaining the period) was the key to making async clocking work at higher sysclock rates. So the whole problem earlier was just the rising noise floor because of the shortening decimation period.
EDIT2: That said, the 10 MHz multiples are still the lowest noise with the 5 MHz intermediaries adding about 10 to 15 dB of noise.
Mode %00 works. Maybe my documentation is off.
For 8-bit samples, do a 'WXPIN #7,pin'. Then, RDPIN returns samples. No need for any subtractions.
I think I see the problem. It looks like in externally-clocked mode, you can only change modes when DIR=0 (smart pin is in reset state). Could that be it?
No, that's not the case. I don't see what the problem is, yet.
Right, but it's really SINC2. It just looks like SINC1 after the sample is boiled down. The differentiation was done in the smart pin.
You'll see that you are getting an 8-bit sample every 128 clocks with X=7.
Right. The SINC2 sample mode differentiates, rounds, and truncates, so you get a nice, tidy sample.
I see ADI have a new ADUM7703. that has much higher dV/dT isolation, much lower drift and I think less degrade on the 8-pin version.
That claims ~ 14bits and lower Icc.
Maybe those modes need more distinct names ? would SINC2-8 and SINC2-16 help ?