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