Chip,
Just testing details of the %FFF logic input block and bumped into what seems to be a flaw with the streamer. I went to serially send out a bitstream using immediate S register data. So 32 bits all up. And decided it would be easier to follow my own progress if I could shift out most significant first. So I set bit 16 (the "a" bit) in the streamer mode. The result is certainly not in bit significance order!
Everything looks fine in least significant order when mode bit 16 is unset.
Chip,
Just testing details of the %FFF logic input block and bumped into what seems to be a flaw with the streamer. I went to serially send out a bitstream using immediate S register data. So 32 bits all up. And decided it would be easier to follow my own progress if I could shift out most significant first. So I set bit 16 (the "a" bit) in the streamer mode. The result is certainly not in bit significance order!
Everything looks fine in least significant order when mode bit 16 is unset.
The "a" bit just reorders bits/twits/nibs within the individual bytes. I see I need to explain this in the doc. Will do so now.
So with the "a" bit set, the immediate #S value is treated as four bytes - least byte first with each byte having most bit first - rather than one longword with most bit first. Right?
So with the "a" bit set, the immediate #S value is treated as four bytes - least byte first with each byte having most bit first - rather than one longword with most bit first. Right?
I finally got the 'DEBUG INTERRUPT' section done in the Google Doc linked to in the first post of this thread.
What was there before was outdated and incomplete. Now that I have this documentation complete, though lacking examples, I have enough reference material to make an initial debugger that I will hook into PNut and later the PropTool.
is the verilog code of the P2 open source?
can we have a peek in your genius mind?
He has not made it open source, though he has shared an occasional snippet during development. He has stated in the past that he eventually plans to open source it (if I'm recalling correctly), but not until a later time.
is the verilog code of the P2 open source?
can we have a peek in your genius mind?
It's not open-source, but maybe it will be someday. It is more than 10 times as complex as P1, in terms of logic, and would take a commitment to get a handle on. If there's anything that is mysterious about any of it, I can provide more detail. I've written the documentation to cover all functional aspects, so people should have all the information necessary to program it for whatever it can possibly do.
I found a picture that illustrates the mental workshop where it all happens.
I realized I had incorrectly described the buffer areas in hub RAM where registers are saved/restored and ISR images are loaded from during a debug interrupt. I just updated the main Google Doc at the top of this thread to correct the mistake.
Are there measured & simulated curves on the P2 Pin's current modes yet ?
eg I can see the 10uA current mode might be useful for 100k thermistor sense, but it would need to be temperature defined, and consistent ?
Can the ADC measure a thermistor without needing a parallel CAP ?
Are there measured & simulated curves on the P2 Pin's current modes yet ?
eg I can see the 10uA current mode might be useful for 100k thermistor sense, but it would need to be temperature defined, and consistent ?
Can the ADC measure a thermistor without needing a parallel CAP ?
There is no temperature compensation, so I think it may not be very accurate.
Are there measured & simulated curves on the P2 Pin's current modes yet ?
eg I can see the 10uA current mode might be useful for 100k thermistor sense, but it would need to be temperature defined, and consistent ?
Can the ADC measure a thermistor without needing a parallel CAP ?
There is no temperature compensation, so I think it may not be very accurate.
Yes, that's why I was asking for numbers.
I did find some current mode numbers, for that region of MOSFET operation, that indicate about -0.2%/°C, so a 25°C change would move ~5%, not stellar, but not hopeless either, and that tempco should be consistent, and someone chasing better precision could reserve one pin as a current-source CAL point.
I found a picture that illustrates the mental workshop where it all happens.
HOW DID YOU GET THIS PICTURE OF MY OFFICE? It's gnomes. No, it's elves. Somebody leaked it. The Deep State is obviously tracking me. OH MY GOD IS THAT A DRONE?
Chip,
I've just discovered that my glob-top revB has damage. Pins P52-P55 have no output control, including the DACs, and are all driven to a static floating to 550 mV. VIO48_55 is still at 3.3 volts so they aren't drawing lots of current. They still work as inputs.
I don't remember this as an issue previously but I also don't remember using that accessory header either. It could have been that way all along. :shrug:
My best guess, at this stage, is I damaged this group when experimenting with extreme VIO48_55 supply volts that I was applying way back. It may have been during the third experiment where I had lowered the board temperature to below 0degC. When I did this the currents involved unexpectedly and dramatically went up into the low milliAmps.
PS: I'm not concerned at all. I still have the second revB board, non-glob-top. Just thought I'd let you know.
EDIT: They are floating, not driven.
EDIT2: Oh, no, it can't have been the high VIO supply experimenting. That was all done on the revA board with its eight group VIO jumpers.
Ah, it looks like the 550 mV floating voltage I've observed with the multimeter is something of an illusion and must rise up higher when I remove the probe. The normally functioning other pins all happily float to zero volts.
I have had good luck with programming the Propellor Quickstart & an older Board of Education from you guys. I am trying to open-source a design for the first civilian Impermeable Plasma Barrier - using slowed, cold plasma. It is potentially feasible with patent #512,340, and a good signalling board. The military & Boeing accomplished this for military use - 5 years ago. I am a registered contentious objector - so my goal is peaceful purposes.
My program will require synchronous phasing of up to 8 frequencies - 2 of each (16 Khz, 64 Khz, 256 Khz, 1.024 Mhz. ) But, if 4 MHz, and 16 Mhz are possible - I would try for that, also. The program also needs to allow on-the-fly changes to frequency, duty cycle & phasing.
I got fairly close with the Quickstart board - and modifying existing FastPWM & Phasing code from your old OBEX site. Unfortunately, my lab partner (and his professor) sabotaged my board & yanked off the mini-USB port.
I am trying to get it replaced right now. But I am also trying to sign up for Early Adopters of the P2, to see what performances improvements I can reach. How can I convince Parallax that this project is worthwhile?
I am offering up my design for open-source discussion. I have some Intel Galileo boards, but I don't think they can signal as well - and I don't feel like going through another learning curve. Anyway, please let me know what I can do to sign up for Early Adopters.
Design attached (27 pages - 1/2 of which are diagrams & CAD pictures). Sources & patents attached.
There is also the option of buying the bare chips - https://www.parallax.com/product/p2x8c4m64p-es It has a thermal pad that must be attached to GND. So need more than just a soldering iron.
Chip,
Just went to use one of the BITx instructions and noted the instruction spreadsheet isn't clear what happens with the unaddressed bits in the D register. I'm guessing they are unaffected by the op.
Chip,
Just went to use one of the BITx instructions and noted the instruction spreadsheet isn't clear what happens with the unaddressed bits in the D register. I'm guessing they are unaffected by the op.
That's correct. I just added some verbiage into the spreadsheet to state this.
As someone who has bought one such four-chip-pack back in 2019 (IIRC, or very early 2020), in retrospect I'd just like to say that it was an absolute bargain. It was the most enjoyment I had from a new piece of silicon since, well, I don't even know when. Everyone involved has pulled off the seemingly impossible. P2 is such a joy to work with, the ES silicon warts didn't diminish anything for me :)
Comments
Just testing details of the %FFF logic input block and bumped into what seems to be a flaw with the streamer. I went to serially send out a bitstream using immediate S register data. So 32 bits all up. And decided it would be easier to follow my own progress if I could shift out most significant first. So I set bit 16 (the "a" bit) in the streamer mode. The result is certainly not in bit significance order!
Everything looks fine in least significant order when mode bit 16 is unset.
The "a" bit just reorders bits/twits/nibs within the individual bytes. I see I need to explain this in the doc. Will do so now.
PS: Mode number is %0100 "imm 32 x 1".
That's right.
After the boot options, in the main doc, there is a description of the boot sequences. It's missing the part about SD card booting.
EDIT: That's something the community could submit now I think about it.
forums.parallax.com/discussion/170637/p2-sd-boot-code-rev-2-silicon
What was there before was outdated and incomplete. Now that I have this documentation complete, though lacking examples, I have enough reference material to make an initial debugger that I will hook into PNut and later the PropTool.
can we have a peek in your genius mind?
He has not made it open source, though he has shared an occasional snippet during development. He has stated in the past that he eventually plans to open source it (if I'm recalling correctly), but not until a later time.
It's not open-source, but maybe it will be someday. It is more than 10 times as complex as P1, in terms of logic, and would take a commitment to get a handle on. If there's anything that is mysterious about any of it, I can provide more detail. I've written the documentation to cover all functional aspects, so people should have all the information necessary to program it for whatever it can possibly do.
I found a picture that illustrates the mental workshop where it all happens.
Chaos is just a higher form of order.
eg I can see the 10uA current mode might be useful for 100k thermistor sense, but it would need to be temperature defined, and consistent ?
Can the ADC measure a thermistor without needing a parallel CAP ?
There is no temperature compensation, so I think it may not be very accurate.
Yes, that's why I was asking for numbers.
I did find some current mode numbers, for that region of MOSFET operation, that indicate about -0.2%/°C, so a 25°C change would move ~5%, not stellar, but not hopeless either, and that tempco should be consistent, and someone chasing better precision could reserve one pin as a current-source CAL point.
HOW DID YOU GET THIS PICTURE OF MY OFFICE? It's gnomes. No, it's elves. Somebody leaked it. The Deep State is obviously tracking me. OH MY GOD IS THAT A DRONE?
OMG!!! If Bob Pease ever had a garage.......
I've just discovered that my glob-top revB has damage. Pins P52-P55 have no output control, including the DACs, and are all driven to a static floating to 550 mV. VIO48_55 is still at 3.3 volts so they aren't drawing lots of current. They still work as inputs.
I don't remember this as an issue previously but I also don't remember using that accessory header either. It could have been that way all along. :shrug:
My best guess, at this stage, is I damaged this group when experimenting with extreme VIO48_55 supply volts that I was applying way back. It may have been during the third experiment where I had lowered the board temperature to below 0degC. When I did this the currents involved unexpectedly and dramatically went up into the low milliAmps.
PS: I'm not concerned at all. I still have the second revB board, non-glob-top. Just thought I'd let you know.
EDIT: They are floating, not driven.
EDIT2: Oh, no, it can't have been the high VIO supply experimenting. That was all done on the revA board with its eight group VIO jumpers.
I have had good luck with programming the Propellor Quickstart & an older Board of Education from you guys. I am trying to open-source a design for the first civilian Impermeable Plasma Barrier - using slowed, cold plasma. It is potentially feasible with patent #512,340, and a good signalling board. The military & Boeing accomplished this for military use - 5 years ago. I am a registered contentious objector - so my goal is peaceful purposes.
My program will require synchronous phasing of up to 8 frequencies - 2 of each (16 Khz, 64 Khz, 256 Khz, 1.024 Mhz. ) But, if 4 MHz, and 16 Mhz are possible - I would try for that, also. The program also needs to allow on-the-fly changes to frequency, duty cycle & phasing.
I got fairly close with the Quickstart board - and modifying existing FastPWM & Phasing code from your old OBEX site. Unfortunately, my lab partner (and his professor) sabotaged my board & yanked off the mini-USB port.
I am trying to get it replaced right now. But I am also trying to sign up for Early Adopters of the P2, to see what performances improvements I can reach. How can I convince Parallax that this project is worthwhile?
I am offering up my design for open-source discussion. I have some Intel Galileo boards, but I don't think they can signal as well - and I don't feel like going through another learning curve. Anyway, please let me know what I can do to sign up for Early Adopters.
Design attached (27 pages - 1/2 of which are diagrams & CAD pictures). Sources & patents attached.
Currently another batch is in production and should show up at the Parallax Store soon.
Enjoy,
Mike
There is also the option of buying the bare chips - https://www.parallax.com/product/p2x8c4m64p-es It has a thermal pad that must be attached to GND. So need more than just a soldering iron.
The Parallax store lists the Rev C Evaluation Boards for pre-order here
No need to sign up, just pay your money and get your board when it is available and then start developing.
Just went to use one of the BITx instructions and noted the instruction spreadsheet isn't clear what happens with the unaddressed bits in the D register. I'm guessing they are unaffected by the op.
That's correct. I just added some verbiage into the spreadsheet to state this.
As someone who has bought one such four-chip-pack back in 2019 (IIRC, or very early 2020), in retrospect I'd just like to say that it was an absolute bargain. It was the most enjoyment I had from a new piece of silicon since, well, I don't even know when. Everyone involved has pulled off the seemingly impossible. P2 is such a joy to work with, the ES silicon warts didn't diminish anything for me :)