23:37 | MatthiasF | left the channel | |
00:26 | fsteinel | joined the channel | |
00:56 | Jin^eLD | changed nick to: Jin|away
| |
00:57 | fsteinel_ | joined the channel | |
01:00 | fsteinel | left the channel | |
01:00 | fsteinel_ | changed nick to: fsteinel
| |
01:14 | ItsMeLenny | joined the channel | |
02:15 | intracube | changed nick to: intracube_afk
| |
02:30 | jucar | left the channel | |
04:45 | ItsMeLenny | left the channel | |
04:46 | ItsMeLenny | joined the channel | |
05:31 | Bertl_zZ | changed nick to: Bertl
| |
05:31 | Bertl | morning folks!
| |
05:37 | ItsMeLenny | morning Bertl!
| |
07:06 | Francky | joined the channel | |
07:15 | Francky | hey Bertl
| |
07:15 | Francky | you saw me yesterday that signal are 1.
| |
07:15 | Francky | 1.8V on connectors on the pic board
| |
07:15 | Francky | so a converter is needed
| |
07:16 | Francky | do you have any converter references that you have already used ?
| |
07:50 | Bertl | yes, for the LVDS (i.e. signals coming from the Zynq) the other signals are 3.3V
| |
07:52 | Bertl | for I2C we have been using the GTL2002 and similar, for unidirectional signals the 74LVC125 or 74AVC4T245 seems to do a good job
| |
07:53 | Bertl | or 74AVC4T774 as alternative
| |
08:00 | Francky | and have you already select which signal will be the jtag signals or it doesn't matter because you will choose in the vhdl code ?
| |
08:01 | Francky | i mean jtag of pic
| |
08:01 | Francky | on the hdr ne connector
| |
08:01 | MatthiasF | joined the channel | |
08:03 | Francky | lvds signals are JX* signals on hdr connectors right ?
| |
08:03 | Bertl | assuming that the PIC will not be reprogrammed that often, we could use the GPIO pins, i.e. 4/5 of the HDR-SE pins connecting to U7
| |
08:04 | Bertl | or alternatively, 4/5 of the medium speed pins from HDR-NE going to U6
| |
08:04 | Bertl | yes, the "right side" of HDR-SE and HDR-NE is from the Zynq
| |
08:08 | Francky | in my mind jtag needs 4 signals ?!
| |
08:08 | Bertl | yeah, we might need the reset as well
| |
08:08 | Francky | oh 4/5 in your sentence mean "4/5 pins" and not "the pins 4 and 5"
| |
08:09 | Bertl | yep
| |
08:09 | Francky | ok
| |
08:09 | cbohnens|away | changed nick to: cbohnens
| |
08:13 | Francky | for I2C/SPI signals, they are 1.8V level too ?
| |
08:13 | Bertl | we'll probably go for 3.3V there
| |
08:14 | Francky | so no need of GTL2002
| |
08:14 | Bertl | unless you want to connect an I2C port to the Zynq, no
| |
08:15 | Bertl | the main difference is bidirectional vs unidirectional
| |
08:16 | Francky | in fact with your 3 point connector for communication bus, we cannot use a spi because spi use 1 CS per slave, so it will be I2C
| |
08:17 | Francky | ok so we'll use gtl2002 for zynq lvds signal to be able to use them in bidirectionnal right ?
| |
08:17 | Bertl | it can still be SPI, if we either have only one slave or designate 1-3 of the SPI-W for CS
| |
08:31 | Francky | to implement gtl2002, we need the 1.8V power supply of the zynq, so do we use on of MP-SE pin to get this voltage ?
| |
08:35 | Bertl | maybe let's use the MP-NE power for the 1.8V rail
| |
08:36 | Francky | but on the pic32 there is not core voltage and io voltage, there is just power voltage and analog voltage, which are set to the same voltage on microchip reference design, so maybe we don't need these two power rails on MP SE ?
| |
08:37 | Bertl | it might be a good idea to keep digital and analog separate for noise reasons
| |
08:38 | Francky | so this is the power board which will make filtering right ?
| |
08:38 | Bertl | correct
| |
08:38 | Francky | and for 1.8V, we remove a GND signal on the MP NE connector ?
| |
08:38 | Bertl | just take the middle pin
| |
08:39 | Bertl | it is connected to the JX1-7
| |
08:39 | Francky | ok
| |
08:39 | Bertl | which is currently not connected on the power board, but easy to patch to 1.8V
| |
08:45 | Jin|away | changed nick to: Jin^eLD
| |
08:45 | fadro | joined the channel | |
08:54 | se6astian|away | changed nick to: se6astian
| |
08:56 | fadro | Hi all
| |
08:58 | fadro | Bertl, i spend some time yesterday on the HW source files. I imagine that things will evoluate in the future but i would like to share some points about the modularity
| |
09:00 | fadro | Concerning the sensor board, it should be a good thing if all the voltage rails related to the sensor would be generated on the sensor board itself, meaning that only a general supply voltage (5v for example) is coming into the sensor board.
| |
09:02 | fadro | This allow to have no hardware change (expect the sensor board of course) when pluging different sensors (and reprograming the IF fpga of course).
| |
09:04 | se6astian | changed nick to: se6astian|away
| |
09:15 | Bertl | yes, and no
| |
09:15 | Bertl | there are two problems with this approach
| |
09:16 | Bertl | first, all programmable voltage control as well as the instrumentation to measure power consumption would have to be placed on the sensor board as well
| |
09:16 | se6astian|away | changed nick to: se6astian
| |
09:16 | Bertl | and secondly, we would get all the heat produced by regulation, instrumentation, etc on the sensor board
| |
09:17 | Bertl | those two points led to the decision to move the actual power supply out of the sensor board and just leave the verification to the board
| |
09:19 | se6astian | good day
| |
09:20 | Bertl | for what? hopefully not to die :)
| |
09:24 | fadro | ok, but instrumentation do not produce heat and the most heating part for the suply is the 1.8V rail, but it can be drawn with a clean dc/dc since it supply digital logic. Most heat generated from this board will be from the sensor itself. And in all case, i that you already have a heat dissipation strategy for this part.
| |
09:25 | se6astian | for a lot of things... :)
| |
09:27 | Bertl | fadro: note that we don't require a hardware change (except for the sensor board) in the current setup either
| |
09:28 | Bertl | (because the power board can accomodate the different voltages)
| |
09:30 | fadro | for now the cmv1200 requires 3.3V x3, 3V and 1.8V., but baybe tomorrow you want to add one with 1.5V, 2.5v and 3.3V with different constaints on the noise level and the ripple. You have enough flexibily and outputs on the power board to handle such cases
| |
09:32 | fadro | I saw the power board, but i a little bit lost because there are many power rails, but i think that a goot part of them are reserved for future use.right?
| |
09:32 | Bertl | for the voltage ranges definitely, noise we try to keep as low as possible anyway, but special additional filtering can still happen on the sensor board
| |
09:32 | Bertl | the current power board is a test board to get something working quickly
| |
09:32 | Bertl | the final power board will feature a central power management system which can be fully programmed
| |
09:35 | fadro | OK, on the power board you put only LDO type. This provide of course low noise and also good noise rejection (plus the ferrite you add at the end of each ldo rail), but produce a lot of heat and have a bad electrical efficiency. Do you plan to use dc/dc on the final power board?
| |
09:36 | Bertl | yes
| |
09:37 | Bertl | we are currently considering two designs (which will be tested soon) one which uses a simple capacitive solution with a single mosfet and a second which utilizes an inductor together with two (push/pull) type mosfets
| |
09:38 | Bertl | depending on the results we might go for one or the other or a mix of both
| |
09:40 | fadro | ok, good. if you need hands on such part i can help.. I quite used to play with dc/dc in video devices (and of course knows how noise impact sensors and video...)
| |
09:40 | fadro | And you also plan to let different voltage rails for the plugins boards, or only a generic rails, and then each module board will generate it's own voltage rails
| |
09:42 | Bertl | that hasn't been decided yet, we know we want the eight voltages (two for the interface and six for the sensor board) to be under programmatic control
| |
09:42 | Bertl | but it might make sense to have the two/four voltages for plugin modules flexible as well
| |
09:46 | fadro | well, from my point of view, it would be better to simply supply the plugin connectors (the x2 PCIe in fact) with a generic supply rail (5V). Since plugin boards are open to the community, it's complicated to imagine what people would need, how much power will be desired
| |
09:47 | fadro | by supplying several rails, you complicate the initial power board design and you are not sure to handle the plugin needs...
| |
09:47 | Bertl | we could also do both, i.e. supply some programmatically controlled power to each module and a general 5V rail, which then allows you to simplify designs even further
| |
09:50 | fadro | yes compromise can be done, but you add strong contraints on the power board itself by adding several rails (so cost, heat, pcb space, ...), and since you add more and more programmable power rails, you also add many risks to make an error when programming one of the many rails which can lead to a risk of burning some items...
| |
09:51 | Bertl | the current design prevents this by direct feedback, of course, it's not 100% but close
| |
09:52 | Bertl | but I agree, for now it is probably better to keep it simple
| |
09:55 | fadro | Yes. since this camera has the vocation to be hacked by anyone (included hobbists), it would be better to keep it simple in the measure where it doesn't kill the overall performance.
| |
09:55 | fadro | I think that hackers will know better that can be anticipated what they should need...
| |
09:57 | surami | joined the channel | |
09:57 | surami | hi
| |
09:57 | Bertl | wb surami!
| |
09:59 | surami | i would like to know things about the low light capabilities of the Beta, especially shooting timelapses
| |
09:59 | surami | i mean milkyway shots etc.
| |
10:00 | surami | is the sensor capable for this things too?
| |
10:00 | fadro | and concerning the interface board (IF board), for now it's a "simple passtrough board". But i imagine that it will rapidly grow with some intelligence and with an hi fpga io pin count. But how do you plan to reduce the number of LVDS incoming from the sensor? The original sensor LVDS are 300Mbps with 64 lanes, so i suppose that you will provide an unified interface with 32 LVDS lanes with 600Mbps??
| |
10:01 | Bertl | actually it is already 600MHz on the v2 of the sensor, but yes, we plan to 'pack' the datastream on the interface board
| |
10:01 | se6astian | surami: you can check out some benchmark results of the sensor by the Magic lantern guys: http://www.magiclantern.fm/forum/index.php?topic=11787.msg129672#msg129672
| |
10:01 | Bertl | fadro: or alternatively pre process it in the interface FPGA
| |
10:02 | Bertl | surami: for astronomy purposes you probably want excellent cooling and you definitely need the equippment to track your object
| |
10:02 | Bertl | but the sensor itself can do very long exposures
| |
10:03 | ItsMeLenny | left the channel | |
10:05 | fadro | ok, 600M on the v2...i don't get it! but i don't get the way you want to pack datastream to reduce the BW.... and even if you do pre-processing on the 1st stage fpga, the bw limitation has the same issues...
| |
10:06 | Bertl | first, we can change the interface in various ways, higher datarate, memory like single ended interface, etc
| |
10:06 | Bertl | secondly, we can avoid transferring idle data
| |
10:07 | Bertl | and finally, if we implement soft exposure for example, it could be completely done in the interface board without need to transfer all the data to the zynq
| |
10:07 | Bertl | so yeah, it's not likely that we will do full bandwidth right now, but there are certainly options for the future
| |
10:11 | fadro | of course the goal is not to have the fuul BW at 1st powerup, but what is not easy is that all cases should be think about it early in the process of architecture design, otherwise, it will require huge efforts to modify the existing, and also drawkbacks of HW imcompatibilities and costs for redesign.
| |
10:11 | se6astian | changed nick to: se6astian|away
| |
10:13 | Bertl | btw, any comments on the existing design, routing, choice of parts, etc?
| |
10:13 | fadro | And concerning your 1st point above, on your new IF fpga you will have the bank you want (speaking about HP banks, cause you speak about higher data rate), but on the µZ side, you only have HR banks and i see the bottleneck on this side...
| |
10:15 | fadro | Comments concerning the existing design are more related to the modularity architecture the the electrical design itself
| |
10:16 | fadro | routing, some question, yes : how do you manage the 100ohm differential lines impedances?? OSHpark gives you the parameters of the stackup to allow such controlled impedance?
| |
10:17 | Bertl | we know the 4 layer stackup and the dielectric constant of the substrate (FR408)
| |
10:18 | fadro | concerning choice of parts, not especially... There are many good but differents ways to achieve a functionnality, and i think that's a little bit early in the design process to discuss such.
| |
10:18 | Bertl | we are not yet in the really critical range (> 2GHz) that we need board controlled impedance, but we did some tests and it looks good
| |
10:19 | fadro | ok, and you know the type of copper foils they use (ED i suppose)?? and also theFR4 fiber weave spacement??(important for the differential lines)?
| |
10:19 | Bertl | the existing 100R differential/50R single setup is the result of EM simulation
| |
10:21 | Bertl | at the prepreg width (6.7mil) the fiber weave is not relly relevant for data rates up to 1.5GHz (which is our current limit)
| |
10:21 | Bertl | s/width/thickness/
| |
10:21 | Bertl | (at least as far as I know :)
| |
10:22 | fadro | OK. I agree with you that since we are under the Ghz, we can relax... but carefull design must stay...they are many connectors to cross, and signal corruption can raise fast...
| |
10:22 | Bertl | yes, agreed
| |
10:22 | fadro | OK, you use a field solver to got the tracks width and spacement??
| |
10:23 | Bertl | yes
| |
10:23 | fadro | Polar, Hyperlinx, or maybe an online one?
| |
10:25 | fadro | In any cases, on the boards you design, the rules of thumbs (crosstalk sepration, reference plane, spacement between differential lines, well grounded connectors IF) are respected so this is a good point.
| |
10:27 | Bertl | we've mostly used ATLC but also investigated openEMS and MMTL
| |
10:28 | Bertl | there are online field solvers?
| |
10:29 | fadro | The only thing i'm not sure (because i've never experienced it before ) is more about the 4 layers stackup. Not because of the 4 layers itself (since 2 layers are sufficient to define a Ghz microstrip line), but because of the materials quality used by 4 layers pcb manufacturers...I would suspect poor ED copper foils (whch can lead to big insertion losses depending on the quality even for signal under Ghz (because of skin effect)) , an
| |
10:30 | fadro | poor FR4 quality leads to big variation of the DK (or Er) and can add enough sken in diff pair to cause many errors on the receptor side....
| |
10:31 | Bertl | http://support.oshpark.com/helpdesk/attachments/4001917116
| |
10:31 | fadro | by poor FR4 quality, i'm speaking about the fiber weave with large spacement which lead to high variation in the Er
| |
10:31 | surami | @se6astian: thanks for the link, @Bertl: ok, i understand
| |
10:31 | Andrej741 | left the channel | |
10:32 | fadro | ooh, very good, give me a few seconds....
| |
10:38 | fadro | Well, that's a good surprise...They use a good FR4 product....In general, when I see ISOLA products, i'm quite confident.... So very good point!
| |
10:39 | Bertl | excellent then!
| |
10:40 | Bertl | so far, we have been very satisfied with the PCBs in almost all regards
| |
10:41 | fadro | I saw a strange thing in the axiom_beta_interface_dummy_v09.sch file. There are double connection (like short circuit) on the Xnorth & Xsouth connectors, but the PCB side is OK. It seems that the sch and pcb file are not related but pcb connection looks good.
| |
10:42 | Bertl | page and coordinates?
| |
10:43 | Bertl | or are you referring to the "broken" ellipses around the pairs?
| |
10:44 | fadro | well, page 2, all the connections on the Xnorth and X south...And i'm speaking about the electrical connection....
| |
10:44 | fadro | But it looks like a drop error that has been saved... I get it from the server of course..
| |
10:45 | Bertl | hmm, okay, let me update the files, just to make sure
| |
10:46 | jucar | joined the channel | |
10:47 | Bertl | okay, please redownload and check if you see the same effect
| |
10:49 | fadro | OK, this time the *.sch file is correct!
| |
10:49 | fadro | just to be back on a previous [12:06] point...
| |
10:49 | fadro | And concerning your 1st point above, on your new IF fpga you will have the bank you want (speaking about HP banks, cause you speak about higher data rate), but on the µZ side, you only have HR banks and i see the bottleneck on this side...
| |
10:50 | Bertl | well, with the de/serializers in the zynq, the HR banks can still do 1.2-1.6GHz
| |
10:51 | Bertl | we have 36 pairs from the interface board to the zynq
| |
10:51 | Bertl | and we have a total of 80 pairs to the sensor board
| |
10:53 | Bertl | so it should be enough to handle the sensors we have for now
| |
10:58 | fadro | OK. Initially, you plan plan to use the µZ. Is this a definitive choice, or the use of a board such as PicoZ can be imagined??
| |
10:59 | Bertl | we already plan to support the PicoZed as well
| |
10:59 | Bertl | (and the Parallella, for those interested in image processing)
| |
11:00 | niemand | joined the channel | |
11:00 | intracube_afk | changed nick to: intracube
| |
11:00 | fadro | goood...I like this idea...from my point of view Picozed offers more scalability, more LVDS lanes, and we can also open an incredible field with the 4 MGT...(7015/7030 version...)
| |
11:01 | Bertl | yes, the only problem is the minimalistic nature of the PicoZed
| |
11:01 | Bertl | i.e. no console, no ethernet, no USB, etc
| |
11:01 | Bertl | but I agree, the MGTs are very interesting
| |
11:02 | fadro | Ah, that right, you have to do your own connector IF, BUT, we have your powerfull plugin architecture, so I see no problems :))
| |
11:03 | se6astian|away | changed nick to: se6astian
| |
11:03 | Bertl | yeah, the most likely solution for the PicoZed will be to add another PCB which handles the MGTs and the missing interfaces
| |
11:05 | fadro | Yes, but once again, extreme care should be taken with connectors interface especially if we play with GTP/GTX signals....
| |
11:06 | fadro | And to handle this, even if it is future (as short as possible...) the modularity architecture has to be well choosen...
| |
11:06 | Bertl | that's the reason why this PCB would address the MGTs directly
| |
11:06 | fadro | to let highspeed signal in the best integrity as possible...
| |
11:09 | fadro | And since µZ and PicoZ connectors are definitively not compatible, how do you plan to handle the future devlopement? 1 power board version for the µZ and 1 PW bard version for the PicoZ??
| |
11:11 | Bertl | interestingly they are compatible
| |
11:11 | Bertl | i.e. the two connectors shared between MicroZed and PicoZed are identical
| |
11:12 | Bertl | all new connections are done through the third connector
| |
11:17 | fadro | Oh, I didn't care about this, so it's surprising and very interesting yet...Compatibility have been well stutied...
| |
11:17 | fadro | But in any cases there should be 2 versions of the PW pcb since if you use the PicoZed, you want to take advantate of the 3rd connector...
| |
11:18 | fadro | *advantage
| |
11:19 | Bertl | that's why I said another PCB :)
| |
11:23 | jucar | left the channel | |
11:23 | fadro | So, what are your plan for versionning of the BETA camera?? All the boards would exists, and the final user will choose in these options to build its own camera depending on its need and budget??
| |
11:24 | Bertl | yes, that's the most likely scenario
| |
11:24 | Bertl | where of course certain boards would be a bad choice, because they have been superceeded by newer ones
| |
11:30 | jucar | joined the channel | |
11:35 | fadro | What do you mean by superceeded?
| |
11:40 | Bertl | for example the v0.12 of the cmv12k sensor board would be a bad choice, given that the v0.13 has same functionality and a better design
| |
11:48 | fadro | OK, obviously. But in any cases I imagine that end users will wait for your green fire to begin buying some HW parts. Only hackers will find interest in the current HW version.
| |
11:48 | Bertl | yes, we hope and think so
| |
11:50 | fadro | Do you have a kind of dead line for a 1st BETA release? I mean did you give some delivery date when doing crowfunding capaign?
| |
11:50 | Bertl | we had some estimates but nothing fixed at the campaign
| |
11:50 | fadro | And what was the estimation ?
| |
11:51 | Bertl | we are good in time but due to the changes we incorporated, we will not make our (originally) planned goal
| |
11:52 | fadro | OK, so what are the changes and what is the reported estimated date??
| |
11:53 | Bertl | the first batch was planned to ship in April, but back then, the AXIOM Beta consisted of a single board including the sensor
| |
11:54 | Bertl | now we have really modular sensor boards, the interface board to allow for full bandwidth and the PCIe plugin modules
| |
11:54 | Bertl | (before those were simple shields on the front of the camera)
| |
11:55 | fadro | OK, so you add the modular architecture from your initials plan... And of course, yes, it requires more design time and more validation....for sure...
| |
11:56 | Bertl | we will have early betas next month, so bold folks can probably still get a beta in april :)
| |
11:56 | fadro | :)
| |
11:56 | Bertl | but I expect the majority will want to wait (even if they backed for the 1st batch) till we have a more mature design :)
| |
11:57 | fadro | Yes, i agree
| |
11:57 | se6astian | changed nick to: se6astian|away
| |
11:59 | fadro | But concerning the HW development, you are the only one involved in the design process?? I mean HW, FPGA, Arch linux?? Cause I see only you name on sch, pcb, hdl file...??
| |
11:59 | niemand | left the channel | |
12:04 | Bertl | I'm doing most of the work on the electronics and software at the moment, but that will hopefully change in the near future
| |
12:05 | Bertl | for example Francky is currently working on the PIC32 "shield"
| |
12:17 | fadro | Is there any existing documents for describing the overall modular architecture? What are the inputs, the options, and also things like dataflows, supply trees, ..
| |
12:18 | Bertl | not yet, it is mostly in our minds, but there will be documentation soon
| |
12:23 | fadro | I'm sure that's it's clear in your mind, but it's always good to write some blackboxes and arrows to have a overall design step back and checks if everything fits together...
| |
12:26 | fadro | Maybe i can do this exercice of writting such diagrams. I think that it will also ease our communication (1 graph is often better than hundreds irc lines!!)
| |
12:27 | Francky | it would had help me yesterday :)
| |
12:27 | Francky | have*
| |
12:29 | fadro | Are you new comer to this project?
| |
12:31 | Francky | yes
| |
12:32 | Francky | and i had to extract lot of information from the head of Bertl :D
| |
12:33 | Francky | in fact i'm interested in zynq device, and i ask lots of questions to Bertl, and in our discussion he tells me that the project needs a PIC board, so i propose my help
| |
12:33 | Francky | and as you see my english is not very good
| |
12:38 | Bertl | fadro: any help is truly appreciated
| |
12:39 | Bertl | Francky: don't worry, it is more than sufficient to communicate :)
| |
12:40 | se6astian|away | changed nick to: se6astian
| |
12:40 | se6astian | changed nick to: se6astian|away
| |
12:41 | Francky | i have difficulty with conjugation
| |
12:42 | Francky | because i'm french and we don't use conjugation very weel in french language
| |
12:42 | Francky | but i agree i undestand what you tell, and we undestand almost i said :)
| |
12:48 | fadro | Francky : You are French? I love this country!!! Vive la France ... Maybe cause that's my native one!!
| |
12:49 | fadro | Bertl : I want to invest myself in Axiom project... I've taken so many from open source, that I decide now to give back...
| |
12:49 | Francky | yep. Where are you now ?
| |
12:50 | fadro | But since i'm more HW than SW, i choose an open source pjct which fits my job...
| |
12:50 | fadro | Euuhhh, in France...
| |
12:51 | Francky | i undestood that you have leave France, don't know why...
| |
12:51 | Francky | for me i'm more SW than HW :)
| |
12:52 | Francky | but i like both
| |
12:52 | fadro | by SW you mean firmware & RTOS or heavier OS like linux, ... I also like both...
| |
12:54 | fadro | Bertl : For doing such king of graph, documention,... do you have prefered application and prefered way to share online doc???
| |
12:56 | Bertl | well, I did this one: https://images.indiegogo.com/file_attachments/846669/files/20140910012757-BETA_interface.jpg with tikz
| |
12:56 | Francky | fadro> my main skills are in low level firmware (BSP), but i work on high level languages too, and on embedded linux (applications dev)
| |
12:57 | Bertl | something TeX based is probably easiest to adjust to changes and also can be easily incorporated into other documents
| |
12:57 | niemand | joined the channel | |
13:00 | fadro | yes, agree, and how do you usually share your drafts doc for team discussion??
| |
13:00 | Bertl | many documents are either just uploaded or shared via google docs
| |
13:01 | Bertl | but we have the wiki as well for documentation
| |
13:01 | fadro | ok, good let's take goole doc as document repository... You have an open account on google doc??
| |
13:02 | Bertl | please check with se6astian when he comes back, I'm not really into google doc
| |
13:02 | fadro | OK, i will...
| |
13:02 | Bertl | (mostly because they prevent "sane" copy/paste on Linux :)
| |
13:03 | fadro | :) i see...
| |
13:08 | danieel | left the channel | |
13:13 | danieel | joined the channel | |
13:18 | niemand | left the channel | |
13:33 | Francky | Bertl> do you have any time to take a look to my schematics ?
| |
13:36 | niemand | joined the channel | |
13:40 | Bertl | sure, url?
| |
13:43 | Francky | https://dl.dropboxusercontent.com/u/782577/axiom_beta_pic_board_v0.1.pdf
| |
13:44 | Francky | i've put spi, jtag, isp, then all IO from zynq and beta board fpga, then led on free pins
| |
13:46 | Bertl | the schematic around the pic looks a little crowded :)
| |
13:47 | Bertl | i.e. it is hard to read
| |
13:47 | Francky | yes but all pins are connectes, unless usb pins that are dedicated for usb
| |
13:47 | Bertl | and it seems to have my copyright :)
| |
13:48 | Francky | yes i have copied your schematics style
| |
13:48 | Francky | to be homogeneous
| |
13:49 | Bertl | so what is the idea how the zynq and the pic communicate?
| |
13:49 | Francky | oh a question about Eagle : how do you do to make labels with small text size and decoration aroud ?
| |
13:49 | Bertl | it is a style option for the label, you can select it in the tool bar or change it later
| |
13:50 | Bertl | the text size can be changed via the size attribute
| |
13:53 | Francky | ok i will search
| |
13:54 | Francky | for communication, there is a mappable UART RX TX on RF0 and RF1, connected to JX2
| |
13:54 | Bertl | PMP would be an option, but that requires at least PMD0-PMD7
| |
13:54 | Bertl | plus the involved control signals and some address lines
| |
13:55 | Francky | it faster, but more expensive about gpio
| |
13:55 | Francky | is*
| |
13:55 | Bertl | how much space do you have left on the board?
| |
13:55 | Francky | do we need high speed communication ?
| |
13:55 | Bertl | it might make sense for the IMU data later
| |
13:56 | Bertl | so if possible, we should keep that option open
| |
13:56 | Francky | https://dl.dropboxusercontent.com/u/782577/axiom_beta_pic_board_v0.1.png
| |
13:57 | Bertl | so it's already rather crowded
| |
13:57 | Francky | it depends on what you want to add :)
| |
13:59 | Bertl | well, we could add some FPGA/CPLD to make better use of the zynq connection(s)
| |
13:59 | Bertl | but I think that is not an option here, too little space left
| |
13:59 | Francky | to use the lvds lines ?
| |
13:59 | Bertl | yeah
| |
14:01 | Francky | so do you have another good idea for the bus between zynq and pic ?
| |
14:02 | Bertl | you're the pic expert :)
| |
14:02 | Francky | pic datasheet says that baud rate on UART could be to 25Mbps
| |
14:03 | Francky | it depends on the real need, and you have more information in mind that me
| |
14:03 | Francky | than*
| |
14:03 | Francky | about global system
| |
14:04 | Bertl | but for a synchronized uart interface we only need what, 3? lines to the zynq, yes?
| |
14:04 | cbohnens | changed nick to: cbohnens|away
| |
14:05 | Bertl | i.e. what do we have the other 7 lines for?
| |
14:05 | Francky | i always use 2 lines in UART communication, because i always make synchronised interface (ie : 1 master asks 1 slave)
| |
14:08 | Bertl | hmm, there is no crystal and no clock input for the PIC32
| |
14:08 | Francky | i don't know what you want to do with :) why did you provise so much pins between zynq and pic ?
| |
14:08 | Bertl | so you completely rely on the internal oscillator
| |
14:08 | Francky | it was my thought
| |
14:09 | Bertl | to answer the question: I didn't :) i.e. I just routed all available zynq I/Os to the header :)
| |
14:09 | Francky | using the internal oscillator to preserve gpio outputs
| |
14:09 | Bertl | this will probably limit the PIC32 to a lower frequency and result in more problems with synchronization
| |
14:10 | Bertl | also, what about the RTCC, it requires the secondary oscillator and a clock crystal IIRC
| |
14:11 | Bertl | and the RTCC as well as keeping time in low power mode would be something really useful
| |
14:11 | Bertl | (just commenting here)
| |
14:13 | Francky | it seems that internally oscillator is sufficient to achienve 200MHz
| |
14:14 | Francky | i have not take into consideration the RTCC
| |
14:14 | Francky | do you think a electrical cell is needed to keep the time if there is no more power ?
| |
14:15 | Francky | like there is in PC
| |
14:18 | Francky | but we can put an external one if you want to have a very precise one
| |
14:19 | Francky | for rtc it seems that there is a 32k internal clock
| |
14:21 | Bertl | okay, so that would work without any oscillator/crystal? and if so, with what precision?
| |
14:22 | Bertl | but let's take a step back and revisit how we can make good/optimal use of the zynq connection and other interface resources first
| |
14:22 | Francky | i think : if you need (a lot of) communication between pic and zynq (rtc, 10DOF, accelerometer, ...), maybe we can put several UART lines between zynq and botch to specialized each line in on (or two, or more) device ?
| |
14:23 | Bertl | from your designs so far, it doesn't seem to make much sense to connect the zynq directly to the PIC, no?
| |
14:23 | Bertl | (different voltages, different speed, no advantage there)
| |
14:24 | Francky | i don't undestand what you mean
| |
14:24 | surami | left the channel | |
14:24 | Bertl | I mean that it wouldn't make much sense to connect the zynq directly to the PIC
| |
14:24 | Bertl | looking at the beta test board, we have a lot of space on the right side
| |
14:24 | niemand | left the channel | |
14:25 | Bertl | which is potential space for the PIC if we decide to put it directly on the beta board
| |
14:25 | Francky | what do you mean by "directly" ?
| |
14:25 | Bertl | if, OTOH, we decide to make the PIC a shield, i.e. keep the headers
| |
14:26 | Bertl | then it would make a lot more sense to put e.g. an FPGA in the place below the shield and have that communicate with the PIC instead
| |
14:26 | Francky | ok i undestand
| |
14:27 | Bertl | the PIC still needs a direct contact to the power management
| |
14:27 | Francky | so your idead is to put a fpga "under" the pic board, to convert lvds from zynq to, for example, PMP
| |
14:27 | Bertl | i.e. a dedicated I2C connection
| |
14:27 | Bertl | yes, that would be the idea
| |
14:27 | Francky | you want that the pic control the power board ?
| |
14:27 | Francky | throught i2c ?
| |
14:27 | Bertl | we could get rid of the PSI-E which seems to be in the way
| |
14:27 | Bertl | *SPI-E
| |
14:28 | Bertl | and instead use all the HDR-SE/NE connections for PIC/zynq I/O
| |
14:29 | Bertl | that would probably allow to use the larger PIC with more GPIOs
| |
14:29 | Bertl | and still have plenty of I/Os left for LCD/buttons/etc
| |
14:30 | Bertl | does that make sense?
| |
14:30 | Francky | why do you want to get rid of the spi_e bus ?
| |
14:30 | Bertl | not the bus, the header :)
| |
14:30 | Francky | i undestood that you want to connect 10DOF on it ?
| |
14:31 | Francky | ok so you want to put a fpga between pic and sensor too ?
| |
14:31 | Bertl | we can terminate the bus on the same FPGA/CPLD which connects to the pic
| |
14:31 | Bertl | or we can just route the sensor bus to the NE/SE header
| |
14:32 | Francky | so you propose to have one big and fast bus between pic and fpga (example : pmp), and keep all other pic IO for lcd and buttons ?
| |
14:33 | Bertl | yes, that would make sense to me, unless you have a better idea?
| |
14:34 | Francky | to be honest the growing complexity make me doubt
| |
14:35 | Francky | but i am not confortable with fpga so i probably don't reflect like you
| |
14:35 | Francky | :)
| |
14:36 | Bertl | well, felxibility adds complexity, unfortunately that's always the case
| |
14:36 | Bertl | the main question is, what advantages/disadvantages do we create/get here
| |
14:36 | Francky | the challenge is to find the perfect ballance
| |
14:36 | Bertl | precisely
| |
14:37 | Francky | i see a lot of disavantages :
| |
14:37 | Bertl | let's hear then
| |
14:37 | Francky | - more chips = more expensive
| |
14:37 | Francky | - more soft = more bugs
| |
14:37 | Francky | - more soft = more difficult to developp and debug
| |
14:37 | niemand | joined the channel | |
14:38 | Francky | but, the communication between zynq and pic could be very fast throught pmp
| |
14:38 | Francky | but you transfer the work of pic (get data from sensors) to the fpga or the fpga just convert spi to pmp ?
| |
14:39 | Bertl | maybe even fast enough to transfer a live image at some point?
| |
14:39 | Francky | there is necessarily a little bit of inteligence into the fpga ?!
| |
14:39 | Bertl | yes, but I think the small FPGA code will be a rather simple mapping
| |
14:39 | Bertl | i.e. a serialization/deserialization
| |
14:40 | Francky | ok i cannot imagine what is the difficulty here
| |
14:40 | Bertl | for a simple test, it could as well be configured to only map inputs to outputs and vice versa
| |
14:40 | Bertl | i.e. it would then become an expensive level shifter :)
| |
14:41 | Francky | :)
| |
14:41 | Francky | why do you want to transfer an image to the pic ?
| |
14:41 | Bertl | but expensive is relative, because the ICE40 for example costs about 2.5 EUR
| |
14:42 | Bertl | well, I do not want to do that now, but it might be interesting for somebody to do that lateron
| |
14:43 | Francky | maybe a small image, because 4K image is quite a huge amount of data
| |
14:43 | Bertl | yeah, of course, something suited for an LCD for example
| |
14:43 | Bertl | anyway, what I would propose is the following:
| |
14:43 | Bertl | (here with some rationale)
| |
14:44 | Bertl | we cannot change the headers right now, but we can plan a change in the next revision
| |
14:44 | Bertl | (the current headers are for testing anyway)
| |
14:45 | Bertl | so, let's design the PIC32 board for the future headers and assume whatever FPGA/CPLD/Level interface we consider apropriate
| |
14:46 | Bertl | then, we simply build an adapter board which maps the current headers to the future layout
| |
14:46 | Bertl | this way we can test it right now, and once we are confident, we simply drop the adapter board and move the content to the beta board
| |
14:46 | Francky | finally the pic board is becoming more like a "module", like you prensent modules for gamma camera ?!
| |
14:47 | Bertl | yeah, we should also consider what we can/should provide to keep it somewhat generic
| |
14:48 | Bertl | so when some atmel/TI freak comes along and wants his favorite microcontroller to work on the Beta, it doesn't require a complete redesign
| |
14:48 | Bertl | does that sound like a plan?
| |
14:48 | Francky | so the "pmp" interface, if we choose it, have to be completly generic
| |
14:49 | Francky | i think it is
| |
14:49 | Bertl | we can reduce it to having so and so many I/O pins dedicated for microcontroller communication
| |
14:50 | Bertl | whether it is PMP or 5xUART or a combination of I2C,SPI and I2S :) shouldn't matter much
| |
14:50 | Francky | but the fpga code will not be the same ?!
| |
14:50 | Bertl | all it requires is that somebody writes the correct glue code for the FPGA
| |
14:50 | Bertl | correct
| |
15:15 | niemand | left the channel | |
15:41 | Bertl | Francky: http://pastebin.com/raw.php?i=saH3XqJa
| |
15:41 | Bertl | this might help
| |
15:42 | Bertl | I did it some time ago, and just digged it out
| |
15:43 | Bertl | and maybe this becomes useful as well: http://vserver.13thfloor.at/Stuff/AXIOM/BETA/pic32mz.lbr
| |
15:44 | Francky | thank you sorry i have a urgent thing to do
| |
15:44 | Bertl | no problem
| |
15:45 | Francky | i propose you to implement à "generic" parrallel port, 16bit data, 16 bit address, RD/WRn
| |
15:45 | Francky | sensors will be mapped in address by the fpga
| |
15:46 | Francky | and microcontroller can talk with everybody throught the pmp
| |
15:46 | Francky | it seems generic no ?
| |
15:46 | Bertl | definitely, but a lot of pins
| |
15:48 | Francky | it could be frightening for someone you just want to create its own microcontroller board just to blink a led... :(
| |
15:49 | Bertl | that's what I meant with number of I/O pins
| |
15:49 | Bertl | let's say, we define 12 or 16 I/O pins for general zynq/microcontroller communication
| |
15:50 | Bertl | then those 16 pins can be used to implement PMP to the PIC
| |
15:50 | Francky | it could be pmp 8data 8addr 1RS/WRn
| |
15:50 | Bertl | or it could be used for simple UART communication
| |
15:50 | Bertl | or in an extreme case, it could be just a board with 16 LEDs :)
| |
15:51 | Francky | why not
| |
15:51 | Bertl | so, let's figure out how many I/Os we need for PMP
| |
15:51 | Francky | can we get 17 IO to get a standard 8bit PMP ?
| |
15:51 | Bertl | 8+8+2 is enough?
| |
15:51 | Bertl | write and read, no?
| |
15:52 | Francky | for me the extra 1 signal is a RD/WRn
| |
15:52 | Francky | but in the pic there are 1 RD and 1 WR
| |
15:52 | Francky | so we can put 2 extra controle signal
| |
15:53 | Bertl | okay, so let's plan with 20 I/Os for now
| |
15:53 | Francky | you are generous :)
| |
15:53 | Bertl | plus one I2C interface to connect to the power board
| |
15:53 | Francky | so the pic will have to monitor/control power regulator ?
| |
15:54 | Bertl | it would make sense to do that for low power applications
| |
15:54 | Bertl | also most of the power sensors are on that I2C bus, so monitoring those would make sense too
| |
15:54 | Francky | but why power board doesn't integrate a dedicated controller for monitoring and controle ?
| |
15:55 | Bertl | it has, no worries, the idea is just to be able to power down various subsystems
| |
15:55 | Bertl | and more importantly, to wake up the entire camera
| |
15:55 | Francky | so the pic will be the main part which will power on all the rest ?
| |
15:56 | Bertl | when in power down state, probably, yes
| |
15:57 | Francky | i think different subsystem are very dispatched, but i think you have a better vision than me about the use of the entire system
| |
15:59 | Bertl | so we have 22 I/O pins total
| |
15:59 | Bertl | the NE/SE headers have 24 pins in total
| |
15:59 | Bertl | so that looks like a good match
| |
16:01 | Bertl | we eliminate the SPI-E
| |
16:01 | Bertl | (header I mean)
| |
16:01 | Francky | yep
| |
16:01 | Francky | i need to go, i continue to reflect about this
| |
16:01 | Bertl | now the question is, what about powering the future "shield"
| |
16:01 | Bertl | okay, cya
| |
16:01 | Francky | bye
| |
16:02 | Francky | left the channel | |
16:09 | Jin^eLD | changed nick to: Jin|away
| |
16:19 | fadro | One question Bertl, you are using eagle, but are you open to switch to a full open source application like Kicad?
| |
16:19 | niemand | joined the channel | |
16:19 | Bertl | yes, as a matter of fact we already decided to switch to kicad
| |
16:20 | Bertl | it is just that right now it would be too time consuming for me to make the transition
| |
16:20 | Bertl | but we verified that we can export from eagle to kicad, it just needs minor rework
| |
16:23 | fadro | OK and library can also be imported...?? This is a critical & time consuming part especially for big cases
| |
16:23 | aombk2 | changed nick to: aombk
| |
16:24 | Bertl | that is indeed the most problematic part, as kicad has a very different library model as eagle
| |
16:24 | Bertl | i.e. in kicad there are no components, just footprints
| |
16:24 | Bertl | and they are shared between various components
| |
16:25 | Bertl | but I'm optimistic that this is something we can handle with the help of volunteers
| |
16:26 | fadro | OK. Since i do not know anything about Kicad nor Eagle (we work on Cadstar & Altium here!) I prefer to use a complete open source app to push it up... The only big advantage of eagle is its community and library!
| |
16:26 | fadro | (i think!)
| |
16:26 | Bertl | yeah, kicad was rather problematic when I started (i.e. almost no features, very complicated to use, etc)
| |
16:27 | Bertl | this has changed since CERN has adopted the software package
| |
16:27 | mars_ | which reminds me, I wanted to try out the new xsignals feature from altium 15
| |
16:29 | fadro | And concerning the 10DOF sensors embedded later, what about to use an existing open module like Adafruit 10-DOF IMU breakout? All libraries are already written and HW job is already done...
| |
16:30 | Bertl | well, the IMUs nowadays do not require many components, so it's basically a MEMs chip with a buffer capacitor
| |
16:31 | Bertl | i.e. adding a rather large breakout board would be overkill IMHO
| |
16:31 | Bertl | regarding the libraries, sure, you can use them, why not
| |
16:31 | Bertl | the IMUs we are considering are all standard solutions
| |
16:32 | Bertl | so I'm pretty sure they are supported already
| |
16:32 | Bertl | (I pasted a list yesterday)
| |
16:36 | fadro | You want to definitively integrate this feature or simply mounting it as an option?? Because in the 1st case, you are right, it's better to build it onboard, but in the 2nd case, it can be easier to solder the IMU or not.
| |
16:36 | Bertl | we can still decide to solder specific components or leave them unpopulated
| |
16:37 | Bertl | but the IMUs are rather cheap compared to the rest of the device
| |
16:37 | Bertl | so I tend to have it on board just in case it becomes useful :)
| |
16:38 | fadro | Sure you're right, the price of the camera will not change with/without this feature!
| |
16:39 | Bertl | but I was considering to keep the solder on design we have now for the center sensors
| |
16:39 | Bertl | just to allow for testing different solutions there, but I haven't found a smart way to reduce the weight
| |
16:40 | Bertl | weight/space/additional PCB
| |
16:40 | Bertl | if you look at the beta board, the center is designed to carry a diamond shaped solder on board
| |
16:41 | Bertl | which is there to provide a quick solution for testing the IMUs
| |
16:42 | Bertl | I thought about making that a cut out in the beta board, but such a solution is hard to stabilize
| |
16:47 | fadro | OK. understand...and you would like to embedded the 10DOF data into each pictures metadata??
| |
16:54 | Bertl | yes, that is the idea
| |
16:55 | Bertl | provide filtered and maybe preprocessed metadata with each frame
| |
17:14 | HoloIRCUser1 | joined the channel | |
17:15 | intracube | changed nick to: intracube_afk
| |
17:15 | Bertl | welcome HoloIRCUser1!
| |
17:16 | HoloIRCUser1 | left the channel | |
17:17 | Francky|busy | joined the channel | |
17:18 | Francky|busy | It was me who try holoIrc :)
| |
17:18 | Bertl | ah, no problem, how was it?
| |
17:19 | Francky|busy | I'm on it now it permit tu be on irc with android
| |
17:19 | Francky|busy | It is good because no ads
| |
17:21 | Francky|busy | I reflect about our discution, shouln't be easier to provide spi + lot of CS?
| |
17:21 | Francky|busy | It is generic
| |
17:21 | Francky|busy | And we can get rid of the fpga
| |
17:22 | Bertl | how so?
| |
17:22 | Bertl | I mean, why/how do we get rid of the fpga?
| |
17:23 | Francky|busy | In fact we can use 1 spi in slave for com with zynq, and 1 spi master with lot of CS to speak with all sensors
| |
17:23 | Francky|busy | In this case no need of fpga
| |
17:23 | Francky|busy | It seems easier but i may be wrong
| |
17:25 | Bertl | well, SPI can probably do 20MHz or maybe 80MHz on the PIC
| |
17:25 | Francky|busy | 25Mbp
| |
17:25 | Francky|busy | Mbps
| |
17:25 | Bertl | let's assume 80MHz, which will give us 10MByte throughput on 3/4 Zynq lanes
| |
17:27 | Bertl | we can easily do 20-50 times that with the PMP for example
| |
17:29 | Bertl | (just saying)
| |
17:30 | Francky|busy | In my job i always need to make the balance between real needs and engineer dreams, so i always have this type of reflexion
| |
17:35 | Francky|busy | Where do you imagine to put the spi protocole decoding with the pmp ?
| |
17:36 | Bertl | I'm just having another crazy idea
| |
17:37 | Bertl | give me a minute to check something
| |
17:40 | Francky|busy | \o/
| |
17:42 | Bertl | nah, won't work, but I verified that we could easily put two more ICE40 on the beta board and have 15 medium speed I/Os per ICE40 for one zynq pair or 13 for two zynq pairs
| |
17:42 | Bertl | together with the 6 medium speed I/Os we already have, that would give 19 or 21 I/Os on each side of the beta
| |
17:43 | Bertl | I didn't check if we can pick a larger ICE40 footprint, which would be an option too
| |
17:45 | Bertl | checking that now
| |
17:45 | Francky|busy | We already have 20 io
| |
17:46 | Bertl | I don't want to use the ucBGA or csBGA versions of the ICE40, because those are hard to solder/route
| |
17:47 | Bertl | but we still have 84pin QFN and a 100pin VQFP
| |
17:51 | Bertl | so the 84QN is problematic with the OSHpark rules
| |
17:52 | Bertl | let's see if we can fit the 100 VQFP on the beta board
| |
17:52 | Francky|busy | left the channel | |
17:53 | Bertl | it's huge but it would fit
| |
18:20 | Francky|busy | joined the channel | |
18:20 | intracube_afk | left the channel | |
18:22 | Francky|busy | left the channel | |
18:31 | intracube | joined the channel | |
19:15 | Francky|busy | joined the channel | |
19:16 | Francky|busy | Hey Bertl what do you want to do with all these io?
| |
19:17 | Bertl | actually I would be more than happy with an 48pin FPGA or something in this area
| |
19:17 | Bertl | but unfortunately suitable parts are not available
| |
19:18 | Bertl | so it seems like we have the choice between the QFN32 and the VQFP100 only
| |
19:18 | Francky|busy | You are speaking about fpga between pic and zynq right?
| |
19:18 | Bertl | yes
| |
19:19 | Francky|busy | The 32 is not big enought to implement 16bit data 16 bit addr an rd/wr
| |
19:20 | Bertl | probably not even big enough to do 8/8 proper
| |
19:20 | Francky|busy | Why?
| |
19:20 | Bertl | well, we have a total of 21 I/O pins on the QFN32
| |
19:21 | Bertl | to make it programmable, we are down to 17 I/Os
| |
19:21 | Francky|busy | 18 pmp + 2 lvds
| |
19:22 | Francky|busy | Erf
| |
19:22 | Francky|busy | :(
| |
19:22 | Bertl | yeah, unfortunately all pin counts between 32 and 100 are some kind of 0.4 or 0.5mm BGA
| |
19:22 | Bertl | which doesn't work with the OSHpark PCBs
| |
19:24 | Bertl | OTOH, with the VQFP 100, we shouldn't have much problems with the routing
| |
19:24 | Francky|busy | 100 is huge, can we use non pmp pins for an other function?
| |
19:25 | Bertl | and we do not need to connect everything
| |
19:25 | Bertl | yes, for sure we can add some more connectors or something like that
| |
19:26 | Francky|busy | Hey but this fpga need to be connected to sensors too no?
| |
19:26 | Bertl | yes
| |
19:26 | Francky|busy | So spi + some CS
| |
19:27 | Bertl | would be doable, if we can route it
| |
19:27 | Francky|busy | We can add i2c for power board too
| |
19:27 | Bertl | correct
| |
19:29 | Francky|busy | So maybe 100 pin is note as huge as we thought
| |
19:29 | Francky|busy | Not*
| |
19:29 | Bertl | we also need to handle some of the I/Os already handled by the current ICE40
| |
19:30 | Francky|busy | Io from zynq?
| |
19:31 | Francky|busy | What to do?
| |
19:34 | Bertl | no, if you check the current beta board
| |
19:35 | Bertl | you'll see that the ice40 connects to the interface board
| |
19:36 | Francky|busy | Ok
| |
19:37 | Francky|busy | We need to do the list of the needed connections
| |
19:37 | Bertl | so that's 12 I/Os for the interface board
| |
19:37 | Bertl | with a 3.3V level
| |
19:38 | Francky|busy | The voltage level of fpga pins are configurable?
| |
19:39 | Francky|busy | By bank
| |
19:39 | Bertl | yes
| |
19:39 | Bertl | i.e. each bank can have a separate I/O voltage
| |
19:41 | Francky|busy | How do you imagine communication on the pmp?
| |
19:42 | Francky|busy | For spi link, i imagine that an address manage a specific CS
| |
19:42 | Francky|busy | But i dont imagine the link between pic and zynq
| |
19:43 | Bertl | well, the PIC can do DMA on the PMP IIRC
| |
19:43 | Bertl | so it could be a memory mapping between zynq and PIC
| |
19:44 | Bertl | but there are more options I guess
| |
19:44 | Francky|busy | So pic will write data into zynq emulated memory throught pmp
| |
19:44 | Francky|busy | Ok
| |
19:44 | Bertl | yup
| |
19:45 | Francky|busy | It make the pic bsp very light because of the unique bus used
| |
19:49 | Francky|busy | I think about anothet disadvantage about unique pmp bus
| |
19:50 | Francky|busy | When pic will asked something to a device on the i2c bu, it will have to wait for answer a long time
| |
19:51 | Francky|busy | Because ok the low speed of i2c
| |
19:51 | Francky|busy | And all is suspend
| |
19:51 | Francky|busy | Of*
| |
19:52 | Francky|busy | Or we put the i2c and spi protocole into the fpga but in this case the pic do not have a lot of thing to do…
| |
19:56 | Bertl | well, the pic can run some userspace logic
| |
19:56 | Bertl | or we can still feed the sensor data into the PIC via the FPGA
| |
19:56 | Bertl | for processing/logging
| |
19:57 | Bertl | and of course, it can handle all the GPIO to the outside
| |
19:57 | Francky|busy | So this is fpga which implement the i2c protocole?
| |
19:57 | Bertl | we can do that if we like to
| |
19:58 | Francky|busy | I don't think it is the easiest way
| |
19:58 | Bertl | but note that the PIC has hardware support for I2C
| |
19:58 | Bertl | so it can be handled completely in interrupt
| |
19:59 | Bertl | which means that nothing has to wait for a completion or similar
| |
19:59 | Francky|busy | It is for that i propose you not to put the i2c and spi to fpga but directly to the pic
| |
20:01 | Francky|busy | But so we need more pins on connectors
| |
20:01 | Bertl | the FPGA can bridge I2C quite fine, it just needs to know the protocol
| |
20:02 | Francky|busy | What is the interest of an i2c bridge?
| |
20:02 | Bertl | I'm not saying that we need/want to do that, I'm saying that we can do that if we want to :)
| |
20:02 | Francky|busy | Why dont connect i2c from power board to pic i2c?
| |
20:03 | Bertl | I'm fine with that
| |
20:04 | Francky|busy | Ok
| |
20:04 | Francky|busy | So what is your final choice?
| |
20:05 | Francky|busy | Or pre final choice :) ?
| |
20:05 | Bertl | hehe
| |
20:06 | Bertl | I think we should sleep over that
| |
20:06 | Bertl | but the following points look very appealing to me (just to summarize)
| |
20:07 | Bertl | - replace the existing QFN32 iCE40 with a VQFP100 version on both sides of the beta board
| |
20:07 | Bertl | - put similar headers on both sides and have at least 20 I/Os on those headers plus probably one or two I2C ports
| |
20:08 | Bertl | - move the PIC32MZ on the shield
| |
20:08 | Bertl | the benefits I see in those changes are:
| |
20:09 | Bertl | - all GPIO on the high speed side can be handled by the iCE40
| |
20:09 | Bertl | - the low speed side can work even without PIC32, e.g. for debugging or really simple I/O
| |
20:09 | niemand | left the channel | |
20:10 | Bertl | - we can potentially have two microcontroller/GPIO interface shields with similar/identical layout
| |
20:10 | Bertl | - we can easily accomodate different microcontrollers with this interface
| |
20:10 | Francky|busy | A shield is an additionnal board right?
| |
20:11 | Bertl | yes, something we plug onto the headers
| |
20:11 | Francky|busy | Ok
| |
20:12 | Bertl | the only drawback I see (which is not really a drawback IMHO) is that we need a shield to have the PIC32
| |
20:12 | Francky|busy | After a good night we'll try to specify the interface signals of the poc shiels
| |
20:12 | Francky|busy | Pic*
| |
20:13 | Bertl | sounds like a plan!
| |
20:13 | Francky|busy | Or to think about a completly new architecture :D
| |
20:15 | Bertl | yeah :)
| |
20:19 | Francky|busy | See you tomorrow
| |
20:19 | Francky|busy | Bye
| |
20:19 | Bertl | cya and thanks!
| |
20:20 | Francky|busy | left the channel | |
21:00 | Bertl | off for a nap ... bbl
| |
21:00 | Bertl | changed nick to: Bertl_zZ
| |
21:10 | Jin|away | changed nick to: Jin^eLD
|