#apertus IRC Channel Logs

morning folks!

hi all

I red the end of yesterday chat and it seems that the beta prototype will be build next week ?!

great :)

yes, of course, a lot of work needs to be done

yes i have some skills on PIC

it is professional work, so i cannot share it

I've also build some boards based on PIC18

okay, well, the first beta prototype will not have the PIC32 on the beta board, but it has headers to plug on a shield like board which can carry a PIC32MZ for example

why did you make this choice ? to concentrate your effort on the main system that is image acquisition ?

yes, it is just to simplify things in the early phase

what design software do you use for creating boards?

ah, excellent, then it should be easy to exchange designs for now

on the right side, there is the "interface" for the PIC32

MP-NE, HDR-NE, SPI-E, HDR-SE and MP-SE

to simplify assembly, it would be great to have the mount holes present as well

personally I'd suggest to use SMD type headers for the inner ones, but THT works as well if you have enough PCB space left

I can provide a simple library for the PIC32MZ

in this schematics was hte way you want to connect the PIC with the signals on connectors ?

because for example the HDR connecotrs have some signals I don't know what to do with

yes

(FPGS/CPLD)

on the HDR-SE, we have 6 GPIO lines (U7) and again 3 pairs from the FPGA

the SPI-E is a connection to the center of the board

(or at least one of those sensors :)

the idea is to connect the U5 FPGA with one of the 6 LVDS pairs

I think it might be a good idea to add a similar CPLD/FPGA for the pic32 connection, as it would allow to have more signals/conenctions to the PIC32

ideas and input are welcome

yes, kind of at the moment

the low speed via GPIO extenders on the I2C bus

then we have the moderate speed interface which comes from the small FPGAs (U1 and U5)

and we have the high speed interfaces from the Zynq, the LVDS pairs

the pmod I2C interface from the zynq is connected to a bus multiplexer

yeah, sorry, I don't have the schematic open, just looking at the images :)

(as the flash is on the other side of the FPGA, the numbers are easy to confuse)

bus*

so we transfer data at 600-1200MHz on the LVDS pairs

so the small FPGAs function as configureable de/serializer

ok

mostly because FPGAs are not that good at procedural things

ok it's clear

or simply collect and preprocess all the DOF data

and on the beta board, for the moment, the small fpga and microzed are not connected right ? we must connect them throught the MP-NE connectors ?

so at least one pair should be dedicated to the FPGA

they are on the high speed side, where the plugin modules get attached (via the PCIe connectors)

and they serve a similar purpose, i.e. to attach devices for testing atm

and for sensors you want to connect to pic32, they have to be on the pic board

not necessarily

like for example the 9/10-DOF sensor

on the SPI-E bus

it could as well be an i2c or similar

ok

yeah, we don't have any dedicated i2c on the pic connectors yet

correct, we have investigated the following devices

they all have advantages and disadvantages so there isn't a clear winner yet

to allow for fast correlation (which would be required for image stabilization)

the FXOS8700CQT seems to be a good candidate for that

it will be not testeed right now ?

ok

i.e. we do not have to redo the entire beta board every time :)

another thing : the pic board need some connectors to connect to lcd or butons i think ?

but other ideas are welcome as well

yes, but that is more an extension for now, as we do not plan to add an LCD right now

ok so the ffc connector will be an extention connector for futher purpose

and should the pic board have some test elements, like leds or 7-segment, etc... ?

i thought the same things

because otherwise, the LEDs on the fron of the camera will show up in the image :)

for me the aim of this led is for testing communication between pic and zynq, or testing actions done by pic, but are operated by the zynq, so in case of camera using, the zynq will be able to disable leds

it is sufficient if the PIC32 can disable them on request

ok

yes, if we find a good reason for keeping those headers later (or an adapted version) then this shouldn't be a problem either

e.g. an atmel or a texas instruments

we fabricate all our boards via OSHpark

in the final product

the idea is that everybody can recreate the AXIOM Beta or parts of it

yes but what i mean is if the global cost is important, your idea of keeping these connectors is good because the board will be adapted to the need and the microcontrollers and other chips could be choose to be the cheapest

so you think keeping the headers in general (or adapted versions) would be a good idea, yes?

and if someone wants to have a lot of functionnalité here, he could take an pic32, and if he just wants to have some low speed gpio, he could take a small pic18, for example

yeah, let's revisit this at a later time when we know more

you have to find the good compromises

i don't garatee that i will be able to spend night and day on the board, but i wiil do my best

no problem

well, in general, the sooner the better

ok and are you alone with hardware conception ?

you are a big expert ! congrats !

i come back on pic board, do you have an idea about the pic32 reference you want to use ? If not, have you list the features you want (to make a choice between all pic32 chips) ?

the pincount is not decided yet, but if we can fit the larger one it probably helps with potential extensions

the bigger one is also the most expensive one

is it a parameter to take care ?

probably not really, given that the rest of the camera is quite expensive

in fact if we need a 200MHz pic32mz, price are from $6.98 to $9.52

for now it doesn't really matter

