P2 Evaluation Board - Accessory Set 64006-ES

13

Comments

  • Oh, nice, thank you Roy.

    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
    I am just another Code Monkey.
    A determined coder can write COBOL programs in any language. -- Author unknown.
    Press any key to continue, any other key to quit

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
  • Docs and schematics are in editing at the moment. I'll see about getting those schematics at least posted here today.
  • 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 !

    https://docs.google.com/document/d/1FTGV1Mn1hwayEaKut5Ej6vmWdjirVlP9TQqyA0wRs34/edit?usp=sharing

  • Very nicely done!
    Any idea when the boards will be available for purchase?
  • 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.
    David
    PropWare: C++ HAL (Hardware Abstraction Layer) for PropGCC; Robust build system using CMake; Integrated Simple Library, libpropeller, and libPropelleruino (Arduino port); Instructions for Eclipse and JetBrain's CLion; Example projects; Doxygen documentation
    CI Server: https://ci.zemon.name?guest=1
  • DavidZemon wrote: »
    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

    http://forums.parallax.com/discussion/comment/1463262/#Comment_1463262

    Enjoy!

    Mike
    I am just another Code Monkey.
    A determined coder can write COBOL programs in any language. -- Author unknown.
    Press any key to continue, any other key to quit

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
  • Having a CON defined base pin at the beginning of each "driver" is fine by me. I like the flexibility to choose where I place the accessory boards.
    "We suspect that ALMA will allow us to observe this rare form of CO in many other discs.
    By doing that, we can more accurately measure their mass, and determine whether
    scientists have systematically been underestimating how much matter they contain."
  • 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.
  • yeah and have that long board + vga and/or audio and/or coax left out of the P2 with all them wires between me and my keyboard.

    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 am just another Code Monkey.
    A determined coder can write COBOL programs in any language. -- Author unknown.
    Press any key to continue, any other key to quit

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
  • 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?
  • Here - https://forums.parallax.com/discussion/comment/1463841/#Comment_1463841
    I haven't got as far as trying it out myself. I wrecked my P2ES when I went to try.
    "We suspect that ALMA will allow us to observe this rare form of CO in many other discs.
    By doing that, we can more accurately measure their mass, and determine whether
    scientists have systematically been underestimating how much matter they contain."
  • 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,
    “Light thinks it travels faster than anything but it is wrong. No matter how fast light travels, it finds the darkness has always got there first, and is waiting for it.”
    “You only live twice:
    Once when you are born
    And once when you look death in the face”
  • pilot0315 wrote: »
    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.

    Enjoy!

    Mike
    I am just another Code Monkey.
    A determined coder can write COBOL programs in any language. -- Author unknown.
    Press any key to continue, any other key to quit

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
  • localroger wrote: »
    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.
  • P2 next respin is going to provide DRVx/TESTP/etc with basepin + group of pins :smiley:
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • 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.

    Mike
  • 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.

    Prop Info and Apps: http://www.rayslogic.com/
  • roglohrogloh Posts: 1,424
    edited 2019-05-11 - 23:00:55
    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.
  • VonSzarvasVonSzarvas Posts: 1,654
    edited 2019-06-17 - 18:03:39
    Hey guys!

    With the new Eval board coming, there's been talk of adding a couple accessory boards to the Parallax range....
    Dual-header accessory with as much HyperRAM that fits.
    Single-header breakout for the Parallax WiFi module (and thus XB footprint devices too).

    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 :)

  • Hi VonSzarvas

    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
  • 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.

  • My wish list is for the Diptrace files for the Accessory boards. That way we came design our own. :)
  • I'm surprised they're not "out there" !

    Will rectify that soon!
  • evanhevanh Posts: 8,042
    edited 2019-06-19 - 04:11:58
    [deleted]
    "We suspect that ALMA will allow us to observe this rare form of CO in many other discs.
    By doing that, we can more accurately measure their mass, and determine whether
    scientists have systematically been underestimating how much matter they contain."
  • Publison wrote: »
    My wish list is for the Diptrace files for the Accessory boards. That way we came design our own. :)

    And please include 64005-ES, (Large Protoboard).
  • VonSzarvasVonSzarvas Posts: 1,654
    edited 2019-06-21 - 08:41:07
    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.
  • @VonSzarvas,

    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
    I am just another Code Monkey.
    A determined coder can write COBOL programs in any language. -- Author unknown.
    Press any key to continue, any other key to quit

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
  • Hi VonSzarvas

    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

Sign In or Register to comment.