Topic for #milkymist is now Radical Tech Coalition :: Milkymist One, Migen, Milkymist SoC & Flickernoise :: Logs: http://en.qi-hardware.com/mmlogs
_whitelogger [_whitelogger!~whitelogg@kaunan.whitequark.org] has joined #milkymist
<wpwrak> kristianpaul: wasn't that hard to fix :)
<kristianpaul> for you..
_whitelogger1 [_whitelogger1!~whitelogg@kaunan.whitequark.org] has joined #milkymist
_whitelogger0 [_whitelogger0!~whitelogg@kaunan.whitequark.org] has joined #milkymist
_whitelogger0 [_whitelogger0!~whitelogg@kaunan.whitequark.org] has joined #milkymist
_whitelogger1 [_whitelogger1!~whitelogg@kaunan.whitequark.org] has joined #milkymist
_whitelogger0 [_whitelogger0!~whitelogg@kaunan.whitequark.org] has joined #milkymist
_whitelogger0 [_whitelogger0!~whitelogg@kaunan.whitequark.org] has joined #milkymist
<whitequark> hm.
_whitelogger [_whitelogger!~whitelogg@kaunan.whitequark.org] has joined #milkymist
<kristianpaul> qi-bot: may get angry for that :)
<whitequark> just fixed a nasty sleeping bug
<whitequark> which caused it to die silently sometimes
<qi-bot> The Firmware build was successfull, see images here: http://fidelio.qi-hardware.com/~xiangfu/build-milkymist/milkymist-firmware-01262012-0207/
pablojavier [pablojavier!~pablo@186.19.202.221] has joined #milkymist
pablojavier [pablojavier!~pablo@186.19.202.221] has quit [#milkymist]
lekernel_ [lekernel_!~lekernel@g225039119.adsl.alicedsl.de] has joined #milkymist
sameeg [sameeg!~leduc@APuteaux-153-1-64-98.w82-124.abo.wanadoo.fr] has joined #milkymist
<wolfspraul> wpwrak: great, with the -tmp files you uploaded yesterday mouse works
<wolfspraul> [unrelated to usb] seems that when trying to run simple mode, if you run into a patch with a problem, you cannot run the entire series
<wolfspraul> it just says "Failed to compile" then all you can do is go back?
<wpwrak> (mouse works) victory !! ;-))
<wpwrak> (compile errors) yes, you have to fix the error(s) before the series will run
<wpwrak> afaik, it's always been like this
<wolfspraul> skip button would be smarter, or maybe ignore altogether
<wolfspraul> ok lemme see the icreativ now
Martoni [Martoni!~chatzilla@ip-167-165.evhr.net] has joined #milkymist
<wolfspraul> oh my god, yes, the values are moving :-)
<wolfspraul> under 'latest active controllers' I just see numbers though
<wolfspraul> like 11 (91)
<wolfspraul> 11 seems to stand for the icreativ pad
<wpwrak> very good :)
<wpwrak> now, assign midi1 through midi3 as follows: pad x, pad y, fader, one of the encoders (dials)
<wolfspraul> how?
<wpwrak> and then you can run the tornado rain dance remix
<wpwrak> ah, open the midi dialog
<wpwrak> then click on midi1 and keep the mouse button pressed
<wpwrak> then use the control in question (i.e., make is send something)
<wpwrak> then the value should appear
<wpwrak> release the mouse button and repeat with midi2, etc.
<wolfspraul> keep mouse button pressed doesn't work, but there's an edit field where I can enter a number
<wolfspraul> if I had a USB connector free for a keyboard, so maybe I need to juggle between mouse & kbd?
<wpwrak> press it with the mouse over "midi1"
<wolfspraul> I did but nothing happens
<wpwrak> did you keep it pressed while making controller input ?
<wolfspraul> but isn't that an edit field next to "midi1"?
<wolfspraul> ahh
<wolfspraul> no, wait
<wpwrak> hah :)
<wolfspraul> our oh-so-intuitive interface
<wolfspraul> ahem
<wolfspraul> yes!
<wpwrak> (intuitive) yeah, it's something you have to know. couldn't think of an easy way to do this without adding clutter
<wolfspraul> what do you mean with pad x/y ?
<wolfspraul> if the first number is the controller, I see 11 and 12 and 13 when playing with the pad
<wolfspraul> can't really see a pattern yet
<wpwrak> horizontal movement = 12
<wpwrak> vertical = 13
<wolfspraul> oh
<wolfspraul> perfect, I have 12-13-7-40 there now
<wpwrak> it works best if you make an x or y movement and when you see the right number appear, release the mouse button in the movement
<wolfspraul> sure
<wpwrak> sounds good
<wpwrak> now, click OK
<wpwrak> and then run the tornado rain dance rmx
<wolfspraul> I may not have the latest data partition
<wolfspraul> geiss & werner
<wpwrak> you could probably download it
<wpwrak> yeah !
<wolfspraul> that must be it
<wolfspraul> wow, very nice
<wolfspraul> is there a way to change the color?
<wpwrak> see what M1 can do ? ;-)
<wpwrak> yes. go back to the MIDI dialog, set the icreativ to "Control" (3rd button on the right), then assign midi4-8 to four of the virtual faders
<wpwrak> OK again, and then you have red/green/blue on the first three faders and the color change speed on the fourth. default color change speed is 0, so nothing will happen before you increase that
<wpwrak> if you play some music, the pattern should become alive a bit more and you can create collision effects in the center:
<wolfspraul> hmm, interesting
<wpwrak> pick a high Y position (with some X you like, shouldn't be extremely low, though); move the spots out a bit with the fader;
<wolfspraul> the ability to control color doesn't come across very well right now for me
<wolfspraul> that's a nice demonstration of the importance of different types of controls
<wpwrak> increase their size/chaosity with the knob/dial (midi4); then bring them closer together with the fader
<wolfspraul> so with those 4 virtual encoders, I don't feel I can influence the color in a controlled way, will play a bit more with that
elldekaa [elldekaa!~hyviquel@abo-168-129-68.bdx.modulonet.fr] has joined #milkymist
<wpwrak> when they're at the point of touching each other, the pattern in the center will "explode" outward
<wpwrak> color is difficult, yes
<wpwrak> the patch also runs a color change algorithm underneath
<wolfspraul> yeah
<wolfspraul> it's ok, just saying
<wpwrak> so R/G/B merely affect how important the respective channel is. also, there's a level balancing. so if you set them all to zero, it still rotates through all of them
<wolfspraul> sure, this needs a lot of thought to be intuitive
<wolfspraul> but all cool, it works :-)
<wolfspraul> usb-midi that is
<wpwrak> you get a clearer effect with the color speed. set a low X high Y value, so that you get more or less a straight line. then you can see how the colors change
<wpwrak> (works) congratulations ! that was an arduous journey ;-)
<wpwrak> ah, and if you want to keep the MIDI settings, you have to save the "performance"
<wolfspraul> nah
<wpwrak> else, they get reset when you reboot
<wolfspraul> if something is on a fader, you better make sure whatever it corresponds to has a min/max that is known and fixed in advance
<wpwrak> of course, once you get the hang of it, you're about as fast setting it up again as you are digging out and loading the performance :)
<wolfspraul> for example in that patch, when I up the fader, the circle of action increases
<wpwrak> yes
<wolfspraul> but what if I want to increase beyond the max?
<wolfspraul> that's frustrating to run into the wall :-)
<wpwrak> every control has a min/max value
<wpwrak> hehe ;-)
<wolfspraul> sure, just saying
<wolfspraul> with an endless encoder you can keep turning, though software then still has to make sense of it
<wpwrak> it's like a real musical instrument. no matter how much you'd like it to, your guitar won't have more strings ;-)
<wpwrak> "trust the designer" :)
<wolfspraul> indeed
<wolfspraul> why does usb work in your images, but not at all in xiangfu's last daily build?
<wpwrak> i was thinking of combining controls, with one adjusting a multiplier/exponent
<wolfspraul> I have to look into the daily builds, not that I think anyone is using them...
<wpwrak> dunno. yesterday, i found and fixed a missing commit that may have broken builds. so maybe it was actually an old version.
<wolfspraul> ah ok
<wpwrak> (fader vs. encoder) it's also a question of which type of control gives you the better movements. e.g., you can also create dynamic effects by varying the position rapidly
<wpwrak> e.g., find a nice "orbit" where the spots don't touch. then quickly move them into the center and bring them out again
<wpwrak> this gives you an "explosion" with the spots superimposed
<wpwrak> now vary them with the music, etc.
<wpwrak> similar, you can create a pumping effect for the whole screen: move the fader to near-zero, Y low, then increase Y until you get an "explosion". then it reaches the edge of the screen, decrease Y to make it shrink again.
<wpwrak> s/then/when/
<wpwrak> you can also play with the rotation. but that doesn't work to nicely with the low resolution of the icreativ
azonenberg1 [azonenberg1!~azonenber@cpe-67-246-33-188.nycap.res.rr.com] has joined #milkymist
<wpwrak> (rotation) e.g., put a finger at X = 0, press with another finger at a larger value of X, to start rotating. then release it to stop. press again, etc. kinda like visual scratching
azonenberg [azonenberg!~azonenber@cpe-67-246-33-188.nycap.res.rr.com] has joined #milkymist
<wpwrak> there are a few more things one could do with this patch, e.g., change the way the border behaves when shrinking the pattern. but we'll need more controls for that :-)
<wpwrak> if you want to try the LV3, you'll need to go PC--(OSC,Ether)-->M1 for now, with midi2osc doing some mapping on the PC
<lekernel_> whitequark: what's that Ruby-based 'flash stuff' about?
<wpwrak> lekernel_: looks like whitequark's job application for working at adobe :)
sameeg [sameeg!~leduc@APuteaux-153-1-64-98.w82-124.abo.wanadoo.fr] has quit [#milkymist]
<Fallenou> 22:14 < mwalle> Fallenou: btw there are four (or five?) unused opcodes, two reserved ones and div/mod (there is only a divu and modu iirc) < OK I must have looked too fast the op code lookup table, indeed I see now the two "reserved" opcodes, great :) We could then use those two reserved opcodes as "Control Register (CR) Format
<Fallenou> Control Register (CR) Format instruction types
<Fallenou> btw I don't get why they put a mul and div opcode in the opcode lookup table, and then do not describe those instructions afterward, they just don't exist (yet) ? It seems you can only get mulu et divu (if you enable it)
<Fallenou> So I wonder why they didn't put mul and div as reserved too
<wpwrak> hmm. i'm getting confused about blocking vs. non-blocking. why is count <= count+1; if (count) ... valid ? if i understand things correctly, the non-blocking assignment <= means that the count <= count+1; and the if (count) can be scheduled concurrently
<wpwrak> or does verilog provide an exception for "obvious" data dependencies ?
<wpwrak> or are we exploiting some implementation properties ?
<Fallenou> if you do count <= count + 1 if (count) your "if" will get the "old count" if I understand correctly
<lekernel_> if you use "<=" the signals take the value from their last assignment only after all the always block has been executed
<wpwrak> aah !
<wpwrak> thanks. that explains a lot ;-)
<lekernel_> it's standard behaviour, not implementation property or someting
<Fallenou> if count = 3, then you will do if (3) and the next clock cycle (or always execution) you will get count = 4
<stekern> the only case where the order matters is if you have for example: count <= count + 1; if (count) count <= 0;
<lekernel_> yes, that why I said "from their *last* assignment"
<wpwrak> which in this case would be implementation-dependent
<lekernel_> no
<wpwrak> in the case of count <= count + 1; if (count) count <= 0; ?
<wpwrak> well, is "last" lexical or temporal ?
<lekernel_> temporal
<lekernel_> that code would produce 0/1/0/1/0/1 ...
<lekernel_> on all implementations
<wpwrak> hmm, why ?
<wpwrak> count <= count+1; and if ... should be able to be scheduled independently if the assignment doesn't block
<lekernel_> start with 0, you get count <= count +1, then the if isn't executed, and at the end of the always block it's only "count <= count +1" which matters, and you get 1
<wpwrak> ah ! got it
<lekernel_> start with 1, you get count <= count +1, but the if gets executed this time, and the last assignment is then "count <= 0", and you get 0
<stekern> it's the same as if (count) count <= 0; else count <= count + 1;
<lekernel_> yes
<wpwrak> subtle :)
<Fallenou> good to know about the "last assignment" thing
<larsc> wpwrak: think of count as two variables
<larsc> count_next when it is on the left side
<larsc> count_prev when it is on the right side
<larsc> at the end of always block you do count_prev = count_next
<wpwrak> yes, i think i got it. i didn't think of the "the assignment is guaranteed not to happen before the end of the block"
<wpwrak> was more thinking of something along the lines of count=`expr count + 1` & if [ count -ne 0 ] ... &
<wpwrak> i.e., where the assignment may or may not complete before the value is read
elldekaa [elldekaa!~hyviquel@adm02.insa-rennes.fr] has joined #milkymist
<wpwrak> and in 26 minutes i'll know if my understanding has sufficiently penetrated the mysteries of verilog ...
<lekernel_> wpwrak: you can edit setup.v and disable large cores like the tmu
<lekernel_> or use a simulator
<Fallenou> if Xst/others would not support multi dimensionals array (like 3-dimensional) that would mean they do not support Verilog-2001 :x
<wpwrak> too lazy to have build variants :)
<wpwrak> i'll just clean up my code while waiting ...
<wpwrak> back to the count example. i'm afraid i still don't get :-( with count <= count + 1; if (count) count <= 0;
<wpwrak> if count is 1 when we do this, don't we have count <= 2 race with count <= 0 at the end of the block ?
<lekernel_> no, it's the last executed assignment which gives the value of count at the end of the block
<wpwrak> yes, but what rules makes the count <= count+1 execute first ? is it still lexical order then ?
<wpwrak> i.e., if i had for (i = 0; i != 1000; i = i+1) foo <= i; would then the result to be guaranteed to be 999 ?
<wpwrak> s/to be g/be g/
<wpwrak> or, alternatively, if i unrolled the loop and wrote foo <= 0; foo <= 1; ...; foo <= 999;
<wpwrak> alas, my verilog book doesn't give much of a definition there ;-( (or maybe they hid it in an unlikely place)
<stekern> yes, foo would be 999
<lekernel_> wpwrak: the "execution" is like a C program... except that the "variables" using <= only take their values at the end of the always block
<wpwrak> okay, thanks. the naming is confusing. seems that calling <= a "deferred assignment" would be clearer
<wpwrak> now my little critter is starting to look good :)
<wpwrak> lekernel_: thanks for forwarding the rtems patch !
pablojavier [pablojavier!~pablo@186.19.202.221] has joined #milkymist
<whitequark> lekernel_: a real-world usage example would be: http://pastie.org/3255932
pablojavier [pablojavier!~pablo@186.19.202.221] has quit [#milkymist]
aeris- [aeris-!~aerith@home.aerith.fr] has joined #milkymist
wolfspra1l [wolfspra1l!~wolfsprau@p5B0AB12B.dip.t-dialin.net] has joined #milkymist
xiangfu [xiangfu!~xiangfu@123.114.251.251] has joined #milkymist
wolfspraul [wolfspraul!~wolfsprau@p5B0AB12B.dip.t-dialin.net] has joined #milkymist
xiangfu [xiangfu!~xiangfu@fidelio.qi-hardware.com] has joined #milkymist
<sh4rm4> whitequark: missing plugin
<whitequark> sh4rm4: I think that's not essential for viewing of the page
<whitequark> flash is used there for something like URL to clipboard copying
<GitHub32> [milkymist] wpwrak created ledmtrx (+1 new commit): https://github.com/milkymist/milkymist/commit/1ec6828
<GitHub32> [milkymist/ledmtrx] LED matrix controller - Werner Almesberger
<lekernel_> wpwrak: you shouldn't do stuff when reset is asserted
<lekernel_> eg if(reset) r <= 0; r <= foo; ===> if(reset) r <= 0; else r <= foo;
<lekernel_> (there are some places in the MM code where I omit reset, but those registers do not have any reset... not a half-implemented one)
<lekernel_> also, what's the "begin: _" syntax? can't you use simply "begin" ?
<wpwrak> verilog sometimes insists that blocks be named, e.g., for local variables or for "disable"
<wpwrak> did you see that, on reset, i exit the always block after initialize() ?
<wpwrak> the "_" is just my silent form of protest that i'm required to provide a name at all :)
<lekernel_> hm, I didn't know about disable... never seen it in any other code than yours
<lekernel_> where did you get that from?
<lekernel_> and does xst do the right thing(tm) when it sees it, or messy hardware?
<wpwrak> from the book "Verilog HDL" by Samir Palnitkar
<lekernel_> the xst coding guide recommends using if(reset) ... else ...
<wpwrak> as far as i can tell, it seems to be a standard feature
<wpwrak> well, it ought to be equivalent. just a different style
<lekernel_> yes, it is... there are tons of features in verilog, some are relevant, others not
<lekernel_> a bit like C
<wpwrak> ;-)
<lekernel_> by the way, if writing reset code bores you (it should), migen takes care of this automatically, too
<wpwrak> ;-))
<wpwrak> let me first understand verilog. then i'm in a much better position to bicker about usability regressions in migen :)
<lekernel_> without "begin: _"
<lekernel_> now maybe that's a xst peculiarity - I've never tried to synthesize tasks
<wpwrak> there's no local variable there
<wpwrak> the "input" is an argument
<wpwrak> ah, right. yes, that work. but i didn't like mixing arguments and local variables
<wpwrak> so i went for a C-ish style with the local variables clearly set apart. but for this, i need to name the block
<lekernel_> then again you should be happy to use migen :p
<wpwrak> just need to de-pythonize migen ;-)
<lekernel_> the advantages of pythonization far outweights the small syntax issues
<wpwrak> syntax matters :)
<lekernel_> it's not worse than verilog
<wpwrak> yeah, i wonder how verilog ended up like this
<lekernel_> let alone vhdl
<wpwrak> `define ? backticks ? c'mon
<wpwrak> and since they already went for C style, pray tell why not use { ... } instead of begin/end ? i don't think the grammar would get ambiguous. just needs a bit more work since it's not trivially LALR(1) anymore
<wpwrak> and then nonsense like requiring blocks to be names in order to get local variables. they had C as a nice and simple example to copy from. was that really too hard ?
<wpwrak> s/names/named/
<wpwrak> of course, that i've seen of VHDL syntax, that one is pure evil. like SDL.
<wpwrak> well, the critter works. that's what counts :) and i've learned a bit about verilog. shouldn't be hard to transform the thing when we do the great big switch to migen.
<wpwrak> actually, you suggesting i use migen suggests migen can be deployed incrementally. so that would be even better than a great big switch.
<lekernel_> yes it can, but it's more work in the end
<lekernel_> and I don't plan to support much of the current architecture (CSR/FML) in Migen
<wpwrak> ah, i see
<lekernel_> but new code should use migen :p
<wpwrak> without a way to connect to the rest of the system ? :)
<lekernel_> there is a way.. only you'll have to implement CSR manually (like you did in verilog)
<wpwrak> okay, that doesn't sound too scary
<lekernel_> the only unsupported thing is tri-state I/O
<lekernel_> but it shouldn't be very hard to add
<wpwrak> oh, important for memory :)
<lekernel_> memory?
<lekernel_> DRAM?
<lekernel_> we'll use a verilog phy... with unidirectional signals to/from the controller
<wpwrak> for NOR, too ?
<lekernel_> yes, too
<wpwrak> hmm, and the gpios have hard-coded directions
<wpwrak> but it would be good to have more flexible gpios for the extension header
<wpwrak> for quick prototyping, without having to write HDL
pablojavier [pablojavier!~pablo@186.19.202.221] has joined #milkymist
pablojavier [pablojavier!~pablo@186.19.202.221] has quit [#milkymist]
<wolfspraul> nice picture of lots of leds :-)
<wolfspraul> can you take a video of how they are being controlled?
<wolfspraul> on the picture, it looks like they are being controlled gradually increasing from off to full?
<whitequark> lekernel_: any comments on "flash stuff"?
<lekernel_> tbh I'm not very interested in flash (nor HTML, javascript, etc.)
<qi-bot> The Firmware build was successfull, see images here: http://fidelio.qi-hardware.com/~xiangfu/build-milkymist/milkymist-firmware-01262012-1611/
antgreen [antgreen!user@nat/redhat/x-quwggvbsclmvaczk] has joined #milkymist
<GitHub102> [migen] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/migen/commit/bf2f6f31e372378bd736dbebefc77b4da07d8edf
<GitHub102> [migen/master] doc: ASMI description - Sebastien Bourdeauducq
kilae [kilae!~chatzilla@catv-161-018.tbwil.ch] has joined #milkymist
<whitequark> lekernel_: expected. I was quite surprised you ever asked about that :)
<lekernel> wpwrak: btw "if (pre_count < prescaler)" ==> "if (pre_count != prescaler)"
<lekernel> test for equality is a bit less expensive than comparision
<xiangfu> lekernel, just sent out two small patches about save and restore the manual edit network configure. please take a look.
<xiangfu> will check email tomorrow. have to goto sleep. see you
<larsc> lekernel: so to continue where i left off yesterday. If you have http://metafoo.de/flow4.png where A1,A2 and B1,B2 are instances of the same type. It is pretty obvious that B1 and B2 can be timeshared since only ever one of them will be active at a time.
<larsc> But you can also deduce from the model that A1 and A2 can be timeshared
elldekaa [elldekaa!~hyviquel@vpn3.enssat.univ-rennes1.fr] has joined #milkymist
aeris- [aeris-!~aerith@home.aerith.fr] has joined #milkymist
<kristianpaul> nice leds :)
<kristianpaul> and source code :)
<kristianpaul> good use of tasks
<kristianpaul> I'll keep in mind
<kristianpaul> so far i just tought using tasks in test benches..
elldekaa [elldekaa!~hyviquel@vpn3.enssat.univ-rennes1.fr] has joined #milkymist
<wpwrak> wolfspraul: (increasing) yes, i just loaded a ramp from 0 to 255. the display is static
<wolfspraul> ok, I see. no dancing led zoo yet... :-)
<wpwrak> lekernel: (test for equality) yeah, i didn't want that to avoid cycling through the values above "prescaler" in case someone sets a value below the current pre_count. of course, if prescaler_bits is reasonably small, like here, it doesn't really matter
<wpwrak> wolfspraul: the dancing LEDs would be under software control ;-) i hope sw-updating the LED array at, say, 10 Hz, wouldn't tax the core to badly
<wpwrak> lekernel: so i'm a bit torn between making it efficient and making it somewhat foolproof. e.g., you could conceivably make the prescaler 32 bits wide and then sit in the dark for ~53 seconds after an ill-fated prescaler update. it's a bit of a "white people problem", admittedly.
<mwalle> wpwrak: since you merge the symtab branch you could remove it from the public repo :)
<wpwrak> yeah .. lemme check what local branches i have left dangling ...
<mwalle> git push github :symtab (or sth like that ;)
<wpwrak> yup
<wpwrak> i used git push origin :symtab
<wpwrak> gone both from milkymist and flickernoise. thanks for the reminder !
<mwalle> mh endless reboots with qemu and mm bios, nice
* wpwrak celebrates the invention of the perpetuum mobile
<mwalle> wpwrak: invented by you?
<wpwrak> by you, no ? "endless reboots" :)
<mwalle> who say it doesnt need any energy to keep it alive ;)
<mwalle> lekernel: what does "BRD: SoC and HAL versions do not match!" mean?
<wpwrak> ah, you cheated. pity.
<wpwrak> (BRD) is it showing you the bird ? :)
<mwalle> lekernel: nevermind, bitstream version, not board revision :)
<mwalle> anybody has a recent flickernoise binary (not stripped) for me? :)
* mwalle is still to lazy to get rtems flying ;)
<wpwrak> mwalle: maybe i could get you interested in my cheat sheet ? http://projects.qi-hardware.com/index.php/p/wernermisc/source/tree/master/m1/BUILD-CHEAT-SHEET
<wpwrak> mwalle: (just updated it to pin to 01-DEC-2011, since they added regressions afterwards which i think are still around)
<mwalle> wpwrak: i still would prefer an image, i would still need to compile lm32-rtems-*
<wpwrak> you don't even have a compiler ? pfui ...
<mwalle> no rtems one :)
<wpwrak> (the difference between the two flickernoises is just the memory command fixes)
<wpwrak> the gateware is still the regular system. no led matrix support :)
<mwalle> wpwrak: thx, just need the fn image for qemu ;)
<mwalle> bios can be compiled with lm32-elf- (which i have :b )
<Fallenou> could be nice to have the equivalent of the "update firmware GUI" with just a shell command
<wpwrak> ;-))
* Fallenou does not have any monitor
<wpwrak> jtag ?
<Fallenou> yep, but not tonight :)
<wpwrak> with m1nor, upgrading via jtag is pretty easy. you just run m1nor <file> or m1nor <files> and it'll do the rest
<wpwrak> i.e., it figures out where things go and such, based on the file name
<Fallenou> nice !
<Fallenou> I will give it a shot this week-end I think
<Fallenou> where is m1nor ?
<Fallenou> thanks
<wolfspraul> should we modify reflash_m1.sh to run on top of m1nor?
<wolfspraul> that would probably introduce a little bit of redundancy, but not much
<wpwrak> not sure ... they do similar things, but there are also several differences
<wpwrak> the most interesting part for sharing would be the partition data. but then it's not something that should need updating very often.
<lekernel> wpwrak: you could reset the prescaler counter on a update
<wpwrak> lekernel: hmm. good point.
<wpwrak> actually, there's an even easier way: counting to zero. then there would only be a problem if you set an insanely large value and have to wait for it to count down
<wpwrak> let's see how this changes the resource footprint ...
<lekernel> probably not much on the whole, but it's a nice learning excercise *g*
<lekernel> and it's actually more a timing problem
<lekernel> by the way, if you use the ISE Project Navigator GUI, there's an almost mediocre schematics viewer that lets you see what xst generates
<wpwrak> i'm currently checking system.srp: 3 Adder/Subtractor(s) 267 D-type flip-flop(s) 5 Comparator(s) 71 Multiplexer(s) 7 Tristate(s)
<wpwrak> (that's with the original version)
<wpwrak> counting to zero eliminated one comparator
<lekernel> well, it probably replaced it with a NOR :)
<wpwrak> it should :)
<lekernel> hmm, in fact, no... it can use the carry output. so that would be even more efficient
<lekernel> (there are hardwired carry chains in the s6)
<wpwrak> how do i invoke that ISE Project Navigator GUI ?
<lekernel> type ise
<lekernel> note that sometimes it crashes if you run KDE at the same time, though it didn't happen to me recently... maybe they fixed this bug eventually
<wpwrak> now it wants a .xise file
<lekernel> yeah, you should do the whole "create project" IDE gig ...
<lekernel> ah and by the way - it has the annoying habits of creating craploads of temporary files in the current directory, so you should create a special folder for it
<wpwrak> hmm. will be a moment. a bat just invaded my office ...
<wpwrak> okay, was a smart one who realized i didn't have it on my menu and that it could thus prioritize escaping over hiding in a corner for days
<wpwrak> what should i choose for the "top-level source type" ?
<wpwrak> tried system.n??
<wpwrak> it doesn't know how to make use of the data, though
<GitHub174> [milkymist] wpwrak pushed 1 new commit to ledmtrx: https://github.com/milkymist/milkymist/commit/41394c1381ea9cb667f78fa282c6b19b5a2f6ee8
<GitHub174> [milkymist/ledmtrx] ledm.v: make prescaler count to zero, to avoid using comparator - Werner Almesberger
<qi-bot> The Firmware build was successfull, see images here: http://fidelio.qi-hardware.com/~xiangfu/build-milkymist/milkymist-firmware-01262012-2301/