2010-12-14 00:00 also, is the M25P32 U8 ? the schematics say X25X64MB 2010-12-14 00:01 U8 also uses different pin names. similar if not identical functions, though. perhaps they started with a different chip and then changed 2010-12-14 00:03 I get some '??' when I open DBG_PRG.sch 2010-12-14 00:04 [commit] Wolfgang Spraul: added ft2232h/c datasheets to BOOKSHELF http://qi-hw.com/p/xue/5642fde 2010-12-14 00:05 wpwrak: for spi vs. nor flash, any thoughts? 2010-12-14 00:05 what are the pros/cons 2010-12-14 00:06 for sure I would think the spi-flash will create substantial work on the software side, compared to just running Milkymist 2010-12-14 00:06 but that's just one factor 2010-12-14 00:07 they're very different. i would assume that they even have entirely different roles in the system. 2010-12-14 00:08 the spi nand should be what the fpga boots from. not sure what the NOR does. 2010-12-14 00:08 same 2010-12-14 00:08 the fpga boots from it 2010-12-14 00:08 afaik 2010-12-14 00:08 (DBG_PRG.sch) did you  eeschema DBG_PRG.sch ? 2010-12-14 00:08 yes 2010-12-14 00:08 you have to open the top-level sheet 2010-12-14 00:09 otherwise, kicad won't find the profile 2010-12-14 00:09 hint: add a makefile and always "make sch" :) 2010-12-14 00:10 hint 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 around 2010-12-14 00:10 same goes for "brd" (or similar - for pcbnew) 2010-12-14 00:11 i was thinking of saving the makefile lecture for andres for later, but if you're already cleaning things up ... :) 2010-12-14 00:13 seems most of the links in BOOKSHELF are just quickly googled web pages 2010-12-14 00:13 nice 2010-12-14 00:13 that's the kind of dedication and quality we need :-) 2010-12-14 00:13 this will be fun :-) 2010-12-14 00:14 ;-) 2010-12-14 00:14 well, the turn-around times give some hint of the level of dedication :) 2010-12-14 00:15 yes but then I may be better off focusing on Milkymist Two 2010-12-14 00:15 but let's not jump to conclusions, I do believe Xue provides some value 2010-12-14 00:15 we just need to beat it into shape 2010-12-14 00:15 a "baby m1" would definitely be good to have 2010-12-14 00:16 sure, starting from xue and cleaning it up is probably easier than starting from m1 and cutting it down 2010-12-14 00:16 andres mentioned a while ago that he should have more time in december. so there's hope. 2010-12-14 00:16 there is a NAND chip on Xue? wondering what it is used for 2010-12-14 00:17 do you have a link to the MM1 schematics ? 2010-12-14 00:17 (cutting down) and translating to kicad :) 2010-12-14 00:30 wpwrak: http://www.milkymist.org/mmone/rc2_schematics.pdf 2010-12-14 00:31 thanks ! 2010-12-14 00:45 hmm, 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. 2010-12-14 00:47 so m1 has nor only 2010-12-14 00:47 xue has spi-flash plus nand 2010-12-14 00:48 why does xue need the nand at all? 2010-12-14 00:48 spi flash is what i know as the "standard' process. but perhaps my information is already outdated. 2010-12-14 00:48 we have a microSD slot 2010-12-14 00:48 and then, why spi-flash instead of reusing m1's nor? 2010-12-14 00:48 a good question for andres :) 2010-12-14 00:49 maybe he envisions to use uSD for really removable media 2010-12-14 01:07 a quick look at ft2232c vs. ft2232h tells me that c = 3rd generation, h = 5th generation 2010-12-14 01:07 it'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 xue 2010-12-14 01:08 but perhaps the other way around 2010-12-14 01:09 yes but one of the important features is flashing speed 2010-12-14 01:10 aside from the software compatibility, which remains a big question 2010-12-14 01:10 what i mean is that you could perhaps use the ~h instead of the ~c 2010-12-14 01:10 it may be bigger 2010-12-14 01:10 let me see 2010-12-14 01:12 the c is a 48-pin lqfp, pins pointing out 2010-12-14 01:12 the h is a 64-pin qfn 2010-12-14 01:12 hmm. ~c or ~d ? 2010-12-14 01:12 c = 9x9mm including leads 2010-12-14 01:12 you can do 'dsv ft2232c' and 'dsv ft2232h' in xue 2010-12-14 01:13 I think xue uses c 2010-12-14 01:13 basically the same size 2010-12-14 01:14 yes h also 9x9 2010-12-14 01:15 they made it back with the qfn 2010-12-14 01:15 so what is the reason that xue uses c instead of h? 2010-12-14 01:15 interesting. the ~C seems to be quite obsolete already. even at OM we used the ~D. digi-key don't have the ~C. 2010-12-14 01:15 probably found some old design that used it ? :) 2010-12-14 01:29 wpwrak: do you think the spi-nand is what the fpga boots from/configures itself from? 2010-12-14 01:29 yes 2010-12-14 01:30 i think it's spi-nand to boot the fpga, nand-nand to boot the cpu (and rootfs etc.), uSD for removable storage 2010-12-14 01:33 http://www.numonyx.com/Documents/Datasheets/319942_J3-65nm_256-Mbit_MLC%20DS.pdf 2010-12-14 01:33 that's the one on m1 2010-12-14 01:34 as JS28F256J3F105 2010-12-14 01:35 USD 12 per chip, 576 minimum order 2010-12-14 01:35 (at digi-key) 2010-12-14 01:35 good thing digi-key is not the only distributor :-) 2010-12-14 01:35 the others probably aren't much cheaper :) 2010-12-14 01:35 I think we pay 10.50 USD 2010-12-14 01:36 it has 256mbit, the one on xue only 32mbit. I'm wondering whether there is any consequence. 2010-12-14 01:36 well there are probably many differences 2010-12-14 01:36 okay, 15% less 2010-12-14 01:37 probably different memory demands for the system 2010-12-14 01:38 the spi-nand is about USD 1.2 at volume 2010-12-14 01:39 so there must be a good reason for the nor. but what is it? 2010-12-14 01:39 not sure about the other nand chip. too under-specified in the schematics. 2010-12-14 01:39 that's a normal Samsung 2GB, same as in Ben NanoNote 2010-12-14 01:40 I mean I just put that in there now :-) (in BOOKSHELF) 2010-12-14 01:40 I would argue for removing it. 2010-12-14 01:40 nand is evil. 2010-12-14 01:40 :-) 2010-12-14 01:40 NOR 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. 2010-12-14 01:41 I think we first need to understand the differences between the NOR on m1 and the spi-nand on xue 2010-12-14 01:41 the Samsung NAND on Xue is just for storage I would think 2010-12-14 01:41 disadvantages are that you have more signals, that it's quite a bit more expensive, and also not as common as NAND. 2010-12-14 01:41 I see a Tiny AVR in BOOKSHELF, what is that used for? 2010-12-14 01:41 lemme see ... 2010-12-14 01:43 oh, I have a theory on how the pdf.png got in there 2010-12-14 01:43 right click on some PDF links, and it gives you "copy image location" and "copy link location" 2010-12-14 01:43 :-) 2010-12-14 01:43 hmm, controls the power supplies 2010-12-14 01:43 yeah, of course :) 2010-12-14 01:44 controls the power supplies? hmm 2010-12-14 01:44 then put on the blindfold, paste, and make sure NOT to verify whether what you did works :) 2010-12-14 01:44 is that control necessary? 2010-12-14 01:45 btw, the ft2232 is a ~D in the schematics 2010-12-14 01:45 I think it's both :-) 2010-12-14 01:45 is ther emore than one ? 2010-12-14 01:45 grep for 2232 in xue-rnc 2010-12-14 01:46 in this kind of projects, my first tool of choice is always good old grep 2010-12-14 01:46 I count 19 ~c and 4 ~d 2010-12-14 01:46 :-) 2010-12-14 01:47 so I cannot tell you fast and for sure which one was 'meant' 2010-12-14 01:47 maybe you can? 2010-12-14 01:47 ah, the ~C is the symbol. ~D is the value. that's okay. as i said, i think ~D and ~C are pin-compatible. 2010-12-14 01:47 should I change the datasheet link to ~d? 2010-12-14 01:48 | grep -v LIBS:  # :) 2010-12-14 01:48 yes 2010-12-14 01:48 why is the symbol ~c ? 2010-12-14 01:48 because someone drew it for the ~C ? 2010-12-14 01:49 you mean a trace of ancient copy/paste history 2010-12-14 01:49 fascinating! 2010-12-14 01:49 or maybe someone drew it for the ~D but named it after the original chip. 2010-12-14 01:50 naw, that's pretty standard procedure. raises the question where that symbol comes from. 2010-12-14 01:50 ok, since we will probably change this to the ~h it doesn't matter much 2010-12-14 01:51 (jtag) so the mm1 has a pluggable jtag while the xue has it on board. okay, that explains the difference 2010-12-14 01:51 do you think the avr is necessary for power control? 2010-12-14 01:51 lemme see ... 2010-12-14 01:51 Sebastien decided to leave the ftdi chip off because in the long run few people will need it and it's an expensive IC 2010-12-14 01:52 it's a close call but I respect the focus 2010-12-14 01:52 of course we could have put the 'debug board' (ftdi) onboard the m1 as well 2010-12-14 01:52 but even if we believe we want to have it onboard for xue, why not use ~h then as well? 2010-12-14 01:53 since you need the ftdi to fully "unbrick", i think it's not a bad idea to have it permanently there 2010-12-14 01:54 for m1 when you press the middle button it will boot from a rescue partition in nor, I believe 2010-12-14 01:54 actually, if i understand the architecture right, it would make even more sense in the MM1, because it has only one flash 2010-12-14 01:54 the value of the jtag-serial will go down over time 2010-12-14 01:54 (rescue) ah .. let's see ... 2010-12-14 01:55 it may make sense for real hardware hacking 2010-12-14 01:55 but in those cases, an external 'jtag key' is very common and easily available anyway 2010-12-14 01:55 it's the old discussion we always had 2010-12-14 01:55 should 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. 2010-12-14 01:56 anyway I won't get hung up on that 2010-12-14 01:56 if it should be onboard on Xue, so be it 2010-12-14 01:56 but at least we can watch 100% software compatibility, and electrical design compatibility with m1+jtag-serial board 2010-12-14 01:57 oh, wow. MM1 has a separate addess bus for flash 2010-12-14 01:58 and a separate data bus as well 2010-12-14 01:58 well, if you have the I/Os and nothing else to do with them ... ;-) 2010-12-14 01:59 not sure if the xue has so many I/Os to spare 2010-12-14 01:59 that's 40 of them 2010-12-14 01:59 what else would it have been used for? 2010-12-14 02:00 xue is missing 5-10 peripherals from m1 2010-12-14 02:00 you say the additional image sensor takes up more ios than the removed midi, dmx, video-in, vga, etc. 2010-12-14 02:00 isn't the FPGA a smaller version ? 2010-12-14 02:00 not that I know 2010-12-14 02:02 man, I can't believe that we have a proper PDF url for every single item on the Milkymist One BOM! 2010-12-14 02:02 http://en.qi-hardware.com/wiki/Milkymist_One_RC2_BOM 2010-12-14 02:02 unbelievable!!! 2010-12-14 02:03 darn amateurs. can't even get the professional untidiness right ! (-:C 2010-12-14 02:05 15 unused I/Os on expantion.sch ... 2010-12-14 02:06 yup. FPGA looks the same. i guess i confused this with SIE. 2010-12-14 02:08 so back to the AVR - you think it's necessary? 2010-12-14 02:08 that was the original question 2010-12-14 02:09 hmm, nice. only 178 ERC error in Xue. 2010-12-14 02:09 in the schematics? 2010-12-14 02:09 the AVR may be necessary to let the system power itself up and down. 2010-12-14 02:09 yup 2010-12-14 02:09 hmm 2010-12-14 02:09 how is this done on m1 then? power-up and down... 2010-12-14 02:10 xilinx says in their marketing that the power-up sequence for the fpga is very flexible/robust 2010-12-14 02:10 you can fix something like 20-30 of them just by putting that little x on the unused pins on the FPGA port 0 sheet ;-) 2010-12-14 02:11 i think MM1 just runs at full power when connected 2010-12-14 02:11 the regulators are always enabled. of course, you can draw more or less after that. 2010-12-14 02:13 ok I see the 178 ERC errors 2010-12-14 02:13 adding to my todo list :-) 2010-12-14 02:13 not sure what this means in practical terms. if all the subsystems can be set to draw almost nothing, then the regulators won't either. 2010-12-14 02:13 yes 2010-12-14 02:13 maybe the main reason for the AVR is copy/paste leftover? 2010-12-14 02:13 but it may just be that MM1 isn't optimized for low power 2010-12-14 02:14 naw, i wouldn't dismiss the AVR so quickly 2010-12-14 02:14 not dismissing, just trying to find the reasons 2010-12-14 02:15 interesting. it also controls the enable line of the regulator that powers it. 2010-12-14 02:16 there's a pull-up, so it's probaby safe 2010-12-14 02:16 [commit] Wolfgang Spraul: better PDF links in BOOKSHELF http://qi-hw.com/p/xue/d5e48e6 2010-12-14 02:17 of course, lots of resistors with unknown values all over the PSU 2010-12-14 02:18 needs to stay in style 2010-12-14 02:18 sigh. it does get a little boring after a while ... 2010-12-14 02:19 there are two paths - cleanup xue or start over from m1 2010-12-14 02:19 I think I want to spend some time in xue first 2010-12-14 02:21 what do you suggest for the names of the schematics pages? 2010-12-14 02:21 first there seems to be a filename, and a 'text string' inside KiCad 2010-12-14 02:21 should we try to keep them the same? 2010-12-14 02:21 nice. you added the FAN4010. just what i needed :) 2010-12-14 02:22 for spaces, I guess we should also go with either '-' or '_' 2010-12-14 02:22 right now it seems to use '_' in the filenames 2010-12-14 02:22 (name vs. string) ah, now you'll mess up the schematic history :) 2010-12-14 02:23 well both file names and strings are so messy that we probably don't want to leave them like that 2010-12-14 02:23 if schhist cannot follow anymore that's bad of course 2010-12-14 02:23 so what do you propose? 2010-12-14 02:23 the filenames are a total mess already now, lowercase, uppercase, typos, everything 2010-12-14 02:24 the strings are slightly better, aside from whitespace inconsistencies, typos, and case inconsistencies 2010-12-14 02:24 :-) 2010-12-14 02:25 intersting. each regulator has a current sensor. they go to the AVR. some of them go to ADC pins. the others .. hmm ... checking ... 2010-12-14 02:26 .. hehe, don't ;-) 2010-12-14 02:26 oh the sweet memories ;-) 2010-12-14 02:27 yeah, the sheet names are a mess. dunno. i tend to keep them terse and the same 2010-12-14 02:27 spaces as? 2010-12-14 02:27 '_' or '-'? 2010-12-14 02:28 strings and filenames 'should' be the same? 2010-12-14 02:28 or not 2010-12-14 02:28 and how can we fix it in Xue so that schhist won't break? 2010-12-14 02:28 as for your AVR comments and unconnected pins - what does it mean? 2010-12-14 02:29 if you fix it, it'll break schhist in one way or another. that is, you get sheets that "jump". 2010-12-14 02:29 i can try to add some more heuristic to navigate around that 2010-12-14 02:30 hmm 2010-12-14 02:30 ok let's go through one by one 2010-12-14 02:30 space: '-' or '_'? 2010-12-14 02:30 in ben-wpan you have one '-' 2010-12-14 02:31 so should we go with '-'? 2010-12-14 02:31 btw, we already have a case where it breaks, FPGA port 1/3 2010-12-14 02:32 - usually looks better in file names. but i do either, depending on daily mood :) 2010-12-14 02:32 alright, '-' for now 2010-12-14 02:32 how about the names (strings) of schematics pages? 2010-12-14 02:33 usually follow the filename? 2010-12-14 02:34 that's what i do. the more descriptive names may be useful in some cases ... but then, maybe not. 2010-12-14 02:34 the only places where they really add something are the fpga sheets 2010-12-14 02:35 e.g., "FPGA Port 1 Port 3 (DDR, USB)" 2010-12-14 02:36 that's for the string? 2010-12-14 02:37 so you don't want the '/' in the strong 2010-12-14 02:37 string 2010-12-14 02:37 but '(' and ')' are OK? 2010-12-14 02:37 about the avr: it seems taht, once the resistors have received some values, you could run the board even without the avr 2010-12-14 02:37 i think there are no/not many restrictions for what goes into the string 2010-12-14 02:38 (avr) i don't know what current consumption to expect, though 2010-12-14 02:38 yes 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 '/' 2010-12-14 02:38 (avr) all the current sensors suggest that someone else is curious about this, too ;-) 2010-12-14 02:39 without the AVR we should save some current for the AVR :-) 2010-12-14 02:39 ah, that was just an abbreviation 2010-12-14 02:39 if you pull the avr, you can also pull the FANs ;-) 2010-12-14 02:40 maybe this is meant to support batteries? 2010-12-14 02:40 but again, not sure what this does to idle/standby power consumption 2010-12-14 02:40 is xue supposed to be low power ? 2010-12-14 02:40 sure 2010-12-14 02:40 but what does 'low power' mean, i'd say first it's about being smart & efficient 2010-12-14 02:40 which is driven by the usecase 2010-12-14 02:41 ah yes, says "+BAT" :) 2010-12-14 02:41 Xilinx says the spartan-6 is 'low power' 2010-12-14 02:41 it all depends on perspective, needs, use case 2010-12-14 02:42 hmm, all the sensor regulators are aways on. interesting. 2010-12-14 02:42 since 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 mobile 2010-12-14 02:42 but then you first need such a conflicting pair to look at - power vs. performance 2010-12-14 02:43 now .. battery where art thou ? 2010-12-14 02:43 how can I cleanup the schematics names without breaking schhist? 2010-12-14 02:43 should I start with filenames? 2010-12-14 02:43 or strings? 2010-12-14 02:44 i'd just go ahead and make whatever change you want. we can always fix schhist later 2010-12-14 02:45 hmm 2010-12-14 02:45 if I only change filename (and not string), and then commit, that should make it easier to track, right? 2010-12-14 02:45 so maybe I change filename, and string, in separate commits? 2010-12-14 02:46 that probably makes things easier, yes 2010-12-14 02:46 schhist tracks both but gives one priority over the other. don't remember which without looking. 2010-12-14 02:47 in any case, changing both in some way will break the existing mechanism somewhere. 2010-12-14 02:50 wpwrak: but maybe if I change them in separate commits schhist can recover? 2010-12-14 02:50 I'll try that... 2010-12-14 02:50 there is a low-power DDR datasheet checked into the xue git, I'll delete it 2010-12-14 02:50 the one I think Xue is using is the non-low-power one from m1 2010-12-14 02:50 now that we have dsv .. :) 2010-12-14 02:52 I can find the url for that one and add it 2010-12-14 02:56 guys 2010-12-14 02:56 i was wondering 2010-12-14 02:57 is it possible to get to know programmatically the power consumption of USB device inserted into PC? 2010-12-14 02:58 the 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. 2010-12-14 02:58 of course, to know if from PC side - because the USB device could be anything 2010-12-14 02:58 if your pc is connected to some current measuring device which is in turn connected to the USB cable ... 2010-12-14 02:58 of 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 distorted 2010-12-14 02:59 (notebook battery) good idea ! 2010-12-14 02:59 hm-hm 2010-12-14 03:00 i thought there is an easy way to do it and this information is avaialble from usb driver 2010-12-14 03:01 i thought that because on Windows, there is some indication in current consumption in USB root device properties.. but it seems inadequate 2010-12-14 03:02 when i insert flash driver, it shows 100mA 2010-12-14 03:03 when i insert some PCB, it shows 448mA 2010-12-14 03:03 no matter what 2010-12-14 03:03 it looks like a device reports something to Windows 2010-12-14 03:04 something like its peak consumptinos 2010-12-14 03:05 good point there may be something in the usb protocol 2010-12-14 03:05 wolfspraul: ah, another little riddle: all the regulators on sensor_psu.sch are TPS793XX :) 2010-12-14 03:05 but unless the device on the other side really measures, the value is meaningless 2010-12-14 03:06 because your notebook won't measure, unless it's a very special-built device 2010-12-14 03:06 wpwrak: you mean they are under-specified? 2010-12-14 03:07 yup 2010-12-14 03:07 that is, you can figure ou the right part number by looking what voltage they're supposed to deliver. so it's an easy riddle. 2010-12-14 03:08 [commit] David Kühling: added emacs startup file for configuring stuff specific to the openwrt package http://qi-hw.com/p/openwrt-packages/f00fc23 2010-12-14 03:08 [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/a670379 2010-12-14 03:08 the unspecified resistors they connect to are a little harder. 2010-12-14 03:09 [commit] David Kühling: typo http://qi-hw.com/p/openwrt-packages/31a24f8 2010-12-14 03:10 i'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. 2010-12-14 03:11 [commit] David Kühling: another type http://qi-hw.com/p/openwrt-packages/7235d39 2010-12-14 03:19 lekernel: hi good morning! 2010-12-14 03:19 the bearstech package is already on the delivery truck - awesome! 2010-12-14 03:23 [commit] Wolfgang Spraul: removed lpddr datasheet copy, linked from BOOKSHELF http://qi-hw.com/p/xue/3cdb0ec 2010-12-14 03:27 lekernel: we had a question for you earlier. We were wondering why you chose the NOR flash for Milkymist One 2010-12-14 03:27 for example in comparison to this spi-nand: http://www.numonyx.com/Documents/Datasheets/M25P32.pdf 2010-12-14 03:32 lekernel: also, is it correct that the FPGA is initialized from NOR ? or did i overlook some spi-thingy somewhere ? 2010-12-14 03:34 wolfspraul: 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 ;-) 2010-12-14 03:34 is there a DC jack? 2010-12-14 03:35 of course, there's no battery charging logic ... 2010-12-14 03:36 (dc jack) nyet 2010-12-14 03:37 ah yes, so you just solder a wire to that fat trace and the board is powered 2010-12-14 03:37 piece of cake 2010-12-14 03:37 scratch off the solder mask and you're there. the trace is quite wide, so it's easy :) 2010-12-14 03:39 about 1 mm wide. that's pretty big. 2010-12-14 03:41 wpwrak: good thing that this is an open hardware project 2010-12-14 03:41 so it's easy to locate the trace 2010-12-14 03:45 [commit] Xiangfu Liu: config.all_packages: add all packages config file base on minial http://qi-hw.com/p/openwrt-xburst/ab11437 2010-12-14 03:50 the 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 :) 2010-12-14 03:53 wolfspraul: plenty of I/O available, easier to work with, supported by xilinx, execute in place possible (for the BIOS) 2010-12-14 03:53 yes, the FPGA is loaded from the NOR 2010-12-14 03:54 that's the only flash memory in the system 2010-12-14 03:54 wpwrak: 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 much 2010-12-14 03:55 but the standby bitstream does put the FPGA and some peripherals in low-power mode 2010-12-14 03:56 btw Xué has FANS?!? 2010-12-14 03:56 even with the lack of low power optimization, the MM1 barely gets hot 2010-12-14 03:57 lekernel: elaborate more on your question whether Xue has fans? :-) 2010-12-14 03:57 okay, thanks. hadn't seen FPGAs load their bitstream from NOR. (of course, i'm an FPGA noob :) 2010-12-14 03:57 (fans) nono .. that's a chip with part number FANxxx 2010-12-14 03:57 fans as in devices shuffling air, or fans as in crazy folks? 2010-12-14 03:57 :-) 2010-12-14 03:57 devices shuffling air :) 2010-12-14 03:57 it's just amusingly confusing ;-) 2010-12-14 03:58 particularly since the chip has very few pins. (it's a current sensor) 2010-12-14 03:59 wpwrak: did we have any other questions for lekernel ? 2010-12-14 04:00 if Milkymist One has a NOR flash, and works fine, I wouldn't know why Xue shouldn't keep the same chip 2010-12-14 04:01 is cost an issue ? 2010-12-14 04:01 lekernel: ah, another one. Xue uses a ft2232d instead of the ft2232h on our jtag-serial board for m1 2010-12-14 04:01 i'm also not sure if there are enough spare pins 2010-12-14 04:01 one of the things we liked about the 'h' was the high speed 2010-12-14 04:02 do you know anything about the ~d? 2010-12-14 04:02 no 2010-12-14 04:02 wpwrak: there must be enough pins, how could it not if xue has so much _LESS_ than m1 2010-12-14 04:02 I just picked the fastest chip 2010-12-14 04:02 I don't even start counting, I cannot imagine where all those pins should have gone. 2010-12-14 04:03 also depends on the voltage domain 2010-12-14 04:03 port 3 has a lot of spares. it's in 2.5 V. i guess the NOR is 3.3 V ? 2010-12-14 04:03 iirc there is 2.5V NOR as well 2010-12-14 04:04 but if you want the FPGA to configure from NOR, you can't choose the pinout 2010-12-14 04:04 the idea of xue was to take m1, remove lots of things, add image sensor 2010-12-14 04:04 btw the Spartan-6 has some pretty crazy constraints wrt the placement of clock pins and the data they relate to 2010-12-14 04:04 that probably was not the process that was actually followed there :-) 2010-12-14 04:05 (nor pins) ahh, yes, makes sense. let's see ... 2010-12-14 04:05 also, some I/O pins have special functions during configuration 2010-12-14 04:05 lekernel: did you see above? bearstech boards on delivery truck - good 2010-12-14 04:05 so the FPGA pinout is something to be checked carefully 2010-12-14 04:06 wolfspraul: yeah, good :) 2010-12-14 04:06 I'm still failing to understand what we need to check if Xue reuses m1 2010-12-14 04:06 lekernel: wpwrak and I are having some fun taking Xue apart. need to understand it a bit... 2010-12-14 04:06 yeah, seeing the backlog 2010-12-14 04:07 have you seen any new case work from roh? 2010-12-14 04:07 can't wait to see new pics... 2010-12-14 04:08 a little bit 2010-12-14 04:08 port 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 connector 2010-12-14 04:08 wpwrak: looking at the 3d view of the xue board, I'd say 95% or more of components have no 3D footprint 2010-12-14 04:08 this of course spells doom for booting from NOR (which uses port 2) 2010-12-14 04:09 the other way round, it spells doom for the external connector 2010-12-14 04:09 (no 3d) i'm not surprised. 2010-12-14 04:09 i don 2010-12-14 04:09 't bother with 3d in fped, for example :) 2010-12-14 04:09 no problem that's why I bring it up 2010-12-14 04:09 should we postpone this until later? 2010-12-14 04:09 postpone what ? 2010-12-14 04:10 worrying that we have full 3D stacking data in KiCad 2010-12-14 04:11 uh, yes. let's revisit this in, say, 2041 ? :) 2010-12-14 04:11 port 1 is 2.5V in xue. nor boot uses that, too. 2010-12-14 04:11 so going from spi-nand to nor is basically a full redesign of the board. 2010-12-14 04:11 you mean nor boot on m1 uses 2.5V? 2010-12-14 04:12 m1 uses 3.3V everywhere except for DDR and JTAG 2010-12-14 04:12 the port that nor boot would use if xue did nor boot is in a 2.5 V domain 2010-12-14 04:12 not sure if the pins are occupied 2010-12-14 04:13 maybe there is a 2.5V variant of the same chip as on m1 2010-12-14 04:13 but 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 all 2010-12-14 04:14 well, flash is certainly very different. not sure about the other stuff. (usb, ether, ...) 2010-12-14 04:15 oneah, another advantage of NOR: with execute-in-place, you don't need RAM for (constant) code or constant data. 2010-12-14 04:16 s/^one// 2010-12-14 04:17 lekernel: how do you feel about moving Milkymist One to KiCad? 2010-12-14 04:18 hum, that's it's an uninteresting time sink? 2010-12-14 04:18 but if someone else wants to do it, why not 2010-12-14 04:19 wolfspraul, wpwrak : i just got info from AiT vendor 2010-12-14 04:19 lekernel: I'm mainly asking because of Milkymist Two 2010-12-14 04:19 as long as it doesn't incur the slightest slowdown in production 2010-12-14 04:19 oh no 2010-12-14 04:19 of course not 2010-12-14 04:19 no worries 2010-12-14 04:19 this is not why I'm asking 2010-12-14 04:20 so let's say one day we start working on Milkymist Two, you mentioned capacitive screen on top, for example 2010-12-14 04:20 how much 'in love' are you with your current EDA tool? 2010-12-14 04:20 if at that point we had the design transferred into KiCad, would you make the schematics changes in KiCad? 2010-12-14 04:20 (this is all hypothetical, I just try to understand your priorities) 2010-12-14 04:21 the "time sink" comment is totally fine :-) 2010-12-14 04:21 adamwang: go on, what about AiT? 2010-12-14 04:22 i'm writing email to list first 2010-12-14 04:22 ok 2010-12-14 04:22 open source hardware -> open source eda tools. kicad is inevitable ;-) 2010-12-14 04:22 milkymist2, if it happens at all, will probably be a major re-spin... 2010-12-14 04:22 let's hope kicad has had the time to improve before that 2010-12-14 04:23 why should it not happen, and could you roughly have in mind then for the re-spin? 2010-12-14 04:23 wolfspraul: in order to keep the xue changes at a reasonable level, i'd try to stay with loading the bitstream from spi-nand. 2010-12-14 04:23 /and what could you/... 2010-12-14 04:24 since most of it will need to be re-done, yes, why not give kicad a try... 2010-12-14 04:24 any indicators what might need to be redone? 2010-12-14 04:24 you are by far the most ahead in thinking about m1 features, so any bit like 'capacitive screen on top' helps... 2010-12-14 04:24 before we start talking about Milkymist2, the spartan6 will probably have become obsolete :) 2010-12-14 04:25 sure we can use this aerix-7 or whatever they call it 2010-12-14 04:25 or non-xilinx if something better is out then 2010-12-14 04:25 aerix-7 2010-12-14 04:25 lol 2010-12-14 04:25 but how about other features? 2010-12-14 04:25 wait I check 2010-12-14 04:26 Artix, sorry 2010-12-14 04:26 Artix-7 2010-12-14 04:26 the successor of the Spartan-6 2010-12-14 04:26 'Spartan' brand is to be retired/discontinued 2010-12-14 04:26 how about other features? more user-oriented stuff 2010-12-14 04:26 anything in mind? 2010-12-14 04:26 (you did mention that screen on top once...) 2010-12-14 04:27 yeah, that was just a random idea, make a mashup of the iPad and M1 :) 2010-12-14 04:27 but let's get the M1 out first and see how users react 2010-12-14 04:27 of course, there is a lot we can do on the manufacturing side to drive costs down 2010-12-14 04:27 I can happily work on that for a while :-) 2010-12-14 04:27 that would probably include bringing it over to KiCad and related tools at some point 2010-12-14 04:28 how does that help with manufacturing costs? 2010-12-14 04:29 it makes the process cheaper when there are changes 2010-12-14 04:29 that's why I am asking about Two 2010-12-14 04:30 if 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 components 2010-12-14 04:30 but I rather like to think about it in a more dynamic way 2010-12-14 04:30 also opens the project for wider participation and makes its results accessible for more people 2010-12-14 04:30 so I anticipate changes 2010-12-14 04:30 even changes that are in reaction to component costs, or manufacturing issues 2010-12-14 04:30 or whole derivative projects like I still think of Xue 2010-12-14 04:32 also 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 up 2010-12-14 04:32 yup. particularly if you want to minimize the changes. turns the incentives around completely ;-) 2010-12-14 04:32 that 'scaffolding' is often tied to and build upon the original tools 2010-12-14 04:32 so 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. 2010-12-14 04:33 I 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. 2010-12-14 04:33 let's focus on milkymist one first 2010-12-14 04:34 of course we are doing a lot of things right already, with the test suite being free software... 2010-12-14 04:34 how to make good software 2010-12-14 04:34 how to sell thousands (or more) 2010-12-14 04:34 how to make it cheap 2010-12-14 04:34 those are the important things atm 2010-12-14 04:34 yes but before that I switch to KiCad for sure, or will try to 2010-12-14 04:34 (the thousands) 2010-12-14 04:34 mh 2010-12-14 04:34 because if we don't, it becomes essentially unchangeable later 2010-12-14 04:35 those who make the change, switch to kicad? 2010-12-14 04:35 personnally I'm not interested in changing stuff 2010-12-14 04:35 correct 2010-12-14 04:35 I'm not asking you to, all fine. 2010-12-14 04:35 except maybe for a complete re-spin (M2) but later 2010-12-14 04:35 way later 2010-12-14 04:36 I just try to understand your thoughts of future changes. 2010-12-14 04:36 it's already mostly clear I think 2010-12-14 04:36 wolfspraul: seems that you won't get MM1 in kicad for christmas after all :) 2010-12-14 04:37 this christmas? 2010-12-14 04:37 sure 2010-12-14 04:37 no there is no rush, we should introduce it when it makes sense for m1 2010-12-14 04:37 I agree with sebastien on the priorities 2010-12-14 04:37 it will make sense as we scale up production, and it's most likely something I can do entirely without Sebastien's help 2010-12-14 04:38 I quite don't see how kicad would help scale up production... 2010-12-14 04:38 for m1 the product, even on the hardware side, there are still many low hanging fruits to pick first 2010-12-14 04:38 case, certification, board optimizations (like the crystal thing we found) 2010-12-14 04:39 lekernel: the other way round. As you scale, your choice of tool typically becomes unchangeable. 2010-12-14 04:39 because the tools and their characteristics and side/helper tools grow as you scale 2010-12-14 04:39 why not scale the current version first, then maybe start the kicad fork later, as a side project? 2010-12-14 04:39 so if we believe in the benefits of free tools, we need to change them while runs are small, or never 2010-12-14 04:40 'scale' is essentially pressure on your tools and processes to grow 2010-12-14 04:40 I can only repeat: choice of tool becomes unchangeable after you scale. 2010-12-14 04:40 economically of course, I mean 2010-12-14 04:40 technically you can always do every crazy thing :-) 2010-12-14 04:41 what's impossible in slowly changing to kicad later? 2010-12-14 04:41 run two different projects... 2010-12-14 04:41 main branch, and kicad branch 2010-12-14 04:41 at that point such a decision would be so risky/expensive, that nobody will want to pony up the money anymore 2010-12-14 04:42 ? 2010-12-14 04:42 it's like starting a new project 2010-12-14 04:42 and you start new projects all the time :p 2010-12-14 04:42 maybe much less than you think :-) 2010-12-14 04:43 anyway, why are we discussing this? the timing of bringing m1 into KiCad? 2010-12-14 04:43 not urgent imo, we are on the same page about that I think 2010-12-14 04:45 lekernel: 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 is 2010-12-14 04:46 wpwrak: yeah I guess the spi-nand issue is a big one on Xue 2010-12-14 04:46 not only technically but also in terms of work that would get thrown away 2010-12-14 04:47 basically the whole layout would have to be redone 2010-12-14 04:47 well either way. I simply don't think we will ever get it to work on the software side. 2010-12-14 04:47 what's the point of soldering together a board that will never turn on and perform a useful function 2010-12-14 04:48 maybe we are better off transferring m1 into KiCad earlier rather than later, even under Sebastien's suspicious eyes :-) 2010-12-14 04:48 why would nor vs. nand make the sw side so impossible ? you've said that you already want to use uSD instead of nand 2010-12-14 04:49 it's not impossible, but I think very practical - who will do it, and who will stand behind it. 2010-12-14 04:49 the reason the m1 run was successful is because of lekernel's excellent preparations and support through the run 2010-12-14 04:50 if there is no such support for Xue we can spare everybody the waste of time of making a dead board. 2010-12-14 04:50 yeah, xue depends on how committed andres and his helpers are 2010-12-14 04:51 and you say layout would need to be thrown away 2010-12-14 04:51 we are only scratching the surface 2010-12-14 04:51 wee can help with some obstacles, but they have to "own" the project 2010-12-14 04:51 if 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 sure 2010-12-14 04:51 (surface) maybe. perhaps more will show up after a first scrubbing. the onion model ;-) 2010-12-14 04:52 just think power supply 2010-12-14 04:53 yeah, the power supply is a bit of a mystery. there must be *some* plan. 2010-12-14 04:53 lekernel: how are the 2 rc2 boards holding up by the way? 2010-12-14 04:53 (supply) it's not something you just overlook. 2010-12-14 04:54 this would also be inconsistent with the other problems we found. 2010-12-14 04:55 what would be inconcistent? 2010-12-14 04:55 last time I checked they still worked... one is with roh atm 2010-12-14 04:56 btw I've run into the "no more boot" problem 2010-12-14 04:56 'no more' as in not at all? 2010-12-14 04:56 no, not at all 2010-12-14 04:56 for how long? 2010-12-14 04:56 (inconsistent) just forgetting the power supply input 2010-12-14 04:56 but after reflashing it worked again, so I guess the "intermittent boot issue" might also corrupt flash data sometimes 2010-12-14 04:57 why is that inconsistent? 2010-12-14 04:57 next time this happens i'll dump the flash and see if something was actually corrupted 2010-12-14 04:57 imho that is consistent with many other things we see on the board 2010-12-14 04:57 lekernel: yes there may be several bugs, masking each other 2010-12-14 04:57 be careful 2010-12-14 04:57 do not cycle the boards too fast 2010-12-14 04:57 this is a trap 2010-12-14 04:57 you are then able to 'reproduce' the bug more often, but I think that is a separate issue then 2010-12-14 04:57 separate bug 2010-12-14 04:58 if you get hung on on too fast power cycles, at least me and Adam have managed to permanently damage 2 boards 2010-12-14 04:58 yeah, I waited a few minutes 2010-12-14 04:58 but still no boot 2010-12-14 04:58 minutes? 2010-12-14 04:58 oh wow 2010-12-14 04:58 :-) 2010-12-14 04:58 I'd say 2 seconds is enough 2010-12-14 04:58 and it immediately worked again after reflashing 2010-12-14 04:58 yes 2010-12-14 04:58 there may be several bugs 2010-12-14 04:58 so this really looks like corrupt flash contents 2010-12-14 04:58 that is very consistent with what I saw 2010-12-14 04:59 no I think there are probably several different bugs/issues 2010-12-14 04:59 well, if the root cause of those problems is a glitch on the flash write enable line during power up, this explains two problems already 2010-12-14 04:59 maybe if we can track down one of them the rest will become clear fast 2010-12-14 04:59 (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. 2010-12-14 05:00 for the "permanently damaged" boards (never had something like that), I can't comment until we know what is damaged 2010-12-14 05:01 we treated them pretty badly 2010-12-14 05:01 :-) 2010-12-14 05:01 that's ok we just did all kinds of tests 2010-12-14 05:01 (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 run 2010-12-14 05:01 I 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 way 2010-12-14 05:02 there is a separate problem somewhere when you keep cycling the board in short cycles, like < 500 ms 2010-12-14 05:02 to be safe, never cycle in less than 2 seconds 2010-12-14 05:02 that's my only point, but important 2010-12-14 05:03 after we 'terminally' tested the 1st board, we wanted to see whether our assumption was correct 2010-12-14 05:03 anyway, what is damaged on those boards? 2010-12-14 05:03 and lo and behold, within a short amount of time we were able to 'terminate' the second one as well 2010-12-14 05:03 could still be useful to know in order to make the design more robust 2010-12-14 05:03 at least that was a successful test 2010-12-14 05:03 yes we will look at them 2010-12-14 05:03 did you try to reflash? 2010-12-14 05:04 but 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 activities 2010-12-14 05:04 oh sure 2010-12-14 05:04 it could simply be a "corrupted flash content" problem like mine 2010-12-14 05:04 no more reflashing 2010-12-14 05:04 oh no 2010-12-14 05:04 we did A LOT of testing 2010-12-14 05:04 and we are not totally stupid, I would hope 2010-12-14 05:04 and? what happens when reflashing? 2010-12-14 05:04 trying to track things down, find pattern, etc. 2010-12-14 05:04 nothing 2010-12-14 05:04 impact can't connect I think 2010-12-14 05:05 or maybe error during flashing 2010-12-14 05:05 it's in the ods 2010-12-14 05:05 mh, ok 2010-12-14 05:05 we put those 2 boards aside 2010-12-14 05:05 is the power supply ok? 2010-12-14 05:05 yes I think so 2010-12-14 05:05 really? 2010-12-14 05:05 just remember: don't cycle very fast in attempts to reproduce the .56A boot hang 2010-12-14 05:05 it's not a good path 2010-12-14 05:05 then the FPGA is burned 2010-12-14 05:05 but there is simply no way that could happen 2010-12-14 05:05 yes 2010-12-14 05:05 except ESD 2010-12-14 05:06 power supply good and the board still dead, that sounds unpleasant 2010-12-14 05:06 cycle very fast will do it 2010-12-14 05:06 after 2 boards we didn't want to do more experiments around that, it needs a more thoughtful approach 2010-12-14 05:06 but then, this type of power cycling is quite unusual 2010-12-14 05:06 only overvoltages can kill the JTAG on the FPGA 2010-12-14 05:06 even shorted I/Os won't do that usually 2010-12-14 05:07 lekernel, the 2 brds at your site, don't do power cycle in one second! 2010-12-14 05:07 maybe the quick cycles mess up something and current flows where it shouldn't? I don't know. We stopped going in that direction. 2010-12-14 05:07 he :-) 2010-12-14 05:07 Adam tries to get the same message across. 2010-12-14 05:07 :-) 2010-12-14 05:07 before we find hard info further. 2010-12-14 05:08 I power cycled both RC1 and RC2 fast, and never run into an issue like that 2010-12-14 05:08 how fast and how many times? 2010-12-14 05:08 i can pretty surely my power supply is ok but ESD don't know. 2010-12-14 05:08 0.5s, maybe 20-30 times 2010-12-14 05:08 lekernel: I really suggest you don't try it any more. 2010-12-14 05:08 we are just wasting boards with very unusual behavior anyway - no value for anybody 2010-12-14 05:09 maybe a first step could be to record the power supplies on scope 2010-12-14 05:09 power cycle fast 2010-12-14 05:09 and verify they don't exceed their nominal voltage 2010-12-14 05:09 yes I think that's on Adam's todo list somewhere 2010-12-14 05:09 also watch what happens on the board 2010-12-14 05:09 http://en.qi-hardware.com/wiki/File:M1_rc2_1a_duration_between_power_cycles_480ms.JPG 2010-12-14 05:10 hmm, no boost converters in sight, so it couldn't be a dc/dc converter going crazy 2010-12-14 05:10 this 0x1a brd we tried power cycle at fast at 480ms, of course this test is un-usual. 2010-12-14 05:10 but really, if the power supply don't go too high in voltage, the only option to kill JTAG is ESD 2010-12-14 05:11 but what somethings we didn't know is that this 0x1a is working well even we added 470nF connected to C60, then it still ok. 2010-12-14 05:11 if you can fix a bug without trying to reproduce it with short (<500ms) power cycles, that is great 2010-12-14 05:11 that's all I can contribute to the discussion :-) 2010-12-14 05:11 and then other 2 brds, me & Wolfgang let them dead. :) 2010-12-14 05:12 adamwang: you can't put whatever capacity you want on the I/O, and it still won't kill the FPGA 2010-12-14 05:12 Adam will be looking into the power some more when things settle down. 2010-12-14 05:12 I don't think it was ESD. 2010-12-14 05:12 the Spartan6 doesn't mind if there is voltage applied on the I/O when the main power is cut 2010-12-14 05:12 yeah....hehe 2010-12-14 05:12 nor capacitor inrush current will be much of a problem, it's limited by the drive strength of the I/O 2010-12-14 05:13 so anyway, before we get hard info later, pls don't try to power cycle in very short duration. 2010-12-14 05:13 as long as it doesn't dissipate too much power (and it won't unless you toggle the I/O fast) it won't burn either 2010-12-14 05:14 how is power cycled ? unplug, then replug ? if yes, could 5V and GND get inverted ? 2010-12-14 05:14 wpwrak, it's possible, i also thought this before , 2010-12-14 05:15 but i have no data to approve. 2010-12-14 05:15 would be fast inversely current involved this? 2010-12-14 05:16 from the picture, yes we unplug power on and off 2010-12-14 05:16 how about just electromechanical, i.e., the connector ? be it the plug-socket interface or maybe some mechanical effect on the socket 2010-12-14 05:17 if you unplug/replug rapidly, the movement/forces may differ from slower cycling, and trigger an unusual problem 2010-12-14 05:18 i didn't connect any mechanical. 2010-12-14 05:18 adamwang: (no mechanical connection) so how did you cycle ? 2010-12-14 05:19 i used a switch to unplug and plug-in to let 5V DC get in DC jack on board. 2010-12-14 05:20 is it not good? 2010-12-14 05:21 okay. does the switch cut 5V and GND or just 5V ? 2010-12-14 05:21 just 5V 2010-12-14 05:22 but from the scope of picture, there's no spark while power-cycling 2010-12-14 05:23 i guess you used a lab supply ? 2010-12-14 05:23 or do you think that I had better to switch both(5V and GND) in very tiny period? 2010-12-14 05:23 adamwang: better check the output voltages (1.2V, 2.5V, 3.3V) on scope 2010-12-14 05:24 http://shop.cpu.com.tw/product/38/info/ 2010-12-14 05:24 maybe even 1.8V and 5V at the same time (got enough channels?) 2010-12-14 05:24 yes, a lab supply 2010-12-14 05:25 um..i need to scope them in only two channels to monitor again 2010-12-14 05:26 adamwang: (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 ;-) 2010-12-14 05:26 yeah...hehe 2010-12-14 05:26 http://en.qi-hardware.com/wiki/Milkymist_One_RC1_Reports#Power_Tree_for_Quiescent_Mode 2010-12-14 05:26 see this while i measured during RC1 made 2010-12-14 05:27 i guess our brd RC1 have hw itself power sequence timing is different 2010-12-14 05:27 so i am thinking that what's best timing between flash and fpga 2010-12-14 05:29 i should plot those relationships in chat as well...then we can know what's timing flash chip stayed at? 2010-12-14 05:29 well...not go to FAE there...will do this. 2010-12-14 05:30 adamwang: we're talking about checking that the power supply levels stay reasonable when the board is power cycled fast 2010-12-14 05:31 in order to explain the "permanent damage" you've seen 2010-12-14 05:31 the flash is a different problem 2010-12-14 05:32 no, actually we don't know. 2010-12-14 05:33 would it be too fast for example are there all IOs status are good for connections between flash and fpga during such so 480ms? 2010-12-14 05:34 would their IOs acts un-normally easily during 480ms?...I don't know. 2010-12-14 05:37 wpwrak, my supply is a new one! hehe. :) not 2nd-hand. :) 2010-12-14 05:39 adamwang: sometimes, 2nd hand is better. already debugged ;-) 2010-12-14 05:39 hehe. :) 2010-12-14 05:40 you know taiwanese here. A new supply may only cost USD 150. 2010-12-14 05:41 2nd -hand, it doesn't worth to repair it. :) well 2010-12-14 05:56 wpwrak: just saw Adam's mail that the AiT parts are EOL essentially 2010-12-14 05:57 the ones used in Xue. compared with the other 10+ issues we found I don't think this can be considered especially bad news though... 2010-12-14 05:57 :-) 2010-12-14 06:02 (AiT) good to know early ;-) i'm having a bit of troubles with my mails, so i haven't seen it yet 2010-12-14 07:08 Hi wolfspra1l 2010-12-14 08:23 andres-calderon: hi 2010-12-14 08:24 so Werner and I looked over xue a little 2010-12-14 08:24 first big surprise was the spi-nand instead of nor flash as on m1 2010-12-14 08:24 at least surprise for me 2010-12-14 08:25 then smaller thing but also different from m1 is the ft2232d instead of ft2232h 2010-12-14 08:27 then the PSU, under-specified regulators, missing resistor values 2010-12-14 08:27 missing 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 :-) 2010-12-14 08:28 178 ERC warnings in KiCad 2010-12-14 08:28 question whether we need the Samsung NAND chip 2010-12-14 08:28 question whether we need the AVR 2010-12-14 09:08 andres-calderon: back? 2010-12-14 09:14 wolfspraul: hi 2010-12-14 09:15 did you see what I wrote earlier? 2010-12-14 09:15 some of our feedback 2010-12-14 09:15 178 ERC warnings 2010-12-14 09:15 question whether we need the Samsung NAND 2010-12-14 09:15 question whether we need the AVR 2010-12-14 09:15 missing DC jack and battery connector, psu design seems unclear 2010-12-14 09:16 spi-nand is different from m1, if it's too hard to change we need to confirm whether that chip is ideal 2010-12-14 09:16 We  prefeer to have NAND flash (optional) for improve mechanical  capabilities... 2010-12-14 09:16 ft2232d instead of ft2232h, why not use same one as in m1? 2010-12-14 09:17 ok let's just start somewhere 2010-12-14 09:18 can you look at the ERC warnings? 2010-12-14 09:18 we have traumatically experiences with automotive  applications.. 2010-12-14 09:18 maybe nobody ever looked at them, many are probably very easy to fix 2010-12-14 09:18 I updated BOOKSHELF a little, we need many more links there, for every last component on the board 2010-12-14 09:19 wpwrak decided that dsv will only support pdf now, and that is the vast majority of 'datasheets' anyway. so no html links... 2010-12-14 09:19 running ERC... 2010-12-14 09:19 the psu needs a complete overhaul I think 2010-12-14 09:20 between missing connectors, unclear avr role, under-specified regulators, missing resistor values, it seems that some big thinking is needed there 2010-12-14 09:22 but maybe we do things step by step 2010-12-14 09:22 AVR has been added for energy measure.  wolfspraul propose energy measure for debuging. 2010-12-14 09:22 oh my god? 2010-12-14 09:22 I'm the reason for the AVR? 2010-12-14 09:22 great - kick it out then 2010-12-14 09:22 I take the idea to the extreme. 2010-12-14 09:22 every chip less is great 2010-12-14 09:23 totally kick it out 2010-12-14 09:24 with the AVR  we  can measure energy in any FPGA tension 2010-12-14 09:24 It is a powerful tool, but also think it's a risk. 2010-12-14 09:25 we should not make random feature picks like that, I've seen it failing too many times 2010-12-14 09:25 either you are lazer sharp and exactly know that this will work, or don't even think about it 2010-12-14 09:25 no powerful tool, it will be a nightmare 2010-12-14 09:25 unless you are the global expert in power measurements with AVR MCUs, don't do it 2010-12-14 09:25 don't just throw a chip somewhere because you think it can do this or that 2010-12-14 09:26 seriously, that is the #1 recipe for failure 2010-12-14 09:26 if you want it, it must be very very deeply thought through and studied 2010-12-14 09:27 especially now that you are telling me I am the reason for the AVR, that's even scarier :-) 2010-12-14 09:27 I hope I'm not the reason, not in any way... 2010-12-14 09:27 we want this board to work... 2010-12-14 09:28 andres-calderon: I will rename the schematics sheets a bit, in a way that will hopefully let schhist follow the history. 2010-12-14 09:28 so you don't need to do that, just need your OK that I can rename them and clean them up (the names). 2010-12-14 09:28 wolfspraul:  ok 2010-12-14 09:28 is that OK? 2010-12-14 09:29 if you have more datasheets, please add the URLs (to the PDFs) to BOOKSHELF 2010-12-14 09:29 for anything from Milkymist, you can take the ones from the m1 bom 2010-12-14 09:29 http://en.qi-hardware.com/wiki/Milkymist_One_RC2_BOM 2010-12-14 09:29 I have no problem in redesigning the source. I hear suggestions 2010-12-14 09:29 do you see the manufacturer p/n 2010-12-14 09:29 I have no problem in redesigning the PSU 2010-12-14 09:29 that's a URL to the datasheet for every last component on m1 2010-12-14 09:30 as I'm hoping xue reuses as many as possible of those, it's easy to move the URLs to BOOKSHELF 2010-12-14 09:30 I will also do it step by step, but the goal is to have datasheet urls for 100% of the components on xue 2010-12-14 09:31 how about reusing those notebook battery controller psus? 2010-12-14 09:31 anything good in there? 2010-12-14 09:31 I haven't looked at this in detail... 2010-12-14 09:31 I 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) 2010-12-14 09:33 2 or more cells raises the complexity ... more problems. much more risk than the AVR. 2010-12-14 09:36 [OT] http://ur1.ca/2l4bg 2010-12-14 09:37 Adam can look for something in TW? 2010-12-14 09:39 we can get a whole notebook controller like the ones I sent you 2010-12-14 09:39 although I'm not sure about the interface to them, 6 pins or so 2010-12-14 09:39 where is the charging circuit? don't know 2010-12-14 09:40 can Adam look for 'something'? for what exactly? 2010-12-14 09:40 if the Samsung NAND is optional, then why not put a microSD slot there? 2010-12-14 09:40 ICs for the charger 2010-12-14 09:41 that makes more sense as an option, I think 2010-12-14 09:41 microSD is not so good for automotive appliance. poor tolerance under vibrations 2010-12-14 09:42 good point although I think that depends on the connector, no? 2010-12-14 09:42 which connector are you referring to? 2010-12-14 09:42 you say any connector will always be worse than a soldered solution? 2010-12-14 09:43 for an early prototype it sounds like a little early to factor in this kind of requirement 2010-12-14 09:43 yes, the better choice is a soldered Flash 2010-12-14 09:43 but...  if i remove de NAND, we gain  a lot of space for the new PSU 2010-12-14 09:44 for the whole PSU, the only idea I have is to reuse notebook battery controllers 2010-12-14 09:44 I stopped at the point where I sent you those controllers 2010-12-14 09:44 don't know exactly what is on them, which ics or circuits 2010-12-14 09:44 if we make a case, there should be a way to integrate such a controller, especially if there are battery cells anyway 2010-12-14 09:45 andres-calderon: let's go step by step 2010-12-14 09:46 can you go through the ERC warnings and fix them? 2010-12-14 09:46 who should do this? 2010-12-14 09:46 Using these notebook chargers is an interesting option. 2010-12-14 09:47 yes, especially if they already integrate all the nasty pieces we need 2010-12-14 09:48 most are dumb mistakes, maybe I should modify the kicad's libraries 2010-12-14 09:48 any bit of cleanup is good, I think there is still potential, but I haven't started looking in detail 2010-12-14 09:49 like for example there are .bak files committed 2010-12-14 09:49 many warning for  unconnected pins. 2010-12-14 09:49 6 of them in kicad/library 2010-12-14 09:50 I would prefer to switch the ft2232 to the ~h version, unless we have a strong reason for the ~d version 2010-12-14 09:50 maybe price? 2010-12-14 09:51 but it could be important for fast development cycles, if people use it to reconfigure the fpga and develop like that 2010-12-14 09:51 not sure 2010-12-14 09:51 of course, I would even prefer the same mechanical header like on m1, so no ft2232 on xue at all 2010-12-14 09:51 since we will have the daughterboard already anyway 2010-12-14 09:51 makes xue cheaper later 2010-12-14 09:52 andres-calderon: ah another small question 2010-12-14 09:52 in docs/sue-docs, you have .png and .svg versions of 2 files 2010-12-14 09:53 can we delete the png version? (is the .svg the original)? 2010-12-14 09:53 of course! 2010-12-14 09:53 I'm slower than normal ... I'm in the office attending other issues. 2010-12-14 09:53 in kicad/modules, it seems we are committing the fped files along with their output files? 2010-12-14 09:54 maybe werner can give more suggestions but we should probably not commit the output files, and generate them with a Makefile instead 2010-12-14 09:55 since I vote for changing the ft2232 from d to h, I actually vote to go back to the same headers as on m1 2010-12-14 09:55 make xue cheaper, we have the daughterboards already anyway so the normal argument against such daughterboards (cost) doesn't work 2010-12-14 09:56 ok need to log out 2010-12-14 09:56 we prefer not  commit  machine generate files... but FPED still exotic. 2010-12-14 09:56 back tomorrow, 'night 2010-12-14 09:57 come on, not exotic :-) 2010-12-14 09:57 a few Makefiles can do wonders 2010-12-14 09:57 :) 2010-12-14 09:57 if you can do a few things here and there, that would be great 2010-12-14 09:57 I'll do more tomorrow as well 2010-12-14 10:34 (psu) without the AVR, also the FANs can go. instant removal of ~15 components ;-) 2010-12-14 10:37 AVR Mcu? 2010-12-14 10:37 sorry i dint follow was a long chat 2010-12-14 10:38 ah i see 2010-12-14 10:42 wow that was scary indeed :) 2010-12-14 10:44 there 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 ;-) 2010-12-14 10:45 maybe keep the sense resistors (make them 0R - they're currently unspecified), for future measurements 2010-12-14 10:54 killing the ft2232 would remove 20 components and add one new. whee. soon, the component count will go negative ! ;-) 2010-12-14 13:26 [commit] kyak: QBall: a QT-base breakout game http://qi-hw.com/p/openwrt-packages/e5016ec 2010-12-14 16:07 [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/4a33228 2010-12-14 16:07 [commit] David Kühling: an alternative, smaller, japanese input dictionary for Emacs http://qi-hw.com/p/openwrt-packages/f32d4c4 2010-12-14 16:29 [commit] David Kühling: fix installation directory, package depenencies http://qi-hw.com/p/openwrt-packages/cfb4a67 2010-12-14 16:29 [commit] David Kühling: Fix dependencies http://qi-hw.com/p/openwrt-packages/b7c65f3 2010-12-14 21:09 [commit] Xiangfu Liu: update the qi-hardware sources mirror address http://qi-hw.com/p/openwrt-xburst/addbbd7 2010-12-14 21:38 wolfspraul: nice work with the PSU simplification ;-) 2010-12-14 21:39 he, funny now i realize i still having some slight issues with LCM when using SIE shared bus 2010-12-14 21:40 hmm bus i dint haven in owrt.. 2010-12-14 21:40 any way, i dont need LCM now 2010-12-14 21:42 wpwrak: you said the other time FFTW is happy with wick kind of data types? 2010-12-14 21:42 complex or real. it can take either. 2010-12-14 21:43 usrp gives you wich kind of data type? 2010-12-14 21:44 wpwrak: hmm 2010-12-14 21:44 ah nv, 16 bit is okay for now 2010-12-14 21:44 plus a dozen other formats i could probably understand if i spent the next few months reading the fine works of Fourier & Co. :) 2010-12-14 21:44 my brain was working so hard I couldn't sleep 2010-12-14 21:44 too much Xue processing 2010-12-14 21:45 usrp outputs 16 bit. 2010-12-14 21:45 wolfspraul: ;-)) 2010-12-14 21:45 I need to digest it, still not sure. 2010-12-14 21:45 I somehow doubt Andres will take a leadership role that will allow us to take this into production. 2010-12-14 21:45 it's more like dragging a mule up the mountain :-) 2010-12-14 21:45 wolfspraul: andres' responses didn't sound too bad. he seems to know exactly where the problems are :) 2010-12-14 21:45 yes sure, but the responses only come when pulled 2010-12-14 21:46 yeah, i wonder about that part 2010-12-14 21:46 should we wait now and see whether anything happens? say about the ERC errors :-) 2010-12-14 21:46 how long? 2010-12-14 21:46 1 week? 1 month? 2010-12-14 21:46 until I pull him back into the channel :-) 2010-12-14 21:46 keep it simple (drop avr) is good, isnt? 2010-12-14 21:46 and it's really scary that the AVR is there because I made a comment at some point 2010-12-14 21:47 wolfspraul: well, doesn't that sound familiar ;-) 2010-12-14 21:47 kristianpaul: 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... 2010-12-14 21:47 yes but most likely we have very very bad judgment on other areas as well then 2010-12-14 21:47 unfortunately 2010-12-14 21:47 so basically the whole design needs to be questioned, every chip, every wire 2010-12-14 21:47 not to mention the layout 2010-12-14 21:47 the 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. 2010-12-14 21:48 the question is who is the designer of the board? 2010-12-14 21:48 that is unclear to me now 2010-12-14 21:48 it seems to be an unholy and strange alliance between Carlos, Andres and me 2010-12-14 21:48 did you ask them ? 2010-12-14 21:48 some people made this 'decision', some people made that 'decision'. Some didn't even know they made a decision :-) 2010-12-14 21:48 well we discover it in our review, no? 2010-12-14 21:48 :-) 2010-12-14 21:49 I start to accept the spi-nand better now 2010-12-14 21:49 i mean, "who is the designer" 2010-12-14 21:49 good :) 2010-12-14 21:49 of course that also needs to be completely re-evaluated for correctness 2010-12-14 21:49 every wire 2010-12-14 21:49 changing Xue to NOR would seem a bit crazy to me. 2010-12-14 21:49 so basically the only thing I can trust now is a short 'feature list', and even that is open for discussion I guess 2010-12-14 21:49 yes, I tend to agree 2010-12-14 21:50 _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 this 2010-12-14 21:50 someone has to own a decision 2010-12-14 21:50 i would expect spi-nand to be the path most traveled. so there ought to be tons of knowledge/tools/etc. for that 2010-12-14 21:50 yes maybe 2010-12-14 21:50 maybe we can pick sebastien's brain to check whether this is correct 2010-12-14 21:50 but who owns responsibility? me? no! cannot right now, know too little 2010-12-14 21:50 wait 1 month, then we discuss again 2010-12-14 21:50 I hate to defocus people who already have great focus. 2010-12-14 21:51 then we rather pick the brain of bystanders like emeb|mac :-) 2010-12-14 21:51 naw, just to confirm whether this is right or wrong 2010-12-14 21:51 he he 2010-12-14 21:51 just pull the guy off the chair in the corner, who tries to hide from dancing... 2010-12-14 21:52 so I think I will let this settle a bit, I have so many todos 2010-12-14 21:52 design by throwing random people (maybe engineers) at it. oh yes, i can see that work ;- 2010-12-14 21:52 ) 2010-12-14 21:52 maybe this is what got us to where it is now? then it can't get worse 2010-12-14 21:52 feedback can always be enlightening, even if you ask a taxi driver 2010-12-14 21:52 maybe that feedback is the most enlightening sometimes, no? 2010-12-14 21:53 maybe I slowly dig into the xue tree and cleanup little by little 2010-12-14 21:53 before 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. 2010-12-14 21:53 see whether Andres comes forward 2010-12-14 21:53 oh we did that maybe 20 times the last 2 months 2010-12-14 21:53 3) all the technical things we already discussed 2010-12-14 21:54 (20 times) urgh :-( 2010-12-14 21:54 at 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. 2010-12-14 21:54 ;-))) 2010-12-14 21:54 maybe I would even rip out the aptina cmos and move the expansion header in a bit 2010-12-14 21:54 then we can have the cmos on a daughterboard on top of the expansion header 2010-12-14 21:55 not 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 ? 2010-12-14 21:55 I 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 footprint 2010-12-14 21:55 wpwrak: oh wait I show you, you will like this :-) 2010-12-14 21:56 (nand) yeah. even for automotive, there's nothing really preventing you from combining uSD with some good old glue ;-) 2010-12-14 21:56 so that would be 2x uSD then ? 2010-12-14 21:57 well I don't want to dismiss the vibration argument 2010-12-14 21:57 that sounds like a real thing coming from the field (well, I hope it does) 2010-12-14 21:57 but even if that is true, it's a big specialization, the kind of thing we can do later to make money 2010-12-14 21:57 but in the first runs? strange 2010-12-14 21:57 I don't get that 2010-12-14 21:57 second microSD looks much much better for the first x hundred boards 2010-12-14 21:58 http://en.qi-hardware.com/wiki/File:Battery_controllers.jpg 2010-12-14 21:58 this is what I mean 2010-12-14 21:58 wpwrak: 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 want 2010-12-14 21:58 hmm definelly i need a start signal here 2010-12-14 21:58 oh, I would remove the 2232 as well of course, and use the same headers as on m1 2010-12-14 21:59 wpwrak: do you see those battery controllers? 2010-12-14 21:59 (bat ctrl) hmph. do they come with data sheets ? 2010-12-14 21:59 I can source them in any quantity (1 to x million) for ca. 6 USD 2010-12-14 21:59 wpwrak: no of course not. China chaos. 2010-12-14 21:59 but I could go to the fab where they make them, find out what we need 2010-12-14 22:00 essentially they have the well known bq27000 or similar ics on them 2010-12-14 22:00 wolfspraul: okay. do you know exactly what they do then ? :) 2010-12-14 22:00 no I don't 2010-12-14 22:00 they are inside the battery 2010-12-14 22:00 the bq27000 doesn't do anything you need 2010-12-14 22:00 the notebook battery is like this: 2010-12-14 22:00 1) controller (this thing you see there) 2010-12-14 22:00 2) cells 2010-12-14 22:00 3) plastic 2010-12-14 22:00 sure we need to see where the charging logic is 2010-12-14 22:00 kristianpaul: you could divide SYNC by 4 and output the divided signal ? 2010-12-14 22:01 it's just an idea 2010-12-14 22:01 wolfspraul: (charging logic) small detail :) 2010-12-14 22:01 wolfspraul: scavenging is good, but you need lots of time and flexibility for it 2010-12-14 22:01 but at least my plan is to look at these controllers and see whether they provide anything useful. 2010-12-14 22:01 wpwrak: yes 2010-12-14 22:01 you mostly need knowledge 2010-12-14 22:02 wpwrak: you meant output in the buffer as well, a space for data other for some "sync" register? 2010-12-14 22:02 wolfspraul: 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 ? 2010-12-14 22:02 wolfspraul: in this context, it's rather ironic that andres worries about automotive use for the NAND ;-) 2010-12-14 22:03 oh I just assume it's a totally not thought through messs 2010-12-14 22:03 until proven otherwise 2010-12-14 22:03 kristianpaul: i was thinking of a SYNC-out signal that alternates at SYNC/4 2010-12-14 22:04 about those controllers, they seem to have 6-8 pin connectors going to the notebook mainboard. P+ P- C D T 2010-12-14 22:04 kristianpaul: but what you really need at the moment is just something that's slow enough that you can keep up with the CPU 2010-12-14 22:04 kristianpaul: for the real interface, you probably want DMA. not sure if you want to implement DMA already now. 2010-12-14 22:05 wpwrak: (slow) thats why i'm arranging data in 16 bits not 4, 2010-12-14 22:05 wpwrak: no DMA now 2010-12-14 22:05 wolfspraul: 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* 2010-12-14 22:05 any idea what P+ P- C D T could stand for? I should do some googlin 2010-12-14 22:06 I don't think there is much reverse engineering to do 2010-12-14 22:06 wolfspraul: 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 produce 2010-12-14 22:06 the chips on those boards are mostly bq.... (from TI I think) 2010-12-14 22:06 wolfspraul: all kinda long-termish 2010-12-14 22:06 dealing with the batteries 2010-12-14 22:06 wpwrak: 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 doing 2010-12-14 22:06 TI is good. they can write ;-) 2010-12-14 22:07 we would only need to understand the connector interface 2010-12-14 22:07 wpwrak: they are all common, because they are all very similar 2010-12-14 22:07 P+ P- C D T 2010-12-14 22:07 :-) 2010-12-14 22:07 just in different randomization on the connector 2010-12-14 22:07 wolfspraul: interface and semantics, i.e., the whole circuit ;-) 2010-12-14 22:08 wolfspraul: 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. 2010-12-14 22:09 wolfspraul: also, please be careful not to confuse regulators with the charging circuit. i think these little boards only have the latter. 2010-12-14 22:09 yes 2010-12-14 22:09 correct 2010-12-14 22:09 I don't confuse them 2010-12-14 22:09 I'm just saying we can source this 6 USD thing and have super flexibility on the battery side 2010-12-14 22:09 one problem less to worry about 2010-12-14 22:10 wolfspraul: 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. 2010-12-14 22:10 and whatever case we build, fitting this controller in in a minor additional task, especially if there are batteries anyway 2010-12-14 22:10 so if we have any plans to reuse such controllers, we should understand them first before thinking about the PSU on Xue 2010-12-14 22:10 kristianpaul: so i guess 16 bit with a slow sync out should be okay ? 2010-12-14 22:11 kristianpaul: all you need now is to receive a few (thousands, millions, whatever) samples. no processing. right ? 2010-12-14 22:11 wpwrak: right 2010-12-14 22:12 wpwrak: (slow sync) yes, i'll let my brain analize it while sleeping, but i think it should work 2010-12-14 22:12 shift registers is amazing usefull :) 2010-12-14 22:12 wolfspraul: perhaps buya few, take a high-res picture of the top. that should make it possible to figure out roughly what they do. 2010-12-14 22:13 kristianpaul: why not ? do you expect to be too slow/irregular ? 2010-12-14 22:13 wpwrak: i dont see relation betweeen slow and irregulare so i dont think si 2010-12-14 22:13 s/si/so 2010-12-14 22:14 kristianpaul: (irregular) i mean occasional long delays, e.g, because there's an interrupt or such 2010-12-14 22:15 I already bought a few and sent to Andres, but not much happened 2010-12-14 22:15 I should have kept them or sent elsewhere :-) 2010-12-14 22:16 kristianpaul:  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. 2010-12-14 22:16 one 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. 2010-12-14 22:16 you can plug in or out the dc jack at any time. 2010-12-14 22:16 wolfspraul: have you made high-res pictures ? ;-) 2010-12-14 22:16 the controller will take care of li-ion recharge cycles, try to minimize cell wear 2010-12-14 22:16 so why not learn more about this and reuse some of it... 2010-12-14 22:17 wpwrak: no I need to redo with another leader in mind? :-) 2010-12-14 22:17 sure. 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. 2010-12-14 22:17 wolfspraul: redo with the community in mind ;-) 2010-12-14 22:18 yes but those chips need to be chosen, then they need a support circuit 2010-12-14 22:18 wpwrak: i was thinking add a counter per every 16bits 2010-12-14 22:18 and 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) 2010-12-14 22:18 well i have more ideas now, but i'm off bed now 2010-12-14 22:18 gn8 2010-12-14 22:18 so 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 in 2010-12-14 22:18 the result should be the same 2010-12-14 22:19 wolfspraul: 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. 2010-12-14 22:19 notebook power supply as in 16V or more? 2010-12-14 22:19 what is your concern there? 2010-12-14 22:19 not handy if you want to run with USB power :) 2010-12-14 22:20 sure but we know too little 2010-12-14 22:20 the battery cells typically have around 4V? 2010-12-14 22:20 my 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 way 2010-12-14 22:21 ~3.7 V, no ? 2010-12-14 22:22 yes 2010-12-14 22:22 maybe those controllers are mostly about managing multiple cells and 'smart' charge cycles 2010-12-14 22:23 so the 6 pins just display themselves to the mainboard as 1 battery 2010-12-14 22:23 c = coulomb counter? 2010-12-14 22:23 t = temperature 2010-12-14 22:23 (total guess :-)) 2010-12-14 22:24 C = control ? :) 2010-12-14 22:24 you really need to get a picture. the rest can probably be found in the reference designs. 2010-12-14 22:25 regarding the "smart" cycles, there's a TON of Li-charger chips out there. 2010-12-14 22:25 how do you like the idea of moving the image sensor to a daughterboard (to be seated on the expansion header that's already there)? 2010-12-14 22:26 doesn't sound crazy to me 2010-12-14 22:26 would you also move the sensor PSU ? (yet another ~4 regulators) 2010-12-14 22:26 5 even. also with many underspecified resistors ;-) 2010-12-14 22:27 4 regulators for the sensor? 2010-12-14 22:28 naturally, under-specified regulators as well. different from the "main" regulators, too. i'm sure it all makes sense somewhere ;-) 2010-12-14 22:28 the sensor needs another psu? 2010-12-14 22:28 it's five of them. 4 x 2.8 V, 1 x 1.8 V 2010-12-14 22:29 something tells me that three of these 2.8 V regulators probably want to be beads ;-) 2010-12-14 22:29 are we trying to fix a few weaknesses, or are we trying to build a palace out of a rubble? 2010-12-14 22:29 as i said, i'm kinda curious about the whole PSU story 2010-12-14 22:30 it 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. 2010-12-14 22:31 so either carlos had too much of columbia's finest export or there's a communication problem between him and andres. 2010-12-14 22:32 (or there's an even weirder explanation. space aliens trying to prevent mankind from developing Xue technology or such ;-) 2010-12-14 22:34 it 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 ? 2010-12-14 22:34 that would explain panicky attempts to rush things 2010-12-14 22:43 it 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 plug 2010-12-14 22:44 i guess the answers we're looking for are much more psychological than technical ;-) 2010-12-14 22:47 [commit] Werner Almesberger: cameo: added KiCad Gerber input and path merging http://qi-hw.com/p/cae-tools/8999b30 2010-12-14 22:47 [commit] Werner Almesberger: cameo: adding toolpath adaptation language (in progress) http://qi-hw.com/p/cae-tools/f80a01a 2010-12-14 22:47 [commit] Werner Almesberger: cameo: changed dog_bone from global variable to argument http://qi-hw.com/p/cae-tools/1f63ef6 2010-12-14 22:47 [commit] Werner Almesberger: cameo/lang.y (align): completed alignment function http://qi-hw.com/p/cae-tools/c8b62c2 2010-12-14 22:47 [commit] Werner Almesberger: cameo: moved tool compensation from cameo.c to ops.c http://qi-hw.com/p/cae-tools/2bf4559 2010-12-14 22:47 [commit] Werner Almesberger: cameo: call tool compensation from script http://qi-hw.com/p/cae-tools/86c27db 2010-12-14 22:47 [commit] Werner Almesberger: cameo: added invocation with an optional script http://qi-hw.com/p/cae-tools/fe50add 2010-12-14 22:47 [commit] Werner Almesberger: cameo: various scanner and parser fixes http://qi-hw.com/p/cae-tools/ddcf519 2010-12-14 22:47 [commit] Werner Almesberger: cameo: documented X/Y translation commands, some small improvements http://qi-hw.com/p/cae-tools/f36f704 2010-12-14 22:47 [commit] Werner Almesberger: cameo: split numbers into dimensions and "bare" numbers http://qi-hw.com/p/cae-tools/68d5eff 2010-12-14 22:47 [commit] Werner Almesberger: cameo: cleaned up and documented the tool compensation http://qi-hw.com/p/cae-tools/3ae3d6c 2010-12-14 22:47 [commit] Werner Almesberger: cameo: fixed processing of omitted file names, documented file name usage http://qi-hw.com/p/cae-tools/26dc02e 2010-12-14 22:48 phew. another night and i'm there. but dinner first ... 2010-12-14 23:34 Hi wolfspraul 2010-12-14 23:34 ah hi! 2010-12-14 23:34 Werner is just having dinner 2010-12-14 23:34 he will be back in a bit 2010-12-14 23:35 andres-calderon: my brain was thinking so much about Xue last night that I could not sleep! :-) 2010-12-14 23:35 I liked it though :-) 2010-12-14 23:35 I 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? 2010-12-14 23:37 He! That was my proposal from the start...... I'm trying to understand, I guess in an open project chaos is normal. 2010-12-14 23:39 Only one board was what you suggested. 2010-12-14 23:39 me again? wow 2010-12-14 23:39 :-) 2010-12-14 23:39 what other things did I suggest or decide? 2010-12-14 23:39 if you like a sensor daughterboard, then let's do it. at least I have no technical reason against it. 2010-12-14 23:39 suggest 2010-12-14 23:40 I like the flexibility of elphel camera 2010-12-14 23:41 2 boards may be improve the design of the case. 2010-12-14 23:41 I like it because we can much quicker try different sensors 2010-12-14 23:41 and also other daughterboards 2010-12-14 23:42 the only important thing will be to be very smart in which fpga wires we route to the connector 2010-12-14 23:42 we already talked about lvds before 2010-12-14 23:42 i agree 2010-12-14 23:42 the smarter we are on the connector, the more flexibility we have later 2010-12-14 23:43 is the design of the sensor PSU finished? 2010-12-14 23:44 is only one copy of the reference design.... (unchecked) 2010-12-14 23:45 a copy from the Aptina design 2010-12-14 23:50 andres-calderon: ok, another question first. do you remember the notebook battery controllers I sent you once. 2010-12-14 23:50 Aptina CIS and PSU can be moved to a second board easy... 2010-12-14 23:50 did you do anything with them? can we use them to hookup battery cells to the Xue board? 2010-12-14 23:50 well I like that, barring other feedback that would make me change my mind... :-) 2010-12-14 23:51 of course...   I review  some those chips. Almost all exotic to me. 2010-12-14 23:52 but the designs are beautiful, very simple. 2010-12-14 23:52 do you see any use in conjunction with Xue? 2010-12-14 23:53 sorry difficult english: do you see any use together with Xue? 2010-12-14 23:53 almost a half of component  from the Ti and Linear reference designs 2010-12-14 23:54 I can buy those controllers easily, for about 6 USD 2010-12-14 23:54 wow 2010-12-14 23:54 from 1 to any amount 2010-12-14 23:54 I intended to use only a cell Xue. 2010-12-14 23:54 but.... 6 USD! 2010-12-14 23:55 sure 2010-12-14 23:55 even buy 1, no problem 2010-12-14 23:55 :-) 2010-12-14 23:55 almost back :) 2010-12-14 23:56 I think we can use them. If we can solve the problem of the connector. 2010-12-14 23:57 what is on those battery controller boards? 2010-12-14 23:57 the connectors seem to have pins like P+ P- C D T 2010-12-14 23:57 do you know what they mean? 2010-12-14 23:58 please can You share  the  link to the photo of the chargers