indeed :)
this adapter was done during early feasibility study


This is just 1:1 adapter fully passive, it is a bit speial as the PMOD connector will be lying flat on the BASEBOARD, and any connected PMOD would be aligned to the motherboard PCB not to the adapter, so the pin numbering in pmod connector looks like wrong..

To ease transition, a cruvi2PMOD adapter would be needed.

its on the TODO list already, I have latest KiCad installed too, and reading about kicad library standard..

plan is that all eagle-kicad project that are open source should link to cadlab.io for easy viewing

https://cadlab.io/cruvi

I just not have had time to actually create the templates and libraries yet..

there is also some problem with kicad libraries:

https://www.snapeda.com/home/

could deliver the library (for the samtec connectors) in all formats, but snapeda is not compatible with kicad library guidelines :(

sure for starters own kicad library would be OK too,, 

Antti

How about designing a carrierboard with this module
https://shop.trenz-electronic.de/de/TE0713-02-200-2C-FPGA-Modul-mit-Xilinx-Artix-7-XC7A200T-2FBG484C-4-x-5-cm-1-GByte-DDR3L?c=457

and some cruvi interfaces as demo?

Ed

MIPI-CSI (RASPI cam?)

MIPI-DSI

HS-1 GiG Ethernet

LS-parallel camera

HS-JESD204B  AD

HS-JESD204B  DA

LS-parallel transceiver (SX1257 PMOD)

 

its on the bottom :)

https://www.digikey.com.au/product-detail/en/hirose-electric-co-ltd/DF12-30DS-0.5V-86/H5215CT-ND/948728

well, gregs feather could be converted to cruvi using this connector.. its the other way around.. hmm
or then small mother board with gregs slot + cruvi slot, that would do also

Greg added this high speed connector to his Feather, but I dont know if it would be possible to wire it up to the adapter.

https://twitter.com/GregDavill/status/115180597056299417670562994176

yes, I probably should have made the doc in google in the first place, right now it is in the office format

https://drive.google.com/drive/folders/1z91rHqIBLRua9_ioNj3Ma6OR9cHTjNSx?usp=sharing

There is CRUVI shared folder, currently there is wip sheet for LS pin mapping-planning only

I suggest to have a google Doc document (written and made available by Antti) where people can add their comments to the standard document.

ed

I2C, RX/TX, SCK,MISO,MOSI - map 1:1, but to where connect SPI select on feather? or have lots of solder jumpers?

This adapter if done "full passive" would be really easy to-do, and it would allow also some very nice things when used with Greg's coming ECP5 feather!

Actually the HS connector could also be fitted, but then a bit more issues (open questions) arise so maybe this passive adapter is good for the first Feather adapter.

Q: what todo with unused feather IO ? and unused PCB space? some proto area?

so true - you actually have to have it "in your hands" ... doing schematic and and looking PCB in 3D is not sufficient.

lots of designs for first hardware "round" are being prepared already, but we should have some community priority "wish-list" ..

Antti

yes, this one of the first "ecosystem" adapters to be targeted:

There are possible at least 4 adapters for Click-to-CRUVI needed

1)  S size PASSIVE to CRUVI LS

this is just wired, it maps very well, SPI, UART, I2C map to cruvi 1:1
this would be too small to accept full size cruvi boards, so:

2)  L size PASSIVE to CRUVI LS
same as [1] but in L size the full CRUVI can be used and fixed with screw to the click adapter

3)  L size TRANSLATING to CRUVI LS+HS
same as [2] but with FPGA gateway to translate both LS and HS to SPI whatever the klick baseboard can accept

4) maybe S size with small fpga translator- pin remapper? can be UP5K

1, 2, are in "processing que" already

3 - need choose FPGA ! UP5K is not ok
4 - with UP5K would be easier and less questions than with [3] ? maybe just do it? would be clickUP5 ! ? ;)

so the concept so far: 

1) all modules with the high speed connector fitted are pretty much forced to include ID EEPROM, also the I2C bus on the HS connector is really pretty much mandatory as well.
2) all modules with Low speed connectors SHOULD also always when possible include the ID EEPROM, but here it is is a bit more relaxed, some ad-on as example could may have 8 LED's only and eeprom..would be not needed

current concept for LS module, use EEPROM in small package: 

24AA025E48T-I/OT

this package has 2 address pins (A2=GND), address for ID EEPROM should be set then 011 - it would be I2C addres 0x53 (or 0xA6 depend on shift)

this eeprom has unique ID (MAC ID) this may already be used to identify the module, there is small portion of EEPROM writeable, should be enough to write the minimal meta data
(TOFE.IO has similar option for small eeprom)


This is SPI Flash adapter for 6x8 mm BGA packages, SOT23-6 EEPROM with ID is added. While on this like adapter the EEPROM may not see as needed, if it has say CORRECT SPI flash device name in it, and maybe link to vendor datasheet, it would be nice benefit. 

TODO:
* I2C addresses scan order?
* meta-data itself - not first priority as it does not change the hardware design

there may be a need to recognize the mdoules by SHORT ID, one example would be where Lattice XO2 has the hardened I2C on the "ID I2C" bus - in that case we can read the TRACE ID (what can be set to identify the board) but we can not add the meta data into XO2, so question is if the additional EEPROM in parallel is mandatory in that case.. ok its corner case

HS modules - PCB space should in most case be more available so larger EEPROM can be use to store lots of meta-data?

Is a widely used system with lots of modules.

https://www.mikroe.com/click

would be great to have a design to download.

ed

I think for now the next logical step would be to make a prototpye and send out some prototypes to the relevant parties.

you can think about something to a certain extent, but then you need to touch hardware to evaluate a concept.

Ed