#milkymist IRC log for Sunday, 2012-04-08

Fallenougn8 !00:00
mwallegn800:00
wolfsprauln800:01
lekernelvideo capture dongles have latency08:02
lekernelwebcams even worse08:04
lekerneland I think turning the M1 into a regular computer will make our publicity problems worse if anything08:17
lekernellet's have high resolution digital video inputs (DVI/HDMI) instead. that's where we can have an advantage, both technically- and marketing-wise.08:22
lekernelalso we need a totally new UI. most people do not dare clicking into the FN GUI, let alone write patches and talk about it08:25
lekernelsomething in the style of reactable would look a lot more attractive08:26
lekernelhaving to choose, I largely prefer spending time on developing a portable, RF-based reactable surface rather than USB shit no one will care about because the proprietary semiconductor industry is already doing it a thousand times better than us08:27
lekernelafter we're out of the closet, then we can think about resource-intensive and low-reward things like USB08:32
lekernelmwalle: what Xst warnings are you suppressing exactly here? some of them are useful at (rare) times...09:32
GitHub193[milkymist] sbourdeauducq pushed 3 new commits to master: https://github.com/milkymist/milkymist/compare/0cf6156...59c183810:11
GitHub193[milkymist/master] fix compiler warnings - Michael Walle10:11
GitHub193[milkymist/master] enable -Werror flag by default - Michael Walle10:11
GitHub193[milkymist/master] bios: only build mkmmimg tool - Michael Walle10:11
mwallelekernel: have a look at filter.filter in synthesis/10:14
lekernelhmm, yes. but what is warning 693? :)10:15
lekernelthat one? http://www.xilinx.com/support/answers/44469.htm10:16
mwallelekernel: yep10:18
lekernelThis issue has been fixed in 13.3. 13.3 XST produces an INFO message instead of the WARNING message without any change to the actual information or message.10:19
mwallelekernel: mh, ok then i should update my xst ;)10:19
mwallelekernel: do you know some other warning messages which can be filtered?10:23
mwallethe patch should be a first step to bring the sheer amount of messages a bit down10:24
GitHub69[milkymist] sbourdeauducq pushed 2 new commits to master: https://github.com/milkymist/milkymist/compare/59c1838...a534e3410:25
GitHub69[milkymist/master] softusb: remap timer to 0x20..0x23 - Michael Walle10:25
GitHub69[milkymist/master] softusb: convert to non blocking assignments - Michael Walle10:25
lekernelmwalle: hmm, no, haven't really looked. and the warnings are only one component of the xilinx toolchain's logorrhea...10:26
mwallebbl lunch10:32
lekernelmwalle: what would you think of not checking the validity of the CRC in hardware and simply forwarding the crc5 and crc16 values to the navre?10:45
lekernelthen you don't have to detect and store the PID in hardware10:46
lekernelmwalle: I suppose the overflow bit is only meant to be read at the end of the reception of a whole packet?10:53
lekernel(as well as the other error bits)10:54
wpwrakhmm, isn't -Werror a bit extreme ? when debugging, you quite often generate code that produces warnings. if you have to edit and then un-edit the Makefile each time, that's messy10:55
mwallewpwrak: maybe introduce a debug flag? or override the flags?12:16
mwallelekernel: (errors) yep checking them at the end. thats my rx routine atm: http://paste.debian.net/162498/12:19
wpwrakmwalle: well, you could add a switch that enables -Werror (and maybe other things). CFLAGS_EXTRA or such.12:21
mwallelekernel: and forwarding the crc5_error and crc16_error (not the values imho) should work too, i havent looked at the cycles we have left to generate an ack/nack after packet reception12:22
wpwrakmwalle:  in normal development, -Werror shouldn't be necessary. the build should be silent enough that you can spot the warning. it's not like xst ;-)12:22
wpwrak(cycles0 very few :)12:22
mwallewpwrak: (flags) so it boils down to opt-in or opt-out the -Werror12:25
mwalleimho it should be enabled by default, and if someone doesnt like it (because hes debugging and too lazy ;)) he/she should be able to turn it off12:27
lekernelwpwrak: so you think there's no time to check the PID, fetch the appropriate CRC5 or CRC16 value, and validate it?12:29
wpwraklekernel: that's probably fine. would need testing, though. if i remember correctly, it's about 6.5 bit times12:35
wpwraklekernel: that is, from EOP to the start of the response12:35
wpwrakmwalle: i'd rather enable -Werror only in the rare case of completely unattended builds. that would be mainly xiangfu's builds.12:36
wpwrakmwalle: also, we may sometimes have warnings we can't get rid of easily. e.g., if there's an upstream issue.12:38
wpwrakmwalle: flickernoise has one such warning12:38
mwalle6.5 bit times would be 26 avr cycles, right?12:46
mwalle(at full speed)12:46
mwallewpwrak: (not our warnings) ok good point ;)12:48
mwallelekernel: if you read a whole value, you would have to make sure its still valid when you're reading it12:49
mwalleeg there was no transition on rx_active12:50
mwalleputting two error flags (crc5 and crc16), into the error register and let the processor decide which flag to use should work if it fits into 26 cycles but makes the error register somewhat unintuitive, because there will always be at least one bit set)12:53
wpwrakmwalle: (avr cycles) hmm, not sure. i usually check the timing on the scope. but it should be in that range, yes. i.e., enough to do something, but not enough to do a lot12:54
wpwrakmwalle: in fact, in our case the timing is a bit more relaxed because we don't have support hubs. but if you use that "buffer", you'll have one additional problem to solve once hub support is added. so ...12:55
lekernelmwalle: what about two error registers then? if(PID=xxx) err = REG_CRC5_ERROR; else err = REG_CRC16_ERROR;13:25
lekerneland reading any of these two registers clears both13:26
qi-botThe firmware build was successful, see images here: http://fidelio.qi-hardware.com/~xiangfu/build-milkymist/milkymist-firmware-20120408-1407/13:52
mwallelekernel: is your navre cycle acurate with the avr one?14:01
lekernelI haven't tried to make it so, but both navre and avr execute most instructions in 1 cycle14:02
mwallelekernel: branches, too?14:03
lekernelno, branches stall the pipeline14:03
wolfspra1llekernel: which RF did you have in mind when you mentioned "RF-based reactable surface" earlier?14:26
lekernelprobably custom in the MHz range; I mean RF as in replacement for a bulky videoprojector + infrared + webcam setup14:33
wolfspra1ldon't understand14:36
wolfspra1lthe new devices has a custom RF that communicates with what?14:36
wolfspra1lif it's custom, then on the other side there needs to be a 2nd device?14:36
lekernelthe reactable senses the objects from under the table by lighting them with infrared and filming with a webcam14:37
lekernelthis requires the webcam to be placed at a certain distance so it can capture the whole table14:37
lekerneland also requires a videoprojector for the picture14:37
lekernelthe idea is to turn that into a slim tablet by using RF and a communicating microcontroller in the objects14:38
wolfspra1lhmm, ok14:41
wolfspra1lI have never used a reactable myself, but I could imagine the look and feel of the table to be a big part of why people like that experience14:41
wolfspra1lyou would need a huge tablet too, no?14:41
wolfspra1land the table is round14:41
lekerneluse a TV flat screen14:42
wolfspra1land the fact that the projector comes from underneath may give a nice impression, don't know14:42
wolfspra1lbut yeah ok, I got it now14:42
wolfspra1lmake physical objects that communicate with a milkymist base station over some custom rf14:42
lekernelhow would the projector be better than a TV screen? seems to me the picture quality is worse with a projector14:43
wolfspra1lI don't know, just thinking14:43
wolfspra1lhave you used a reactable yourself?14:43
lekernelthe objects can be pretty small too14:43
lekernelactually, they can be smaller than with the original reactable :)14:43
wolfspra1lwhether someone likes something or not can depend on very small details14:43
lekernelwe'd just have to stick a 5x5mm AVR in them, plus a few passives14:43
wolfspra1land a round table with bottom side illuminiation etc. already is quite something special to start with14:44
lekernelnot a pattern big enough for the webcam to catch14:44
wolfspra1lit seems their physical objects need no electronics at all either, no battiers14:44
wolfspra1ltteries14:44
lekernelwe can have wireless power14:44
lekernelno batteries either14:44
wolfspra1lhow?14:45
wolfspra1lyou can get the energy across over RF?14:45
lekernelfor example, with a large coil around the screen14:45
lekernelyes, sure14:45
lekernelI'd actually like to pump a lot of it, so we can even have flashy LEDs and stuff on the objects14:45
wolfspra1lI mean I understand the physics that theoretically you can, but I'm wondering what we can power on the other side :-)14:45
lekernel1W sounds feasible14:46
lekernelas long as the magnetic field doesn't mess up with e.g. the screen or its control electronics14:46
wolfspra1lwe need to re-read the ISM band duty cycle limitations again :-)14:46
lekernelit won't be ISM band14:46
lekernelwe're talking about low frequency near field communications14:46
lekernelso we can even use the AVR to modulate - no special transceiver needed14:47
wpwrakyou probably want to get rid of the webcam14:47
lekernelfrequency for power and milkymist->object communication would be 100kHz or so14:48
wolfspra1lsounds interesting14:49
lekernelthen we can sense the object's position with its low power transmission received with an array of PCB printed coils14:50
lekernelthe object, of course, can incorporate a host of gadgetry (LEDs, accelerometers, buttons, what not)14:50
lekernelwe can make them arduino compatible, even :)14:51
lekernelyou can actually pump a lot of power over near field wireless, eg http://en.wikipedia.org/wiki/Magne_Charge14:52
lekernelwe're 3-4 orders of magnitude smaller than that :)14:53
qi-botThe firmware (using branch) build was successful, checkout the VERSIONS for detail, see images here: http://fidelio.qi-hardware.com/~xiangfu/build-milkymist/milkymist-firmware-20120408-1552/15:32
Fallenoustrange lm32 code is using clogb2() function which is log2()+1 and not log2()15:46
Fallenouso you have things like localparam addr_set_width = clogb2(sets)-1; everywhere15:46
GitHub70[migen] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/migen/commit/6a52e44d09afeadc7727f9a0cc9ebe405469360e16:14
GitHub70[migen/master] fhdl: support len() on signals - Sebastien Bourdeauducq16:14
Action: Fallenou would need the .len()16:21
--- Mon Apr 9 201200:00

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