#milkymist IRC log for Thursday, 2012-02-02

lekernelok let's put an end to the bike shedding00:09
lekernelhttp://papillon.lamiral.info/poll/yirUKT1328141155/00:09
lekerneland the one who's method name wins the vote has to send the patch00:10
lekernel:)00:10
lekernelwhose00:10
wpwrakdo you have a code example with a few assignments ?00:16
lekernelhttps://github.com/milkymist/milkymist-ng/blob/master/milkymist/uart/__init__.py00:17
lekernelbut well... the proper way to fix it is with a preprocessor anyway00:17
lekernelwe can simply have directives "FHDL preprocess on/off"00:18
lekernelthat encapsulate the currently not-so-nice blocks00:18
wpwrakwould "set" be available ?00:19
lekernelthere's a python set() built in function ... it messes up dumb syntax highlighters, but it seems python is able to tell it from the built-in00:19
wpwrakso my perferences would be: #1: [sl]et; #2/#3 (unordered): assign, be; negative vote: eq00:21
wpwrak"eq" is very bad because shell and perl use "eq" for comparison00:22
wpwrakset and let are commonly associated with assignments00:22
wpwrak"be" would be a new meme :)00:22
wpwrak"assign" has, besides the length, the slight drawback of already meaning something else in verilog00:23
wpwrakcladamw: directly user-controllable I/Os are coming :)00:52
wpwrak(for the LED array)00:53
cladamwwpwrak, are u meaning that verilog codes to have this for 3*4*2 ledm?00:55
wpwrakcladamw: yeah. the coming version will let you stop the PWM and let you set pins individually to 0/1/Z00:57
cladamw(J21 pins initial status) yesterday I remeaured J21.pins from fpga when power-cycling, it level from 3.3V goes to Low.00:57
wpwrakcladamw: not with pull-up, though00:57
cladamwgreat !00:58
cladamws/remeaured/remeasured00:58
wpwrakyes, the expansion header pins are set to pulldown00:59
cladamwso for DC power overriding control pin: so we can set its three status, correct?00:59
cladamw(pulldown) hmm... got it01:00
wpwrakhttps://github.com/milkymist/milkymist/blob/master/boards/milkymist-one/synthesis/common.ucf#L31501:01
wpwrakyou can change it if you want :)01:01
cladamwwow :) phew~ I don't think currently i can handle it with such *.ucf file, well... do you think that one day that we can have like your small script 'dumplock' said as 'setpinstate pin 1/0/Z' command?01:09
wpwrakoh, sure. it would be pretty simple to add this to FN01:14
wpwrakor even have a script that generates the command. similar to the one for ramps.01:15
GitHub156[milkymist] wpwrak pushed 1 new commit to ledmtrx: https://github.com/milkymist/milkymist/commit/978b8e2ab8c5eba84de36dd35550d87482992c9d01:15
GitHub156[milkymist/ledmtrx] ledm: added I/O overrides and corrected prescaler formula - Werner Almesberger01:15
cladamwthanks a lot !01:16
cladamwwpwrak, (two off-matix led) DC-in & Booted, as your points, those two did you plan both to right-angle facing led on bottom pcb side, or still place them on top? I forgot to ask this question.01:23
cladamwI think they can be also placed at bottom side, how do you think? if yes, so we let just only one type of led used in r4.01:25
cladamwbut if also we can put both at top side which is easiler to monitor intuitively.01:27
cladamwin other words, two leds: green for both, the others are rest.01:32
wpwraki think the DC led should go under the DC connector01:39
wpwraknote sure about the other one. it could just go under the button01:39
wpwrakor have it on top if you don't mind having several led types01:40
cladamwwith two led types, yes. that's pretty easy to identify Booted led if still place on top, DC in for green under connector can be distinguished from others too.01:52
cladamwokay, so DC-in (bottom, green), Booted(top, green), else (bottom, red, r/a facing)01:54
wpwrakso that's three types ?01:55
cladamwno, two types only,01:59
wpwrakfor green, would you use top-facing leds ? (like the ones in M1rc3) or side-facing ?02:00
cladamwDC-in(i.e. current D1) and Booted (i.e. current D2) are the ones in M1rc302:01
cladamwor do you also want DC-in to be r/a side-facing with red?02:01
wpwrakokay. then the led for DC in shuold probably go on top, too02:01
cladamwha... ;-)02:02
wpwrakyou can probably still see a top-facing bottom-mounted led, but not as easily02:02
cladamwalright, two green leds(green, top-facing as M1rc3) on top, else(red, side-facing) are bottom. let's keep them simple. ;-)02:03
wpwrakbut yes, why not. that way, you also get a known brightness, since these leds aren't modulated. (of course, we could do that too ;-)02:03
wolfspraulI'd rather have them all the same color02:22
wolfsprauland all the same type02:22
wpwraki knew you'd say that ;-)02:29
wolfsprauldo we have to have that second 'booted' led?02:36
wolfspraulI cannot imagine with all those other leds and pretty much any use of them, that not at least one of the others would come on after a successful boot?02:37
wolfsprauland the 'dimly lit' condition cannot seriously be a feature/warning sign that we are engineering for!?02:37
wolfspraulwe don't even know why it is 'dimly lit'02:37
wolfspraulso I think the DC led can be under the PCB like all others, side-facing, red02:38
wolfsprauland the 'booted' led can be removed02:38
wolfspraulit will be redundant when we are done anyway02:38
wpwrakoh, i know why it is dimly lit :) cladamw, do you ?02:49
wolfspraulsure but even if we know, that's not a feature/controlled experience we are designing for...02:50
wolfspraulmy main arguments are for the DC led to be the same type, color, orientation like all the others02:50
wpwrakthe "booted" led has diagnostic value. it provides a quick indication of whether the FPGA has been able to configure.02:50
wolfsprauland the booted led will be redundant later on, inevitably, as we start to use the other leds02:51
wolfspraulwpwrak: yes, but it will be redundant02:51
wolfspraulor do we plan to not make use of the other 16+ leds?02:51
wolfspraulthere will be plenty of 'booted' indication02:51
wpwrakthe LEDs work in different ways. the matrix only starts doing something when the FPGA is configured.02:51
wolfspraulnice02:51
wolfspraula 'booted' indicator ;-)02:52
wpwrakand by default, it's all dark ;-) (but we can change that if we must)02:52
wolfspraulmy point is that there is no value left in the 'booted' led after we start using the other leds in r402:53
wolfspraulit will be totally redundant, unless we believe in leaving it there to 'mark' certain stages of the boot process, like led equivalent of printk() calls along the way...02:53
wolfspraulwhich I think we wouldn't want02:53
wolfspraulif people feel strongly for the booted led now, so be it. can be removed in r5 then :-)02:54
wpwrakmaybe ... that "booted" led acts quite differently: it's affected by the pull-up and it is a simple output, so it can be changed "en passant" when configuring the FPGA, even in the standby bitstream02:54
wolfspraulI understand02:54
wpwrakhaving a direct access to a led is very often desirable :)02:55
wolfspraullike I said, later on I believe it will be 100% redundant02:55
wolfspraulok if you feel we need it, fine by me02:55
wolfspraulI just tried to make an argument02:55
wpwrakmaybe. we have a lot of alternatives, that's true02:55
wolfspraulmy other argument is to have all leds be of the same type, color, orientation02:55
wolfspraulput the 'booted' led right next to the DC led, bottom side, same color, etc.02:56
wpwraki'm not against this. though then we may need to "tune" the brightness of the off-matrix leds.02:56
wolfspraulthere's just 2 there, so what02:56
wolfspraulso when you plug in, one comes on. some time later, the second one comes on.02:57
wpwrakin the matrix, they run at ~1/4-1/3 of their nominal peak current and at a duty cycle of <= 16%.02:57
wpwrakif you just feed them in a "traditional" circuit, they'll be ~20 times brighter. you may need that "turn off" feature then ;-))02:58
wolfspraulok, one by one02:59
wolfspraulwe agree that there should be 2 - dc & booted?02:59
wpwraki think brightness perception is something like according to a logarithmic law. e.g., the "ramp" i made with ledm has a (linear) brightness value of around 1.2^n with n being the number of the led.02:59
wolfsprauland they should both be on the bottom, same color, orientation?03:00
wolfsprauland then yes, if they are on, they should be as bright as the others when they are 100% 'on', as per our circuit03:00
wolfspraulnot brighter03:00
wpwrak2, dc and booted, yes03:00
wolfsprauland on bottom side of DC jack, side by side?03:00
wpwraki don't particularly care about where they go or what color they have03:01
wolfspraulbut you have no reason against bottom of dc jack & side-by-side either?03:02
wpwrakah, i would put the "booted" led on the front, not next to DC. how about under the button ?03:03
wpwrakthat looks like a nice place and there's nothing else there for now03:03
wolfspraulfeel like a cousin of the power-led to me, but ok03:04
wolfspraulalso under the button it breaks through your concept of led for ports03:04
wpwrakwe could also do fun things like having a standby mode. and the the led could indicate that the button will wake up the system.03:04
wolfspraulit looks like a led for the button, depends on what the button does then03:05
wolfspraulno standby mode03:05
wpwrakof course, we could also add yet another led to the matrix for that. places in the matrix are cheap ;-)03:05
wolfspraulnah, already enough leds now03:05
wpwrakhehe :)03:05
wolfsprauleven the booted one is redundant imho03:05
wolfspraulI'm voting for side-by-side with power led03:05
wolfspraulit's the power led's big brother, when the system is fully up03:06
wpwrakhmm. if we move it over to DC, then i'd be inclined to want one more LED for the button. the general concept is that the leds indicate when some peripherals is active/inactive. so if we use the button for more than reset, an indicator may be desirable.03:08
wolfspraulthen under the button :-)03:08
wolfspraulbooted led under the button, and no more additional leds03:08
wolfspraulso now brightness03:09
wolfspraulyou say if the power and booted leds are the same type as the others in the matrix, they will be too bright?03:09
wpwrakwe can adjust the brightness by limiting the current (with a larger resistor)03:09
wolfspraulyeah, sounds right. how large is that large resistor, physically?03:10
wpwrakplus, if we err on the high side, we could also add some pwm to dim them, similar to the matrix but of course simpler03:10
wolfspraulwe should keep an eye on the number of different parts in the bom03:11
wpwrakpretty much any size you could want should be okay03:11
wolfspraulthen we can decide what is easier - a different led type for those 2 leds, or resistor03:11
wpwrakthings would get difficult at nanoscales, though :)03:11
wolfspraulcan we reuse a resistor we already have in the m1 bom?03:11
wpwrak(it needs to dissipate around 2 mW, worst case if we're very conservative, maybe 10 mW)03:12
wpwraklet's say we feed the led with 2 mA. that should make it a bit brighter than the rest, but not excessively so03:13
wpwrak2 mA maximum. let's say 1 mA minimum. so the resistor would have to be in that range03:14
wpwrakit's a bit tricky to dimension that resistor since the LED's voltage/current curve gets very flat in that range. let's say we have a Vf about 1.7 V03:16
wpwrakso we'd have to drop 1.6 V at ~1.5 mA. 1 kOhm.03:16
wpwrakR22 and friends03:17
wpwrak0402, 1k, even excessively precise at 1%03:18
wolfspraulcool, the R22 resistors would do?03:21
wpwraklet's see if this is really how things work (cross-checking resistive vs. PWM limiting)03:21
cladamwwpwrak, (DC-in led) if no verilog existes in fpga, what state of led you supposed to be? OFF or ON? This is to identify when in manufacture mode with overriding circuit.03:30
wpwrakhmm. noce quite the same. let's check the numbers ...03:32
wpwrakcladamw: default state is lit03:32
wolfspraulcladamw: I think we already agree on a few things:03:35
wolfspraulall leds should be the same type, all on bottom, all side-facing03:35
wolfspraulpower led is under DC jack03:35
wolfspraul'booted' led is under button03:35
wolfspraulall the same color03:35
wolfspraulthe only thing remaining is brightness03:35
cladamwi didn't see backlog, so those two (DC-in & booted leds) are still off-matrix?03:36
wolfspraulyes03:36
wolfspraulhere is what we agree on already:03:36
wolfspraul1. all leds on m1 should have the same color03:37
cladamwwpwrak, the link we broken: http://downloads.qi-hardware.com/people/werner/tmp/d1.ps03:37
wolfspraul2. all leds should be on bottom side, side-facing03:37
cladamws/we/is03:37
wolfspraulno different color, not some on top some on bottom03:37
cladamwwolfspraul, okay03:37
wolfspraulideally we should have just 1 led type, 1 partnumber03:37
wolfspraulI don't want to blow up the bom with more and more different parts03:37
wolfspraulthe last thing Werner is looking into right now is the brightness03:38
wolfspraulso the 2 led off-matrix (power and booted/button) will not be too bright03:38
wpwrak1 kOhm doesn't seem to be right. at least with my LTST-C190KRKT, 1 kOhm produces 1.5 mA, which is about as bright as the matrix with duty cycle 100/25503:39
cladamwwpwrak, i remembered your BJT circuit with a resistor in serial to transistor's collector, i doubt that IF no codes in fpga, how will you let DC-in led to be lit?03:39
wpwrakthe fpga resets to pull-up. so the bjt should conduct.03:40
cladamwwhen you used PWM to light means verilog existed there. my question is about DC-in led (fully on/fully off/dimly lit) when manufacturer assembled?03:41
cladamwwpwrak, ha...'pull-up' after reset. i see.03:41
cladamwso current J21's pins are all you set 'pulldown' by configured, not by reset itself.03:42
wpwrakseems 560 Ohm would be more appropriate03:47
wpwrakwe have one 560 Ohm resistor, R14203:47
wpwrakexactly03:48
wpwrakand that's also why you get the "dimply lit". that's the FPGA's pull-up when it fails to configure.03:48
wpwraks/dimply/dimly/03:48
wpwrakah, R142 is a RSET pull-down on the VGA DAC03:51
wpwrakRSET ("R-set") is a current reference, not a "reset". so it looks like something that won't go away too quickly.03:53
cladamwwpwrak, sorry , too quick on chats above you with wolfspraul03:55
cladamwwpwrak, i'm doing soldering about DC-in led circuit with MOSFET(2N7002)03:55
cladamwso i'd want to predict the 'dimly lit03:56
cladamw' condition while in manufacturing mode(i.e. no verilog codes, default)03:57
wolfspraulwpwrak: so a 560 Ohm (R142) resistor would roughly balance the brightness of both off-matrix leds with the on-matrix ones?03:57
wolfspraulthen we would have all data points complete for cladamw, I believe03:57
wpwrakyes, 560 Ohm looks good04:02
cladamwwpwrak, yes, R142 (560 Ohm) is not driven by fpga. so with a N-MOSFET with a resistor in serial can be ON during default mode. What scaling rate when you set current at IF = 20mA? (cycle ?/255)04:02
wolfspraulperfect, so we have it all complete for Adam, I think04:02
wpwrak(at least with my LTST-C190KRKT). if it's too bright, we can always throttle it with a PWM04:02
cladamwwpwrak, so let me list up your results:04:03
cladamw1. ledm with 270 ohm in serial04:03
cladamw2. off-matrix for 2 led: default/dimly lit is 560 Ohm, then using to PWM to bright likely as ledm red led to do ON& scaling04:05
cladamwalthough you used a LTST-C190KRKT.04:06
wpwrakno, 560 Ohm should look about as bright at the others. if it's too bright, we can add a PWM to dim it. but for no, i assume we don't need that04:06
cladamwwpwrak, am i correct?04:06
wolfspraulI hope we don't build big contraptions around these little leds04:07
wolfspraulbut I cannot judge that technically, have to rely on werner's and adam's common sense ;-)04:07
wpwrakleds are subtle :)04:07
wolfspraulthat's fine. good engineering is also subtle.04:07
wpwrakand the interface on the side of the user (the eye) is even more subtle ;-)04:07
cladamwwpwrak, wait. so you meaned 560 Ohm for off-matrix circuit, and expected to all other red leds?04:08
wpwrake.g., you can see a led flash on for about 100 us quite clearly. even though you wouldn't never notice it flash off for that amount of time  :)04:09
wpwrak560 Ohm for off-matrix and 270 Ohm for on-matrix04:10
wpwrakthat seems to produce similar apparent brightness (with my LTST-C190KRKT and my eyes :)04:10
cladamwi see, so you used a constant with duty in 100us to compare off-matix and on-matrix, correct?04:10
wpwrakno no .. that 100 us was just an unrelated remark04:11
wpwrakfor the visual comparison, i sent a constant current through one led and compared it with one in the matrix, running at maximum duty cycle04:12
cladamw1. maximum duty cycle = (off-matrix, on-matrix) = ( ? / 255, )  ==> led ON,04:16
cladamw2. medium duty cycle = (off-matrix[default], on-matrix) = ( ?/ 255, ? / 255) ==> led dimly lit likely04:17
cladamw3. minimum duty cycle = ( off-matirx, on-matix) = ( low input to BJT/MOSFET on gate pin, ? / 255)04:18
wpwrakerr, off-matrix don't have a duty cycle :)04:19
wpwrakduty cycle = part of the time during which they're lit04:19
cladamwwpwrak, i hope 2N7002 circuit can do this dimly lit less then IF = 20mF to act as dimly lit?04:20
wpwrakwhat do you mean with "dimly lit" ? the error condition when the fpga is not configured ?04:23
wpwrakthat error condition has a current of only something like 10-100 uA. that's not something we aim for here.04:24
wpwrakthere are basically three parameters: current, duty cycle, and luminous intensity04:25
wpwrakluminous intensity is a function of current and the sort of device we have. (the millicandela rating)04:25
wpwrakduty cycle depends on what circuit we have and how it is configured. e.g., the off-matrix leds should be always on, so 100% duty cycle.04:26
wpwrakthe on-matrix leds have a maximum duty cycle of about 16% (due to multiplexing), which can be further reduced in steps of 1/256.04:28
cladamwwpwrak, i should have drew DC-in led circuit with 2N7002 firstly in resistor. ;-)04:28
wpwrakthe "booting" led will also have the special condition that, if the fpga isn't configured, it will have a very low current through the fpga's pull-up. that's the "dimly lit" error condition.04:29
wpwrak(dc with fet) i'm curious what you'll have at the end ;-)04:30
cladamwyes, i meant 'dimly lit' = 'is not configured' when saying on DC-in led, so fpga pin is connected to 'Gate' pin of fet, so a default of 'pullup' will let fet to pass cuurent from Drain to Source then led is fully ON.04:32
cladamwso upon this condition, a 560 Ohm in serial with fet will act the result luminous as you just did?04:33
wpwrakyup. a very bright kind of "dim" ;-))04:33
cladamwnight later I'll show this to you. ;-) hope it works well, I'll also measure Id.04:36
wpwrakhehe :)04:48
cladamwwill you go to sleep now?04:50
cladamwcan you wait me 5 minutes?04:50
cladamwi'm going to upload the sch.04:51
wpwrakhehe :)04:53
wpwraki'll eat now. so you have more than 5 min :)04:53
cladamwhttp://downloads.qi-hardware.com/people/adam/m1/tmp/m1r4/Misc_led_20120202.pdf04:56
cladamwD1 and D2 are also side-facing type, forget about my text there.04:57
cladamwbut please help me to see those BLACK text i wrote about D1, tks. ;-)04:58
cladamwso my question is: when reset default/no verilog code, i assumed it's a pullup input status on Q3 gate pin, so fet should ON, then D1 is ON05:02
cladamwwhich will not be 'dimly lit' as we chatted, but this is also good to indicate that M1 equipped with good power 3.3V in successfully when in manufacturing mode. hope you get my point. ;-)05:04
cladamwwhen pulldown input comes, D1 is fully OFF.05:05
cladamwis this circuit proposedly same as your original BJT idea?05:05
cladamwso i assumed when pullup input comes, then D1 is fully ON.05:12
lekernelI didn't follow... why add a MOSFET to control one of the LEDs?09:22
wpwrakcladamw: sorry, fell asleep :-(  not, checking ...09:59
wpwraklekernel: wolfgang wants to be able to turn off the DC led. and it should default (= with the fpga unconfigured) to on09:59
lekernelah, i see10:00
wpwraks/not,/now,/10:00
wpwrakcladamw: D1 circuit looks better now :) do we really want an external pull-down, given that we have an internal pull-up ? if you want the external pull resistor, i'd rather make it pull-up as well, so it pulls i the same direction as the internal resistor10:03
cladamwwpwrak, oah. since that R229 i added because gate pin senses easily while my finger touched the extendable wire and tried to connect GND, then Q3 works reandomly, so later it works well after I added R229 to make correct Vgs.10:31
Fallenoulekernel: when you said you already had MM soc run with isim-fuse, was it milkymist or milkymist-ng ? cause I'm using milkymist-ng (modified)10:36
cladamwwpwrak, can you tell me your current If while you were testing that off-ledm for simulation of 'booted'?10:36
wpwrak(R229) yeah, FETs are known for being sensitive to their gate voltage. i think they can also take damage if the gate is left floating, no ?10:38
cladamwwpwrak, with your experimented current value so that I can fine tune R41/D1 circuit to get our 'expected' similar luminance (you there).10:38
wpwrak(If) about 2.45 mA10:38
cladamwwpwrak, no, if we add an external pulldown, then we don't worry that left floating.10:39
wpwrak(If) but it doesn't have to be very exact. you can't tell a difference between 2.3 mA and 2.5 mA anyway, unless you have the LEDs right next to each other10:39
cladamwwpwrak, yours is also 2.45mA?10:39
wpwrak(R229) it would make it a pullup10:39
wpwraks/it would/I would/10:39
wpwrakyes, 2.45 mA. ltst-c190krkt is a bit different, electronically, from the APA... but not a lot (Vf about 100 mV lower)10:40
wpwrakerr, sorry. 100 mV higher.10:40
cladamwwpwrak, oah..yes a pullup (R229) can also make D1 ON when in manufacturing mode[default].10:40
cladamwwpwrak, okay... I'll change R229 to be a pullup like 10K Ohm, is that okay?10:42
wpwrakwhy so low ? you only need it to protect the gate10:43
cladamwoh~you replied, checking...10:43
wpwrakthe FPGA already has a perfectly good internal pull-up resistor10:43
wpwrakso R229 is only a protection to prevent the gate from floating. not even sure if we actually need it, since there are clamping diodes in the FPGA anyway.10:44
cladamwwpwrak, ah...forgot, so add also 1 M Ohm pull-up?10:44
wpwrakyup10:44
cladamwbtw, i didn't used supply from +5V10:45
wpwrakhmm ?10:46
cladamwbut with +3.3V net, as a productive diagnostic on supply circuits which is also good for checking the success of U10(5V-to-3.3V), how do you think?10:47
lekernelFallenou: it was a very old milkymist10:48
lekernel0.1 or something :)10:48
wpwrakcladamw: sure. just like in M1rc3 :-)10:50
cladamwwpwrak, good. ;-)10:53
Fallenoulekernel: huhu ok10:53
FallenouI will check if I have not made any obvious mistake while kicking out nor & uart10:54
VJTachyonhey guys14:06
VJTachyonlooks like i have some money to blow this year :)14:07
VJTachyonhow are the revs of MM1 coming along?14:07
rohVJTachyon: good. also we are continuing to support older revs. means they should be and stay fully function complete15:15
VJTachyonroh: how do you know which revs you will get when ordering?15:16
rohalso many improvements are only manufacturing improvements15:16
rohVJTachyon: the recent one. i think current orders will be a r315:17
VJTachyonif i get one from amazon, i want to try to get the latest15:17
rohi think you will. rc2 shouldnt be around in trade anymore i think.15:17
rohso you'll get a rc3 if you order now i think15:18
VJTachyonok cool15:18
rohrc4 isnt produced yet afaik.15:18
VJTachyoni just finished recoding my whole damn android dj app15:18
VJTachyonwell not finished15:18
VJTachyonbut mostly15:18
VJTachyonported mpg123 over15:18
rohyou work on a tablet?15:18
VJTachyoni work on everything15:19
VJTachyon:P15:19
VJTachyonif it is android i do it15:19
VJTachyonnative, java, etc15:19
VJTachyoni want to build an Android ADK bridge into the MM115:19
VJTachyonso you can control everything from the android device15:20
VJTachyoncould probably do bluetooth or wifi or something too15:20
VJTachyonits too bad the usb interface isnt opened up in the NDK for Android though15:20
rohheh15:20
VJTachyonjust in the SDK15:20
rohwell.. lots of different hw backends in android. in the end adk only relies on 'can be a client' on the android device side15:21
VJTachyonwell some devices have a host15:21
VJTachyonbut yeah15:21
rohonly some of the devices can do host, not all, thus their choice15:21
VJTachyon;)15:21
lekernelVJTachyon: all M1s for sale are contain a R3 board15:38
lekernel-are15:38
VJTachyonlekernel: right on15:39
VJTachyonlekernel: so yeah i started an LLC last year, so now im trying to find stuff to spend money on :)15:39
lekernelhttp://chrs-smthng.com/transfer/scope_no8-milkymist_presentation.zip (740M)15:53
wpwrakroh: rc4 is still months out. finish schematics, review schematics, then layout, sourcing, pcb, smt.15:57
VJTachyonwhat changes are there?15:57
lekernelDVI and LEDs15:58
lekernelbut DVI won't be supported in the FPGA design right away ...15:58
lekernel(DVI-D, that is)15:58
wpwrakfor now, more USB ports, a DVI-I connector instead of VGA, and lot of blinkenlights :)15:59
VJTachyonhehe15:59
wpwrak(work items) and then testing, and rework, etc. so minimum 3 months.16:00
wpwrakpcb and smt alone tend to take a month (not the actual work, but getting a slot in their schedule)16:00
VJTachyonany other revs on the roadmap?16:03
VJTachyonor you think rc4 will be it for awhile?16:03
wpwrakafter r4 ? we'll see16:03
wpwrakmaybe it'll be time for a greater redesign after M1r4. e.g., with faster memory, different case, a built-in touch screen, etc.16:04
wpwrakor maybe we'll find there are some more improvements we want to make based on M1r4 that we'd rather focus on an M1r5 first16:04
kristianpaulhttp://www.landley.net/toybox/design.html18:25
lekernelmwalle: what do you think about sharing the SRAM of the GDB stub with that of the (future) BIOS which will contain a more complex SDRAM initialization code written in C?22:01
lekernelyou will not be able to use GDB with the BIOS, but that doesn't sound like a big constraint... the BIOS is relatively straightforward22:02
--- Fri Feb 3 201200:00

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