the price, and probably the choice, as they are pin compatible

land pattern is number of pin right ?

sorry but english is not my native language so sometime i don't understand all :)

ok where are you from ?

ok

for now it can be powered by the MP-NE as well as the MP-SE

so it would be preferable to use those

for potential core and I/O voltages

for the PIC, it is probably better to separate analog and digital

i.e. use one for the AVdd and another for the Vdd

the power management is on the power board, i.e. you don't need to provide a regulator on the pic board

MP-SE 1,3 connects to PWR-SE

and why pin 2 is not the gnd ?

i don't undestand your sentence :S

I added two GND pins on the other side though

if we figure out that we need a GND on this side, we can change that at a later time

what is the purpose of jx2-112 ?

it doesn't have a specific use at the momen

and the vbat for the pic board is to make some ADC measures ?

it isn't designated yet, but it is available

we will do battery measurements on the power board

(it's just the name the MicroZed used, because there it backs the FPGA memory)

do you have*

generaly you use this size ?

?

but if your design is with 0603 or even largen, no problem with that either

Bertl : do you think 4 layers is required for the pic board (essentialy to have a gnd plan) or 2 layer is sufficient ?

we stopped doing 2 layer boards for everything but the simplest of boards or when it is supposed to be mass produced, simply because of the time savings during layout

yes, a breakout or dummy board is usually fine with 2 layers but I would opt for 4 layers here as well

Hello

Bertl is this stack ored correct: MicroZed>Power>Beta>Interface>Sensor?

need it for a sketch on the wiki...

the power board is the size of the MicroZed

and both interface and sensor boards are squares the smaller size of the MicroZed

ultimately on the beta board or on a "shield style" board right above the beta board (i.e. at level of the interface board)

we might keep the headers (or similar headers) for example to allow for replacing the PIC

for now I would not go behind interface board level + 2.5mm

on both sides or just right side?

the high speed side will most likely lose the shield later

(i.e. it is mainly for testing atm)

the enormous connector is for debug/programming the pic, but a smaller one can be used

but I would suggest to put a 2mm pinheader (or similar) there and use an adapter

X3 is an FPC, correct?

yes a small 8 pin FPC

assuming that I'm looking at the board from the front

okay, then the FPC should go right

that would go to the front of the camera, which is probably not the best either

don't worry about putting it on the bottom side ?

it is just a question i have no idea :)

do you have a schematic/pinlist (what connects where) with some explanation regarding the choices?

i would like to be sure that i have the same vision as you have

so we need to make decisions what goes where and why

here are the promised .dru files for OSHpark: http://vserver.13thfloor.at/Stuff/OSHPARK/

I would suggest using the 4layer-tuned.dru

how do you use dru files ? I always use cam files to generate gerber files with eagle

there is a Load button, which allows you to select the .dru

after that, Apply/OK and run the DRC

it isn't a little bit rich to use an entire connector for jtag whereas this connector could be used for GPIO ?

the main idea is that the pic can be reprogrammed from "inside" the camera

jtag is rather simple to do, we can easily put that in any FPGA

ok

i.e. the 6 pairs coming from the Zynq will most likely have a 1.8V level

looks good, as I said, for now (test boards) we also have headers and a "shield" on the high speed front

(the power board has the same interface and a µSD on the low speed side

Bertl : do you have any idea about the price of the axiom alpha if I want to build it ?

it is only the sensor board in fact ?! the zedboard can be buy in one piece

you will get 3 boards for about 75 USD

the components are rather cheap, around 50 bucks

and of course the sensor, which is really expensive

you also need to build a small cable from one PMOD port to the connector on the sensor PCB

yes, back then, we first got an engineering sample (at half the price)

If you get the sensor out of the socket you can use it for the beta again!

it makes sense

that is easy, if you use the tool designed by daFred to safely remove the sensor :p

but it has to be designed and built first... and of course closed source :-)

i found the price of the sensor in the wiki o_O

there are cheaper alternatives, but only for the beta I think

the initial project is to have 4K camera in fact ?

yes, the plan is to have a 4k cinema movie camera

(with lower resolutions)

yes

ok

the image is stored completely (i.e. 4k raw) in memory

so you can take 4k snapshots with the AXIOM Alpha

ok

i.e. there will be a CMV2k/4k sensor board for the Beta

but the soft will have to be change too ?! it is not pin to pin compatible because the number of outputs are not the same ?!

the sensor board is already well defined from the connector pinout

ok i remember your yesterday discution about this

and you can not connect all the outputs of sensor to the zynq (64 for cmv12k or 16 for cmv2k) and configure zynq code in function of sensor reference (i imagine the reference can be get throught spi) ?

for the CMV2k/4k it would be possible

you use 32 lvds output multiplexage on the alpha ?

actually +3, because we have an input and output clock as well

for now, yes

ok

for now, yes, with a fully functional interface board, no

i.e. the interface board will be reconfigured according to the sensor

ok

\o/

yes :)

and you had subsystems one after the others

thanks for this good discution

good evening

bye