<wolfspraul>
the 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)
<wolfspraul>
wpwrak: 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 market
<wolfspraul>
I 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 it
<wolfspraul>
and a Mac (well, the reference point, he :-)) will happily provide 700 mA or more
<wolfspraul>
just as an example
<wolfspraul>
so if our reset circuit is weak, maybe in the future m1 will gain a reputation of being 'unstable' when plugging in USB devices...
<roh>
well.. what devices should use that much and are supported sw-wise anyhow?
<roh>
mouse with integrated coffeemachine?
<wolfspraul>
yes 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 later
<roh>
sure. just know that 500mA at 5V are 2.5W thats about what mm1 uses for power i guess
<roh>
so 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 safely
<wolfspraul>
I didn't say that, it was just an example as what one may encounter in USB land
<roh>
n.p. .. just thinking it through ;)
<wolfspraul>
I'm not saying we need to design for 700 or 800 ma
<roh>
usually you get 500mA per hub
<roh>
or port pair
<wolfspraul>
but I am saying from specific industry experience (caiaq/native instruments here) that others do :-)
<wolfspraul>
the question we have now is just whether to go with the proposed ic to connect the reset circuit to different rails
<roh>
was is prototyped more than once?
<wolfspraul>
Werner'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)
<roh>
if not i suggest rework 10 boards, run same tests again
<roh>
just to reduce the stupid measurement noise a bit ;)
<wolfspraul>
actually that's a typo, maybe SMT6719
<roh>
i guess its rather a sourcing question than a technical one. i bet we would get it to work with both solutions
<wolfspraul>
sure, fine. if werner thinks with a 4.0v reset ic it's stable, then so be it.
<wolfspraul>
you cannot always stack one protection on top of another to gain 'safety', that's for sure
<roh>
exactly. and since werner has one board to test.. add more samples to the stats
<roh>
or did you already sell all of them? ;)
<wolfspraul>
and in the same mail Ed suggests a 12V->5V regulator, where I don't know whether that leads us in the right direction
<roh>
just more waste or another switching regulator
<wolfspraul>
some of those uber-regulators easily cost 10 USD...
<roh>
you mean modules?
<wolfspraul>
forgot which one exactly, but they can be costly that's my memory
<roh>
sure
<roh>
if you want to make it cheaper, move the psu to the board and dont source it 3rd party. safes a few euros for sure
<roh>
but you need to source the coil, the diodes, caps and the psu switcher chip then
<roh>
dunno if that pays of in those volumes
<wolfspraul>
another typo. STM6719 maybe :-)
<wolfspraul>
ok one by one, we are not looking for ways to waste time and money.
<wolfspraul>
just a simple little question: 4.0v reset ic or different rails...
<roh>
monitoring all rails would make sure we are safe even in case of some other ldo overload
<roh>
so.. maybe its just luxury.. depends on the real world loads on the ldo and their buffercaps
<roh>
(means what order voltages rise and fall on power up/down)
<wolfspraul>
STM6719 is about 1.50 USD on digikey in low volume
<roh>
well.. make sure its tested
<wolfspraul>
sure if we think this is better, then we need to source it, design verification, etc.
<GitHub32>
[scripts] xiangfu pushed 2 new commits to master: http://git.io/UE0CaQ
<GitHub32>
[scripts/master] lm32 toolchain: update gdb to 7.3.1 - Xiangfu Liu
<GitHub32>
[scripts/master] add gdb bit-ism-and-more-sloppy-macros.patch by werner - Xiangfu Liu
<wpwrak>
lekernel: btw, what would i have to do to enable full-speed USB ? just kick some register bit ? (and make navre not fail the port)
<wpwrak>
wolfspraul: 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 ;-)
<wolfspraul>
should we switch to the proposed three-input STM chip in rc4?
<wolfspraul>
what about Sebastien's new ideas?
<wolfspraul>
actually I'm hesitating to think of the 5V supply as this unknown/unregulated thing
<wolfspraul>
that's just not the case. the power supply, even external, is a very well specified circuit as well, chosen as per our requirements
<wolfspraul>
sure 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 :-)
<wpwrak>
oh, i'm not saying your power supply is evil
<wpwrak>
but 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 path
<wolfspraul>
understood, so let's look at actual options
<wolfspraul>
evaluate stm now?
<wpwrak>
and yes, you get the issue of people using other supplies, too
<wolfspraul>
actually I think it's rare unless we ship without supplies which we don't do
<wpwrak>
(stm) we can do this. it's a bit messy (for evaluation), but not impossible
<wolfspraul>
nah we have to make an economic decision
<wolfspraul>
of course we can evaluate many things
<wolfspraul>
how about the ferrite beads and increasing value of decoupling caps [proposed by Sebastien]
<wpwrak>
see the mailing list ;-)
<wpwrak>
beads seem to be pointless
<wpwrak>
we're in the kHz range here. beads are nice for MHz
<wolfspraul>
ah, and then the diodes usb power switch
<wpwrak>
i like that current switch, though. it may solve a bunch of issues at once
<wolfspraul>
(btw, datasheet also mentions 0.7A if I see this correctly)
<wolfspraul>
so you think 4.0v reset ic + diodes usb power switch?
<wpwrak>
yes, nominal 0.5 A, but will only kick in around 0.7 A. but careful, that's typical. minimum is still 550 mA
<wpwrak>
that may work, yes
<roh>
well.. be careful. too much caps make the same issues (brownouts)
<wpwrak>
i think USB is the only place where the 5 V rail is directly exposed
<roh>
remember the openmoko debugboard v2 to v3 changes? ;)
<wpwrak>
in technicolor and 3D ;-)
<roh>
;)
<wolfspraul>
how about increasing the decoupling usb caps?
<wpwrak>
i think it was me who asked EE to check that inrush current. explained how to measure it. big "aha" moment ;-)
<roh>
well.. make room for a real coil ;)
<wpwrak>
the next day i had a reworked debug v2 :) (i was i tpe at that time)
<roh>
something in the mH range *duck*
<wpwrak>
s/i tpe/in tpe/
<wpwrak>
yeah. always ask yourself what tesla would have used ;-)
<roh>
anyhow.. 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 range
<roh>
well.. one thats not only stepdown but also stepup. brownout at 4.5V or so
<wpwrak>
roh: yes, i'd feel much better with an on-board regulator that beats the input into shape. up/down would be nice, too, agreed :)
<wpwrak>
the current design is a bit what the french call "bricoler" :)
<roh>
heh. i just designed a few small rs485 io nodes. uses a mc34063 and 2 coils to stepdown from ~24V to 5V
<roh>
ldo would need bigger bus wires due to wasting more in heat than using :)
<wpwrak>
ldo = no go :)
<wolfspraul>
the ones we found in the past were too expensive, candidate was National LMZ12002
<wpwrak>
it 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.
<roh>
how many voltages and which one at what load do we need?
<wolfspraul>
easily 10 USD in low quantities
<wpwrak>
the current hodgepodge where rails come and go as they please is just asking for the kind of trouble we're seeing
<wpwrak>
something like 5V, 3.3 V, 2.5 V, 1.8 V, and 1.something V
<wpwrak>
lemme check ...
<wpwrak>
5, 4.3, 3.3, 2.5, 1.8. 1.2
<wpwrak>
4.3 seems to be just audio
<wpwrak>
dunno about current. aw_ ?
<roh>
wpwrak: hm.. well.. somethin with coil can be cheaper i guess
<wpwrak>
i'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)
<aw_>
wpwrak, what current you're asking?
<wpwrak>
aw_: basically all the power rails on M1. do we have a current distribution diagram for the whole M1 ?
<roh>
wpwrak: depends.. chaining can help reduce thermal load on the ldo when done right
<aw_>
do you mean how's consumption of those all rails of supplies?
<roh>
aw_: yes. all voltages and the load on these rails would be nice to know
<wpwrak>
aw_: their designed maximum consumption, yes
<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.
<wpwrak>
quiescent is a start, thanks
<roh>
yes
<wpwrak>
well, we can take the ratings of the existing regs at a start
<roh>
i guess we need some min-max table
<wpwrak>
and then ask lekernel what he used as a reference. maybe he simply copied from his eval board design.
<wpwrak>
lekernel: btw, is it this week that you're returning to hack-on-M1 mode ?
<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."
<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..."
<wolfspraul>
:-)
<wpwrak>
hehe ;-)
<wpwrak>
yeah, it's always tempting to have an overly aggressive voltage monitor
<lekernel>
of course, full speed transfers do not work
<lekernel>
grmbl
<lekernel>
"interestingly", some devices go a bit further than others. not the LV3, unfortunately
<GitHub67>
[milkymist] sbourdeauducq pushed 1 new commit to master: http://git.io/NhlzMQ
<wpwrak>
which 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)
<wpwrak>
(beagle 12) not so clever ;-)
<wpwrak>
you could probably hack a recorder reasonably quickly with an FPGA
<lekernel>
it's not _that_ simple, you need to transfer or store the relatively high bandwidth data to the PC ...
<wpwrak>
use an M1 and dump the data to RAM ?
<lekernel>
yeah, but it needs DMA, software, etc.
<wpwrak>
and yes, moving the data to the PC is where most of those inexpensive USB LAs fail ;-)
<lekernel>
that crap totalphase software also tries to reorder packets by what it thinks to be USB transactions, instead of presenting it by chronological order
<lekernel>
aaargh
<lekernel>
what do they think their stuff is good for? debugging perfect USB transactions? useful product, that.
<wpwrak>
maybe there's a red/green idiot LED, too ? ;-) "hooray, i've fixed it for you !"
<lekernel>
I guess I'll give it a go... and ask for a RMA
<wpwrak>
i don't see them mention horror stories ;-)
<lekernel>
wpwrak: what do you think of the openbench?
<wpwrak>
uses only fpga-internal memory -> short
<wpwrak>
you'd have to put the usb decoder for the fpga
<wpwrak>
s/for/into/
<lekernel>
chicken and egg problem ...
<wpwrak>
so 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.
<wpwrak>
since you have a ton of memory, you probably don't even need a trigger
<wpwrak>
let's see ... 2 bits, let's use 128 MB, at 50 MHz ...
<wpwrak>
half a minute. that's forever ;)
<wpwrak>
then move all the stuff to the PC over ether. does M1 do 10 or 100 Mbps Ether ?
<kristianpaul>
1MB/s :-) last time i tried
<wpwrak>
i somehow suspected that :)
<wpwrak>
M1 has all the hardware one level better than what the SOC actually supports ;-) USB, Ether, VGA, ... :)
<wpwrak>
well, better than the opposite ;-)
<lekernel>
LA.. phew, too much (boring) work
<lekernel>
I give up. USB and totalphase suck.
<kristianpaul>
may be considering now SDIO-like protocols .. ?
<kristianpaul>
32Gb memcards are getting cheap too, dump all sdram content there a few times :)
<lekernel>
worse
<kristianpaul>
i know ;-)
<kristianpaul>
ah, well you said jtag-serial pod can achieve up to 24 Mbps, may be consider an upgrade now?
<wolfspra1l>
I think we should change how we talk about missing features or performance of some peripherals on m1
<wpwrak>
"upgradeability" :)
<wolfspra1l>
right 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 things
<wolfspra1l>
I mean even myself I am still in this process, because it seems we are deliberately hiding the facts
<wolfspra1l>
that gets everybody into some kind of "lets' see which feature I have not yet discovered not working" mode
<wolfspra1l>
I don't think the actual specs are any problem, in fact the focus is good on something that works now, rather than chasing specs
<wolfspra1l>
but the way we talk about them, I think we can improve. I will start :-)
<wpwrak>
i 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 ;-)
<wolfspra1l>
so maybe from now on I will say "1 MBit/sec Ethernet" or "640x480 VGA" or "Low-speed USB" or "DDR1" (instead of just DDR)
<kristianpaul>
wpwrak: yes :)
<wolfspra1l>
of course that's only to developers/technically interested people
<wolfspra1l>
well my point is about what expectations certain terminology creates, irrespective of what the book says
<wolfspra1l>
you say USB, people say "oh, usb stick", or "oh, wifi/3g dongle"
<wolfspra1l>
you say VGA, they ask about HD
<wolfspra1l>
you say Ethernet, they ask about gigabit ethernet
<wolfspra1l>
and so on
<wpwrak>
the 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 ;-)
<lekernel>
oh, ok
<lekernel>
should we make a device with DDR3, HDMI etc.?
<lekernel>
and no time wasters like USB
<wpwrak>
(of course, all the other students hated us when we played xtanks on that segment and made their NFS time out :)
<lekernel>
wpwrak: 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.
<kristianpaul>
hum i tought MB was Mega Byte?
<wolfspra1l>
one by one, priorities have not been bad I think, otherwise we wouldn't have gotten m1 to where it is today
<wolfspra1l>
lekernel: yes, I am only suggesting a change in communication, nothing technical
<wolfspra1l>
right now I think the truth is we leave it to people to find out what does *not* work
<wpwrak>
wolfspra1l: 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.
<wolfspra1l>
a risky strategy :-)
<wolfspra1l>
oh sure, I don't want that
<wolfspra1l>
but I don't want m1 to be known as something where you have to find out all the things that don't work yourself
<wolfspra1l>
I think kristianpaul and wpwrak can both relate to that experience already :-)
<wolfspra1l>
so we have to be smart how we communicate what works and what doesn't, and what is possible etc.
<wolfspra1l>
coming out with a new device in 2011 that can barely do 10 mbit/ethernet, low-speed usb, and 640x480 vga really *IS* something unusual :-)
<wolfspra1l>
I 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.
<wolfspra1l>
if we pretend that all is 'normal' with our usb/ether/vga, people may be disappointed
<lekernel>
ethernet is 100Mbps
<kristianpaul>
for the record, the uplink still 100M
<wolfspra1l>
things lighten up alraedy ;-)
<kristianpaul>
max troughput is other topic :)
<wolfspra1l>
hey I said I am happy and I'm not worried, but my point was about communication
<wolfspra1l>
I don't want to be known as hyping something, and the other side has to find out the shortcomings themselves
<wolfspra1l>
that will backfire
<wolfspra1l>
we 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 failure
<wolfspra1l>
so... ether is how muhc now?
<wolfspra1l>
hardware is 100m
<wolfspra1l>
100 mbit/sec
<wolfspra1l>
but kpaul can get how much?
<kristianpaul>
:-)
<wolfspra1l>
usb is low-speed right now, lekernel looking into full-speed as we chat
<wolfspra1l>
vga we know quite well now, 640x480 rendering, 1024x768 gui, no ddc
<lekernel>
...and (re)discovering that totalphase makes products much crappier than what we do
<wolfspra1l>
:-)
<wolfspra1l>
kristianpaul: what's the throughput you have seen?
<lekernel>
he
<kristianpaul>
wolfspra1l: 1 Megabyte per second, full duplex
<wpwrak>
wolfspra1l: 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"
<lekernel>
should I really have implemented a fast ethernet controller? with DMA, scatter-gather, hw CRC and what not?
<lekernel>
to transfer patches and the occasional software update?
<wolfspra1l>
right
<kristianpaul>
sure not lekernel ;)
<wolfspra1l>
that's why we got m1 to where it is today
<kristianpaul>
indeed !!!
<wpwrak>
(hw CRC) yes ;-)
<kristianpaul>
he
<wolfspra1l>
(in case my msg was ambiguous - I meant 'no', of course not :-))
<kristianpaul>
all 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 ;-)
<wpwrak>
huh ? i think it's very much "for development" at the moment :)
<GitHub123>
[milkymist] sbourdeauducq pushed 1 new commit to master: http://git.io/O-uK5Q
<lekernel>
wpwrak: could you try attaching a USB full speed device with the current softusb firmware?
<lekernel>
by 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 console
<kristianpaul>
wpwrak: sure sure, i dont meant the contrary
<wpwrak>
right 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)
<kristianpaul>
sure
<wpwrak>
lekernel: lemme see ...
<lekernel>
wpwrak: if you want to use directly the git version, you have to reflash soc+bios
<lekernel>
otherwise just use the v1.0 branch and copy the softusb code... the rest is compatible
<lekernel>
wpwrak: btw, ./build_demo.sh builds everything, including the softusb firmware, into a nice image you just have to boot to test the USB mods
<wpwrak>
just fn shold be okay too, no ?
<lekernel>
if you want, but it's more complicated than using the demo firmware
<lekernel>
and you won't see the AVR debug messages
<wpwrak>
flashing FN ...
<lekernel>
flashing?!
<wpwrak>
to NOR
<lekernel>
yes
<lekernel>
but the BIOS supports TFTP :)
<kristianpaul>
but tftp is temporary :)
<wpwrak>
flashing takes seconds
<kristianpaul>
wpwrak: 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..
<kristianpaul>
i hope you get my point
<lekernel>
kristianpaul: is there a single development board which has "hihg speed trasfer to the pc"?
<wpwrak>
funny. my hhkb didn't kill it this time
<wpwrak>
but i don't work either
<lekernel>
wpwrak: is that a full speed device?
<wpwrak>
es
<wpwrak>
yes
<lekernel>
ok. now could you please take your mighty rigol scope and do a capture of the USB signals? :)
<kristianpaul>
lekernel: well, at least faster ethernet transfers, or uart with Megabytes/s support transfers
<wpwrak>
lemme see how i can wire this up ...
<kristianpaul>
but is OKAY, really, i like my M1
<kristianpaul>
than buying those others boards
<lekernel>
kristianpaul: that's a FPGA design problem, not a board problem. most other FPGA systems are equal or worse.
<kristianpaul>
yes of course :-)
<kristianpaul>
I dint mean that otherwise, thats the good thing abut upgradeability :-D
<lekernel>
wpwrak: 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 control
<wpwrak>
hmm. i think i'll try with the test points first. don't want to upset the analog signals
<lekernel>
they're only 12Mhz... a decent 1:10 probe won't upset them
<wpwrak>
otherwise i need to make a buffer, etc.
<lekernel>
mh?
<wpwrak>
that's what i once thought, too :)
<lekernel>
USB is supposed to drive several meters of cable, too
<wpwrak>
dunno what exactly it disliked. but it didn't want to have my probes around. when i added a buffer, everything worked well
<wpwrak>
one 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 test
<wpwrak>
the mighty rigol sees some traffic. let's see what it is ...
<wpwrak>
wishes the mighty rigol was a bit faster on that USB ... downloading takes forever
<wpwrak>
actually, i could have zoomed in to help it a bit. hmm ..
<wpwrak>
yeah, better than to wait half an hour to dump the whole memory
<lekernel>
except for the noise, this looks reasonable
<wpwrak>
zoomed in on just on one packet
<lekernel>
so why are devices not answering?
<lekernel>
maybe check at the USB connector too?
<lekernel>
there's this "high speed slew rate" enable pin on the transceivers... if the level is wrong there, this can seriously degrade the full speed signal
<wpwrak>
hmm .. lemme see if i still have that atusb with buffers around
<lekernel>
but the PC sends the very same thing, and it gets a reply?
<wpwrak>
just a sec ...
<wpwrak>
hmm, the pc does get an answer. now .. where amidst all those SOFs is it ...
<wpwrak>
phew. impossible to catch :-(
<wpwrak>
i need to change my firmware to generate a trigger when it receives something
<wpwrak>
in fact, it does this, but i don't remember what condition i had programmed ;-)
<GitHub3>
[clang-lm32] jpbonn pushed 498 new commits to master: http://git.io/41PMdA
<GitHub3>
[clang-lm32/master] Refactor static analyzer to use simpler interface to constant expression evaluation. - Richard Smith
<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 Smith
<GitHub3>
[clang-lm32/master] Don't try to diagnose anything when we're passing incomplete types - Douglas Gregor
<kristianpaul>
finally desides to install the blobed altium viewver..
<kristianpaul>
altmun designer summer 09 viwer was intterrupted? wtf?
<wpwrak>
the time between making a difficult decision and ruing it was pretty short in this case :)
<kristianpaul>
argh, it get stuck
<kristianpaul>
lekernel: what altium viewer build are you using? (asuming you run in wine)
<lekernel>
I don't use altium viewer
<lekernel>
and I run altium in virtualbox
<kristianpaul>
hum
<kristianpaul>
well.. lets what i can do with gerbers
<kristianpaul>
lekernel: what you think is easier to hack to get a glck with global clock bufer, ac97 or vga?
<lekernel>
what's your problem? you want to send a clock from the I/O port?
<lekernel>
just 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.
<Alarm>
lekernel: Hi ! Do you know a model of cheap mini projector DMX512?