<lekernel>
but well... the proper way to fix it is with a preprocessor anyway
<lekernel>
we can simply have directives "FHDL preprocess on/off"
<lekernel>
that encapsulate the currently not-so-nice blocks
<wpwrak>
would "set" be available ?
<lekernel>
there'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-in
<wpwrak>
so my perferences would be: #1: [sl]et; #2/#3 (unordered): assign, be; negative vote: eq
<wpwrak>
"eq" is very bad because shell and perl use "eq" for comparison
<wpwrak>
set and let are commonly associated with assignments
<wpwrak>
"be" would be a new meme :)
<wpwrak>
"assign" has, besides the length, the slight drawback of already meaning something else in verilog
lekernel_ [lekernel_!~lekernel@g225041205.adsl.alicedsl.de] has joined #milkymist
xiangfu [xiangfu!~xiangfu@fidelio.qi-hardware.com] has joined #milkymist
cladamw [cladamw!~Adam@host-222.80-43-115.dynamic.totalbb.net.tw] has joined #milkymist
<wpwrak>
cladamw: directly user-controllable I/Os are coming :)
<wpwrak>
(for the LED array)
<cladamw>
wpwrak, are u meaning that verilog codes to have this for 3*4*2 ledm?
<wpwrak>
cladamw: yeah. the coming version will let you stop the PWM and let you set pins individually to 0/1/Z
<cladamw>
(J21 pins initial status) yesterday I remeaured J21.pins from fpga when power-cycling, it level from 3.3V goes to Low.
<wpwrak>
cladamw: not with pull-up, though
DJTachyon [DJTachyon!~Tachyon@ool-43529b4a.dyn.optonline.net] has joined #milkymist
<cladamw>
great !
<cladamw>
s/remeaured/remeasured
<wpwrak>
yes, the expansion header pins are set to pulldown
<cladamw>
so for DC power overriding control pin: so we can set its three status, correct?
kristianpaul [kristianpaul!~kristianp@cl-498.udi-01.br.sixxs.net] has joined #milkymist
kristianpaul [kristianpaul!~kristianp@unaffiliated/kristianpaul] has joined #milkymist
<cladamw>
wow :) 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?
<wpwrak>
oh, sure. it would be pretty simple to add this to FN
<wpwrak>
or even have a script that generates the command. similar to the one for ramps.
<GitHub156>
[milkymist/ledmtrx] ledm: added I/O overrides and corrected prescaler formula - Werner Almesberger
<cladamw>
thanks a lot !
<cladamw>
wpwrak, (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.
<cladamw>
I 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.
<cladamw>
but if also we can put both at top side which is easiler to monitor intuitively.
<cladamw>
in other words, two leds: green for both, the others are rest.
wolfspraul [wolfspraul!~wolfsprau@221.217.223.225] has joined #milkymist
<wpwrak>
i think the DC led should go under the DC connector
<wpwrak>
note sure about the other one. it could just go under the button
<wpwrak>
or have it on top if you don't mind having several led types
<cladamw>
with 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.
<wpwrak>
for green, would you use top-facing leds ? (like the ones in M1rc3) or side-facing ?
<cladamw>
DC-in(i.e. current D1) and Booted (i.e. current D2) are the ones in M1rc3
<cladamw>
or do you also want DC-in to be r/a side-facing with red?
<wpwrak>
okay. then the led for DC in shuold probably go on top, too
<cladamw>
ha... ;-)
<wpwrak>
you can probably still see a top-facing bottom-mounted led, but not as easily
<cladamw>
alright, two green leds(green, top-facing as M1rc3) on top, else(red, side-facing) are bottom. let's keep them simple. ;-)
<wpwrak>
but yes, why not. that way, you also get a known brightness, since these leds aren't modulated. (of course, we could do that too ;-)
DJTachyon [DJTachyon!~Tachyon@ool-43529b4a.dyn.optonline.net] has joined #milkymist
<wolfspraul>
I'd rather have them all the same color
<wolfspraul>
and all the same type
<wpwrak>
i knew you'd say that ;-)
<wolfspraul>
do we have to have that second 'booted' led?
<wolfspraul>
I 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?
<wolfspraul>
and the 'dimly lit' condition cannot seriously be a feature/warning sign that we are engineering for!?
<wolfspraul>
we don't even know why it is 'dimly lit'
<wolfspraul>
so I think the DC led can be under the PCB like all others, side-facing, red
<wolfspraul>
and the 'booted' led can be removed
<wolfspraul>
it will be redundant when we are done anyway
antgreen [antgreen!~user@64.134.168.217] has joined #milkymist
<wpwrak>
oh, i know why it is dimly lit :) cladamw, do you ?
<wolfspraul>
sure but even if we know, that's not a feature/controlled experience we are designing for...
<wolfspraul>
my main arguments are for the DC led to be the same type, color, orientation like all the others
<wpwrak>
the "booted" led has diagnostic value. it provides a quick indication of whether the FPGA has been able to configure.
<wolfspraul>
and the booted led will be redundant later on, inevitably, as we start to use the other leds
<wolfspraul>
wpwrak: yes, but it will be redundant
<wolfspraul>
or do we plan to not make use of the other 16+ leds?
<wolfspraul>
there will be plenty of 'booted' indication
<wpwrak>
the LEDs work in different ways. the matrix only starts doing something when the FPGA is configured.
<wolfspraul>
nice
<wolfspraul>
a 'booted' indicator ;-)
<wpwrak>
and by default, it's all dark ;-) (but we can change that if we must)
<wolfspraul>
my point is that there is no value left in the 'booted' led after we start using the other leds in r4
<wolfspraul>
it 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...
<wolfspraul>
which I think we wouldn't want
<wolfspraul>
if people feel strongly for the booted led now, so be it. can be removed in r5 then :-)
<wpwrak>
maybe ... 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 bitstream
<wolfspraul>
I understand
<wpwrak>
having a direct access to a led is very often desirable :)
<wolfspraul>
like I said, later on I believe it will be 100% redundant
<wolfspraul>
ok if you feel we need it, fine by me
<wolfspraul>
I just tried to make an argument
<wpwrak>
maybe. we have a lot of alternatives, that's true
<wolfspraul>
my other argument is to have all leds be of the same type, color, orientation
<wolfspraul>
put the 'booted' led right next to the DC led, bottom side, same color, etc.
<wpwrak>
i'm not against this. though then we may need to "tune" the brightness of the off-matrix leds.
<wolfspraul>
there's just 2 there, so what
<wolfspraul>
so when you plug in, one comes on. some time later, the second one comes on.
<wpwrak>
in the matrix, they run at ~1/4-1/3 of their nominal peak current and at a duty cycle of <= 16%.
<wpwrak>
if you just feed them in a "traditional" circuit, they'll be ~20 times brighter. you may need that "turn off" feature then ;-))
<wolfspraul>
ok, one by one
<wolfspraul>
we agree that there should be 2 - dc & booted?
<wpwrak>
i 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.
<wolfspraul>
and they should both be on the bottom, same color, orientation?
<wolfspraul>
and then yes, if they are on, they should be as bright as the others when they are 100% 'on', as per our circuit
<wolfspraul>
not brighter
<wpwrak>
2, dc and booted, yes
<wolfspraul>
and on bottom side of DC jack, side by side?
<wpwrak>
i don't particularly care about where they go or what color they have
<wolfspraul>
but you have no reason against bottom of dc jack & side-by-side either?
<wpwrak>
ah, i would put the "booted" led on the front, not next to DC. how about under the button ?
<wpwrak>
that looks like a nice place and there's nothing else there for now
<wolfspraul>
feel like a cousin of the power-led to me, but ok
<wolfspraul>
also under the button it breaks through your concept of led for ports
<wpwrak>
we could also do fun things like having a standby mode. and the the led could indicate that the button will wake up the system.
<wolfspraul>
it looks like a led for the button, depends on what the button does then
<wolfspraul>
no standby mode
<wpwrak>
of course, we could also add yet another led to the matrix for that. places in the matrix are cheap ;-)
<wolfspraul>
nah, already enough leds now
<wpwrak>
hehe :)
<wolfspraul>
even the booted one is redundant imho
<wolfspraul>
I'm voting for side-by-side with power led
<wolfspraul>
it's the power led's big brother, when the system is fully up
<wpwrak>
hmm. 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.
<wolfspraul>
then under the button :-)
<wolfspraul>
booted led under the button, and no more additional leds
<wolfspraul>
so now brightness
<wolfspraul>
you say if the power and booted leds are the same type as the others in the matrix, they will be too bright?
<wpwrak>
we can adjust the brightness by limiting the current (with a larger resistor)
<wolfspraul>
yeah, sounds right. how large is that large resistor, physically?
<wpwrak>
plus, if we err on the high side, we could also add some pwm to dim them, similar to the matrix but of course simpler
<wolfspraul>
we should keep an eye on the number of different parts in the bom
<wpwrak>
pretty much any size you could want should be okay
<wolfspraul>
then we can decide what is easier - a different led type for those 2 leds, or resistor
<wpwrak>
things would get difficult at nanoscales, though :)
<wolfspraul>
can we reuse a resistor we already have in the m1 bom?
<wpwrak>
(it needs to dissipate around 2 mW, worst case if we're very conservative, maybe 10 mW)
<wpwrak>
let's say we feed the led with 2 mA. that should make it a bit brighter than the rest, but not excessively so
<wpwrak>
2 mA maximum. let's say 1 mA minimum. so the resistor would have to be in that range
<wpwrak>
it'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 V
<wpwrak>
so we'd have to drop 1.6 V at ~1.5 mA. 1 kOhm.
<wpwrak>
R22 and friends
<wpwrak>
0402, 1k, even excessively precise at 1%
<wolfspraul>
cool, the R22 resistors would do?
<wpwrak>
let's see if this is really how things work (cross-checking resistive vs. PWM limiting)
<cladamw>
wpwrak, (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.
<wpwrak>
hmm. noce quite the same. let's check the numbers ...
<wpwrak>
cladamw: default state is lit
<wolfspraul>
cladamw: I think we already agree on a few things:
<wolfspraul>
all leds should be the same type, all on bottom, all side-facing
<wolfspraul>
power led is under DC jack
<wolfspraul>
'booted' led is under button
<wolfspraul>
all the same color
<wolfspraul>
the only thing remaining is brightness
<cladamw>
i didn't see backlog, so those two (DC-in & booted leds) are still off-matrix?
<wolfspraul>
yes
<wolfspraul>
here is what we agree on already:
<wolfspraul>
1. all leds on m1 should have the same color
<wolfspraul>
2. all leds should be on bottom side, side-facing
<cladamw>
s/we/is
<wolfspraul>
no different color, not some on top some on bottom
<cladamw>
wolfspraul, okay
<wolfspraul>
ideally we should have just 1 led type, 1 partnumber
<wolfspraul>
I don't want to blow up the bom with more and more different parts
<wolfspraul>
the last thing Werner is looking into right now is the brightness
<wolfspraul>
so the 2 led off-matrix (power and booted/button) will not be too bright
<wpwrak>
1 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/255
<cladamw>
wpwrak, 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?
<wpwrak>
the fpga resets to pull-up. so the bjt should conduct.
<cladamw>
when 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?
<cladamw>
wpwrak, ha...'pull-up' after reset. i see.
<cladamw>
so current J21's pins are all you set 'pulldown' by configured, not by reset itself.
rejon [rejon!~rejon@li382-141.members.linode.com] has joined #milkymist
<wpwrak>
seems 560 Ohm would be more appropriate
<wpwrak>
we have one 560 Ohm resistor, R142
<wpwrak>
exactly
<wpwrak>
and that's also why you get the "dimply lit". that's the FPGA's pull-up when it fails to configure.
<wpwrak>
s/dimply/dimly/
<wpwrak>
ah, R142 is a RSET pull-down on the VGA DAC
<wpwrak>
RSET ("R-set") is a current reference, not a "reset". so it looks like something that won't go away too quickly.
<cladamw>
wpwrak, sorry , too quick on chats above you with wolfspraul
<cladamw>
wpwrak, i'm doing soldering about DC-in led circuit with MOSFET(2N7002)
<cladamw>
so i'd want to predict the 'dimly lit
<cladamw>
' condition while in manufacturing mode(i.e. no verilog codes, default)
<wolfspraul>
wpwrak: so a 560 Ohm (R142) resistor would roughly balance the brightness of both off-matrix leds with the on-matrix ones?
<wolfspraul>
then we would have all data points complete for cladamw, I believe
<wpwrak>
yes, 560 Ohm looks good
<cladamw>
wpwrak, 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)
<wolfspraul>
perfect, so we have it all complete for Adam, I think
<wpwrak>
(at least with my LTST-C190KRKT). if it's too bright, we can always throttle it with a PWM
<cladamw>
wpwrak, so let me list up your results:
<cladamw>
1. ledm with 270 ohm in serial
<cladamw>
2. 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& scaling
<cladamw>
although you used a LTST-C190KRKT.
<wpwrak>
no, 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 that
<cladamw>
wpwrak, am i correct?
<wolfspraul>
I hope we don't build big contraptions around these little leds
<wolfspraul>
but I cannot judge that technically, have to rely on werner's and adam's common sense ;-)
<wpwrak>
leds are subtle :)
<wolfspraul>
that's fine. good engineering is also subtle.
<wpwrak>
and the interface on the side of the user (the eye) is even more subtle ;-)
<cladamw>
wpwrak, wait. so you meaned 560 Ohm for off-matrix circuit, and expected to all other red leds?
<wpwrak>
e.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 :)
<wpwrak>
560 Ohm for off-matrix and 270 Ohm for on-matrix
<wpwrak>
that seems to produce similar apparent brightness (with my LTST-C190KRKT and my eyes :)
<cladamw>
i see, so you used a constant with duty in 100us to compare off-matix and on-matrix, correct?
<wpwrak>
no no .. that 100 us was just an unrelated remark
<wpwrak>
for the visual comparison, i sent a constant current through one led and compared it with one in the matrix, running at maximum duty cycle
<cladamw>
1. maximum duty cycle = (off-matrix, on-matrix) = ( ? / 255, ) ==> led ON,
<cladamw>
2. medium duty cycle = (off-matrix[default], on-matrix) = ( ?/ 255, ? / 255) ==> led dimly lit likely
<wpwrak>
err, off-matrix don't have a duty cycle :)
<wpwrak>
duty cycle = part of the time during which they're lit
<cladamw>
wpwrak, i hope 2N7002 circuit can do this dimly lit less then IF = 20mF to act as dimly lit?
<wpwrak>
what do you mean with "dimly lit" ? the error condition when the fpga is not configured ?
<wpwrak>
that error condition has a current of only something like 10-100 uA. that's not something we aim for here.
<wpwrak>
there are basically three parameters: current, duty cycle, and luminous intensity
<wpwrak>
luminous intensity is a function of current and the sort of device we have. (the millicandela rating)
<wpwrak>
duty 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.
<wpwrak>
the on-matrix leds have a maximum duty cycle of about 16% (due to multiplexing), which can be further reduced in steps of 1/256.
<cladamw>
wpwrak, i should have drew DC-in led circuit with 2N7002 firstly in resistor. ;-)
<wpwrak>
the "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.
<wpwrak>
(dc with fet) i'm curious what you'll have at the end ;-)
<cladamw>
yes, 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.
<cladamw>
so upon this condition, a 560 Ohm in serial with fet will act the result luminous as you just did?
<wpwrak>
yup. a very bright kind of "dim" ;-))
<cladamw>
night later I'll show this to you. ;-) hope it works well, I'll also measure Id.
<wpwrak>
hehe :)
<cladamw>
will you go to sleep now?
<cladamw>
can you wait me 5 minutes?
rejon [rejon!~rejon@li382-141.members.linode.com] has joined #milkymist
<cladamw>
i'm going to upload the sch.
<wpwrak>
hehe :)
<wpwrak>
i'll eat now. so you have more than 5 min :)
<cladamw>
D1 and D2 are also side-facing type, forget about my text there.
<cladamw>
but please help me to see those BLACK text i wrote about D1, tks. ;-)
<cladamw>
so 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 ON
<cladamw>
which 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. ;-)
<cladamw>
when pulldown input comes, D1 is fully OFF.
<cladamw>
is this circuit proposedly same as your original BJT idea?
<cladamw>
so i assumed when pullup input comes, then D1 is fully ON.
mumptai [mumptai!~calle@brmn-4dbc9713.pool.mediaWays.net] has joined #milkymist
rejon [rejon!~rejon@li382-141.members.linode.com] has joined #milkymist
Martoni [Martoni!~chatzilla@ip-167-165.evhr.net] has joined #milkymist
<lekernel>
I didn't follow... why add a MOSFET to control one of the LEDs?
<wpwrak>
lekernel: wolfgang wants to be able to turn off the DC led. and it should default (= with the fpga unconfigured) to on
<lekernel>
ah, i see
<wpwrak>
s/not,/now,/
<wpwrak>
cladamw: 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 resistor
Martoni [Martoni!~chatzilla@ip-167-165.evhr.net] has joined #milkymist
<cladamw>
wpwrak, 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.
<Fallenou>
lekernel: 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)
<cladamw>
wpwrak, can you tell me your current If while you were testing that off-ledm for simulation of 'booted'?
<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 ?
<cladamw>
wpwrak, with your experimented current value so that I can fine tune R41/D1 circuit to get our 'expected' similar luminance (you there).
<wpwrak>
(If) about 2.45 mA
<cladamw>
wpwrak, no, if we add an external pulldown, then we don't worry that left floating.
rejon [rejon!~rejon@li382-141.members.linode.com] has joined #milkymist
<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 other
<cladamw>
wpwrak, yours is also 2.45mA?
<wpwrak>
(R229) it would make it a pullup
<wpwrak>
s/it would/I would/
<wpwrak>
yes, 2.45 mA. ltst-c190krkt is a bit different, electronically, from the APA... but not a lot (Vf about 100 mV lower)
<wpwrak>
err, sorry. 100 mV higher.
<cladamw>
wpwrak, oah..yes a pullup (R229) can also make D1 ON when in manufacturing mode[default].
<cladamw>
wpwrak, okay... I'll change R229 to be a pullup like 10K Ohm, is that okay?
<wpwrak>
why so low ? you only need it to protect the gate
<cladamw>
oh~you replied, checking...
<wpwrak>
the FPGA already has a perfectly good internal pull-up resistor
<wpwrak>
so 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.
<cladamw>
wpwrak, ah...forgot, so add also 1 M Ohm pull-up?
<wpwrak>
yup
<cladamw>
btw, i didn't used supply from +5V
<wpwrak>
hmm ?
<cladamw>
but 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?
<lekernel>
Fallenou: it was a very old milkymist
<lekernel>
0.1 or something :)
<wpwrak>
cladamw: sure. just like in M1rc3 :-)
wolfspraul [wolfspraul!~wolfsprau@114.241.252.33] has joined #milkymist
<cladamw>
wpwrak, good. ;-)
<Fallenou>
lekernel: huhu ok
<Fallenou>
I will check if I have not made any obvious mistake while kicking out nor & uart
cladamw [cladamw!~Adam@host-222.80-43-115.dynamic.totalbb.net.tw] has joined #milkymist