Are there already schematics of them boards available as of you knowledge?
Sadly I started this stupid electronics interest at a time where my eyesight already was dwindling and the hands seem not as precise as before. I have a hard time soldering thru hole components, this SMD stuff I could not even place, let alone solder.
Currently I have my p2 sitting next to the PPDB using jumper wires, so I really like the offered boards.
Attached here are the Schematics in pdf format, which are available ahead of launch.
The user guide is available here, with commenting enabled. As with the P2-EVAL docs, please feel free to add notes beside anything you see needs improving, or ask questions if anything is unclear !
Great instructions. I would recommend putting a picture of each board in the section that talks about it, you did it already for a couple of the boards.
Does anyone remember what thread it was where someone proposed a "standard" placement for each accessory board? I like the idea of everyone there being a standard so that all (many) of the demo programs we write will "just work" on anyone's setup without having to re-order board or rename pins in the code.
Does anyone remember what thread it was where someone proposed a "standard" placement for each accessory board? I like the idea of everyone there being a standard so that all (many) of the demo programs we write will "just work" on anyone's setup without having to re-order board or rename pins in the code.
yes, me
@Ahle2 brought this up and I made up some with reasoning
I think we should have both -- definitely drivers should be able to change their basepins, but if there's a convention on which boards (usually) get plugged into where then the defaults will work for most people.
I liked @msrobots ' suggestion, with one caveat: all of the existing VGA drivers seem to use basepin=0, I think because in the FPGA the DAC is hard-coded there. So it probably makes sense to plug the AV board into the pin 0 group.
Has anyone made a keyboard USB driver for the P2? I'd like to get my embedded basic interpreter working without a connection to a PC. I have VGA code that works with Rayman's VGA adapter board but I need a way to connect a keyboard.
I will admit to being wrong about the "just specify basepin" thing in one respect -- in Spin2, every blasted reference to the pins has to be split between OUTA/OUTB and DIRA/DIRB depending on whether you're in the top or bottom 32. That is a real nuisance when writing general purpose use-any-pin code. I can understand why you have to be aware that you can't do something like OUT[24..37], because of the pin 32 barrier, but with banks of 8 surely there should be a way to make common code that works on any basepin?
The enclosure is pretty good. The only thing I have found that the engineering of the enclosure did not have the data of the accessory boards dimensions. If any body wants I can have the enclosure re re done. Give me your thoughts on this. Please give me your design ideas.
Thanks.
Send me a direct message please,
The enclosure is pretty good. The only thing I have found that the engineering of the enclosure did not have the data of the accessory boards dimensions. If any body wants I can have the enclosure re re done. Give me your thoughts on this. Please give me your design ideas.
Thanks.
Send me a direct message please,
just use a nail file and round up the corners of the accessory boards, take 2-3 min each, you do not need to remove much.
I will admit to being wrong about the "just specify basepin" thing in one respect -- in Spin2, every blasted reference to the pins has to be split between OUTA/OUTB and DIRA/DIRB depending on whether you're in the top or bottom 32. That is a real nuisance when writing general purpose use-any-pin code. I can understand why you have to be aware that you can't do something like OUT[24..37], because of the pin 32 barrier, but with banks of 8 surely there should be a way to make common code that works on any basepin?
In BASIC you can use output(x) for any 0 <= x < 64, and under the hood it gets converted to OUTA or OUTB as appropriate (similarly for direction() and DIRA/B, input() and INA/B). But sometimes this can result in a fair amount of "hidden" code, so I don't know if it's appropriate for Spin.
For single pin output Spin2 does provide dir_(), dirl_(), dirh_(), and drvnot_(). (See the "New intrinsics" section of the spin.pdf document that comes with spin2gui.
This is simple compared to the STM chip where there are only 16 pins per group and multiple groups that are memory mapped and require several instructions just to set a pin.
I didn't expect the HDMI cable from my monitor to be providing power...
But, when connected to my Eval board (with nothing else connected, except my HyperRam board) an WS2812 LED on HyperRam board lit up.
Seems I have 2.2 on the 5V supply, 2.5 V on 3.3 V supply and 3.2 V on either the pin labelled 1 or the one labelled 2 (seems to change each time).
So, it's providing some power, but not enough to power on the board...
Interestingly, I also see +5V on SCL and SDA holes but zero on the 5V hole.
Current Mirror Logic (CML) receivers used by HDMI need a 50 ohm pullup resistor to VCC on each differential pair input for typical termination. Seems like that is what would be feeding back into your Eval board and through P2 protection diodes etc.
The 5V on SCL/SDA is strange. I would expect the monitor would(should?) use the 5V provided to it over HDMI for the i2c pullups but maybe it doesn't need to and simply uses some internal 5V instead.
Though I have no personal preferences, the existence of an HyperSomething breakout would help a lot of my own dreams to become true.
If possible, please don't forget to include some optional solder-jumper(s) (one per HyperRam footprint), in order to enable the coexistence of HyperFlash(s) and HyperRam(s), since the difference between them is (mostly) restricted to the position of the CS# pin.
It should be better if the footprints could contemplate both options, running from different P2 pins (thus no solder jumpers at all), because it would enable the use of multi-chip package devices (the ones that have both CS1# and CS2#).
Since those boards would be targeting development purposes, IMHO, all the 16 (sixteen) interface signals would need to be brought to individual P2 pins:
CS1#, CS2#, CK, RWDS, DQ[7:0], INT#, RESET#, RSTO# and PSC.
Thru the use of solder jumpers, CS1# and CS2# could also be repurposed to serve two independent footprints, allowing the assemblage of any mix of two (Rams and/or Flashes), non Multi-Chip Packaged devices.
The same would apply to INT#, RSTO# and PSC, that could be repurposed, thru the use of solder jumpers, becoming, eventually, CS3#, CS4# and CS5#, thus allowing up-to five devices to be assembled over a single breakout board.
HypeRams have no internal connections to INT# and RSTO#, only HyperFlashs could, eventually, bennefit from their existence.
PSC is a someway "specialty" signal, and I don't really believe it'll be used in a foreseeable future.
Being open-drain signals, INT# and RSTO# may require that an optional pull-up resistor, to 3.3 V, could be eventually assembled.
Beyond commom rules for spreading capacitive decoupling, it's also advisable to preview at least one bigger footprint (0805?), for an up-to 2.2 uF (or even more) device, near the 3.3 V distribution entry-point.
Keeping the whole interface clean and the signal routes as even and balanced as possible, it's also possible to devise an extension at boards free edge, aiming the use of that breakout as a data bridge with shared memory, allowing it to be simultaneously connected to up to two P2 Eval boards.
In that sense, INT#, RSTO# and PSC could be repurposed to act as bus arbitration control signals (kind of BusRequest#, BusGrant# and BusGrantAcknowledge#), all open-drain, thus requiring their own pull-ups to 3.3 V, wich, it that case, could have its own seletive-connection jumper (with a previewed higher current demand, in this case), to enable the routing of power to the breakout, from either side of the connection.
Sure I know: dreams are free, hardware has its own costs...
Agreeing with Yanomami about how since two full headers are being used, might as well dedicate all relevant hyperflash and hyperram pins.
As for accessory boards, perhaps an analog input board that has mini spring or screw terminal blocks?
How about 2 potentiometers, 4 voltage analog inputs, and 2 of 4-20 mA current analog inputs (250 ohm resistor).
For the voltage inputs have adjustable voltage scaling op-amps that are also over-range protected.
0-5V, 0-10V input range.
Are there rail-to-rail 3.3V op-amps yet? If not I guess use the 5V that's provided on the pin header.
update- Took a look, and yes it seems shareable versions of the layout files were never generated.
I can see at least one reason why- as that's not a trivial task given the font and graphics manipulations that are not standard Diptrace features. Will take a look whilst doing the next accessory boards, and see if I can put the tasks together.
As for a respin of them existing boards, I really like a couple of the LED Matric ones they help to visualize if something is going on, on the pins, on the other hand I have not figured out what to do with the goertzel one and might not need another.
So consider different amounts of each of them, not 200 of each one. Protoboard, LED matrix, Control, USB might be used more often.
I like @whicker's idea of a analog input board, that would make testing ADC/DAC quite more funny. And YES some external RAM solution compatible to what @"Peter Jakacki" is planning would be wonderful.
WIFI for the boot pins as module would be very cool, so that it works like on the P1 wx boards. Would give a Path to Blockly…
As usual, I've been musing about some way to have a bit more options at the connection path between two P2 Eval boards (in fact, even more than two).
At the same time, being jealous about the herd we have, I don't want to loose the possibility of connecting any one of the currently available at the accessory set, and sure, need to find enough headroom, to deal with the yet to come new one(s).
There has been some threads dedicated to P2-to-P2 comms, and there should be many more ahead, as next silicon is just about to comme, very soon.
Also, to the extent of my knowledge, there are many ways to interconnect two or more P2, but they seem to be yet unknown. The SERDES are also mostly unnexplored; I've yet to heard something about synchronous comms.
Well, perhaps some new means could be devised, to easy the interconnection path, while not loosing nothing that have been conquered so far.
I hope the following image could explain what I've been planning, better that a lot of blah blah blah blah...
(Please, excuse my Sketchup habilities being that poor; it was done at a venerable Athlon XP 2400+, running... Windows XP)
Comments
Are there already schematics of them boards available as of you knowledge?
Sadly I started this stupid electronics interest at a time where my eyesight already was dwindling and the hands seem not as precise as before. I have a hard time soldering thru hole components, this SMD stuff I could not even place, let alone solder.
Currently I have my p2 sitting next to the PPDB using jumper wires, so I really like the offered boards.
Enjoy!
Mike
The user guide is available here, with commenting enabled. As with the P2-EVAL docs, please feel free to add notes beside anything you see needs improving, or ask questions if anything is unclear !
https://docs.google.com/document/d/1FTGV1Mn1hwayEaKut5Ej6vmWdjirVlP9TQqyA0wRs34/edit?usp=sharing
Any idea when the boards will be available for purchase?
yes, me
@Ahle2 brought this up and I made up some with reasoning
http://forums.parallax.com/discussion/comment/1463262/#Comment_1463262
Enjoy!
Mike
I liked @msrobots ' suggestion, with one caveat: all of the existing VGA drivers seem to use basepin=0, I think because in the FPGA the DAC is hard-coded there. So it probably makes sense to plug the AV board into the pin 0 group.
No all driver should support a BasePin so they are adaptable.
My primary list was because I have a very small workspace so I wanted the most stationary wires on the top and right, having PC-USB on top and right.
but its just a proposal for presetting a BasePin in demos.
Enjoy!
Mike
I haven't got as far as trying it out myself. I wrecked my P2ES when I went to try.
Thanks.
Send me a direct message please,
just use a nail file and round up the corners of the accessory boards, take 2-3 min each, you do not need to remove much.
Enjoy!
Mike
In BASIC you can use output(x) for any 0 <= x < 64, and under the hood it gets converted to OUTA or OUTB as appropriate (similarly for direction() and DIRA/B, input() and INA/B). But sometimes this can result in a fair amount of "hidden" code, so I don't know if it's appropriate for Spin.
For single pin output Spin2 does provide dir_(), dirl_(), dirh_(), and drvnot_(). (See the "New intrinsics" section of the spin.pdf document that comes with spin2gui.
Mike
But, when connected to my Eval board (with nothing else connected, except my HyperRam board) an WS2812 LED on HyperRam board lit up.
Seems I have 2.2 on the 5V supply, 2.5 V on 3.3 V supply and 3.2 V on either the pin labelled 1 or the one labelled 2 (seems to change each time).
So, it's providing some power, but not enough to power on the board...
Interestingly, I also see +5V on SCL and SDA holes but zero on the 5V hole.
The 5V on SCL/SDA is strange. I would expect the monitor would(should?) use the 5V provided to it over HDMI for the i2c pullups but maybe it doesn't need to and simply uses some internal 5V instead.
With the new Eval board coming, there's been talk of adding a couple accessory boards to the Parallax range....
Is there anything else you'd like added to the list?
And also... which was your favourite from the previous set.
I'm just curious..... I think I have a good guess about which it was
Though I have no personal preferences, the existence of an HyperSomething breakout would help a lot of my own dreams to become true.
If possible, please don't forget to include some optional solder-jumper(s) (one per HyperRam footprint), in order to enable the coexistence of HyperFlash(s) and HyperRam(s), since the difference between them is (mostly) restricted to the position of the CS# pin.
It should be better if the footprints could contemplate both options, running from different P2 pins (thus no solder jumpers at all), because it would enable the use of multi-chip package devices (the ones that have both CS1# and CS2#).
Since those boards would be targeting development purposes, IMHO, all the 16 (sixteen) interface signals would need to be brought to individual P2 pins:
CS1#, CS2#, CK, RWDS, DQ[7:0], INT#, RESET#, RSTO# and PSC.
Thru the use of solder jumpers, CS1# and CS2# could also be repurposed to serve two independent footprints, allowing the assemblage of any mix of two (Rams and/or Flashes), non Multi-Chip Packaged devices.
The same would apply to INT#, RSTO# and PSC, that could be repurposed, thru the use of solder jumpers, becoming, eventually, CS3#, CS4# and CS5#, thus allowing up-to five devices to be assembled over a single breakout board.
HypeRams have no internal connections to INT# and RSTO#, only HyperFlashs could, eventually, bennefit from their existence.
PSC is a someway "specialty" signal, and I don't really believe it'll be used in a foreseeable future.
Being open-drain signals, INT# and RSTO# may require that an optional pull-up resistor, to 3.3 V, could be eventually assembled.
Beyond commom rules for spreading capacitive decoupling, it's also advisable to preview at least one bigger footprint (0805?), for an up-to 2.2 uF (or even more) device, near the 3.3 V distribution entry-point.
Keeping the whole interface clean and the signal routes as even and balanced as possible, it's also possible to devise an extension at boards free edge, aiming the use of that breakout as a data bridge with shared memory, allowing it to be simultaneously connected to up to two P2 Eval boards.
In that sense, INT#, RSTO# and PSC could be repurposed to act as bus arbitration control signals (kind of BusRequest#, BusGrant# and BusGrantAcknowledge#), all open-drain, thus requiring their own pull-ups to 3.3 V, wich, it that case, could have its own seletive-connection jumper (with a previewed higher current demand, in this case), to enable the routing of power to the breakout, from either side of the connection.
Sure I know: dreams are free, hardware has its own costs...
Henrique
As for accessory boards, perhaps an analog input board that has mini spring or screw terminal blocks?
How about 2 potentiometers, 4 voltage analog inputs, and 2 of 4-20 mA current analog inputs (250 ohm resistor).
For the voltage inputs have adjustable voltage scaling op-amps that are also over-range protected.
0-5V, 0-10V input range.
Are there rail-to-rail 3.3V op-amps yet? If not I guess use the 5V that's provided on the pin header.
Will rectify that soon!
And please include 64005-ES, (Large Protoboard).
I can see at least one reason why- as that's not a trivial task given the font and graphics manipulations that are not standard Diptrace features. Will take a look whilst doing the next accessory boards, and see if I can put the tasks together.
thank you for asking the question.
As for a respin of them existing boards, I really like a couple of the LED Matric ones they help to visualize if something is going on, on the pins, on the other hand I have not figured out what to do with the goertzel one and might not need another.
So consider different amounts of each of them, not 200 of each one. Protoboard, LED matrix, Control, USB might be used more often.
I like @whicker's idea of a analog input board, that would make testing ADC/DAC quite more funny. And YES some external RAM solution compatible to what @"Peter Jakacki" is planning would be wonderful.
WIFI for the boot pins as module would be very cool, so that it works like on the P1 wx boards. Would give a Path to Blockly…
my two cents,
Mike
As usual, I've been musing about some way to have a bit more options at the connection path between two P2 Eval boards (in fact, even more than two).
At the same time, being jealous about the herd we have, I don't want to loose the possibility of connecting any one of the currently available at the accessory set, and sure, need to find enough headroom, to deal with the yet to come new one(s).
There has been some threads dedicated to P2-to-P2 comms, and there should be many more ahead, as next silicon is just about to comme, very soon.
Also, to the extent of my knowledge, there are many ways to interconnect two or more P2, but they seem to be yet unknown. The SERDES are also mostly unnexplored; I've yet to heard something about synchronous comms.
Well, perhaps some new means could be devised, to easy the interconnection path, while not loosing nothing that have been conquered so far.
I hope the following image could explain what I've been planning, better that a lot of blah blah blah blah...
(Please, excuse my Sketchup habilities being that poor; it was done at a venerable Athlon XP 2400+, running... Windows XP)
Henrique