#milkymist IRC log for Monday, 2012-03-12

wolfspraulwpwrak: since it's Monday (here), I am thinking about this week and beyond...01:04
wolfspraulare the usb fixes finished? last I read something about a protocol analyzer?01:05
wolfspraulAdam will probably soon get to layout01:05
wolfspraulthen kicad & boom01:05
wolfspraulmy feeling is after R4 we should jump ahead and go directly to -7 ddr3 spi, and so on01:06
wolfspraulrather than another smaller incremental update01:07
wolfspraulbut just guessing, let's see how it goes the next few weeks01:07
rohone step at a time01:08
wpwrak(usb fixes) naw, there's another big round waiting to be done. the last round was about higher-level problems. the bit- or byte-level issues are still around. but they're hard to debug without proper tools.01:11
wpwrak(usb) we'll also need to merge proper HID handlinh. xiangfu already wrote code to retrieve the report descriptor. now we have to parse it and use the "bytecode" it contains.01:12
wpwrak(ddr, etc.) yes, maybe. depends on how well r4 goes. if we have no regression, i think an update of the core (fpga, ddr) is a good idea01:14
wolfspraulok01:14
wolfspraulgood01:14
wpwraklekernel should probably get a eval board, though. that way, he won't have to fight hardware issues (layout is probably quite hairy with faster DDRs) and intrinsic memory painfulness at the same time, when debugging the DDR controller01:15
wolfspraulI'm not that far into the specifics yet, want to do a superb job with R4 first01:17
wolfsprauland create a basis for the future01:17
wolfspraulthe reason I am thinking about R5, or anything post-R4, is simply to plan the run size of R401:17
wolfspraulbut my feeling is we want to accelerate01:18
wolfspraulor rather we 'can', if the foundation gets better01:18
wolfspraulwithout destroying the product's usability01:18
wolfsprauland yes I totally agree, it depends on R4 regression testing as well01:18
wolfspraulI don't want to leap ahead when my product falls apart, turn into an infinite lab. no way.01:18
wolfspraulR4 has to be rock solid and show that everything is under control, especially mem performance as sebastien pointed out already.01:19
wolfspraullet's do that right first01:19
wolfsprauland if we succeed, assuming that we will, then the next step01:19
wpwrak(kicad & boom) i'm working on the new boom. but it'll still take a while until it can do anything useful. the design philosophy will change a bit - the old one was centered around pattern matching and text substitution, much like sendmail.cf. that made it flexible but also led to awkward solutions for some problems. the new one knows all the main data types (names, name sets, values with SI prefix and unit, tolerances) and handles parsi01:19
wpwrakng, comparison, etc. in C. so you only tell it what kind of fields you have but don't set up some elaborate chain of substitutions that lead to textual matches.01:19
wolfspraulsounds good01:21
wolfsprauldo you remember the feedback from the first round?01:21
wolfspraulI vaguely remember digi-reel as one of the biggest wishlist items01:21
wolfsprauland/or tray01:21
wolfspraulright?01:21
wpwrakthat's at least for the part that concerns characteristics (.chr files) and kicad. .chr file generation, i.e., parsing of vendor part codes, may still be better served by a purely string-based approach. but that can even live in a separate kind of program.01:22
wpwrakyes, i have a distinction between "manual" and "machine" now ;-)01:22
wpwrakreel vs. non-reel (possibly with reeling as an option) was the main feedback01:26
wpwrakfrom my side, the main issue of the old one is lack of scalability, speed-wise. it's already approaching its limit with what i'm doing for ben-wpan.01:28
lekernelmwalle: larsc: what do you think of Sergey's patch?09:59
mwallelekernel: can be applied, signals in lm32 port need a rework anyway11:24
lekernelgreat, thanks. doing it.11:32
GitHub119[linux-milkymist] sbourdeauducq pushed 1 new commit to master: http://git.io/-RZgSA11:34
GitHub119[linux-milkymist/master] Fix of Linux signals for LM32 arch - Sergey Koulik11:34
sh4rm4Fallenou, once the MMU is finished i'd be interested if musl libc could be ported to milkymist-linux18:21
--- Tue Mar 13 201200:00

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