#milkymist IRC log for Monday, 2011-11-14

wolfspraulthe usb/reset ic problems reported on the list make me wonder whether we shouldn't go with the other safer idea that was proposed (hooking it up to different rails)00:56
wolfspraulwpwrak: you can see the drops you reported on the list today, but what about arbitrary other USB devices? usb is a very rough world, lots of stuff pushing beyond the standard is on the market00:57
wolfspraulI remember a story from caiaq for example that they now design USB for 700-800 mA per port, because there are quite a few devices that will simply draw that much and expect to get it00:58
wolfsprauland a Mac (well, the reference point, he :-)) will happily provide 700 mA or more00:58
wolfsprauljust as an example00:58
wolfspraulso if our reset circuit is weak, maybe in the future m1 will gain a reputation of being 'unstable' when plugging in USB devices...00:59
rohwell.. what devices should use that much and are supported sw-wise anyhow?01:15
rohmouse with integrated coffeemachine?01:15
wolfspraulyes but it may be just a little extra kick now to do it right, versus a big "oh my god not that" thing x months later01:16
rohsure. just know that 500mA at 5V are 2.5W thats about what mm1 uses for power i guess01:26
rohso you need to basically spec your psu 3 times as big as for a mm1 and keyboard and mouse if you want 700mA at 2 ports safely01:26
wolfspraulI didn't say that, it was just an example as what one may encounter in USB land01:30
rohn.p. .. just thinking it through ;)01:30
wolfspraulI'm not saying we need to design for 700 or 800 ma01:30
rohusually you get 500mA per hub01:31
rohor port pair01:31
wolfspraulbut I am saying from specific industry experience (caiaq/native instruments here) that others do :-)01:32
wolfspraulthe question we have now is just whether to go with the proposed ic to connect the reset circuit to different rails01:32
rohwas is prototyped more than once?01:32
wolfspraulWerner's latest results somehow suggest to me that we are at the edge trying to do this on the 5V one, just as already pointed out on the list earlier (forgot by whom)01:32
rohif not i suggest rework 10 boards, run same tests again01:32
rohjust to reduce the stupid measurement noise a bit ;)01:33
wolfspraulhere http://lists.milkymist.org/pipermail/devel-milkymist.org/2011-October/002025.html01:37
wolfspraulSMT617901:37
rohi like werners 1 rail solution01:38
rohsimple and already prototyped01:38
wolfspraulactually that's a typo, maybe SMT671901:40
rohi guess its rather a sourcing question than a technical one. i bet we would get it to work with both solutions01:40
wolfspraulsure, fine. if werner thinks with a 4.0v reset ic it's stable, then so be it.01:40
wolfspraulyou cannot always stack one protection on top of another to gain 'safety', that's for sure01:40
rohexactly. and since werner has one board to test.. add more samples to the stats01:41
rohor did you already sell all of them? ;)01:42
wolfsprauland in the same mail Ed suggests a 12V->5V regulator, where I don't know whether that leads us in the right direction01:42
rohjust more waste or another switching regulator01:43
wolfspraulsome of those uber-regulators easily cost 10 USD...01:43
rohyou mean modules?01:43
wolfspraulforgot which one exactly, but they can be costly that's my memory01:43
rohsure01:43
rohif you want to make it cheaper, move the psu to the board and dont source it 3rd party. safes a few euros for sure01:44
rohbut you need to source the coil, the diodes, caps and the psu switcher chip then01:45
rohdunno if that pays of in those volumes01:45
wolfspraulanother typo. STM6719 maybe :-)01:45
wolfspraulok one by one, we are not looking for ways to waste time and money.01:46
wolfsprauljust a simple little question: 4.0v reset ic or different rails...01:46
rohmonitoring all rails would make sure we are safe even in case of some other ldo overload01:49
rohso.. maybe its just luxury.. depends on the real world loads on the ldo and their buffercaps01:49
roh(means what order voltages rise and fall on power up/down)01:49
wolfspraulSTM6719 is about 1.50 USD on digikey in low volume01:51
rohwell.. make sure its tested01:52
wolfspraulsure if we think this is better, then we need to source it, design verification, etc.01:56
GitHub32[scripts] xiangfu pushed 2 new commits to master: http://git.io/UE0CaQ03:01
GitHub32[scripts/master] lm32 toolchain: update gdb to 7.3.1 - Xiangfu Liu03:01
GitHub32[scripts/master] add gdb bit-ism-and-more-sloppy-macros.patch by werner - Xiangfu Liu03:01
wpwraklekernel: btw, what would i have to do to enable full-speed USB ? just kick some register bit ? (and make navre not fail the port)04:21
wpwrakwolfspraul: yes, i'd say we're seeing the limits of the design relying on an external 5.0 V supply that then trickles down to the USB ports. M2 wants something nicer ;-)05:49
wolfspraulthe external supply we provide is not an unknown (just for completeness) http://en.qi-hardware.com/w/index.php?title=File:Sharism_5V_2000mA_KS032940_s54878.pdf05:52
wolfspraulshould we switch to the proposed three-input STM chip in rc4?05:53
wolfspraulwhat about Sebastien's new ideas?05:54
wolfspraulactually I'm hesitating to think of the 5V supply as this unknown/unregulated thing05:54
wolfspraulthat's just not the case. the power supply, even external, is a very well specified circuit as well, chosen as per our requirements05:55
wolfspraulsure we can prepare for people attaching 'unknown' supplies, but that logic can be applied indefinitely until we ship our own diesel generator with each m1 :-)05:56
wpwrakoh, i'm not saying your power supply is evil05:57
wpwrakbut you still have the problem that you have a fairly complex chain of things hanging off it that's supposed to have hardly any loss along the path05:58
wolfspraulunderstood, so let's look at actual options05:58
wolfspraulevaluate stm now?05:59
wpwrakand yes, you get the issue of people using other supplies, too05:59
wolfspraulactually I think it's rare unless we ship without supplies which we don't do06:00
wpwrak(stm) we can do this. it's a bit messy (for evaluation), but not impossible06:00
wolfspraulnah we have to make an economic decision06:00
wolfspraulof course we can evaluate many things06:00
wolfspraulhow about the ferrite beads and increasing value of decoupling caps [proposed by Sebastien]06:01
wpwraksee the mailing list ;-)06:01
wpwrakbeads seem to be pointless06:01
wpwrakwe're in the kHz range here. beads are nice for MHz06:02
wolfspraulah, and then the diodes usb power switch06:04
wpwraki like that current switch, though. it may solve a bunch of issues at once06:04
wolfspraul(btw, datasheet also mentions 0.7A if I see this correctly)06:04
wolfspraulso you think 4.0v reset ic + diodes usb power switch?06:05
wpwrakyes, nominal 0.5 A, but will only kick in around 0.7 A. but careful, that's typical. minimum is still 550 mA06:05
wpwrakthat may work, yes06:05
rohwell.. be careful. too much caps make the same issues (brownouts)06:07
wpwraki think USB is the only place where the 5 V rail is directly exposed06:07
rohremember the openmoko debugboard v2 to v3 changes? ;)06:07
wpwrakin technicolor and 3D ;-)06:07
roh;)06:08
wolfspraulhow about increasing the decoupling usb caps?06:09
wpwraki think it was me who asked EE to check that inrush current. explained how to measure it. big "aha" moment ;-)06:09
rohwell.. make room for a real coil ;)06:10
wpwrakthe next day i had a reworked debug v2 :) (i was i tpe at that time)06:11
rohsomething in the mH range *duck*06:11
wpwraks/i tpe/in tpe/06:11
wpwrakyeah. always ask yourself what tesla would have used ;-)06:11
rohanyhow.. if you change the psu from 5V to something higher... i would go for a switching regulator. and then we can go to 5-15V range06:12
rohwell.. one thats not only stepdown but also stepup. brownout at 4.5V or so06:13
wpwrakroh: yes, i'd feel much better with an on-board regulator that beats the input into shape. up/down would be nice, too, agreed :)06:13
wpwrakthe current design is a bit what the french call "bricoler" :)06:15
rohheh. i just designed a few small rs485 io nodes. uses a mc34063 and 2 coils to stepdown from ~24V to 5V06:16
rohldo would need bigger bus wires due to wasting more in heat than using :)06:17
wpwrakldo = no go :)06:18
wolfspraulthe ones we found in the past were too expensive, candidate was National LMZ1200206:19
wolfspraulwww.national.com/ds/LM/LMZ12002.pdf06:20
wpwrakit would actually be nice to have a PMIC that integrates step-down (or up/down) and LDOs. nothing as hyper-complex as the critter we had at openmoko, but still with some degree of integration. that would also give us a controlled power-up sequence.06:20
rohhow many voltages and which one at what load do we need?06:21
wolfsprauleasily 10 USD in low quantities06:21
wpwrakthe current hodgepodge where rails come and go as they please is just asking for the kind of trouble we're seeing06:21
wpwraksomething like 5V, 3.3 V, 2.5 V, 1.8 V, and 1.something V06:22
wpwraklemme check ...06:22
wpwrak5, 4.3, 3.3, 2.5, 1.8. 1.206:23
wpwrak4.3 seems to be just audio06:24
wpwrakdunno about current. aw_ ?06:25
rohwpwrak: hm.. well.. somethin with coil can be cheaper i guess06:27
wpwraki'm also not sure if it's really such a great idea to chain LDOs as in the case of U11 (2.5 V) - U13 (1.2 V)06:28
aw_wpwrak, what current you're asking?06:29
wpwrakaw_: basically all the power rails on M1. do we have a current distribution diagram for the whole M1 ?06:29
rohwpwrak: depends.. chaining can help reduce thermal load on the ldo when done right06:30
aw_do you mean how's consumption of those all rails of supplies?06:30
rohaw_: yes. all voltages and the load on these rails would be nice to know06:30
wpwrakaw_: their designed maximum consumption, yes06:30
aw_hmm...good questions: here you are, http://en.qi-hardware.com/wiki/Milkymist_One_RC1_Reports#Measurement_of_Voltage.2FCurrent_during_Standby.2FQuiescent_Mode06:30
wpwrak;-)06:31
aw_the designed maximum consumption which i think that no one has done before. but I tried to measure each rail of them on M1rc1 board without any s/w porting then.06:32
wpwrakquiescent is a start, thanks06:32
rohyes06:33
wpwrakwell, we can take the ratings of the existing regs at a start06:33
rohi guess we need some min-max table06:33
wpwrakand then ask lekernel what he used as a reference. maybe he simply copied from his eval board design.06:34
wpwraklekernel: btw, is it this week that you're returning to hack-on-M1 mode ?07:30
wolfspraulwpwrak: some of that sounds *very* familiar :-) http://www.gag.com/bdale/blog/posts/RF_Immunity.html09:22
wolfspraul"One of the big changes between v1.0 and v1.1 on TeleMetrum was that the newer boards incorporate a better reset circuit. This helps ensure the GPS chip always comes up running at power on, which was a problem at temperature extremes with older boards. However, a side-effect of this change is that a v1.1 board will reset any time the 3.3 volt rail drops below 3.15 volts, whereas older boards didn't trip until a much lower voltage."09:23
wolfspraul"The first hardware change is moving to a slightly lower trip voltage on the reset controller. Instead of 3.15, the new part trips at 3.00 volts nominal. This gives us more "headroom" to tolerate 3.3 volt rail droop during charge firing..."09:23
wolfspraul:-)09:23
wpwrakhehe ;-)10:29
wpwrakyeah, it's always tempting to have an overly aggressive voltage monitor10:30
lekernelof course, full speed transfers do not work11:30
lekernelgrmbl11:30
lekernel"interestingly", some devices go a bit further than others. not the LV3, unfortunately11:36
GitHub67[milkymist] sbourdeauducq pushed 1 new commit to master: http://git.io/NhlzMQ11:46
GitHub67[milkymist/master] USB: try enumerating full speed devices - Sebastien Bourdeauducq11:46
lekernelwpwrak: I remember you had some USB protocol decoder software?12:01
lekernelI have a beagle 12 and it's a true piece of crap12:01
lekernelthe guys at totalphase are geniuses: they developed a debug tool which doesn't work when your devices send broken packets12:01
lekernelit just discards such packets by the thousand and groups them in "sync errors"12:01
lekernelretards12:01
wpwraklekernel: my USB decoder is in http://svn.openmoko.org/developers/werner/ahrt/host/tmc/lib/decode.py13:13
wpwrakis's used by http://svn.openmoko.org/developers/werner/ahrt/host/tmc/lib/dxplore.py13:13
lekernelhmm... what can I feed as input?13:14
wpwrakwhich in turn is fed by the rest of the infrastructure there. the data comes from a scope with deep memory (rigol ds1102cd, with 512 kSa per channel)13:14
wpwrak(beagle 12) not so clever ;-)13:15
wpwrakyou could probably hack a recorder reasonably quickly with an FPGA13:16
lekernelit's not _that_ simple, you need to transfer or store the relatively high bandwidth data to the PC ...13:17
wpwrakuse an M1 and dump the data to RAM ?13:17
lekernelyeah, but it needs DMA, software, etc.13:18
wpwrakand yes, moving the data to the PC is where most of those inexpensive USB LAs fail ;-)13:18
wpwrakwell, you have all that already :)13:18
lekernelI could also use the same FPGA...13:19
lekernelself logic analyzer13:19
lekernelbut either way it's a little mess13:19
wpwrakah, here are my "batch decoder" scripts: http://projects.qi-hardware.com/index.php/p/ben-wpan/source/tree/master/atusb/fw/an13:21
lekernelthat crap totalphase software also tries to reorder packets by what it thinks to be USB transactions, instead of presenting it by chronological order13:27
lekernelaaargh13:27
lekernelwhat do they think their stuff is good for? debugging perfect USB transactions? useful product, that.13:28
wpwrakmaybe there's a red/green idiot LED, too ? ;-) "hooray, i've fixed it for you !"13:35
lekernelhttp://www.totalphase.com/offer/customer-contest-2011/13:39
lekernelI guess I'll give it a go... and ask for a RMA13:39
wpwraki don't see them mention horror stories ;-)13:41
lekernelwpwrak: what do you think of the openbench?13:42
wpwrakuses only fpga-internal memory -> short13:47
wpwrakyou'd have to put the usb decoder for the fpga13:47
wpwraks/for/into/13:47
lekernelchicken and egg problem ...13:50
wpwrakso how about making that little M1-LA ? :) just stream N bits at rate R samples/sec into a DRAM buffer of size S. very simple.13:51
wpwraksince you have a ton of memory, you probably don't even need a trigger13:51
wpwraklet's see ... 2 bits, let's use 128 MB, at 50 MHz ...13:51
wpwrakhalf a minute. that's forever ;)13:52
wpwrakthen move all the stuff to the PC over ether. does M1 do 10 or 100 Mbps Ether ?13:52
kristianpaul1MB/s :-) last time i tried13:53
wpwraki somehow suspected that :)13:54
wpwrakM1 has all the hardware one level better than what the SOC actually supports ;-) USB, Ether, VGA, ... :)13:54
wpwrakwell, better than the opposite ;-)13:55
lekernelLA.. phew, too much (boring) work14:01
lekernelI give up. USB and totalphase suck.14:04
kristianpaulmay be considering now SDIO-like protocols .. ?14:05
kristianpaul32Gb memcards are getting cheap too, dump all sdram content there a few times :)14:07
lekernelworse14:07
kristianpauli know ;-)14:08
kristianpaulah, well you said jtag-serial pod can achieve up to 24 Mbps, may be consider an upgrade now?14:09
wolfspra1lI think we should change how we talk about missing features or performance of some peripherals on m114:11
wpwrak"upgradeability" :)14:11
wolfspra1lright now we say "ethernet" or "usb" or "vga" and then we let people discover themselves that the actual performance is much less than what most people would expect nowadays when they hear those things14:11
wolfspra1lI mean even myself I am still in this process, because it seems we are deliberately hiding the facts14:11
wolfspra1lthat gets everybody into some kind of "lets' see which feature I have not yet discovered not working" mode14:12
wolfspra1lI don't think the actual specs are any problem, in fact the focus is good on something that works now, rather than chasing specs14:12
wolfspra1lbut the way we talk about them, I think we can improve. I will start :-)14:12
wpwraki find that mode actually quite enjoyable ;-) i get three good things out of each discovery: 1) i get to tease lekernel a little, 2) i get to scare wolfspra1l a bit, 3) sometimes i get something i can fix ;-)14:13
wolfspra1lso maybe from now on I will say "1 MBit/sec Ethernet" or "640x480 VGA" or "Low-speed USB" or "DDR1" (instead of just DDR)14:13
kristianpaulwpwrak: yes :)14:13
wolfspra1lof course that's only to developers/technically interested people14:13
lekernelDDR = DDR114:13
lekernelhttp://en.wikipedia.org/wiki/DDR_SDRAM14:14
wolfspra1lwell my point is about what expectations certain terminology creates, irrespective of what the book says14:14
wolfspra1lyou say USB, people say "oh, usb stick", or "oh, wifi/3g dongle"14:14
wolfspra1lyou say VGA, they ask about HD14:14
wolfspra1lyou say Ethernet, they ask about gigabit ethernet14:15
wolfspra1land so on14:15
wpwrakthe ether is actually 10 Mbps - nobody bothered to make anything slower than that. and hey, it was good enough to connect a whole room of top notch unix workstations just a few years ago ;-)14:15
lekerneloh, ok14:15
lekernelshould we make a device with DDR3, HDMI etc.?14:15
lekerneland no time wasters like USB14:15
wpwrak(of course, all the other students hated us when we played xtanks on that segment and made their NFS time out :)14:15
lekernelwpwrak: the main source of ethernet slowness is software. not even FPGA design, what runs on the LM32. and it's fast enough for what it does at the moment.14:16
kristianpaulhum i tought MB was Mega Byte?14:16
wolfspra1lone by one, priorities have not been bad I think, otherwise we wouldn't have gotten m1 to where it is today14:16
wolfspra1llekernel: yes, I am only suggesting a change in communication, nothing technical14:16
wolfspra1lright now I think the truth is we leave it to people to find out what does *not* work14:16
wpwrakwolfspra1l: it's a bit tricky to talk about things like this. first of all, you draw attention to the shortcomings. second, some of them are only temporary. third, some are hard to explain, such as the USB driver situation.14:16
wolfspra1la risky strategy :-)14:16
wolfspra1loh sure, I don't want that14:16
wolfspra1lbut I don't want m1 to be known as something where you have to find out all the things that don't work yourself14:17
wpwrakkristianpaul: MB = MegaByte, Mb = Megabit14:17
wolfspra1lI think kristianpaul and wpwrak can both relate to that experience already :-)14:17
wolfspra1lso we have to be smart how we communicate what works and what doesn't, and what is possible etc.14:17
wolfspra1lcoming out with a new device in 2011 that can barely do 10 mbit/ethernet, low-speed usb, and 640x480 vga really *IS* something unusual :-)14:18
wolfspra1lI have totally no problem defending this, and it can be fun and can be a great way to get people interested. but we have to be careful I think.14:18
wolfspra1lif we pretend that all is 'normal' with our usb/ether/vga, people may be disappointed14:19
lekernelethernet is 100Mbps14:19
kristianpaulfor the record, the uplink still 100M14:19
wolfspra1lthings lighten up alraedy ;-)14:19
kristianpaulmax troughput is other topic :)14:19
wolfspra1lhey I said I am happy and I'm not worried, but my point was about communication14:20
wolfspra1lI don't want to be known as hyping something, and the other side has to find out the shortcomings themselves14:20
wolfspra1lthat will backfire14:20
wolfspra1lwe need to get the real point across, without drawing attention to shortcomings as werner said, but also without raising expectations and thus setting up people for failure14:21
wolfspra1lso... ether is how muhc now?14:21
wolfspra1lhardware is 100m14:21
wolfspra1l100 mbit/sec14:21
wolfspra1lbut kpaul can get how much?14:21
kristianpaul:-)14:21
wolfspra1lusb is low-speed right now, lekernel looking into full-speed as we chat14:22
wolfspra1lvga we know quite well now, 640x480 rendering, 1024x768 gui, no ddc14:22
lekernel...and (re)discovering that totalphase makes products much crappier than what we do14:22
wolfspra1l:-)14:22
wolfspra1lkristianpaul: what's the throughput you have seen?14:23
lekernelhe14:23
kristianpaulwolfspra1l: 1 Megabyte per second, full duplex14:23
wpwrakwolfspra1l: i'd just call the whole M1 "rough". there are still a lot of construction sites that need to be closed before you have what could be considered a "consumer device"14:23
lekernelshould I really have implemented a fast ethernet controller? with DMA, scatter-gather, hw CRC and what not?14:24
lekernelto transfer patches and the occasional software update?14:24
wolfspra1lright14:24
kristianpaulsure not lekernel ;)14:24
wolfspra1lthat's why we got m1 to where it is today14:24
kristianpaulindeed !!!14:24
wpwrak(hw CRC) yes ;-)14:24
kristianpaulhe14:25
wolfspra1l(in case my msg was ambiguous - I meant 'no', of course not :-))14:25
kristianpaulall is okay, M1 is not intedent for development, if you need something devel just do it, if you need that gclk pin with bufio2 just do the rework ;-)14:40
wpwrakhuh ? i think it's very much "for development" at the moment :)14:42
GitHub123[milkymist] sbourdeauducq pushed 1 new commit to master: http://git.io/O-uK5Q14:42
GitHub123[milkymist/master] USB: retry address setting - Sebastien Bourdeauducq14:42
lekernelwpwrak: could you try attaching a USB full speed device with the current softusb firmware?14:42
lekernelby the way, you can find the "silly" demo firmware quite useful here, as you can netboot it very fast and it displays all the AVR messages on the serial console14:43
kristianpaulwpwrak: sure sure, i dont meant the contrary14:43
wpwrakright now, it has well passed the "proof of concept" stage, but is still very much "for early adopters" (who don't mind a bit of grease on their hands)14:43
kristianpaulsure14:43
wpwraklekernel: lemme see ...14:44
lekernelwpwrak: if you want to use directly the git version, you have to reflash soc+bios14:44
lekernelotherwise just use the v1.0 branch and copy the softusb code... the rest is compatible14:45
lekernelwpwrak: btw, ./build_demo.sh builds everything, including the softusb firmware, into a nice image you just have to boot to test the USB mods14:46
wpwrakjust fn shold be okay too, no ?14:46
lekernelif you want, but it's more complicated than using the demo firmware14:46
lekerneland you won't see the AVR debug messages14:46
wpwrakflashing FN ...14:47
lekernelflashing?!14:47
wpwrakto NOR14:48
lekernelyes14:48
lekernelbut the BIOS supports TFTP :)14:48
kristianpaulbut tftp is temporary :)14:48
wpwrakflashing takes seconds14:48
kristianpaulwpwrak: i mean i dont want to mean you cant develop on it, just the " developer out of the box experience" like the hihg speed trasfer to the pc, the support for dedicated clock route in my particular case, ok let see M1 is not a "SDK" product like a xilinx dev board etc..14:49
kristianpauli hope you get my point14:49
lekernelkristianpaul: is there a single development board which has "hihg speed trasfer to the pc"?14:50
wpwrakfunny. my hhkb didn't kill it this time14:50
wpwrakbut i don't work either14:50
lekernelwpwrak: is that a full speed device?14:50
wpwrakes14:50
wpwrakyes14:51
lekernelok. now could you please take your mighty rigol scope and do a capture of the USB signals? :)14:51
kristianpaullekernel: well, at least faster ethernet transfers, or uart with Megabytes/s support transfers14:52
wpwraklemme see how i can wire this up ...14:52
kristianpaulbut is OKAY, really, i like my M114:52
kristianpaulthan buying those others boards14:52
lekernelkristianpaul: that's a FPGA design problem, not a board problem. most other FPGA systems are equal or worse.14:52
kristianpaulyes of course :-)14:53
kristianpaulI dint mean that otherwise, thats the good thing abut upgradeability :-D14:53
lekernelwpwrak: rc2+ boards have test points before the transceiver... but you may want to probe at the plug directly in case there's a bug e.g. with the direction control14:54
wpwrakhmm. i think i'll try with the test points first. don't want to upset the analog signals14:57
lekernelthey're only 12Mhz... a decent 1:10 probe won't upset them14:58
wpwrakotherwise i need to make a buffer, etc.14:58
lekernelmh?14:58
wpwrakthat's what i once thought, too :)14:58
lekernelUSB is supposed to drive several meters of cable, too14:58
wpwrakdunno what exactly it disliked. but it didn't want to have my probes around. when i added a buffer, everything worked well14:59
wpwrakone item for the M1rc4 wish list: sprinkle some TPs connected to GND over the board so that we can find ground reasonably close to things we test15:00
wpwrakthe mighty rigol sees some traffic. let's see what it is ...15:17
Action: wpwrak wishes the mighty rigol was a bit faster on that USB ... downloading takes forever15:22
wpwrakactually, i could have zoomed in to help it a bit. hmm ..15:22
wpwrakyeah, better than to wait half an hour to dump the whole memory15:22
wpwrak[~SETUP0/0][~DATA0:00.05.01.00.00.00.00.00][~+15:26
lekernelthat looks like a correct set address packet15:28
lekerneldoes the device answer?15:28
wpwraklemme see  .... i have a second packet there15:31
wpwrakbtw, this is the processed signal: http://downloads.qi-hardware.com/people/werner/m1/usb/burst1.png15:32
wpwrakthe next packets are again  [~SETUP0/0][~DATA0:00.05.01.00.00.00.00.00]15:32
wpwrakthis is the whole session: http://downloads.qi-hardware.com/people/werner/m1/usb/usb1.png15:34
lekerneldid the first packet get answered by the device?15:34
wpwrakapparently not15:34
lekernelhum15:34
wpwrakCH1 (yellow) is TP2215:34
wpwraklet's see if you got the D+/D- inversion right15:34
lekernelit's in softusb_tx.v ... should be ok unless there's a subtle bug15:37
lekernelline 106+15:37
wpwrakyes, looks good15:39
wpwrakmaybe it's just the keyboard. let's try some other device15:39
lekernelI suspect similar behaviour from my devices...15:40
lekernelmaybe the signals are still driven by the transceiver and the devices can't answer?15:40
wpwrakwhere's that 3rd channel when you need it ? ;-)15:41
wpwraklemme check what my nanoKONTROL2 yields ...15:42
wpwrakprecisely the same pattern15:42
lekernelyou should be able to make sense of the signals by observing just one end of the differential pair15:46
lekernelthen the 2nd channel can be connected to OE15:46
wpwrakyes yes ...15:48
wpwraktried to get my scope to catch each transaction into segmented memory, but that doesn't work very well15:49
wpwrakonly saw 2 retries. there must me more.15:50
wpwraki see 22 of them15:51
lekernelok, this retry count is expected in the case the M1 gets total silence from the device15:58
lekernelwhich can happen for a variety of reasons (wrong CRC, wrong token, ...) which is part of the "beauty" of USB15:59
wpwrak(retry) yes, that's the expected outcome16:04
wpwrakhttp://downloads.qi-hardware.com/people/werner/m1/usb/CH1nOE-CH2DN.png16:05
wpwrakCH1 is nOE, CH2 is D-16:05
lekernelexcept for the noise, this looks reasonable16:05
wpwrakzoomed in on just on one packet16:05
lekernelso why are devices not answering?16:05
lekernelmaybe check at the USB connector too?16:06
lekernelthere's this "high speed slew rate" enable pin on the transceivers... if the level is wrong there, this can seriously degrade the full speed signal16:07
wpwrakhmm .. lemme see if i still have that atusb with buffers around16:07
wpwrakwell, you see the signals in http://downloads.qi-hardware.com/people/werner/m1/usb/burst1.png16:08
wpwrakah wait16:08
wpwrakthat's of course the digital side16:08
wpwrakdoesn't prove much then16:08
lekernelyes :)16:08
lekernelinterestingly I have one USB stick that does answer16:08
lekernelbut it fails later on16:08
lekerneltried another stick and the LV3, seems no answer at all (guessing from the totalphase crapware and the serial console log)16:09
wpwrak;-)16:10
wpwraknothing exciting o RCV either16:13
wpwrakand here's SPD: http://downloads.qi-hardware.com/people/werner/m1/usb/CH1SPD-CH2DN.png16:16
wpwrakeverything looks quite sane16:16
wpwraknice. gdb patch was accepted16:18
wpwraksame picture with atusb16:21
wpwrak(a regular one)16:21
wpwraklet's try a low-speed device for a change16:21
wpwraklow-speed: [~SETUP0/0][~DATA0:00.05.01.00.00.00.00.00][~ACK][~IN0/0][~DATA1][~ACK][~SETUP1/0][~DATA0:80.06.00.01.00.00.12.00][~ACK][~IN1/0][~DATA1:12.01.10.01.00.00.00.08][~ACK][~IN1/0][~DATA0:5E.04.40.00.00.03.01.03][~ACK][~IN1/0][~DATA1:00.01][~ACK][~OUT1/0][~DATA1][~ACK][~SETUP1/0][~DATA0:80.06.00.02.00.00.7F.00][~ACK][~IN1/0][~DATA1:09.02.22.00.01.01.00.A0][~ACK][~IN1/0][~DATA0:32.09.04.00.00.01.03.01][~ACK][~IN1/0][~DATA1:02.00.09.216:32
wpwrak1.10.01.00.01][~ACK][~IN1/0][~DATA0:22.48.00.07.05.81.03.04][~ACK][~IN1/0][~DATA1:00.0A][~ACK][~OUT1/0][~DATA1][~ACK][~SETUP1/0][~DATA0:00.09.01.00.00.00.00.00][~ACK][~IN1/0][~DATA1][~ACK][~IN1/1][~NAK][~+16:32
wpwrakhttp://downloads.qi-hardware.com/people/werner/m1/usb/usb-ls.png16:33
wpwrakcould perhaps the time between the last bit and turning off OE# be too long ?16:34
wpwrakin low-speed, i get about 300 ns between the last out bit and the first in bit16:35
wpwrakOE# seems to change about 400 ns after the last edge16:36
wpwrakthat still wouldn't explain why there's no response at all, though16:36
wpwrakmaybe the problem is on the other end. maybe assert OE# a bit earlier ?16:37
wpwrakfound my little atusb with instrumentation. let's see if it still works ...17:00
lekernelwpwrak: don't you see a glitch on OE# near the end of some packets?17:01
wpwrakit's this critter: http://downloads.qi-hardware.com/people/werner/tmp/teaser0.png17:02
wpwrak(glitch) hmm. lemme search17:02
lekernelby enabling OE# one 48MHz cycle earlier, I still get silence17:05
lekernelbut looking at the code I found something that might cause a glitch just before EOPs17:05
wpwraki don't see a glitch17:09
stekernhow are the SOFs generated in softusb?17:10
wpwrak(at 100 MSa/s, peak detect)17:10
wpwrakstekern: are they ? ;-)17:10
stekernI don't know, I'm the one asking ;)17:10
wpwrakhere's nOE at 100 MSa/s: http://downloads.qi-hardware.com/people/werner/m1/usb/CH1nOE-CH2DN-detail.png17:11
lekernelaah! they're not!17:15
stekernthat might explain things17:16
lekernelindeed17:16
wpwrakfor completeness, here's the beginning of packet side, at 200 MSa/s: http://downloads.qi-hardware.com/people/werner/m1/usb/CH1nOE-CH2DN-bop.png17:17
lekernelwhat's the hex encoding for the SOF token? anyone remembers?17:19
lekernela5?17:21
wpwraklooks good, yes17:21
lekernelzero effect17:22
lekerneltough...17:25
wpwraktough or though ?17:33
lekerneltough17:36
lekernelUSB is tough17:36
lekernelmassive time wastage on overengineered crap17:37
wpwrak;-)17:38
wpwrakit's like gravity. it may not always be convenient but ot17:39
wpwrakit's unavoidable :)17:39
GitHub194[milkymist] sbourdeauducq pushed 2 new commits to master: http://git.io/TOeesw17:42
GitHub194[milkymist/master] USB: generate SOFs - Sebastien Bourdeauducq17:42
GitHub194[milkymist/master] USB: shorter timeouts, fewer retries - Sebastien Bourdeauducq17:42
lekernelmy, my PC sends 2D 04 28 as SETUP17:52
lekerneland the M1 2D 00 1017:53
lekernelthat just says address 4. but changing it on the M1 side still gets me ignored17:56
lekernelincluding by that USB stick that used to acknowledge the "set address"17:56
lekernelmaybe it's just the totalcrap software that misses some packets...17:57
wpwrakintersting. i don't get a signal on one channel. i wonder if that's my board that's broken, though17:57
lekernelone channel?17:58
lekernelyou mean USB pin?17:58
wpwrakD+, yes17:58
wpwrakwas a bad solder joint18:05
wpwrakhmm. same picture. SETUP, then silence18:05
wpwraknow, let's compare this with the PC ...18:05
wpwrakoh, wait a minute ...18:12
wpwrakthe decoder says: [~SETUP0/0+SE1SE1[~DATA0:00.05.01.00.00.00.00.00+SE1SE1[~+18:12
wpwrakso the packets don't end18:12
lekernelyou mean, there's no EOP with the M1?18:13
lekernelSE1?18:13
lekernelSE1 should never happen, right?18:13
lekernelis that a decoder trace from M1?18:14
wpwrakbut wait .. that's probably okay18:14
wpwrakSE1 is SE0 - my buffer inverts18:14
wpwraklemme change the scripts ...18:14
wpwrakah, false alarm. sorry. now they're healty18:16
stekern0.18:16
stekernoops, sorry18:16
wpwrak[~SETUP0/0][~DATA0:00.05.01.00.00.00.00.00][~+18:17
wpwrakjust how it should be18:17
lekernelbut the PC sends the very same thing, and it gets a reply?18:19
wpwrakjust a sec ...18:20
wpwrakhmm, the pc does get an answer. now .. where amidst all those SOFs is it ...18:26
wpwrakphew. impossible to catch :-(18:34
wpwraki need to change my firmware to generate a trigger when it receives something18:53
wpwrakin fact, it does this, but i don't remember what condition i had programmed ;-)18:53
GitHub3[clang-lm32] jpbonn pushed 498 new commits to master: http://git.io/41PMdA19:18
GitHub3[clang-lm32/master] Refactor static analyzer to use simpler interface to constant expression evaluation. - Richard Smith19:18
GitHub3[clang-lm32/master] Reinstate r141898 (reverted in r141921), without the -Wc++98-compat-variadic-templates flag. Consensus is that -Wc++98-compat is a useful addition to clang, but per-C++11-feature warnings may not be. - Richard Smith19:18
GitHub3[clang-lm32/master] Don't try to diagnose anything when we're passing incomplete types - Douglas Gregor19:18
Action: kristianpaul finally desides to install the blobed altium viewver..19:26
kristianpaulaltmun designer summer 09 viwer was intterrupted? wtf?19:27
wpwrakthe time between making a difficult decision and ruing it was pretty short in this case :)19:29
kristianpaulargh, it get stuck19:32
kristianpaullekernel: what altium viewer build are you using? (asuming you run in wine)19:32
lekernelI don't use altium viewer19:33
lekerneland I run altium in virtualbox19:33
kristianpaulhum19:33
kristianpaulwell.. lets what i can do with gerbers19:34
kristianpaullekernel: what you think is easier to hack to get a glck with global clock bufer, ac97 or vga?19:42
lekernelwhat's your problem? you want to send a clock from the I/O port?20:07
lekerneljust use clock_dedicated_route=false. first, there is no other option, second, it will work unless you need precise I/O timings relative to that clock.20:10
Alarmlekernel: Hi ! Do you know a model of cheap mini projector DMX512?20:16
lekerneltry sonovente.com?20:28
qi-botThe Firmware build was successfull, see images here: http://fidelio.qi-hardware.com/~xiangfu/build-milkymist/milkymist-firmware-11142011-2001/20:58
lars_hm, i'm doing something wrong. removing stuff from the design and the timing gets worse21:19
kristianpaullekernel: yes thats my problem, and yes i had been using that clock_dedicated...=false22:18
kristianpaulnot send, just avoid that =false i still dont like it22:21
kristianpaulbecause that clock input is actually the main clock for my custom miljymist soc22:22
--- Tue Nov 15 201100:00

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