<roh>
renzo: you mean use the hw as a lighting-controller?
<renzo>
kind of
<roh>
that should be possible (only sw needed) .. it can already send and recieve dmx with flickrnoise
<renzo>
for example, be able to play a dmx show
<renzo>
yes, but it need an engine to play on a timeline, isn't it?
<roh>
engine?
<renzo>
does flickrnoise make fades between two values?
<roh>
dunno. i guess it can
<roh>
flickrnoise plays 'patches' like the old winamp did
<lekernel>
it can, but it doesn't have the relatively advanced timeline support you probably need
<roh>
i guess it would make sense to write a specialized app for the mm1 for your usecase
<renzo>
another thing: should it be possible to add real time clock on the hardware?
<lekernel>
yup
<roh>
hm. realtime clock. there is none now. and without soldering you could only count crystal cycles...
<lekernel>
(rtc) you could add a rtc chip on the gpio expansion header, but if you're not into electronics/fpga/low-level it's probably easier to use NTP
<roh>
i guess one could add one via expansion header.. an i2c thingie with backup battery
<lekernel>
yup
<roh>
does one need a rtc 'on stage' ?
<roh>
i thought clocks are important.. but not the absolute time
<renzo>
even if i could use ntp, i am not always connected, but i can try to.
<roh>
as in midi or so masterclock
<roh>
renzo: counting crystal cycles is 'stable enough' for normal stuff. but a real clock would drift less (could be seconds a day)
<renzo>
or maybe i could use separate clock module, which start power when needed.
<renzo>
roh: i see
<renzo>
first, i will try in qemu to understand current dmx features
<renzo>
(rtc) there is a rtc in every pc, is it a simple thing?
<roh>
yes and no.
<roh>
yes its simple
<roh>
no, building one yourself doesnt make much sense right now
<roh>
mostly because one needs a low-current asic backed by a battery/accumulator
<roh>
and a extra 32khz crystal
<roh>
so i guess its not really making sense e.g. designging one on vhdl  or verilog besides if you want to build chips from that
<renzo>
ok
<roh>
of course it would be nice to have a foss rtc design ;)
<renzo>
:)
<roh>
just not that real-world useable with an fpga till made an asic
<nightlybuild>
hey roh. Did you finally receive cases order confirmation from Ccile?
<roh>
i did
<roh>
well.. no extra confirmation.. but a mail explaining my confusion ;)
<roh>
anyhow.. the acryllic is ordered and will be sent out to me today i was told on the phone earlier today
<roh>
so i hope it will all work out in time
<nightlybuild>
roh: great
<roh>
any idea how to get the stuff to fosdem? or where does it need to go to?
<nightlybuild>
roh: depends on shedule actually. May be lekernel may bring them with him. If not, you'll have to ship them out to Paris
<roh>
i see
<roh>
about dates.. when will you leave paris for brussels?
<lekernel>
roh: actually for simple and slow stuff like rtc's, actel fpga or cpld might be useful
<lekernel>
or even just make your own IC. shouldn't be very hard.
<lekernel>
I can't bring more stuff to fosdem. i'm not in Berlin anymore and will be back on Feb 7th
<roh>
i see
<roh>
then i'll send it
<nightlybuild>
roh: february 4th in the morning to Paris, then afternoon train to Bruxelles
<nightlybuild>
roh: so, postal delivery to Paris still the last solution
<nightlybuild>
time will tell
<roh>
we'll see how fast i get it done
<nightlybuild>
roh: yep. No worries
<nightlybuild>
we are also familiar with hacking time ;)
<roh>
hehe.. thats not my worries.. rather logistics and all the stuff i dont do
<lekernel>
roh: how much do those "triple head resolution expanders" cost?
<renzo>
do you think this kind of module would be easy to connect on mm1 ?
<larsc>
is the minimac driver supposed to work?
<mwalle>
hi
<drasko>
hi
<mwalle>
drasko: i thought you would submit some code or patches..
<drasko>
finaly it turned out to be very specific
<drasko>
and I guess useles
<drasko>
for the rest of the world
<drasko>
whot can be usefull is the breakpoint manipulation
<drasko>
which was not present in your code
<drasko>
So, what I commited was AMR946e target that was missing :http://openocd.git.sourceforge.net/git/gitweb.cgi?p=openocd/openocd;a=commit;h=9e3d43cfe75df7c4f6797d630576f1a02428b218
<drasko>
Point is that for LM32 all the commands processed by VHDL code are completely specific for the core that I have (that was customised hevily), so I did not want to commit these.
<drasko>
mwalle, did you progress further on OpenOCD port for Milkymist core ?
<mwalle>
drasko: not really
<drasko>
OK, then I will take up from the file you sent me, and try to update it wit all the general/non-specific stuff that can be relevant for Milkymist and send it by the end of the wee.
<drasko>
*week
<drasko>
I will not be able to test anything
<drasko>
I corrected several things, I thing cashed registers handling on break mode entry...
<mwalle>
drasko: hm there was some rewrite some months ago, you can find the updated source at my git repository
<drasko>
I had most of the trouble on commands part
<drasko>
because I did not know the format of the commands (documentation lost), so I had to look though VHDL code. Also Lattce's monitor comes as a closed source, so I had to disassemble it and reverse engineer the commands to send to it.
<drasko>
I basically added single stepping, and breakpoint handling
<drasko>
and just corrected few minor things in your code
<drasko>
and it works now correctly
<larsc>
yeay!
<drasko>
larsc, not for Milkymist, though :)
<larsc>
is the jtag interface different ?
<drasko>
completely
<roh>
oh?
<drasko>
but if Michael got Milkymist jtag iface working with UrJTAG, I guess it will not be a problem, because he knows all the commands needed to pass to the TAP controller
<drasko>
I'll integrate the changes of OpenOCD code, and send some instructions how I made my stuff working
<mwalle>
drasko: that would be cool :)
<drasko>
I can not test anything for Milkymist because I do not have platform, but it should be very close
<drasko>
mwalle, just for my information, what is the cirrent status on your OPenOCD port in the sense of functionality ? I guess you can send BREAK, and communicate with Monitor ROM ?
<drasko>
I.e. what is working for you and what is not ?
<mwalle>
iirc breakpoints and reset were working the last time i tested
<mwalle>
singlestep would be cool :)
<mwalle>
larsc: apropos gdb, we should redefine the registers (of course breaking lattice/theobromas/jons toolchain)
<mwalle>
as you noticed there are some missing :)
<drasko>
Most of the time I spend with toolchain
<drasko>
Lattice's toolchain sucks, GDB is complaining of Dwarf header error
<drasko>
so I used gcc-4.5.1, although Lattices toolchain whorks also when recompiled with new binutils (and preferebly new GDB also).