#qi-hardware IRC log for Tuesday, 2010-12-14

wpwrakalso, is the M25P32 U8 ? the schematics say X25X64MB00:00
wpwrakU8 also uses different pin names. similar if not identical functions, though. perhaps they started with a different chip and then changed00:01
wolfspraulI get some '??' when I open DBG_PRG.sch00:03
qi-bot[commit] Wolfgang Spraul: added ft2232h/c datasheets to BOOKSHELF http://qi-hw.com/p/xue/5642fde00:04
wolfspraulwpwrak: for spi vs. nor flash, any thoughts?00:05
wolfspraulwhat are the pros/cons00:05
wolfspraulfor sure I would think the spi-flash will create substantial work on the software side, compared to just running Milkymist00:06
wolfspraulbut that's just one factor00:06
wpwrakthey're very different. i would assume that they even have entirely different roles in the system.00:07
wpwrakthe spi nand should be what the fpga boots from. not sure what the NOR does.00:08
wolfspraulthe fpga boots from it00:08
wpwrak(DBG_PRG.sch) did you  eeschema DBG_PRG.sch ?00:08
wpwrakyou have to open the top-level sheet00:08
wpwrakotherwise, kicad won't find the profile00:09
wpwrakhint: add a makefile and always "make sch" :)00:09
wpwrakhint 2: you can also have a makefile in xue/ with a "sch" target, so you don't need to cd into kicad/xue-rnc/ when moving around00:10
wpwraksame goes for "brd" (or similar - for pcbnew)00:10
wpwraki was thinking of saving the makefile lecture for andres for later, but if you're already cleaning things up ... :)00:11
wolfspraulseems most of the links in BOOKSHELF are just quickly googled web pages00:13
wolfspraulthat's the kind of dedication and quality we need :-)00:13
wolfspraulthis will be fun :-)00:13
wpwrakwell, the turn-around times give some hint of the level of dedication :)00:14
wolfspraulyes but then I may be better off focusing on Milkymist Two00:15
wolfspraulbut let's not jump to conclusions, I do believe Xue provides some value00:15
wolfspraulwe just need to beat it into shape00:15
wpwraka "baby m1" would definitely be good to have00:15
wolfspraulsure, starting from xue and cleaning it up is probably easier than starting from m1 and cutting it down00:16
wpwrakandres mentioned a while ago that he should have more time in december. so there's hope.00:16
wolfspraulthere is a NAND chip on Xue? wondering what it is used for00:16
wpwrakdo you have a link to the MM1 schematics ?00:17
wpwrak(cutting down) and translating to kicad :)00:17
wolfspraulwpwrak: http://www.milkymist.org/mmone/rc2_schematics.pdf00:30
wpwrakthanks !00:31
wpwrakhmm, the NOR does indeed seem to be the only flash in MM1. didn't know those critters would boot from something with so many I/Os.00:45
wolfspraulso m1 has nor only00:47
wolfspraulxue has spi-flash plus nand00:47
wolfspraulwhy does xue need the nand at all?00:48
wpwrakspi flash is what i know as the "standard' process. but perhaps my information is already outdated.00:48
wolfspraulwe have a microSD slot00:48
wolfsprauland then, why spi-flash instead of reusing m1's nor?00:48
wpwraka good question for andres :)00:48
wpwrakmaybe he envisions to use uSD for really removable media00:49
wolfspraula quick look at ft2232c vs. ft2232h tells me that c = 3rd generation, h = 5th generation01:07
wolfspraulit's probably safe to assume that the software that will work out of the box for the ft2232h-based jtag-serial daughterboard will not work with the ft2232c on xue01:07
wpwrakbut perhaps the other way around01:08
wolfspraulyes but one of the important features is flashing speed01:09
wolfspraulaside from the software compatibility, which remains a big question01:10
wpwrakwhat i mean is that you could perhaps use the ~h instead of the ~c01:10
wolfspraulit may be bigger01:10
wolfspraullet me see01:10
wolfspraulthe c is a 48-pin lqfp, pins pointing out01:12
wolfspraulthe h is a 64-pin qfn01:12
wpwrakhmm. ~c or ~d ?01:12
wolfspraulc = 9x9mm including leads01:12
wolfspraulyou can do 'dsv ft2232c' and 'dsv ft2232h' in xue01:12
wolfspraulI think xue uses c01:13
wpwrakbasically the same size01:13
wolfspraulyes h also 9x901:14
wolfspraulthey made it back with the qfn01:15
wolfspraulso what is the reason that xue uses c instead of h?01:15
wpwrakinteresting. the ~C seems to be quite obsolete already. even at OM we used the ~D. digi-key don't have the ~C.01:15
wpwrakprobably found some old design that used it ? :)01:15
wolfspraulwpwrak: do you think the spi-nand is what the fpga boots from/configures itself from?01:29
wpwraki think it's spi-nand to boot the fpga, nand-nand to boot the cpu (and rootfs etc.), uSD for removable storage01:30
wolfspraulthat's the one on m101:33
wpwrakas JS28F256J3F10501:34
wpwrakUSD 12 per chip, 576 minimum order01:35
wpwrak(at digi-key)01:35
wolfspraulgood thing digi-key is not the only distributor :-)01:35
wpwrakthe others probably aren't much cheaper :)01:35
wolfspraulI think we pay 10.50 USD01:35
wolfspraulit has 256mbit, the one on xue only 32mbit. I'm wondering whether there is any consequence.01:36
wolfspraulwell there are probably many differences01:36
wpwrakokay, 15% less01:36
wpwrakprobably different memory demands for the system01:37
wpwrakthe spi-nand is about USD 1.2 at volume01:38
wolfspraulso there must be a good reason for the nor. but what is it?01:39
wpwraknot sure about the other nand chip. too under-specified in the schematics.01:39
wolfspraulthat's a normal Samsung 2GB, same as in Ben NanoNote01:39
wolfspraulI mean I just put that in there now :-) (in BOOKSHELF)01:40
wolfspraulI would argue for removing it.01:40
wolfspraulnand is evil.01:40
wpwrakNOR has a few advantages. it doesn't have the weird error properties of NAND, you access it like RAM, so you can execute code in place, and it has a wider bus, which is faster.01:40
wolfspraulI think we first need to understand the differences between the NOR on m1 and the spi-nand on xue01:41
wolfspraulthe Samsung NAND on Xue is just for storage I would think01:41
wpwrakdisadvantages are that you have more signals, that it's quite a bit more expensive, and also not as common as NAND.01:41
wolfspraulI see a Tiny AVR in BOOKSHELF, what is that used for?01:41
wpwraklemme see ...01:41
wolfsprauloh, I have a theory on how the pdf.png got in there01:43
wolfspraulright click on some PDF links, and it gives you "copy image location" and "copy link location"01:43
wpwrakhmm, controls the power supplies01:43
wpwrakyeah, of course :)01:43
wolfspraulcontrols the power supplies? hmm01:44
wpwrakthen put on the blindfold, paste, and make sure NOT to verify whether what you did works :)01:44
wolfspraulis that control necessary?01:44
wpwrakbtw, the ft2232 is a ~D in the schematics01:45
wolfspraulI think it's both :-)01:45
wpwrakis ther emore than one ?01:45
wolfspraulgrep for 2232 in xue-rnc01:45
wolfspraulin this kind of projects, my first tool of choice is always good old grep01:46
wolfspraulI count 19 ~c and 4 ~d01:46
wolfspraulso I cannot tell you fast and for sure which one was 'meant'01:47
wolfspraulmaybe you can?01:47
wpwrakah, the ~C is the symbol. ~D is the value. that's okay. as i said, i think ~D and ~C are pin-compatible.01:47
wolfspraulshould I change the datasheet link to ~d?01:47
wpwrak| grep -v LIBS:  # :)01:48
wolfspraulwhy is the symbol ~c ?01:48
wpwrakbecause someone drew it for the ~C ?01:48
wolfspraulyou mean a trace of ancient copy/paste history01:49
wpwrakor maybe someone drew it for the ~D but named it after the original chip.01:49
wpwraknaw, that's pretty standard procedure. raises the question where that symbol comes from.01:50
wolfspraulok, since we will probably change this to the ~h it doesn't matter much01:50
wpwrak(jtag) so the mm1 has a pluggable jtag while the xue has it on board. okay, that explains the difference01:51
wolfsprauldo you think the avr is necessary for power control?01:51
wpwraklemme see ...01:51
wolfspraulSebastien decided to leave the ftdi chip off because in the long run few people will need it and it's an expensive IC01:51
wolfspraulit's a close call but I respect the focus01:52
wolfspraulof course we could have put the 'debug board' (ftdi) onboard the m1 as well01:52
wolfspraulbut even if we believe we want to have it onboard for xue, why not use ~h then as well?01:52
wpwraksince you need the ftdi to fully "unbrick", i think it's not a bad idea to have it permanently there01:53
wolfspraulfor m1 when you press the middle button it will boot from a rescue partition in nor, I believe01:54
wpwrakactually, if i understand the architecture right, it would make even more sense in the MM1, because it has only one flash01:54
wolfspraulthe value of the jtag-serial will go down over time01:54
wpwrak(rescue) ah .. let's see ...01:54
wolfspraulit may make sense for real hardware hacking01:55
wolfspraulbut in those cases, an external 'jtag key' is very common and easily available anyway01:55
wolfspraulit's the old discussion we always had01:55
wolfspraulshould we put something in that only interests 5% of people, and if the product ever takes off only 1%, and then only 0.1%, etc.01:55
wolfspraulanyway I won't get hung up on that01:56
wolfspraulif it should be onboard on Xue, so be it01:56
wolfspraulbut at least we can watch 100% software compatibility, and electrical design compatibility with m1+jtag-serial board01:56
wpwrakoh, wow. MM1 has a separate addess bus for flash01:57
wpwrakand a separate data bus as well01:58
wpwrakwell, if you have the I/Os and nothing else to do with them ... ;-)01:58
wpwraknot sure if the xue has so many I/Os to spare01:59
wpwrakthat's 40 of them01:59
wolfspraulwhat else would it have been used for?01:59
wolfspraulxue is missing 5-10 peripherals from m102:00
wolfspraulyou say the additional image sensor takes up more ios than the removed midi, dmx, video-in, vga, etc.02:00
wpwrakisn't the FPGA a smaller version ?02:00
wolfspraulnot that I know02:00
wolfspraulman, I can't believe that we have a proper PDF url for every single item on the Milkymist One BOM!02:02
wpwrakdarn amateurs. can't even get the professional untidiness right ! (-:C02:03
wpwrak15 unused I/Os on expantion.sch ...02:05
wpwrakyup. FPGA looks the same. i guess i confused this with SIE.02:06
wolfspraulso back to the AVR - you think it's necessary?02:08
wolfspraulthat was the original question02:08
wpwrakhmm, nice. only 178 ERC error in Xue.02:09
wolfspraulin the schematics?02:09
wpwrakthe AVR may be necessary to let the system power itself up and down.02:09
wolfspraulhow is this done on m1 then? power-up and down...02:09
wolfspraulxilinx says in their marketing that the power-up sequence for the fpga is very flexible/robust02:10
wpwrakyou can fix something like 20-30 of them just by putting that little x on the unused pins on the FPGA port 0 sheet ;-)02:10
wpwraki think MM1 just runs at full power when connected02:11
wpwrakthe regulators are always enabled. of course, you can draw more or less after that.02:11
wolfspraulok I see the 178 ERC errors02:13
wolfsprauladding to my todo list :-)02:13
wpwraknot sure what this means in practical terms. if all the subsystems can be set to draw almost nothing, then the regulators won't either.02:13
wolfspraulmaybe the main reason for the AVR is copy/paste leftover?02:13
wpwrakbut it may just be that MM1 isn't optimized for low power02:13
wpwraknaw, i wouldn't dismiss the AVR so quickly02:14
wolfspraulnot dismissing, just trying to find the reasons02:14
wpwrakinteresting. it also controls the enable line of the regulator that powers it.02:15
wpwrakthere's a pull-up, so it's probaby safe02:16
qi-bot[commit] Wolfgang Spraul: better PDF links in BOOKSHELF http://qi-hw.com/p/xue/d5e48e602:16
wpwrakof course, lots of resistors with unknown values all over the PSU02:17
wolfspraulneeds to stay in style02:18
wpwraksigh. it does get a little boring after a while ...02:18
wolfspraulthere are two paths - cleanup xue or start over from m102:19
wolfspraulI think I want to spend some time in xue first02:19
wolfspraulwhat do you suggest for the names of the schematics pages?02:21
wolfspraulfirst there seems to be a filename, and a 'text string' inside KiCad02:21
wolfspraulshould we try to keep them the same?02:21
wpwraknice. you added the FAN4010. just what i needed :)02:21
wolfspraulfor spaces, I guess we should also go with either '-' or '_'02:22
wolfspraulright now it seems to use '_' in the filenames02:22
wpwrak(name vs. string) ah, now you'll mess up the schematic history :)02:22
wolfspraulwell both file names and strings are so messy that we probably don't want to leave them like that02:23
wolfspraulif schhist cannot follow anymore that's bad of course02:23
wolfspraulso what do you propose?02:23
wolfspraulthe filenames are a total mess already now, lowercase, uppercase, typos, everything02:23
wolfspraulthe strings are slightly better, aside from whitespace inconsistencies, typos, and case inconsistencies02:24
wpwrakintersting. each regulator has a current sensor. they go to the AVR. some of them go to ADC pins. the others .. hmm ... checking ...02:25
wpwrak.. hehe, don't ;-)02:26
wpwrakoh the sweet memories ;-)02:26
wpwrakyeah, the sheet names are a mess. dunno. i tend to keep them terse and the same02:27
wolfspraulspaces as?02:27
wolfspraul'_' or '-'?02:27
wolfspraulstrings and filenames 'should' be the same?02:28
wolfspraulor not02:28
wolfsprauland how can we fix it in Xue so that schhist won't break?02:28
wolfspraulas for your AVR comments and unconnected pins - what does it mean?02:28
wpwrakif you fix it, it'll break schhist in one way or another. that is, you get sheets that "jump".02:29
wpwraki can try to add some more heuristic to navigate around that02:29
wolfspraulok let's go through one by one02:30
wolfspraulspace: '-' or '_'?02:30
wolfspraulin ben-wpan you have one '-'02:30
wolfspraulso should we go with '-'?02:31
wpwrakbtw, we already have a case where it breaks, FPGA port 1/302:31
wpwrak- usually looks better in file names. but i do either, depending on daily mood :)02:32
wolfspraulalright, '-' for now02:32
wolfspraulhow about the names (strings) of schematics pages?02:32
wolfspraulusually follow the filename?02:33
wpwrakthat's what i do. the more descriptive names may be useful in some cases ... but then, maybe not.02:34
wpwrakthe only places where they really add something are the fpga sheets02:34
wpwrake.g., "FPGA Port 1 Port 3 (DDR, USB)"02:35
wolfspraulthat's for the string?02:36
wolfspraulso you don't want the '/' in the strong02:37
wolfspraulbut '(' and ')' are OK?02:37
wpwrakabout the avr: it seems taht, once the resistors have received some values, you could run the board even without the avr02:37
wpwraki think there are no/not many restrictions for what goes into the string02:37
wpwrak(avr) i don't know what current consumption to expect, though02:38
wolfspraulyes but first you said something breaks with "FPGA port 1/3" and then later you write "FPGA Port 1 Port 3" as if to avoid the '/'02:38
wpwrak(avr) all the current sensors suggest that someone else is curious about this, too ;-)02:38
wolfspraulwithout the AVR we should save some current for the AVR :-)02:39
wpwrakah, that was just an abbreviation02:39
wpwrakif you pull the avr, you can also pull the FANs ;-)02:39
wolfspraulmaybe this is meant to support batteries?02:40
wpwrakbut again, not sure what this does to idle/standby power consumption02:40
wpwrakis xue supposed to be low power ?02:40
wolfspraulbut what does 'low power' mean, i'd say first it's about being smart & efficient02:40
wolfspraulwhich is driven by the usecase02:40
wpwrakah yes, says "+BAT" :)02:41
wolfspraulXilinx says the spartan-6 is 'low power'02:41
wolfspraulit all depends on perspective, needs, use case02:41
wpwrakhmm, all the sensor regulators are aways on. interesting.02:42
wolfspraulsince Xue may well be operated mobile, you could say that when in conflict, low power trumps performance/features more so than if it would not be operated mobile02:42
wolfspraulbut then you first need such a conflicting pair to look at - power vs. performance02:42
wpwraknow .. battery where art thou ?02:43
wolfspraulhow can I cleanup the schematics names without breaking schhist?02:43
wolfspraulshould I start with filenames?02:43
wolfspraulor strings?02:43
wpwraki'd just go ahead and make whatever change you want. we can always fix schhist later02:44
wolfspraulif I only change filename (and not string), and then commit, that should make it easier to track, right?02:45
wolfspraulso maybe I change filename, and string, in separate commits?02:45
wpwrakthat probably makes things easier, yes02:46
wpwrakschhist tracks both but gives one priority over the other. don't remember which without looking.02:46
wpwrakin any case, changing both in some way will break the existing mechanism somewhere.02:47
wolfspraulwpwrak: but maybe if I change them in separate commits schhist can recover?02:50
wolfspraulI'll try that...02:50
wolfspraulthere is a low-power DDR datasheet checked into the xue git, I'll delete it02:50
wolfspraulthe one I think Xue is using is the non-low-power one from m102:50
wpwraknow that we have dsv .. :)02:50
wolfspraulI can find the url for that one and add it02:52
kyaki was wondering02:56
kyakis it possible to get to know programmatically the power consumption of USB device inserted into PC?02:57
wolfspraulthe PC would need to measure it, and it will not have the necessary hardware prerequisites for that. But if it's a notebook, maybe you can look at the battery.02:58
kyakof course, to know if from PC side - because the USB device could be anything02:58
wpwrakif your pc is connected to some current measuring device which is in turn connected to the USB cable ...02:58
wolfspraulof course that's for the whole system, so if the screen brightness changes, or your HDD usage pattern changes, or whatever other parts of the system, the measurements may be distorted02:58
wpwrak(notebook battery) good idea !02:59
kyaki thought there is an easy way to do it and this information is avaialble from usb driver03:00
kyaki thought that because on Windows, there is some indication in current consumption in USB root device properties.. but it seems inadequate03:01
kyakwhen i insert flash driver, it shows 100mA03:02
kyakwhen i insert some PCB, it shows 448mA03:03
kyakno matter what03:03
kyakit looks like a device reports something to Windows03:03
kyaksomething like its peak consumptinos03:04
wolfspraulgood point there may be something in the usb protocol03:05
wpwrakwolfspraul: ah, another little riddle: all the regulators on sensor_psu.sch are TPS793XX :)03:05
wolfspraulbut unless the device on the other side really measures, the value is meaningless03:05
wolfspraulbecause your notebook won't measure, unless it's a very special-built device03:06
wolfspraulwpwrak: you mean they are under-specified?03:06
wpwrakthat is, you can figure ou the right part number by looking what voltage they're supposed to deliver. so it's an easy riddle.03:07
qi-bot[commit] David Kühling: added emacs startup file for configuring stuff specific to the openwrt package http://qi-hw.com/p/openwrt-packages/f00fc2303:08
qi-bot[commit] David Kühling: pull out japanese input dictionary into a separate package.  it's too large to http://qi-hw.com/p/openwrt-packages/a67037903:08
wpwrakthe unspecified resistors they connect to are a little harder.03:08
qi-bot[commit] David Kühling: typo http://qi-hw.com/p/openwrt-packages/31a24f803:09
wpwraki'm also kinda curious how the system is supposed to be powered. there's a battery rail, but i don't see it go to any connector. not sure what USB power plays in all this.03:10
qi-bot[commit] David Kühling: another type http://qi-hw.com/p/openwrt-packages/7235d3903:11
wolfspraullekernel: hi good morning!03:19
wolfspraulthe bearstech package is already on the delivery truck - awesome!03:19
qi-bot[commit] Wolfgang Spraul: removed lpddr datasheet copy, linked from BOOKSHELF http://qi-hw.com/p/xue/3cdb0ec03:23
wolfspraullekernel: we had a question for you earlier. We were wondering why you chose the NOR flash for Milkymist One03:27
wolfspraulfor example in comparison to this spi-nand: http://www.numonyx.com/Documents/Datasheets/M25P32.pdf03:27
wpwraklekernel: also, is it correct that the FPGA is initialized from NOR ? or did i overlook some spi-thingy somewhere ?03:32
wpwrakwolfspraul: the xue layout is nice to look at. still haven't found the battery connector, though. well, there's a fat trace for +BAT, so you just add a wire ;-)03:34
wolfspraulis there a DC jack?03:34
wpwrakof course, there's no battery charging logic ...03:35
wpwrak(dc jack) nyet03:36
wolfspraulah yes, so you just solder a wire to that fat trace and the board is powered03:37
wolfspraulpiece of cake03:37
wpwrakscratch off the solder mask and you're there. the trace is quite wide, so it's easy :)03:37
wpwrakabout 1 mm wide. that's pretty big.03:39
wolfspraulwpwrak: good thing that this is an open hardware project03:41
wolfspraulso it's easy to locate the trace03:41
qi-bot[commit] Xiangfu Liu: config.all_packages: add all packages config file base on minial http://qi-hw.com/p/openwrt-xburst/ab1143703:45
wpwrakthe ftdi gets usb power, but that stays there. usb host connects to the +5V rail, okay. usb device does not connect to vbus. so .. no other way in than directly to the trace, it seems :)03:50
lekernelwolfspraul: plenty of I/O available, easier to work with, supported by xilinx, execute in place possible (for the BIOS)03:53
lekernelyes, the FPGA is loaded from the NOR03:53
lekernelthat's the only flash memory in the system03:54
lekernelwpwrak: the MM1 isn't optimized for low power - it's competing with power guzzlers that happily draw 80W or more (see edirol cg8 for example) so I don't care much03:54
lekernelbut the standby bitstream does put the FPGA and some peripherals in low-power mode03:55
lekernelbtw Xué has FANS?!?03:56
lekerneleven with the lack of low power optimization, the MM1 barely gets hot03:56
wolfspraullekernel: elaborate more on your question whether Xue has fans? :-)03:57
wpwrakokay, thanks. hadn't seen FPGAs load their bitstream from NOR. (of course, i'm an FPGA noob :)03:57
wpwrak(fans) nono .. that's a chip with part number FANxxx03:57
wolfspraulfans as in devices shuffling air, or fans as in crazy folks?03:57
lekerneldevices shuffling air :)03:57
wpwrakit's just amusingly confusing ;-)03:57
wpwrakparticularly since the chip has very few pins. (it's a current sensor)03:58
wolfspraulwpwrak: did we have any other questions for lekernel ?03:59
wolfspraulif Milkymist One has a NOR flash, and works fine, I wouldn't know why Xue shouldn't keep the same chip04:00
wpwrakis cost an issue ?04:01
wolfspraullekernel: ah, another one. Xue uses a ft2232d instead of the ft2232h on our jtag-serial board for m104:01
wpwraki'm also not sure if there are enough spare pins04:01
wolfspraulone of the things we liked about the 'h' was the high speed04:01
wolfsprauldo you know anything about the ~d?04:02
wolfspraulwpwrak: there must be enough pins, how could it not if xue has so much _LESS_ than m104:02
lekernelI just picked the fastest chip04:02
wolfspraulI don't even start counting, I cannot imagine where all those pins should have gone.04:02
wpwrakalso depends on the voltage domain04:03
wpwrakport 3 has a lot of spares. it's in 2.5 V. i guess the NOR is 3.3 V ?04:03
lekerneliirc there is 2.5V NOR as well04:03
lekernelbut if you want the FPGA to configure from NOR, you can't choose the pinout04:04
wolfspraulthe idea of xue was to take m1, remove lots of things, add image sensor04:04
lekernelbtw the Spartan-6 has some pretty crazy constraints wrt the placement of clock pins and the data they relate to04:04
wolfspraulthat probably was not the process that was actually followed there :-)04:04
wpwrak(nor pins) ahh, yes, makes sense. let's see ...04:05
lekernelalso, some I/O pins have special functions during configuration04:05
wolfspraullekernel: did you see above? bearstech boards on delivery truck - good04:05
lekernelso the FPGA pinout is something to be checked carefully04:05
lekernelwolfspraul: yeah, good :)04:06
wolfspraulI'm still failing to understand what we need to check if Xue reuses m104:06
wolfspraullekernel: wpwrak and I are having some fun taking Xue apart. need to understand it a bit...04:06
lekernelyeah, seeing the backlog04:06
wolfspraulhave you seen any new case work from roh?04:07
wolfspraulcan't wait to see new pics...04:07
lekernela little bit04:08
wpwrakport 2 is in an unknown voltage domain. regulator under-specified, rail is not marked. but that may be intentional. all of port 2 goes to the external connector04:08
wolfspraulwpwrak: looking at the 3d view of the xue board, I'd say 95% or more of components have no 3D footprint04:08
wpwrakthis of course spells doom for booting from NOR (which uses port 2)04:08
wolfspraulthe other way round, it spells doom for the external connector04:09
wpwrak(no 3d) i'm not surprised.04:09
wpwraki don04:09
wpwrak't bother with 3d in fped, for example :)04:09
wolfspraulno problem that's why I bring it up04:09
wolfspraulshould we postpone this until later?04:09
wpwrakpostpone what ?04:09
wolfspraulworrying that we have full 3D stacking data in KiCad04:10
wpwrakuh, yes. let's revisit this in, say, 2041 ? :)04:11
wpwrakport 1 is 2.5V in xue. nor boot uses that, too.04:11
wpwrakso going from spi-nand to nor is basically a full redesign of the board.04:11
wolfspraulyou mean nor boot on m1 uses 2.5V?04:11
lekernelm1 uses 3.3V everywhere except for DDR and JTAG04:12
wpwrakthe port that nor boot would use if xue did nor boot is in a 2.5 V domain04:12
wpwraknot sure if the pins are occupied04:12
wolfspraulmaybe there is a 2.5V variant of the same chip as on m104:13
wolfspraulbut I guess we can see already that m1 compatibility was not very high on the list of design goals for xue, if it was there at all04:13
wpwrakwell, flash is certainly very different. not sure about the other stuff. (usb, ether, ...)04:14
wpwrakoneah, another advantage of NOR: with execute-in-place, you don't need RAM for (constant) code or constant data.04:15
wolfspraullekernel: how do you feel about moving Milkymist One to KiCad?04:17
lekernelhum, that's it's an uninteresting time sink?04:18
lekernelbut if someone else wants to do it, why not04:18
adamwangwolfspraul, wpwrak : i just got info from AiT vendor04:19
wolfspraullekernel: I'm mainly asking because of Milkymist Two04:19
lekernelas long as it doesn't incur the slightest slowdown in production04:19
wolfsprauloh no04:19
wolfspraulof course not04:19
wolfspraulno worries04:19
wolfspraulthis is not why I'm asking04:19
wolfspraulso let's say one day we start working on Milkymist Two, you mentioned capacitive screen on top, for example04:20
wolfspraulhow much 'in love' are you with your current EDA tool?04:20
wolfspraulif at that point we had the design transferred into KiCad, would you make the schematics changes in KiCad?04:20
wolfspraul(this is all hypothetical, I just try to understand your priorities)04:20
wolfspraulthe "time sink" comment is totally fine :-)04:21
wolfsprauladamwang: go on, what about AiT?04:21
adamwangi'm writing email to list first04:22
wpwrakopen source hardware -> open source eda tools. kicad is inevitable ;-)04:22
lekernelmilkymist2, if it happens at all, will probably be a major re-spin...04:22
lekernellet's hope kicad has had the time to improve before that04:22
wolfspraulwhy should it not happen, and could you roughly have in mind then for the re-spin?04:23
wpwrakwolfspraul: in order to keep the xue changes at a reasonable level, i'd try to stay with loading the bitstream from spi-nand.04:23
wolfspraul /and what could you/...04:23
lekernelsince most of it will need to be re-done, yes, why not give kicad a try...04:24
wolfspraulany indicators what might need to be redone?04:24
wolfspraulyou are by far the most ahead in thinking about m1 features, so any bit like 'capacitive screen on top' helps...04:24
lekernelbefore we start talking about Milkymist2, the spartan6 will probably have become obsolete :)04:24
wolfspraulsure we can use this aerix-7 or whatever they call it04:25
wolfspraulor non-xilinx if something better is out then04:25
wolfspraulbut how about other features?04:25
wolfspraulwait I check04:25
wolfspraulArtix, sorry04:26
wolfspraulthe successor of the Spartan-604:26
wolfspraul'Spartan' brand is to be retired/discontinued04:26
wolfspraulhow about other features? more user-oriented stuff04:26
wolfspraulanything in mind?04:26
wolfspraul(you did mention that screen on top once...)04:26
lekernelyeah, that was just a random idea, make a mashup of the iPad and M1 :)04:27
lekernelbut let's get the M1 out first and see how users react04:27
wolfspraulof course, there is a lot we can do on the manufacturing side to drive costs down04:27
wolfspraulI can happily work on that for a while :-)04:27
wolfspraulthat would probably include bringing it over to KiCad and related tools at some point04:27
lekernelhow does that help with manufacturing costs?04:28
wolfspraulit makes the process cheaper when there are changes04:29
wolfspraulthat's why I am asking about Two04:29
wolfspraulif we say "it's a dead product and there will never be a modification/change anymore", then we can just squeeze every penny out of the existing procedures and components04:30
wolfspraulbut I rather like to think about it in a more dynamic way04:30
wpwrakalso opens the project for wider participation and makes its results accessible for more people04:30
wolfspraulso I anticipate changes04:30
wolfsprauleven changes that are in reaction to component costs, or manufacturing issues04:30
wolfspraulor whole derivative projects like I still think of Xue04:30
wolfspraulalso when we scale up, there is a lot of 'scaffolding' stuff we need to build so that the unit costs come down when the volume goes up04:32
wpwrakyup. particularly if you want to minimize the changes. turns the incentives around completely ;-)04:32
wolfspraulthat 'scaffolding' is often tied to and build upon the original tools04:32
wolfspraulso once you are in that, your original tools grow with you. I'd rather have that to be our free process with free tools etc.04:32
wolfspraulI can't give you an exact example for this now, it depends on what happens as we scale. But trust me, the original choice of tools then normally multiplies itself, for good or for bad.04:33
lekernellet's focus on milkymist one first04:33
wolfspraulof course we are doing a lot of things right already, with the test suite being free software...04:34
lekernelhow to make good software04:34
lekernelhow to sell thousands (or more)04:34
lekernelhow to make it cheap04:34
lekernelthose are the important things atm04:34
wolfspraulyes but before that I switch to KiCad for sure, or will try to04:34
wolfspraul(the thousands)04:34
wolfspraulbecause if we don't, it becomes essentially unchangeable later04:34
lekernelthose who make the change, switch to kicad?04:35
lekernelpersonnally I'm not interested in changing stuff04:35
wolfspraulI'm not asking you to, all fine.04:35
lekernelexcept maybe for a complete re-spin (M2) but later04:35
lekernelway later04:35
wolfspraulI just try to understand your thoughts of future changes.04:36
wolfspraulit's already mostly clear I think04:36
wpwrakwolfspraul: seems that you won't get MM1 in kicad for christmas after all :)04:36
wolfspraulthis christmas?04:37
wolfspraulno there is no rush, we should introduce it when it makes sense for m104:37
wolfspraulI agree with sebastien on the priorities04:37
wolfspraulit will make sense as we scale up production, and it's most likely something I can do entirely without Sebastien's help04:37
lekernelI quite don't see how kicad would help scale up production...04:38
wolfspraulfor m1 the product, even on the hardware side, there are still many low hanging fruits to pick first04:38
wolfspraulcase, certification, board optimizations (like the crystal thing we found)04:38
wolfspraullekernel: the other way round. As you scale, your choice of tool typically becomes unchangeable.04:39
wolfspraulbecause the tools and their characteristics and side/helper tools grow as you scale04:39
lekernelwhy not scale the current version first, then maybe start the kicad fork later, as a side project?04:39
wolfspraulso if we believe in the benefits of free tools, we need to change them while runs are small, or never04:39
wolfspraul'scale' is essentially pressure on your tools and processes to grow04:40
wolfspraulI can only repeat: choice of tool becomes unchangeable after you scale.04:40
wolfsprauleconomically of course, I mean04:40
wolfspraultechnically you can always do every crazy thing :-)04:40
lekernelwhat's impossible in slowly changing to kicad later?04:41
lekernelrun two different projects...04:41
lekernelmain branch, and kicad branch04:41
wolfspraulat that point such a decision would be so risky/expensive, that nobody will want to pony up the money anymore04:41
lekernelit's like starting a new project04:42
lekerneland you start new projects all the time :p04:42
wolfspraulmaybe much less than you think :-)04:42
wolfspraulanyway, why are we discussing this? the timing of bringing m1 into KiCad?04:43
wolfspraulnot urgent imo, we are on the same page about that I think04:43
wolfspraullekernel: I was hoping to use Xue to test our KiCad process, and also prepare for future m1/KiCad, but we found a lot of issues in Xue now so I'm thinking what the best order of things is04:45
wolfspraulwpwrak: yeah I guess the spi-nand issue is a big one on Xue04:46
wpwraknot only technically but also in terms of work that would get thrown away04:46
wpwrakbasically the whole layout would have to be redone04:47
wolfspraulwell either way. I simply don't think we will ever get it to work on the software side.04:47
wolfspraulwhat's the point of soldering together a board that will never turn on and perform a useful function04:47
wolfspraulmaybe we are better off transferring m1 into KiCad earlier rather than later, even under Sebastien's suspicious eyes :-)04:48
wpwrakwhy would nor vs. nand make the sw side so impossible ? you've said that you already want to use uSD instead of nand04:48
wolfspraulit's not impossible, but I think very practical - who will do it, and who will stand behind it.04:49
wolfspraulthe reason the m1 run was successful is because of lekernel's excellent preparations and support through the run04:49
wolfspraulif there is no such support for Xue we can spare everybody the waste of time of making a dead board.04:50
wpwrakyeah, xue depends on how committed andres and his helpers are04:50
wolfsprauland you say layout would need to be thrown away04:51
wolfspraulwe are only scratching the surface04:51
wpwrakwee can help with some obstacles, but they have to "own" the project04:51
wolfspraulif we would continue in this style, by the time all schematics changes have been made the layout would need a massive re-work anyway, I'm sure04:51
wpwrak(surface) maybe. perhaps more will show up after a first scrubbing. the onion model ;-)04:51
wolfsprauljust think power supply04:52
wpwrakyeah, the power supply is a bit of a mystery. there must be *some* plan.04:53
wolfspraullekernel: how are the 2 rc2 boards holding up by the way?04:53
wpwrak(supply) it's not something you just overlook.04:53
wpwrakthis would also be inconsistent with the other problems we found.04:54
wolfspraulwhat would be inconcistent?04:55
lekernellast time I checked they still worked... one is with roh atm04:55
lekernelbtw I've run into the "no more boot" problem04:56
wolfspraul'no more' as in not at all?04:56
lekernelno, not at all04:56
wolfspraulfor how long?04:56
wpwrak(inconsistent) just forgetting the power supply input04:56
lekernelbut after reflashing it worked again, so I guess the "intermittent boot issue" might also corrupt flash data sometimes04:56
wolfspraulwhy is that inconsistent?04:57
lekernelnext time this happens i'll dump the flash and see if something was actually corrupted04:57
wolfspraulimho that is consistent with many other things we see on the board04:57
wolfspraullekernel: yes there may be several bugs, masking each other04:57
wolfspraulbe careful04:57
wolfsprauldo not cycle the boards too fast04:57
wolfspraulthis is a trap04:57
wolfspraulyou are then able to 'reproduce' the bug more often, but I think that is a separate issue then04:57
wolfspraulseparate bug04:57
wolfspraulif you get hung on on too fast power cycles, at least me and Adam have managed to permanently damage 2 boards04:58
lekernelyeah, I waited a few minutes04:58
lekernelbut still no boot04:58
wolfsprauloh wow04:58
wolfspraulI'd say 2 seconds is enough04:58
lekerneland it immediately worked again after reflashing04:58
wolfspraulthere may be several bugs04:58
lekernelso this really looks like corrupt flash contents04:58
wolfspraulthat is very consistent with what I saw04:58
wolfspraulno I think there are probably several different bugs/issues04:59
lekernelwell, if the root cause of those problems is a glitch on the flash write enable line during power up, this explains two problems already04:59
wolfspraulmaybe if we can track down one of them the rest will become clear fast04:59
wpwrak(inconsistent) naw, it's a different kind of sloppiness. one kind is where the board couldn't be produced (because some data hasn't been provided), the other kind is where it doesn't work.04:59
lekernelfor the "permanently damaged" boards (never had something like that), I can't comment until we know what is damaged05:00
wolfspraulwe treated them pretty badly05:01
wolfspraulthat's ok we just did all kinds of tests05:01
wpwrak(inconsistency) so i suspect it's either something that got postponed (and carlos doesn't know/remember it was) or they fully intend to use some hack in the first run05:01
wolfspraulI only want to get 1 point across: if you run into the .56A boot bug, and you want to reproduce it better, and you discover that if you work with shorter power cycles, you can reproduce it better, don't go that way05:01
wolfspraulthere is a separate problem somewhere when you keep cycling the board in short cycles, like < 500 ms05:02
wolfspraulto be safe, never cycle in less than 2 seconds05:02
wolfspraulthat's my only point, but important05:02
wolfspraulafter we 'terminally' tested the 1st board, we wanted to see whether our assumption was correct05:03
lekernelanyway, what is damaged on those boards?05:03
wolfsprauland lo and behold, within a short amount of time we were able to 'terminate' the second one as well05:03
lekernelcould still be useful to know in order to make the design more robust05:03
wolfspraulat least that was a successful test05:03
wolfspraulyes we will look at them05:03
lekerneldid you try to reflash?05:03
wolfspraulbut there has been so much testing on these boards at some point it's hard to squeeze more data out of them that is not just mirrors of prior activities05:04
wolfsprauloh sure05:04
lekernelit could simply be a "corrupted flash content" problem like mine05:04
wolfspraulno more reflashing05:04
wolfsprauloh no05:04
wolfspraulwe did A LOT of testing05:04
wolfsprauland we are not totally stupid, I would hope05:04
lekerneland? what happens when reflashing?05:04
wolfspraultrying to track things down, find pattern, etc.05:04
wolfspraulimpact can't connect I think05:04
wolfspraulor maybe error during flashing05:05
wolfspraulit's in the ods05:05
lekernelmh, ok05:05
wolfspraulwe put those 2 boards aside05:05
lekernelis the power supply ok?05:05
wolfspraulyes I think so05:05
wolfsprauljust remember: don't cycle very fast in attempts to reproduce the .56A boot hang05:05
wolfspraulit's not a good path05:05
lekernelthen the FPGA is burned05:05
lekernelbut there is simply no way that could happen05:05
lekernelexcept ESD05:05
wpwrakpower supply good and the board still dead, that sounds unpleasant05:06
wolfspraulcycle very fast will do it05:06
wolfspraulafter 2 boards we didn't want to do more experiments around that, it needs a more thoughtful approach05:06
wolfspraulbut then, this type of power cycling is quite unusual05:06
lekernelonly overvoltages can kill the JTAG on the FPGA05:06
lekerneleven shorted I/Os won't do that usually05:06
adamwanglekernel, the 2 brds at your site, don't do power cycle in one second!05:07
wolfspraulmaybe the quick cycles mess up something and current flows where it shouldn't? I don't know. We stopped going in that direction.05:07
wolfspraulhe :-)05:07
wolfspraulAdam tries to get the same message across.05:07
adamwangbefore we find hard info further.05:07
lekernelI power cycled both RC1 and RC2 fast, and never run into an issue like that05:08
wolfspraulhow fast and how many times?05:08
adamwangi can pretty surely my power supply is ok but ESD don't know.05:08
lekernel0.5s, maybe 20-30 times05:08
wolfspraullekernel: I really suggest you don't try it any more.05:08
wolfspraulwe are just wasting boards with very unusual behavior anyway - no value for anybody05:08
lekernelmaybe a first step could be to record the power supplies on scope05:09
lekernelpower cycle fast05:09
lekerneland verify they don't exceed their nominal voltage05:09
wolfspraulyes I think that's on Adam's todo list somewhere05:09
wolfspraulalso watch what happens on the board05:09
wpwrakhmm, no boost converters in sight, so it couldn't be a dc/dc converter going crazy05:10
adamwangthis 0x1a brd we tried power cycle at fast at 480ms, of course this test is un-usual.05:10
lekernelbut really, if the power supply don't go too high in voltage, the only option to kill JTAG is ESD05:10
adamwangbut what somethings we didn't know is that this 0x1a is working well even we added 470nF connected to C60, then it still ok.05:11
wolfspraulif you can fix a bug without trying to reproduce it with short (<500ms) power cycles, that is great05:11
wolfspraulthat's all I can contribute to the discussion :-)05:11
adamwangand then other 2 brds, me & Wolfgang let them dead. :)05:11
lekerneladamwang: you can't put whatever capacity you want on the I/O, and it still won't kill the FPGA05:12
wolfspraulAdam will be looking into the power some more when things settle down.05:12
wolfspraulI don't think it was ESD.05:12
lekernelthe Spartan6 doesn't mind if there is voltage applied on the I/O when the main power is cut05:12
lekernelnor capacitor inrush current will be much of a problem, it's limited by the drive strength of the I/O05:12
adamwangso anyway, before we get hard info later, pls don't try to power cycle in very short duration.05:13
lekernelas long as it doesn't dissipate too much power (and it won't unless you toggle the I/O fast) it won't burn either05:13
wpwrakhow is power cycled ? unplug, then replug ? if yes, could 5V and GND get inverted ?05:14
adamwangwpwrak, it's possible, i also thought this before ,05:14
adamwangbut i have no data to approve.05:15
adamwangwould be fast inversely current involved this?05:15
adamwangfrom the picture, yes we unplug power on and off05:16
wpwrakhow about just electromechanical, i.e., the connector ? be it the plug-socket interface or maybe some mechanical effect on the socket05:16
wpwrakif you unplug/replug rapidly, the movement/forces may differ from slower cycling, and trigger an unusual problem05:17
adamwangi didn't connect any mechanical.05:18
wpwrakadamwang: (no mechanical connection) so how did you cycle ?05:18
adamwangi used a switch to unplug and plug-in to let 5V DC get in DC jack on board.05:19
adamwangis it not good?05:20
wpwrakokay. does the switch cut 5V and GND or just 5V ?05:21
adamwangjust 5V05:21
adamwangbut from the scope of picture, there's no spark while power-cycling05:22
wpwraki guess you used a lab supply ?05:23
adamwangor do you think that I had better to switch both(5V and GND) in very tiny period?05:23
lekerneladamwang: better check the output voltages (1.2V, 2.5V, 3.3V) on scope05:23
lekernelmaybe even 1.8V and 5V at the same time (got enough channels?)05:24
adamwangyes, a lab supply05:24
adamwangum..i need to scope them in only two channels to monitor again05:25
wpwrakadamwang: (switch) no, just 5V seems better than switching both. lab supply is good, too. unlikely to do crazy things. (well, unless you got a really bad one ;-)05:26
adamwangsee this while i measured during RC1 made05:26
adamwangi guess our brd RC1 have hw itself power sequence timing is different05:27
adamwangso i am thinking that what's best timing between flash and fpga05:27
adamwangi should plot those relationships in chat as well...then we can know what's timing flash chip stayed at?05:29
adamwangwell...not go to FAE there...will do this.05:29
lekerneladamwang: we're talking about checking that the power supply levels stay reasonable when the board is power cycled fast05:30
lekernelin order to explain the "permanent damage" you've seen05:31
lekernelthe flash is a different problem05:31
adamwangno, actually we don't know.05:32
adamwangwould it be too fast for example are there all IOs status are good for connections between flash and fpga during such so 480ms?05:33
adamwangwould their IOs acts un-normally easily during 480ms?...I don't know.05:34
adamwangwpwrak, my supply is a new one! hehe. :) not 2nd-hand. :)05:37
wpwrakadamwang: sometimes, 2nd hand is better. already debugged ;-)05:39
adamwanghehe. :)05:39
adamwangyou know taiwanese here. A new supply may only cost USD 150.05:40
adamwang2nd -hand, it doesn't worth to repair it. :) well05:41
wolfspraulwpwrak: just saw Adam's mail that the AiT parts are EOL essentially05:56
wolfspraulthe ones used in Xue. compared with the other 10+ issues we found I don't think this can be considered especially bad news though...05:57
wpwrak(AiT) good to know early ;-) i'm having a bit of troubles with my mails, so i haven't seen it yet06:02
andres-calderonHi wolfspra1l07:08
wolfspraulandres-calderon: hi08:23
wolfspraulso Werner and I looked over xue a little08:24
wolfspraulfirst big surprise was the spi-nand instead of nor flash as on m108:24
wolfspraulat least surprise for me08:24
wolfspraulthen smaller thing but also different from m1 is the ft2232d instead of ft2232h08:25
wolfspraulthen the PSU, under-specified regulators, missing resistor values08:27
wolfspraulmissing DC jack or battery connector, leaving the only way to supply power to the board the surgery to find the right wire in the pcb and apply the power there :-)08:27
wolfspraul178 ERC warnings in KiCad08:28
wolfspraulquestion whether we need the Samsung NAND chip08:28
wolfspraulquestion whether we need the AVR08:28
wolfspraulandres-calderon: back?09:08
andres-calderonwolfspraul: hi09:14
wolfsprauldid you see what I wrote earlier?09:15
wolfspraulsome of our feedback09:15
wolfspraul178 ERC warnings09:15
wolfspraulquestion whether we need the Samsung NAND09:15
wolfspraulquestion whether we need the AVR09:15
wolfspraulmissing DC jack and battery connector, psu design seems unclear09:15
wolfspraulspi-nand is different from m1, if it's too hard to change we need to confirm whether that chip is ideal09:16
andres-calderonWe  prefeer to have NAND flash (optional) for improve mechanical  capabilities...09:16
wolfspraulft2232d instead of ft2232h, why not use same one as in m1?09:16
wolfspraulok let's just start somewhere09:17
wolfspraulcan you look at the ERC warnings?09:18
andres-calderonwe have traumatically experiences with automotive  applications..09:18
wolfspraulmaybe nobody ever looked at them, many are probably very easy to fix09:18
wolfspraulI updated BOOKSHELF a little, we need many more links there, for every last component on the board09:18
wolfspraulwpwrak decided that dsv will only support pdf now, and that is the vast majority of 'datasheets' anyway. so no html links...09:19
andres-calderonrunning ERC...09:19
wolfspraulthe psu needs a complete overhaul I think09:19
wolfspraulbetween missing connectors, unclear avr role, under-specified regulators, missing resistor values, it seems that some big thinking is needed there09:20
wolfspraulbut maybe we do things step by step09:22
andres-calderonAVR has been added for energy measure.  wolfspraul propose energy measure for debuging.09:22
wolfsprauloh my god?09:22
wolfspraulI'm the reason for the AVR?09:22
wolfspraulgreat - kick it out then09:22
andres-calderonI take the idea to the extreme.09:22
wolfspraulevery chip less is great09:22
wolfspraultotally kick it out09:23
andres-calderonwith the AVR  we  can measure energy in any FPGA tension09:24
andres-calderonIt is a powerful tool, but also think it's a risk.09:24
wolfspraulwe should not make random feature picks like that, I've seen it failing too many times09:25
wolfsprauleither you are lazer sharp and exactly know that this will work, or don't even think about it09:25
wolfspraulno powerful tool, it will be a nightmare09:25
wolfspraulunless you are the global expert in power measurements with AVR MCUs, don't do it09:25
wolfsprauldon't just throw a chip somewhere because you think it can do this or that09:25
wolfspraulseriously, that is the #1 recipe for failure09:26
wolfspraulif you want it, it must be very very deeply thought through and studied09:26
wolfspraulespecially now that you are telling me I am the reason for the AVR, that's even scarier :-)09:27
wolfspraulI hope I'm not the reason, not in any way...09:27
wolfspraulwe want this board to work...09:27
wolfspraulandres-calderon: I will rename the schematics sheets a bit, in a way that will hopefully let schhist follow the history.09:28
wolfspraulso you don't need to do that, just need your OK that I can rename them and clean them up (the names).09:28
andres-calderonwolfspraul:  ok09:28
wolfspraulis that OK?09:28
wolfspraulif you have more datasheets, please add the URLs (to the PDFs) to BOOKSHELF09:29
wolfspraulfor anything from Milkymist, you can take the ones from the m1 bom09:29
andres-calderonI have no problem in redesigning the source. I hear suggestions09:29
wolfsprauldo you see the manufacturer p/n09:29
andres-calderonI have no problem in redesigning the PSU09:29
wolfspraulthat's a URL to the datasheet for every last component on m109:29
wolfspraulas I'm hoping xue reuses as many as possible of those, it's easy to move the URLs to BOOKSHELF09:30
wolfspraulI will also do it step by step, but the goal is to have datasheet urls for 100% of the components on xue09:30
wolfspraulhow about reusing those notebook battery controller psus?09:31
wolfspraulanything good in there?09:31
wolfspraulI haven't looked at this in detail...09:31
wolfspraulI would think they are fairly integrated and thought through, but I don't know exactly what's in the controller with the cells, and what's on the mainboard PCB (in a notebook)09:31
andres-calderon2 or more cells raises the complexity ... more problems. much more risk than the AVR.09:33
kristianpaul[OT] http://ur1.ca/2l4bg09:36
andres-calderonAdam can look for something in TW?09:37
wolfspraulwe can get a whole notebook controller like the ones I sent you09:39
wolfspraulalthough I'm not sure about the interface to them, 6 pins or so09:39
wolfspraulwhere is the charging circuit? don't know09:39
wolfspraulcan Adam look for 'something'? for what exactly?09:40
wolfspraulif the Samsung NAND is optional, then why not put a microSD slot there?09:40
andres-calderonICs for the charger09:40
wolfspraulthat makes more sense as an option, I think09:41
andres-calderonmicroSD is not so good for automotive appliance. poor tolerance under vibrations09:41
wolfspraulgood point although I think that depends on the connector, no?09:42
wolfspraulwhich connector are you referring to?09:42
wolfspraulyou say any connector will always be worse than a soldered solution?09:42
wolfspraulfor an early prototype it sounds like a little early to factor in this kind of requirement09:43
andres-calderonyes, the better choice is a soldered Flash09:43
andres-calderonbut...  if i remove de NAND, we gain  a lot of space for the new PSU09:43
wolfspraulfor the whole PSU, the only idea I have is to reuse notebook battery controllers09:44
wolfspraulI stopped at the point where I sent you those controllers09:44
wolfsprauldon't know exactly what is on them, which ics or circuits09:44
wolfspraulif we make a case, there should be a way to integrate such a controller, especially if there are battery cells anyway09:44
wolfspraulandres-calderon: let's go step by step09:45
wolfspraulcan you go through the ERC warnings and fix them?09:46
wolfspraulwho should do this?09:46
andres-calderonUsing these notebook chargers is an interesting option.09:46
wolfspraulyes, especially if they already integrate all the nasty pieces we need09:47
andres-calderonmost are dumb mistakes, maybe I should modify the kicad's libraries09:48
wolfspraulany bit of cleanup is good, I think there is still potential, but I haven't started looking in detail09:48
wolfspraullike for example there are .bak files committed09:49
andres-calderonmany warning for  unconnected pins.09:49
wolfspraul6 of them in kicad/library09:49
wolfspraulI would prefer to switch the ft2232 to the ~h version, unless we have a strong reason for the ~d version09:50
wolfspraulmaybe price?09:50
wolfspraulbut it could be important for fast development cycles, if people use it to reconfigure the fpga and develop like that09:51
wolfspraulnot sure09:51
wolfspraulof course, I would even prefer the same mechanical header like on m1, so no ft2232 on xue at all09:51
wolfspraulsince we will have the daughterboard already anyway09:51
wolfspraulmakes xue cheaper later09:51
wolfspraulandres-calderon: ah another small question09:52
wolfspraulin docs/sue-docs, you have .png and .svg versions of 2 files09:52
wolfspraulcan we delete the png version? (is the .svg the original)?09:53
andres-calderonof course!09:53
andres-calderonI'm slower than normal ... I'm in the office attending other issues.09:53
wolfspraulin kicad/modules, it seems we are committing the fped files along with their output files?09:53
wolfspraulmaybe werner can give more suggestions but we should probably not commit the output files, and generate them with a Makefile instead09:54
wolfspraulsince I vote for changing the ft2232 from d to h, I actually vote to go back to the same headers as on m109:55
wolfspraulmake xue cheaper, we have the daughterboards already anyway so the normal argument against such daughterboards (cost) doesn't work09:55
wolfspraulok need to log out09:56
andres-calderonwe prefer not  commit  machine generate files... but FPED still exotic.09:56
wolfspraulback tomorrow, 'night09:56
wolfspraulcome on, not exotic :-)09:57
wolfspraula few Makefiles can do wonders09:57
wolfspraulif you can do a few things here and there, that would be great09:57
wolfspraulI'll do more tomorrow as well09:57
wpwrak(psu) without the AVR, also the FANs can go. instant removal of ~15 components ;-)10:34
kristianpaulAVR Mcu?10:37
kristianpaulsorry i dint follow was a long chat10:37
kristianpaulah i see10:38
kristianpaulwow that was scary indeed :)10:42
wpwrakthere go: one MCU with decoupling caps, its JTAG, maybe the whole JTAG circuit, four current sensors, each with sense and output resistor, the firmware for the MCU, plus four regulator enable signals. nice work ;-)10:44
wpwrakmaybe keep the sense resistors (make them 0R - they're currently unspecified), for future measurements10:45
wpwrakkilling the ft2232 would remove 20 components and add one new. whee. soon, the component count will go negative ! ;-)10:54
qi-bot[commit] kyak: QBall: a QT-base breakout game http://qi-hw.com/p/openwrt-packages/e5016ec13:26
qi-bot[commit] David Kühling: more complete _host_ installation of Emacs so we can run ja-dic-cnv etc., http://qi-hw.com/p/openwrt-packages/4a3322816:07
qi-bot[commit] David Kühling: an alternative, smaller, japanese input dictionary for Emacs http://qi-hw.com/p/openwrt-packages/f32d4c416:07
qi-bot[commit] David Kühling: fix installation directory, package depenencies http://qi-hw.com/p/openwrt-packages/cfb4a6716:29
qi-bot[commit] David Kühling: Fix dependencies http://qi-hw.com/p/openwrt-packages/b7c65f316:29
qi-bot[commit] Xiangfu Liu: update the qi-hardware sources mirror address http://qi-hw.com/p/openwrt-xburst/addbbd721:09
wpwrakwolfspraul: nice work with the PSU simplification ;-)21:38
kristianpaulhe, funny now i realize i still having some slight issues with LCM when using SIE shared bus21:39
kristianpaulhmm bus i dint haven in owrt..21:40
kristianpaulany way, i dont need LCM now21:40
kristianpaulwpwrak: you said the other time FFTW is happy with wick kind of data types?21:42
wpwrakcomplex or real. it can take either.21:42
kristianpaulusrp gives you wich kind of data type?21:43
wolfspraulwpwrak: hmm21:44
kristianpaulah nv, 16 bit is okay for now21:44
wpwrakplus a dozen other formats i could probably understand if i spent the next few months reading the fine works of Fourier & Co. :)21:44
wolfspraulmy brain was working so hard I couldn't sleep21:44
wolfspraultoo much Xue processing21:44
wpwrakusrp outputs 16 bit.21:45
wpwrakwolfspraul: ;-))21:45
wolfspraulI need to digest it, still not sure.21:45
wolfspraulI somehow doubt Andres will take a leadership role that will allow us to take this into production.21:45
wolfspraulit's more like dragging a mule up the mountain :-)21:45
wpwrakwolfspraul: andres' responses didn't sound too bad. he seems to know exactly where the problems are :)21:45
wolfspraulyes sure, but the responses only come when pulled21:45
wpwrakyeah, i wonder about that part21:46
wolfspraulshould we wait now and see whether anything happens? say about the ERC errors :-)21:46
wolfspraulhow long?21:46
wolfspraul1 week? 1 month?21:46
wolfsprauluntil I pull him back into the channel :-)21:46
kristianpaulkeep it simple (drop avr) is good, isnt?21:46
wolfsprauland it's really scary that the AVR is there because I made a comment at some point21:46
wpwrakwolfspraul: well, doesn't that sound familiar ;-)21:47
wolfspraulkristianpaul: oh sure, out with that crap. If it is really based on my comment then I have every right to immediately dismiss it as well...21:47
wolfspraulyes but most likely we have very very bad judgment on other areas as well then21:47
wolfspraulso basically the whole design needs to be questioned, every chip, every wire21:47
wolfspraulnot to mention the layout21:47
wpwrakthe AVR has a whole domino chain attached to it. with it, the current sensors go. then JTAG gets a lot simpler, so you could probably share it with MM1.21:47
wolfspraulthe question is who is the designer of the board?21:48
wolfspraulthat is unclear to me now21:48
wolfspraulit seems to be an unholy and strange alliance between Carlos, Andres and me21:48
wpwrakdid you ask them ?21:48
wolfspraulsome people made this 'decision', some people made that 'decision'. Some didn't even know they made a decision :-)21:48
wolfspraulwell we discover it in our review, no?21:48
wolfspraulI start to accept the spi-nand better now21:49
wpwraki mean, "who is the designer"21:49
wpwrakgood :)21:49
wolfspraulof course that also needs to be completely re-evaluated for correctness21:49
wolfspraulevery wire21:49
wpwrakchanging Xue to NOR would seem a bit crazy to me.21:49
wolfspraulso basically the only thing I can trust now is a short 'feature list', and even that is open for discussion I guess21:49
wolfspraulyes, I tend to agree21:49
wolfspraul_but_, I know too little, so if this is me making the decision for spi-nand, sorry I need a few weeks to dig into this21:50
wolfspraulsomeone has to own a decision21:50
wpwraki would expect spi-nand to be the path most traveled. so there ought to be tons of knowledge/tools/etc. for that21:50
wolfspraulyes maybe21:50
wpwrakmaybe we can pick sebastien's brain to check whether this is correct21:50
wolfspraulbut who owns responsibility? me? no! cannot right now, know too little21:50
wolfspraulwait 1 month, then we discuss again21:50
wolfspraulI hate to defocus people who already have great focus.21:50
wolfspraulthen we rather pick the brain of bystanders like emeb|mac :-)21:51
wpwraknaw, just to confirm whether this is right or wrong21:51
wolfspraulhe he21:51
wolfsprauljust pull the guy off the chair in the corner, who tries to hide from dancing...21:51
wolfspraulso I think I will let this settle a bit, I have so many todos21:52
wpwrakdesign by throwing random people (maybe engineers) at it. oh yes, i can see that work ;-21:52
wolfspraulmaybe this is what got us to where it is now? then it can't get worse21:52
wolfspraulfeedback can always be enlightening, even if you ask a taxi driver21:52
wolfspraulmaybe that feedback is the most enlightening sometimes, no?21:52
wolfspraulmaybe I slowly dig into the xue tree and cleanup little by little21:53
wpwrakbefore letting it settle, i think you need to give andres and carlos some to do list. e.g., 1) elect a leader. 2) understand that it's this person who drives things forward, nobody else.21:53
wolfspraulsee whether Andres comes forward21:53
wolfsprauloh we did that maybe 20 times the last 2 months21:53
wpwrak3) all the technical things we already discussed21:53
wpwrak(20 times) urgh :-(21:54
wolfspraulat least if I am the leader I can have some fun. I will just rip out avr, rip out the entire psu and reuse a notebook battery controller.21:54
wolfspraulmaybe I would even rip out the aptina cmos and move the expansion header in a bit21:54
wolfspraulthen we can have the cmos on a daughterboard on top of the expansion header21:54
wpwraknot sure about that battery controller idea. do you mean a simple battery-usb charging controller, or more something like the pcf50633, with a dozen regulators and such ?21:55
wolfspraulI would leave the Samsung NAND unpopulated, maybe I would even replace it with a microSD because even though the automotive/vibration argument is strong, the early boards are all going to developers and they will like a microSD connector much more than an unpopulated NAND footprint21:55
wolfspraulwpwrak: oh wait I show you, you will like this :-)21:55
wpwrak(nand) yeah. even for automotive, there's nothing really preventing you from combining uSD with some good old glue ;-)21:56
wpwrakso that would be 2x uSD then ?21:56
wolfspraulwell I don't want to dismiss the vibration argument21:57
wolfspraulthat sounds like a real thing coming from the field (well, I hope it does)21:57
wolfspraulbut even if that is true, it's a big specialization, the kind of thing we can do later to make money21:57
wolfspraulbut in the first runs? strange21:57
wolfspraulI don't get that21:57
wolfspraulsecond microSD looks much much better for the first x hundred boards21:57
wolfspraulthis is what I mean21:58
kristianpaulwpwrak: are you aware of, when polling data from a register how make sure it is some how sync, you remenber my first aprouch with SiGE was get help from sync, now that i'm implementing a 16bits buffer that will be refres evry sync/4, i just cant poll it when i want21:58
kristianpaulhmm definelly i need a start signal here21:58
wolfsprauloh, I would remove the 2232 as well of course, and use the same headers as on m121:58
wolfspraulwpwrak: do you see those battery controllers?21:59
wpwrak(bat ctrl) hmph. do they come with data sheets ?21:59
wolfspraulI can source them in any quantity (1 to x million) for ca. 6 USD21:59
wolfspraulwpwrak: no of course not. China chaos.21:59
wolfspraulbut I could go to the fab where they make them, find out what we need21:59
wolfspraulessentially they have the well known bq27000 or similar ics on them22:00
wpwrakwolfspraul: okay. do you know exactly what they do then ? :)22:00
wolfspraulno I don't22:00
wolfspraulthey are inside the battery22:00
wpwrakthe bq27000 doesn't do anything you need22:00
wolfspraulthe notebook battery is like this:22:00
wolfspraul1) controller (this thing you see there)22:00
wolfspraul2) cells22:00
wolfspraul3) plastic22:00
wolfspraulsure we need to see where the charging logic is22:00
wpwrakkristianpaul: you could divide SYNC by 4 and output the divided signal ?22:00
wolfspraulit's just an idea22:01
wpwrakwolfspraul: (charging logic) small detail :)22:01
wpwrakwolfspraul: scavenging is good, but you need lots of time and flexibility for it22:01
wolfspraulbut at least my plan is to look at these controllers and see whether they provide anything useful.22:01
kristianpaulwpwrak: yes22:01
wolfspraulyou mostly need knowledge22:01
kristianpaulwpwrak: you meant output in the buffer as well, a space for data other for some "sync" register?22:02
wpwrakwolfspraul: before changing the PSU, i'd like to hear a bit more about the usage case. there's simply a chunk missing. where is it and how is it supposed to work ?22:02
wpwrakwolfspraul: in this context, it's rather ironic that andres worries about automotive use for the NAND ;-)22:02
wolfsprauloh I just assume it's a totally not thought through messs22:03
wolfsprauluntil proven otherwise22:03
wpwrakkristianpaul: i was thinking of a SYNC-out signal that alternates at SYNC/422:03
wolfspraulabout those controllers, they seem to have 6-8 pin connectors going to the notebook mainboard. P+ P- C D T22:04
wpwrakkristianpaul: but what you really need at the moment is just something that's slow enough that you can keep up with the CPU22:04
wpwrakkristianpaul: for the real interface, you probably want DMA. not sure if you want to implement DMA already now.22:04
kristianpaulwpwrak: (slow) thats why i'm arranging data in 16 bits not 4,22:05
kristianpaulwpwrak: no DMA now22:05
wpwrakwolfspraul: you need to get a bunch, try to find the chips, reverse engineer them. or find the manufacturer and squeeze the docs out of them. there must be *something*22:05
wolfspraulany idea what P+ P- C D T could stand for? I should do some googlin22:05
wolfspraulI don't think there is much reverse engineering to do22:06
wpwrakwolfspraul: then you need to develop an understanding of which designs are common and which aren't, so that your supply won't dry up when you're ready to produce22:06
wolfspraulthe chips on those boards are mostly bq.... (from TI I think)22:06
wpwrakwolfspraul: all kinda long-termish22:06
wolfsprauldealing with the batteries22:06
kristianpaulwpwrak: my need now is get the data dump and jump to processing and correlation, also i will send the data to a guy (from CTAE) is waiting it to help me a bit to debug how i'm doing22:06
wpwrakTI is good. they can write ;-)22:06
wolfspraulwe would only need to understand the connector interface22:07
wolfspraulwpwrak: they are all common, because they are all very similar22:07
wolfspraulP+ P- C D T22:07
wolfsprauljust in different randomization on the connector22:07
wpwrakwolfspraul: interface and semantics, i.e., the whole circuit ;-)22:07
wpwrakwolfspraul: i'm not sure they really give you so much you need. there may be little else but a charger chip plus some fancy diagnostics. you don't care about the latter. charging circuits aren't rocket science.22:08
wpwrakwolfspraul: also, please be careful not to confuse regulators with the charging circuit. i think these little boards only have the latter.22:09
wolfspraulI don't confuse them22:09
wolfspraulI'm just saying we can source this 6 USD thing and have super flexibility on the battery side22:09
wolfspraulone problem less to worry about22:09
wpwrakwolfspraul: and they probably operate around 14 V or such, which may not be the most convenient voltage for Xue. but again, we need the full PSU story for this.22:10
wolfsprauland whatever case we build, fitting this controller in in a minor additional task, especially if there are batteries anyway22:10
wolfspraulso if we have any plans to reuse such controllers, we should understand them first before thinking about the PSU on Xue22:10
wpwrakkristianpaul: so i guess 16 bit with a slow sync out should be okay ?22:10
wpwrakkristianpaul: all you need now is to receive a few (thousands, millions, whatever) samples. no processing. right ?22:11
kristianpaulwpwrak: right22:11
kristianpaulwpwrak: (slow sync) yes, i'll let my brain analize it while sleeping, but i think it should work22:12
kristianpaulshift registers is amazing usefull :)22:12
wpwrakwolfspraul: perhaps buya few, take a high-res picture of the top. that should make it possible to figure out roughly what they do.22:12
wpwrakkristianpaul: why not ? do you expect to be too slow/irregular ?22:13
kristianpaulwpwrak: i dont see relation betweeen slow and irregulare so i dont think si22:13
wpwrakkristianpaul: (irregular) i mean occasional long delays, e.g, because there's an interrupt or such22:14
wolfspraulI already bought a few and sent to Andres, but not much happened22:15
wolfspraulI should have kept them or sent elsewhere :-)22:15
wpwrakkristianpaul:  you could also add an acknowledgement logic. after reading, you toggle the ACK signal. if ACK changes twice without SYNCout changing, you have an underrun. of SYNCout changes twice without ACK changing, you have an overrun.22:16
wolfspraulone thing I like about the idea is that notebook batteries, charging, regulator circuits are very robust. You can rip the battery out at any time, as long as the external plug is in - no problem.22:16
wolfspraulyou can plug in or out the dc jack at any time.22:16
wpwrakwolfspraul: have you made high-res pictures ? ;-)22:16
wolfspraulthe controller will take care of li-ion recharge cycles, try to minimize cell wear22:16
wolfspraulso why not learn more about this and reuse some of it...22:16
wolfspraulwpwrak: no I need to redo with another leader in mind? :-)22:17
wpwraksure. but then again, there are many chips that do just this for you. no need to design around a battery circuit that may not really fit in a number of other regards.22:17
wpwrakwolfspraul: redo with the community in mind ;-)22:17
wolfspraulyes but those chips need to be chosen, then they need a support circuit22:18
kristianpaulwpwrak: i was thinking add a counter per every 16bits22:18
wolfsprauland when you are done you are back to what you have in these controllers already, big surprise, because this is one giant standardized market (notebook controllers)22:18
kristianpaulwell i have more ideas now, but i'm off bed now22:18
wolfspraulso it's about learning first, it doesn't matter whether you start learning by reading this or that IC datasheet, or looking at such a controller and digging in22:18
wolfspraulthe result should be the same22:18
wpwrakwolfspraul: but they may still not be a nice fit. e.g., not sure if they work if all you have is USB power. so you need a notebook power supply as well. etc.22:19
wolfspraulnotebook power supply as in 16V or more?22:19
wolfspraulwhat is your concern there?22:19
wpwraknot handy if you want to run with USB power :)22:19
wolfspraulsure but we know too little22:20
wolfspraulthe battery cells typically have around 4V?22:20
wpwrakmy guess would be that these controller boards give you a bit of what you need plus a ton of constraints that only get in the way22:20
wpwrak~3.7 V, no ?22:21
wolfspraulmaybe those controllers are mostly about managing multiple cells and 'smart' charge cycles22:22
wolfspraulso the 6 pins just display themselves to the mainboard as 1 battery22:23
wolfspraulc = coulomb counter?22:23
wolfsprault = temperature22:23
wolfspraul(total guess :-))22:23
wpwrakC = control ? :)22:24
wpwrakyou really need to get a picture. the rest can probably be found in the reference designs.22:24
wpwrakregarding the "smart" cycles, there's a TON of Li-charger chips out there.22:25
wolfspraulhow do you like the idea of moving the image sensor to a daughterboard (to be seated on the expansion header that's already there)?22:25
wpwrakdoesn't sound crazy to me22:26
wpwrakwould you also move the sensor PSU ? (yet another ~4 regulators)22:26
wpwrak5 even. also with many underspecified resistors ;-)22:26
wolfspraul4 regulators for the sensor?22:27
wpwraknaturally, under-specified regulators as well. different from the "main" regulators, too. i'm sure it all makes sense somewhere ;-)22:28
wolfspraulthe sensor needs another psu?22:28
wpwrakit's five of them. 4 x 2.8 V, 1 x 1.8 V22:28
wpwraksomething tells me that three of these 2.8 V regulators probably want to be beads ;-)22:29
wolfspraulare we trying to fix a few weaknesses, or are we trying to build a palace out of a rubble?22:29
wpwrakas i said, i'm kinda curious about the whole PSU story22:29
wpwrakit looks simply like an unfinished construction site to me. unfinished by andres. and then for some reason carlos barged ahead and tried to push you into producing.22:30
wpwrakso either carlos had too much of columbia's finest export or there's a communication problem between him and andres.22:31
wpwrak(or there's an even weirder explanation. space aliens trying to prevent mankind from developing Xue technology or such ;-)22:32
wpwrakit would also be good to know what exactly the external constraints of Xue are. did anyone promise some demo/product/whatever with some specific date ?22:34
wpwrakthat would explain panicky attempts to rush things22:34
wpwrakit could also be that they've lost interest and are just looking for a way to make you to be the one who pulls the plug22:43
wpwraki guess the answers we're looking for are much more psychological than technical ;-)22:44
qi-bot[commit] Werner Almesberger: cameo: added KiCad Gerber input and path merging http://qi-hw.com/p/cae-tools/8999b3022:47
qi-bot[commit] Werner Almesberger: cameo: adding toolpath adaptation language (in progress) http://qi-hw.com/p/cae-tools/f80a01a22:47
qi-bot[commit] Werner Almesberger: cameo: changed dog_bone from global variable to argument http://qi-hw.com/p/cae-tools/1f63ef622:47
qi-bot[commit] Werner Almesberger: cameo/lang.y (align): completed alignment function http://qi-hw.com/p/cae-tools/c8b62c222:47
qi-bot[commit] Werner Almesberger: cameo: moved tool compensation from cameo.c to ops.c http://qi-hw.com/p/cae-tools/2bf455922:47
qi-bot[commit] Werner Almesberger: cameo: call tool compensation from script http://qi-hw.com/p/cae-tools/86c27db22:47
qi-bot[commit] Werner Almesberger: cameo: added invocation with an optional script http://qi-hw.com/p/cae-tools/fe50add22:47
qi-bot[commit] Werner Almesberger: cameo: various scanner and parser fixes http://qi-hw.com/p/cae-tools/ddcf51922:47
qi-bot[commit] Werner Almesberger: cameo: documented X/Y translation commands, some small improvements http://qi-hw.com/p/cae-tools/f36f70422:47
qi-bot[commit] Werner Almesberger: cameo: split numbers into dimensions and "bare" numbers http://qi-hw.com/p/cae-tools/68d5eff22:47
qi-bot[commit] Werner Almesberger: cameo: cleaned up and documented the tool compensation http://qi-hw.com/p/cae-tools/3ae3d6c22:47
qi-bot[commit] Werner Almesberger: cameo: fixed processing of omitted file names, documented file name usage http://qi-hw.com/p/cae-tools/26dc02e22:47
wpwrakphew. another night and i'm there. but dinner first ...22:48
andres-calderonHi wolfspraul23:34
wolfspraulah hi!23:34
wolfspraulWerner is just having dinner23:34
wolfspraulhe will be back in a bit23:34
wolfspraulandres-calderon: my brain was thinking so much about Xue last night that I could not sleep! :-)23:35
wolfspraulI liked it though :-)23:35
wolfspraulI had one idea I wanted to ask you: What do you think about moving the image sensor to a daughterboard, which is to be seated on the expansion header?23:35
andres-calderonHe! That was my proposal from the start...... I'm trying to understand, I guess in an open project chaos is normal.23:37
andres-calderonOnly one board was what you suggested.23:39
wolfspraulme again? wow23:39
wolfspraulwhat other things did I suggest or decide?23:39
wolfspraulif you like a sensor daughterboard, then let's do it. at least I have no technical reason against it.23:39
andres-calderonI like the flexibility of elphel camera23:40
andres-calderon2 boards may be improve the design of the case.23:41
wolfspraulI like it because we can much quicker try different sensors23:41
wolfsprauland also other daughterboards23:41
wolfspraulthe only important thing will be to be very smart in which fpga wires we route to the connector23:42
wolfspraulwe already talked about lvds before23:42
andres-calderoni agree23:42
wolfspraulthe smarter we are on the connector, the more flexibility we have later23:42
wolfspraulis the design of the sensor PSU finished?23:43
andres-calderonis only one copy of the reference design.... (unchecked)23:44
andres-calderona copy from the Aptina design23:45
wolfspraulandres-calderon: ok, another question first. do you remember the notebook battery controllers I sent you once.23:50
andres-calderonAptina CIS and PSU can be moved to a second board easy...23:50
wolfsprauldid you do anything with them? can we use them to hookup battery cells to the Xue board?23:50
wolfspraulwell I like that, barring other feedback that would make me change my mind... :-)23:50
andres-calderonof course...   I review  some those chips. Almost all exotic to me.23:51
andres-calderonbut the designs are beautiful, very simple.23:52
wolfsprauldo you see any use in conjunction with Xue?23:52
wolfspraulsorry difficult english: do you see any use together with Xue?23:53
andres-calderonalmost a half of component  from the Ti and Linear reference designs23:53
wolfspraulI can buy those controllers easily, for about 6 USD23:54
wolfspraulfrom 1 to any amount23:54
andres-calderonI intended to use only a cell Xue.23:54
andres-calderonbut.... 6 USD!23:54
wolfsprauleven buy 1, no problem23:55
wpwrakalmost back :)23:55
andres-calderonI think we can use them. If we can solve the problem of the connector.23:56
wolfspraulwhat is on those battery controller boards?23:57
wolfspraulthe connectors seem to have pins like P+ P- C D T23:57
wolfsprauldo you know what they mean?23:57
andres-calderonplease can You share  the  link to the photo of the chargers23:58
--- Wed Dec 15 201000:00

Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!