00:52 | MatthiasF | left the channel | |
01:58 | fsteinel_ | joined the channel | |
02:01 | fsteinel | left the channel | |
02:03 | intracube | left the channel | |
07:04 | Bertl_zZ | changed nick to: Bertl
| |
07:04 | Bertl | morning folks!
| |
08:28 | Francky | joined the channel | |
08:30 | Francky | hi all
| |
08:35 | Bertl | hey Francky!
| |
08:39 | Francky | I red the end of yesterday chat and it seems that the beta prototype will be build next week ?!
| |
08:41 | Bertl | with a little luck, yes
| |
08:44 | Francky | great :)
| |
08:44 | Francky | do you still need some help ?
| |
08:44 | Bertl | yes, of course, a lot of work needs to be done
| |
08:45 | Bertl | you said yesterday, that you would be interested in working on the PIC32 side, yes?
| |
08:46 | Francky | yes i have some skills on PIC
| |
08:47 | Bertl | anything online you can show me?
| |
08:48 | Francky | it is professional work, so i cannot share it
| |
08:48 | Francky | in summary i've made lot of firmware on pic18 and pic32, using a lot the Ethernet stack on both devices
| |
08:48 | Francky | I've also build some boards based on PIC18
| |
08:50 | Francky | i must admit i am not aware with open source organisation, because i haven't got any occasion working on microchip devices for this type of project
| |
08:50 | Bertl | 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
| |
08:52 | Bertl | so you could, if you like, design such a board and help integrating it into the system, including software for the pic32
| |
08:52 | Francky | why did you make this choice ? to concentrate your effort on the main system that is image acquisition ?
| |
08:53 | Bertl | once we know what interface we want/need, we adapt the design and put it on the Beta board
| |
08:53 | Bertl | yes, it is just to simplify things in the early phase
| |
08:53 | Francky | ok
| |
08:54 | Bertl | what design software do you use for creating boards?
| |
08:54 | Francky | the same like you : Eagle :)
| |
08:55 | Bertl | ah, excellent, then it should be easy to exchange designs for now
| |
08:55 | Bertl | check out: http://vserver.13thfloor.at/Stuff/AXIOM/BETA/axiom_beta_board_100_v0.16_test.{sch,brd}
| |
08:56 | Bertl | on the right side, there is the "interface" for the PIC32
| |
08:57 | Bertl | it consists of 5 headers, all 2mm pitch
| |
08:57 | Bertl | MP-NE, HDR-NE, SPI-E, HDR-SE and MP-SE
| |
08:58 | Bertl | the measurement labeled with 2250 is also the width of the interface board, so the "pic" board has all the space to the right of that line
| |
08:59 | Bertl | to simplify assembly, it would be great to have the mount holes present as well
| |
08:59 | Bertl | the first step would be to create an empty board which connects to the headers
| |
09:00 | Bertl | 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
| |
09:00 | Francky | ok undestood
| |
09:01 | Bertl | I can provide a simple library for the PIC32MZ
| |
09:02 | Bertl | and some schematic we planned for the beta before we decided to make it even more modular
| |
09:02 | Francky | in this schematics was hte way you want to connect the PIC with the signals on connectors ?
| |
09:03 | Bertl | the current connections are just for testing purposes
| |
09:03 | Francky | because for example the HDR connecotrs have some signals I don't know what to do with
| |
09:03 | Francky | what you want to do with
| |
09:03 | Bertl | yes
| |
09:04 | Bertl | on the HDR-NE, we have 6 lines from the U5 FPGA
| |
09:04 | Bertl | (FPGS/CPLD)
| |
09:04 | Bertl | and 6 lines (3 pairs) directly from the MicroZed FPGA
| |
09:05 | Bertl | on the HDR-SE, we have 6 GPIO lines (U7) and again 3 pairs from the FPGA
| |
09:05 | Francky | ok they are general purpose IO and we don't know now what will be the use right ?
| |
09:05 | Bertl | the SPI-E is a connection to the center of the board
| |
09:05 | Bertl | where for example the 10-DOF sensor will be located
| |
09:06 | Bertl | (or at least one of those sensors :)
| |
09:06 | Bertl | this is currently also designed to allow for testing
| |
09:07 | Bertl | the idea is to connect the U5 FPGA with one of the 6 LVDS pairs
| |
09:08 | Bertl | so that it can service the various interface board connections
| |
09:09 | Bertl | 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
| |
09:09 | Bertl | but that isn't strictly necessary, so that is something which has not been decided yet
| |
09:09 | Bertl | ideas and input are welcome
| |
09:11 | Francky | just to be sure of what i think : the beta board is an interface board right ? between sensor board, microzed board and pic board ?!
| |
09:12 | Bertl | yes, kind of at the moment
| |
09:12 | Bertl | basically we have 3 speed grades for signals on the beta board
| |
09:12 | Bertl | the low speed via GPIO extenders on the I2C bus
| |
09:12 | Bertl | that's U3 and U7
| |
09:13 | Bertl | then we have the moderate speed interface which comes from the small FPGAs (U1 and U5)
| |
09:13 | Francky | the i2c bus is used by ZYNQ right ?
| |
09:13 | Bertl | and we have the high speed interfaces from the Zynq, the LVDS pairs
| |
09:14 | Bertl | yes, the zynq has access to the i2c bus
| |
09:15 | Bertl | the pmod I2C interface from the zynq is connected to a bus multiplexer
| |
09:16 | Francky | it is clear for the i2c and lvds, but what about U1 and U5 ? It seems to be flash memory with spi interface. the fpga are u2 and u6 no ?
| |
09:16 | Bertl | yeah, sorry, I don't have the schematic open, just looking at the images :)
| |
09:17 | Francky | so the aim of these small fpga is to be used as gpio expender on an lvds buf of the zynq ?!
| |
09:17 | Bertl | (as the flash is on the other side of the FPGA, the numbers are easy to confuse)
| |
09:17 | Bertl | yes, to reduce the amount of LVDS pairs/signals used from the zynq
| |
09:17 | Francky | bus*
| |
09:17 | Francky | ok
| |
09:18 | Bertl | so we transfer data at 600-1200MHz on the LVDS pairs
| |
09:18 | Bertl | but for example the pic can only handle 80MHz or so on the PMP or similar
| |
09:19 | Bertl | so the small FPGAs function as configureable de/serializer
| |
09:19 | Francky | ok the small fpga will make the conversion
| |
09:19 | Francky | ok
| |
09:19 | Francky | and the aim of the pic is to interface with sensors and gpio ? why don't do that with the small fpga ?
| |
09:20 | Bertl | mostly because FPGAs are not that good at procedural things
| |
09:20 | Bertl | and many tasks a processor like the PIC can do easily (because of hardware interfaces) are hard or resource hungry in an FPGA
| |
09:21 | Francky | ok it's clear
| |
09:21 | Bertl | for example, the PIC could handle an LCD display or manage a number of buttons and dials
| |
09:22 | Bertl | or simply collect and preprocess all the DOF data
| |
09:22 | Bertl | watch sensors, create logs, etc
| |
09:22 | Francky | 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 ?
| |
09:23 | Bertl | correct
| |
09:23 | Bertl | so at least one pair should be dedicated to the FPGA
| |
09:23 | Francky | and what about the connectors WEST ?
| |
09:24 | Bertl | they are on the high speed side, where the plugin modules get attached (via the PCIe connectors)
| |
09:24 | Francky | ok
| |
09:24 | Bertl | and they serve a similar purpose, i.e. to attach devices for testing atm
| |
09:25 | Bertl | most likely they will get replaced by a single FPGA, but we haven't decided yet
| |
09:25 | Francky | and for sensors you want to connect to pic32, they have to be on the pic board
| |
09:25 | Francky | ?
| |
09:26 | Bertl | not necessarily
| |
09:26 | Bertl | the center of the beta board is unused, so that would be a great place to put a bunch of sensors
| |
09:26 | Bertl | like for example the 9/10-DOF sensor
| |
09:27 | Francky | connected on the spi bus
| |
09:27 | Francky | on the SPI-E bus
| |
09:27 | Bertl | yes, if we decide to use it as SPI
| |
09:27 | Bertl | it could as well be an i2c or similar
| |
09:27 | Bertl | I just labeled it SPI because I had 3 lines
| |
09:28 | Francky | ok
| |
09:28 | Francky | i was searching for i2c bus on the pic connectors...
| |
09:29 | Bertl | yeah, we don't have any dedicated i2c on the pic connectors yet
| |
09:29 | Francky | in my opinion SPI bus are better than i2c, mostly for speed, but it depends on what sensors we will use
| |
09:29 | Bertl | correct, we have investigated the following devices
| |
09:30 | Bertl | http://pastebin.com/1Xa6ENyk
| |
09:31 | Bertl | they all have advantages and disadvantages so there isn't a clear winner yet
| |
09:32 | Bertl | we also want to put at least a second accelerometer at the side (or sides) of the Beta pcb
| |
09:32 | Bertl | to allow for fast correlation (which would be required for image stabilization)
| |
09:32 | Francky | ok
| |
09:32 | Bertl | the FXOS8700CQT seems to be a good candidate for that
| |
09:33 | Francky | but there wasn't this type of device on the proto board ?
| |
09:33 | Francky | it will be not testeed right now ?
| |
09:34 | Bertl | correct, the sensors get added as 'solder on' boards in the middle or on the PIC32 board for now
| |
09:34 | Francky | ok
| |
09:34 | Bertl | this also allows for simplified testing
| |
09:34 | Bertl | i.e. we do not have to redo the entire beta board every time :)
| |
09:35 | Francky | ok it is clearer for me
| |
09:36 | Francky | another thing : the pic board need some connectors to connect to lcd or butons i think ?
| |
09:36 | Bertl | yes, we were considering an FPC/FFC connection for this purpose
| |
09:36 | Bertl | but other ideas are welcome as well
| |
09:37 | Francky | ok so we will need to build another board to add a lcd or button ?
| |
09:38 | Bertl | yes, but that is more an extension for now, as we do not plan to add an LCD right now
| |
09:38 | Bertl | but the main idea is to keep that option open for folks who want to use the Beta as still camera
| |
09:38 | Francky | ok so the ffc connector will be an extention connector for futher purpose
| |
09:38 | Bertl | that was the idea, yes
| |
09:39 | Francky | and should the pic board have some test elements, like leds or 7-segment, etc... ?
| |
09:39 | Bertl | I think the first PIC32 board should also feature a bunch of LEDs for debugging/testing purpose which later can/should be repurposed as GPIO interfaces
| |
09:40 | Francky | i thought the same things
| |
09:41 | Bertl | it is important though, that we can disable them
| |
09:41 | Bertl | because otherwise, the LEDs on the fron of the camera will show up in the image :)
| |
09:42 | cbohnens|away | changed nick to: cbohnens
| |
09:43 | Francky | 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
| |
09:43 | Bertl | and in general, really low power solutions are preferable, not just because of the power consumption but also because of the light pollution
| |
09:43 | Bertl | it is sufficient if the PIC32 can disable them on request
| |
09:44 | Bertl | just avoid things like a "power good" LED or so
| |
09:44 | Francky | ok
| |
09:45 | Francky | in any case, as it will be a "extention board", the pic board will be able to be removed if it generate too much noise, so it is a good idea to have put these headers
| |
09:45 | Bertl | yes, if we find a good reason for keeping those headers later (or an adapted version) then this shouldn't be a problem either
| |
09:46 | Bertl | for example, I was thinking of having those headers to allow for a different microcontroller than the PIC32
| |
09:46 | Bertl | e.g. an atmel or a texas instruments
| |
09:46 | Francky | is the cost of this board important ?
| |
09:47 | Bertl | we fabricate all our boards via OSHpark
| |
09:47 | Francky | i mean the final board
| |
09:47 | Francky | in the final product
| |
09:47 | Bertl | I'm talking about the final boards :)
| |
09:48 | Bertl | the idea is that everybody can recreate the AXIOM Beta or parts of it
| |
09:48 | Bertl | so the design guidelines (you can get proper .dru files from me) are those from OSHpark
| |
09:48 | Francky | 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
| |
09:49 | Francky | i don't know if what i say is clear :p
| |
09:49 | Bertl | so you think keeping the headers in general (or adapted versions) would be a good idea, yes?
| |
09:49 | niemand | joined the channel | |
09:50 | MatthiasF | joined the channel | |
09:50 | Bertl | well, as I said, no problem with that, if it turns out to make sense :)
| |
09:50 | Francky | 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
| |
09:50 | Francky | it is my opinion without having a long time reflexion :)
| |
09:51 | Bertl | yeah, let's revisit this at a later time when we know more
| |
09:52 | Francky | you also have to be carrefull of wanting to have the most versatiel system, and finally the system is too complex
| |
09:53 | Francky | you have to find the good compromises
| |
09:53 | Bertl | yes, of course
| |
09:55 | Francky | i don't garatee that i will be able to spend night and day on the board, but i wiil do my best
| |
09:57 | Francky | as the same time i am very interested in the zynq chip because i find it is a wonderfull device
| |
09:59 | niemand | left the channel | |
10:00 | Bertl | sure, just keep us updated and if you have any question or want to discuss some decisions, do not hesitate
| |
10:01 | Francky | no problem
| |
10:01 | Francky | do you work with a planning ? i. e. is there a dead line for the pic board ? Or a date you want the board done to make tests ?
| |
10:19 | Bertl | well, in general, the sooner the better
| |
10:20 | Bertl | I'd say if we have a design in a week and maybe can test/assemble the board in two weeks that would be excellent, of course, if it takes longer, then it takes longer :)
| |
10:22 | Francky | ok and are you alone with hardware conception ?
| |
10:23 | Bertl | for now, I'm doing most of the hardware design and testing, yes
| |
10:27 | Francky | you are a big expert ! congrats !
| |
10:30 | Bertl | thanks! I do my best
| |
10:37 | Francky | 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) ?
| |
10:37 | Bertl | we decided to go for the PIC32MZ which is relatively new
| |
10:38 | Bertl | the pincount is not decided yet, but if we can fit the larger one it probably helps with potential extensions
| |
10:39 | Bertl | the existing versions only differ in the memory/feature size not in the pin assignment
| |
10:43 | Francky | the bigger one is also the most expensive one
| |
10:44 | Francky | price is from $1.51 to $9.52 into the pic32mz familly
| |
10:44 | Francky | is it a parameter to take care ?
| |
10:44 | Bertl | yup, so a good range
| |
10:45 | Bertl | probably not really, given that the rest of the camera is quite expensive
| |
10:45 | Bertl | but of course, if somebody wants to build an extemely low cost version, then the cheap pic32mz would work as well
| |
10:46 | Francky | in fact if we need a 200MHz pic32mz, price are from $6.98 to $9.52
| |
10:46 | Francky | so maybe taking the bigger one is the simplest way
| |
10:46 | Bertl | for now it doesn't really matter
| |
10:47 | Francky | what doesn't matter ? the choice of the pic or the price of the pic ?
| |
10:47 | Bertl | the price, and probably the choice, as they are pin compatible
| |
10:48 | Bertl | the only question is what land pattern do we choose
| |
10:48 | Francky | land pattern is number of pin right ?
| |
10:49 | Bertl | yes, that and if it is QFN or not
| |
10:49 | Francky | sorry but english is not my native language so sometime i don't understand all :)
| |
10:49 | Bertl | mine neither, so no problem there
| |
10:50 | Francky | ok where are you from ?
| |
10:50 | Bertl | Austria
| |
10:50 | Francky | ok
| |
11:06 | Francky | the pic board will be powered by the vbat of MP-NE ? what is the voltage of VBAT ?
| |
11:07 | Bertl | for now it can be powered by the MP-NE as well as the MP-SE
| |
11:07 | Bertl | in general the pins 1 and 3 of the MP-SE are 'dedicated' for the PIC
| |
11:08 | Bertl | so it would be preferable to use those
| |
11:08 | Francky | why 2 différent voltage ?
| |
11:08 | Bertl | for potential core and I/O voltages
| |
11:10 | Francky | the pic will command IO with the IO voltage (by a nmos for example) and a regulator will be used to get power to the pic from the core voltage ?
| |
11:12 | Bertl | for the PIC, it is probably better to separate analog and digital
| |
11:12 | Francky | do you mean voltage from MP-SE is for core and voltage from MP-NE is for IO ?
| |
11:12 | Bertl | i.e. use one for the AVdd and another for the Vdd
| |
11:13 | Francky | in fact i don't undestand the signal routing on MP-SE
| |
11:13 | Bertl | the power management is on the power board, i.e. you don't need to provide a regulator on the pic board
| |
11:13 | Francky | aaahhhh ok
| |
11:13 | Bertl | MP-SE 1,3 connects to PWR-SE
| |
11:14 | Bertl | which is a direct conenction to the power board
| |
11:15 | Francky | and why pin 2 is not the gnd ?
| |
11:15 | Bertl | because the JX2-112 was on this side :)
| |
11:16 | Francky | i don't undestand your sentence :S
| |
11:17 | Bertl | I didn't put a GND on this side, because the connection to JX2-112 was more important for me
| |
11:17 | Bertl | I added two GND pins on the other side though
| |
11:17 | Francky | ah ok, but i take each MP connector separatly...
| |
11:18 | Bertl | if we figure out that we need a GND on this side, we can change that at a later time
| |
11:18 | Francky | it was a misconception in my mind
| |
11:18 | Francky | what is the purpose of jx2-112 ?
| |
11:19 | Bertl | on the MicroZed it is a power pin as well, so I used the same to provide power to the beta board
| |
11:19 | Bertl | it doesn't have a specific use at the momen
| |
11:19 | Bertl | *moment
| |
11:20 | Francky | and the vbat for the pic board is to make some ADC measures ?
| |
11:20 | Bertl | the vbat (JX1-7) is the same story as with the JX2-112
| |
11:20 | Bertl | it isn't designated yet, but it is available
| |
11:20 | Francky | ok
| |
11:21 | Bertl | we will do battery measurements on the power board
| |
11:21 | Bertl | it already has the instrumentation for that, so not related to the battery
| |
11:21 | Bertl | (it's just the name the MicroZed used, because there it backs the FPGA memory)
| |
11:25 | Francky | do you restriction about device size, for resistors for example ?
| |
11:25 | Francky | do you have*
| |
11:26 | Bertl | we shouldn't go below 0402, because it is hard to hand assemble
| |
11:28 | Francky | generaly you use this size ?
| |
11:28 | Francky | or biggger if possible
| |
11:28 | Francky | ?
| |
11:29 | Bertl | I think 0402 is fine, larger sizes usually only if required to reduce costs or have more parts available (like for larger capacitors or ferrite beads)
| |
11:29 | Bertl | but if your design is with 0603 or even largen, no problem with that either
| |
11:54 | Francky | changed nick to: Francky|away
| |
12:06 | niemand | joined the channel | |
12:37 | niemand | left the channel | |
13:23 | fsteinel_ | changed nick to: fsteinel
| |
13:26 | niemand | joined the channel | |
13:47 | MedicalSMT | joined the channel | |
13:51 | MedicalSMT | left the channel | |
14:26 | fsteinel | left the channel | |
14:29 | Francky|away | changed nick to: Francky
| |
14:30 | Francky | Bertl : do you think 4 layers is required for the pic board (essentialy to have a gnd plan) or 2 layer is sufficient ?
| |
14:34 | Bertl | probably 4 layer will be simpler
| |
14:34 | cbohnens | 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
| |
14:35 | cbohnens | (engineering hours > board costs)
| |
14:35 | Bertl | yes, a breakout or dummy board is usually fine with 2 layers but I would opt for 4 layers here as well
| |
14:36 | intracube | joined the channel | |
14:50 | philippej|away | changed nick to: philippej
| |
14:54 | cbohnens | changed nick to: cbohnens|away
| |
15:04 | niemand | left the channel | |
15:05 | daFred | joined the channel | |
15:05 | daFred | Hello
| |
15:07 | Bertl | hello daFred!
| |
15:08 | daFred | Bertl is this stack ored correct: MicroZed>Power>Beta>Interface>Sensor?
| |
15:08 | daFred | order*
| |
15:09 | daFred | need it for a sketch on the wiki...
| |
15:11 | Bertl | yes
| |
15:11 | Bertl | the power board is the size of the MicroZed
| |
15:11 | Bertl | the beta board is slighly wider on one side (for the PCIe connectors)
| |
15:12 | Bertl | and both interface and sensor boards are squares the smaller size of the MicroZed
| |
15:12 | daFred | ok. and where will be the PIC32 be located?
| |
15:13 | Bertl | ultimately on the beta board or on a "shield style" board right above the beta board (i.e. at level of the interface board)
| |
15:14 | Bertl | the current test boards have headers for two shields, one on the high speed and one on the pic32 side to test different setups
| |
15:15 | Bertl | we might keep the headers (or similar headers) for example to allow for replacing the PIC
| |
15:15 | daFred | we are looking for the avilable space for the cooling stuff, so we should not go behind the interface board level?
| |
15:16 | Bertl | for now I would not go behind interface board level + 2.5mm
| |
15:16 | Bertl | i.e. half between interface board and sensor board to accomodate for part heights
| |
15:17 | daFred | on both sides or just right side?
| |
15:17 | Bertl | on both sides
| |
15:17 | Bertl | the high speed side will most likely lose the shield later
| |
15:17 | daFred | ok thanks
| |
15:18 | Bertl | (i.e. it is mainly for testing atm)
| |
15:34 | Francky | is this type of pic board something like you had in mind ? https://dl.dropboxusercontent.com/u/782577/axiom_beta_pic_board.png
| |
15:35 | Francky | the enormous connector is for debug/programming the pic, but a smaller one can be used
| |
15:36 | Bertl | ah, yes, we plan to do the programming of the pic via jtag from the beta board, but for now it is fine to have it external
| |
15:36 | Bertl | but I would suggest to put a 2mm pinheader (or similar) there and use an adapter
| |
15:36 | Francky | of course
| |
15:37 | Bertl | X3 is an FPC, correct?
| |
15:37 | Francky | about jtag, it seems that microchip standard tools don't know about jtag and use only the Microchip connection
| |
15:37 | Francky | yes a small 8 pin FPC
| |
15:38 | Bertl | it would probably be better to put it on the right side, because the left side rivals with the interface board
| |
15:38 | Bertl | assuming that I'm looking at the board from the front
| |
15:39 | Francky | the board is shown at the top, 2mm connectors are on bottom
| |
15:39 | Bertl | okay, then the FPC should go right
| |
15:39 | Francky | ok por fpc. Can we immagine put a vertical one to preserve space ?
| |
15:40 | Bertl | that would go to the front of the camera, which is probably not the best either
| |
15:40 | Francky | ok
| |
15:41 | Francky | don't worry about putting it on the bottom side ?
| |
15:41 | Bertl | regarding jtag: I know about the microchip proprietary programming interface, but I also know that we can use pic32 prog and/or similar to programm the pic
| |
15:41 | Francky | it is just a question i have no idea :)
| |
15:41 | Bertl | bottom or top, both should be fine
| |
15:42 | Bertl | do you have a schematic/pinlist (what connects where) with some explanation regarding the choices?
| |
15:44 | Francky | for the moment i don't really make a choice, just for SPI, but other pin are connected to connector without reflexion
| |
15:44 | Francky | i would like to be sure that i have the same vision as you have
| |
15:45 | Bertl | okay, because certain peripherials are not mappable on the PIC32
| |
15:45 | Bertl | so we need to make decisions what goes where and why
| |
15:45 | Francky | yes, i look for the SPI, which is correctly connected
| |
15:46 | Bertl | here are the promised .dru files for OSHpark: http://vserver.13thfloor.at/Stuff/OSHPARK/
| |
15:46 | Francky | after it depend on what you want to do with signals on HDR-* connectors
| |
15:46 | Bertl | I would suggest using the 4layer-tuned.dru
| |
15:47 | Bertl | yes, the HDR-SE low speed interfaces is more or less planned for the jtag of the PIC, although it might be an option to use the HDR-NE medium speed ports as well
| |
15:48 | Francky | how do you use dru files ? I always use cam files to generate gerber files with eagle
| |
15:48 | Bertl | Edit -> Design Rules
| |
15:48 | Bertl | there is a Load button, which allows you to select the .dru
| |
15:49 | Francky | ah ok it's design rules files, i used to manually change these settings...
| |
15:49 | Bertl | after that, Apply/OK and run the DRC
| |
15:49 | cbohnens|away | changed nick to: cbohnens
| |
15:51 | Francky | it isn't a little bit rich to use an entire connector for jtag whereas this connector could be used for GPIO ?
| |
15:51 | Francky | ie : what is the reason why you will use jtag ?
| |
15:52 | Bertl | the main idea is that the pic can be reprogrammed from "inside" the camera
| |
15:52 | Bertl | (like all the other elements)
| |
15:53 | cbohnens | changed nick to: cbohnens|away
| |
15:53 | Francky | and you have a jtag emulator inside ?!
| |
15:54 | Bertl | jtag is rather simple to do, we can easily put that in any FPGA
| |
15:55 | Bertl | it also allows us to do boundary scan tests
| |
15:55 | Francky | ok
| |
15:57 | Bertl | note that we probably need at least a level converter for the LVDS lanes
| |
15:57 | Bertl | i.e. the 6 pairs coming from the Zynq will most likely have a 1.8V level
| |
15:58 | Bertl | but it would probably be better to run them through a CPLD or similar
| |
16:01 | intracube_ | joined the channel | |
16:05 | intracube | left the channel | |
16:05 | intracube_ | changed nick to: intracube
| |
16:08 | daFred | stack concept drawing v3 in the wiki added: https://wiki.apertus.org/images/e/e6/PCB_Stack_Concept_V03_02.jpg
| |
16:12 | Bertl | looks good, as I said, for now (test boards) we also have headers and a "shield" on the high speed front
| |
16:12 | Bertl | and most likely, we will get rid of the dual µSD module on the back, at least for the default stackup
| |
16:14 | Bertl | (the power board has the same interface and a µSD on the low speed side
| |
16:14 | Bertl | )
| |
16:14 | Francky | Bertl : do you have any idea about the price of the axiom alpha if I want to build it ?
| |
16:15 | Bertl | daFred: what I was wondering is how the module PCBs "connect" to the module cages
| |
16:15 | Francky | it is only the sensor board in fact ?! the zedboard can be buy in one piece
| |
16:15 | Bertl | you can order the sensor board via OSHpark
| |
16:15 | Bertl | you will get 3 boards for about 75 USD
| |
16:15 | Bertl | (including shipping)
| |
16:16 | Bertl | the components are rather cheap, around 50 bucks
| |
16:16 | Bertl | the expensive parts are the sensor socket (about 40 EUR, IIRC)
| |
16:16 | Bertl | and of course the sensor, which is really expensive
| |
16:17 | Bertl | (se6astian|away has the details for the sensor price)
| |
16:17 | Bertl | you also need to build a small cable from one PMOD port to the connector on the sensor PCB
| |
16:17 | Francky | did you buy the sensor directly from cmosis ?
| |
16:17 | Bertl | yes, back then, we first got an engineering sample (at half the price)
| |
16:18 | Bertl | and later we bought a "perfect" sensor (as they call them)
| |
16:18 | daFred | If you get the sensor out of the socket you can use it for the beta again!
| |
16:18 | Bertl | yep, that's the main reason for using a socket :)
| |
16:19 | Francky | it makes sense
| |
16:19 | daFred | If you don´t brake one of the tiny pins :-)
| |
16:19 | Bertl | that is easy, if you use the tool designed by daFred to safely remove the sensor :p
| |
16:20 | daFred | :-)
| |
16:24 | niemand | joined the channel | |
16:25 | mars_ | you could sell the tool and get rich!
| |
16:29 | daFred | but it has to be designed and built first... and of course closed source :-)
| |
16:30 | mars_ | closed source and at least 20 patents on it
| |
16:31 | Francky | i found the price of the sensor in the wiki o_O
| |
16:31 | mars_ | yeah...
| |
16:32 | mars_ | there are cheaper alternatives, but only for the beta I think
| |
16:32 | Francky | your need was to have 12MP for the camera right ?
| |
16:34 | Francky | the initial project is to have 4K camera in fact ?
| |
16:34 | Francky | you did not want to sacrify the resolution due to the price ?
| |
16:34 | Bertl | yes, the plan is to have a 4k cinema movie camera
| |
16:35 | Bertl | but there are cheaper sensor options as well, for example the CMV2k/4k
| |
16:35 | Bertl | (with lower resolutions)
| |
16:35 | Francky | and in the alpha software the zynq make a resizing of the image to 1080p ?
| |
16:35 | Bertl | yes
| |
16:35 | Francky | to be complient with hdmi ?
| |
16:35 | Francky | ok
| |
16:35 | Francky | is it a resize or a cut ?
| |
16:35 | Bertl | the image is stored completely (i.e. 4k raw) in memory
| |
16:36 | Bertl | and again retrieved from memory, downconverted to 1080p and transmitted via HDMI
| |
16:36 | Bertl | so you can take 4k snapshots with the AXIOM Alpha
| |
16:36 | Francky | exact the cmv2k is sufficient to make 1080p
| |
16:36 | Francky | ok
| |
16:37 | Bertl | yes, and we will also support the CMV2k on the Beta
| |
16:37 | Bertl | i.e. there will be a CMV2k/4k sensor board for the Beta
| |
16:37 | Francky | it's a good idea to have a quiet cheaper camera
| |
16:38 | Francky | 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 ?!
| |
16:38 | Bertl | the trick is the interface board
| |
16:38 | Bertl | the sensor board is already well defined from the connector pinout
| |
16:39 | Bertl | and the interface board does the necessary data mangling to make the datastream and configuration sensor agnostic
| |
16:39 | Francky | ok i remember your yesterday discution about this
| |
16:39 | Bertl | for now, the interface board is just a patch board which connects a subset of the sensor pins
| |
16:41 | Francky | 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) ?
| |
16:42 | Bertl | well, we don't have 64 LVDS pairs on the Zynq, so no
| |
16:42 | Bertl | for the CMV2k/4k it would be possible
| |
16:42 | Bertl | but it is simpler to generalize the interface
| |
16:42 | Francky | you use 32 lvds output multiplexage on the alpha ?
| |
16:43 | Bertl | yes, the alpha only connects 32 + 1 pairs
| |
16:43 | Bertl | actually +3, because we have an input and output clock as well
| |
16:44 | Francky | so to be clear (for me) the interface board is just a "routing" board to connect the sensor to the "standard" beta board connectors ?
| |
16:45 | Bertl | for now, yes
| |
16:45 | Bertl | it will become a pre-processing board later
| |
16:45 | Francky | ok
| |
16:46 | Francky | but for zynq software, there was to different type of connexions : 32 lvds for cmv12k and 16 for cmv2k so it will have to configure itself to get data correctly ?
| |
16:46 | Bertl | for now, yes, with a fully functional interface board, no
| |
16:46 | Francky | ok
| |
16:47 | Bertl | i.e. the interface board will be reconfigured according to the sensor
| |
16:47 | Bertl | but the zynq always sees the same interface
| |
16:47 | Francky | ok
| |
16:50 | Francky | i start to understand the project :D
| |
16:50 | Bertl | \o/
| |
16:52 | Francky | and you expect to have a working first prototype of beta in one or two weeks ?
| |
16:52 | Bertl | yes :)
| |
16:53 | Francky | it was the "base" of the system if i understand right
| |
16:54 | Francky | and you had subsystems one after the others
| |
16:54 | Francky | (pic, preproc board, etc...)
| |
16:57 | Francky | thanks for this good discution
| |
16:57 | Francky | i need to go
| |
16:57 | Francky | good evening
| |
16:58 | Bertl | have a good evening! cya!
| |
16:58 | Francky | bye
| |
16:58 | Francky | left the channel | |
17:07 | philippej | changed nick to: philippej|away
| |
17:23 | se6astian|away | changed nick to: se6astian
| |
17:49 | niemand | left the channel | |
19:03 | se6astian | changed nick to: se6astian|away
| |
19:08 | niemand | joined the channel | |
19:35 | intracube | left the channel | |
19:41 | intracube | joined the channel | |
19:50 | alesage | left the channel | |
19:52 | alesage | joined the channel | |
20:09 | Bertl | off for a nap ... bbl
| |
20:10 | Bertl | changed nick to: Bertl_zZ
| |
20:13 | Andrej741 | left the channel | |
20:14 | se6astian|away | changed nick to: se6astian
| |
20:44 | niemand | left the channel | |
22:04 | daFred | left the channel | |
22:14 | Andrej741 | joined the channel | |
22:31 | Jin^eLD | joined the channel | |
22:31 | se6astian | time for bed
| |
22:34 | se6astian | changed nick to: se6astian|away
|