#milkymist IRC log for Friday, 2011-09-02

adamw_xiangfu, can we have an item about full screen shows up in test program? If yes, make this item as an optional but not include it into totally pass counting.03:19
xiangfuadamw_, " full screen shows up in test program" what you mean 'full screen' ?03:20
adamw_so far now I'd prefer to test incoming camera quality check in test program03:20
adamw_yes, full screen03:21
adamw_then I don't need to power-cycle again to rendering mode or select 'full screen' patch in gui03:22
adamw_I'd like test program to have this function while I can also test all keyboards for incoming parts check.03:23
adamw_Of course in gui can also do everything, but I'd this 'full screen' included in test program, if it's easy. ;-)03:23
xiangfulet me check03:28
xiangfuadamw_, just double check the videoin test. it only use half screen.04:00
xiangfuadamw_, you just want full screen?04:00
xiangfuadamw_, or direct load videoin test will give blank screen, I have to start 'vga' test first, then 'videoin' will working04:00
adamw_xiangfu, yes, the initialization on vga firstly then video-in, so I'd also suggest that it also initiate vga chip before video-in test while I press 'h' to test video-in, i.e. I think it doesn't matter to add initialization in video-in test item, how do you think?04:04
xiangfuadamw_, yes. but before test videoin. better test VGA.04:05
adamw_when you repeatedly press 'h' to test camera, you will get '5' and '4' not '7' and '4'. did you see that whenn you repeatedly test video-in04:06
adamw_xiangfu, sure, agreed, so in order to test video-in, i have to press 'd' to test vga first, so i don't think i need to always press 'd' again04:07
xiangfuadamw_, yes. it' give me 5 and 4 when repeat press 'h'04:08
adamw_btw, check if it's possible make it full screen in test program. if it's easy.04:08
adamw_xiangfu, yes, pls take some times to fix that from '7' to '5'04:09
adamw_it must be s/w initialization in video chip, maybe reset video codec somewhere, when I repeatedly test it04:09
adamw_so i won't be confused that if camera detect is not good, actually this is definitely s/w initial problem. I want to see every time it shows '7' and '4' when I press 'h'.04:11
xiangfuadamw_, ok. 1 try to full screen. 2. check why it's give '5' sometimes. it should always '7' right?04:13
adamw_xiangfu, yes, thanks a lots.04:13
xiangfuadamw_, seems the half screen is on purpose.04:17
adamw_my question is the vga pattern can be full screen, but why camera's out can not pass through a full screen, if it's a little hard, no rush to understand it now. ;-)04:20
xiangfuadamw_, no. the video in buffer is 720x288. and VGA buffer is 640x480.04:24
xiangfuso it cut the video in buff to from 720x288 to 640x28804:24
xiangfuI can insert a duplicate data in 288. it's like  1 2 3 4 -->  11 22 33 44 , make 288 stretch to 48004:26
adamw_you can study for a while first, not directly insert, since my goal is to see full screen in test program. so inserting data is if a good idea, maybe you can ask wpwrak. or you can study how gui to process this full screen's method in 640 * 480 mode firstly? ;-)04:33
adamw_well..no rush on this feature.  thanks. :)04:33
xiangfuwhere I can find more info about m1 TMU05:06
xiangfuok. seems the easy way is just insert duplicate data , under flickernoise. it's using TMU to display full screen. if I understand correct.05:09
GitHub23[autotest-m1] xiangfu pushed 2 new commits to master: http://git.io/4Vd3jg05:18
GitHub23[autotest-m1/master] build depends libs - Xiangfu Liu05:18
GitHub23[autotest-m1/master] tests_videoin: stretch to fullscreen - Xiangfu Liu05:18
GitHub70[autotest-m1] xiangfu pushed 1 new commit to master: http://git.io/Yyb14w05:27
GitHub70[autotest-m1/master] add git rev to boot.crc.bin - Xiangfu Liu05:27
wpwrakbooting ...06:45
wpwrakah, test programs :)06:55
awrc3 accessories packing 30 sets done without m1/case: http://downloads.qi-hardware.com/people/adam/m1/pic/rc3_30sets_accessories_packing.JPG07:19
awthose 30 sets I put accessories firstly by following instructions. later I'll put whole assembled M1 with case in EVA.07:23
awnow next step: assembly of m1 with cases.07:23
qi-botThe build was successfull, see images here: http://fidelio.qi-hardware.com/~xiangfu/build-milkymist/milkymist-openwrt.minimal-09022011-1116/10:11
lekernelxiangfu, is there anything new in those openwrt images?10:17
adamw_finger cot: http://downloads.qi-hardware.com/people/adam/m1/pic/rc3_m1_case_assemble_finger_cot.JPG13:58
aerisPlus pratique les gants...14:03
wpwrakaeris: i guess the cute fingertip thingies give you better respiration14:05
aerisIt's true14:05
kristianpaulnice cot, very fingy ;)14:07
Fallenounice !14:08
kristianpaulactually because when you uses gloves doest feel very confortable for manipulate tiny styuff14:08
lekernelI'm sure wpwrak could find an interesting name for those14:08
wpwrak"finger cot" appears to be a sensible name ... the expression does exist in regular english14:11
adamw_my poor english so just found that name for it. ;-)14:12
adamw_well...before put into EVA, need to check and clean if need. :)14:13
xiangfulekernel, (openwrt) no. I just setup the build.14:17
lekernelxiangfu, maybe it can skip it if there has been no new commit since last build?14:19
xiangfulekernel, yes. in TODO list. haven't setup that.  :)14:20
lekernelwolfspraul, to improve startup feedback, what do you think of blinking the render LED while the patches are compiling?15:16
wpwraki wonder if it would be really so hard to just cache compiled patches ... kinda the equivalent of   for p in *.patch; do c=`md5sum "$p" | sed 's/ .*//'`; if [ ! -r "$c" ]; then compile <"$p" >tmp && mv tmp "$c"; false; fi && load_patch "$c"; done15:59
GitHub156[autotest-m1] xiangfu pushed 1 new commit to master: http://git.io/DsW8NQ16:00
GitHub156[autotest-m1/master] output build data time and git rev when start - Xiangfu Liu16:00
wolfspraulsure - blinking, why not :-)16:03
lekernelwpwrak, in theory not, but you have to define a format for loading and storing, which isn't supported yet16:10
lekernelalso it should do the right thing when loading a patch that has been compiled by an earlier incompatible version of FN16:11
wpwrak(format) ah, i see. so it's not just a long byte string you could just dump16:12
wpwrak(incompatible) erase the cache each time you upgrade FN ? :)16:12
wpwrak(or downgrade, same-grade, whatever)16:13
wolfspraulI think we can also delete cache files each time the patch is edited/written, since we control the (few) access paths in the sources quite well16:13
wolfspraulthat would solve the need for any timestamp or hash16:14
wpwrakthis wouldn't affect the out-of-the-box experience because adam would have already sat through that initial compilation when testing16:14
wpwrakwolfspraul: according to sebastien, no all access paths are controlled16:14
wpwrake.g., FTP or such16:14
wolfspraulhow is that not controlled? :-)16:17
wolfspraulthat's the secret radio backdoor in the xilinx fpga?16:17
wolfspraulmaybe it's ugly, but definitely it's another idea. just adding to the list.16:18
wpwrakdunno. maybe it's a program that comes with RTEMS lekernel hasn't modified or doesn't want to modify16:18
wpwrakto reliably delete the cache, you'd have to add taps to all the places that could change a patch. or introduce some generic file monitoring service to RTEMS16:19
wpwrakwell, one approach would be to have a designated upload area, from where patches are then moved through a controlled process16:20
wpwrakthe process would basically go like this: cd uploads/; for p in *.patch; do if [ -r "../patches/$p" ]; then c=`md5sum "../patches/$p" | sed 's/ .*//'`; rm -f ../cache/$c; fi; mv "$p" ../patches; ...compile...; done16:23
wpwrakand most important, have a button to unconditionally delete the whole cache and force recompilation of all patches :)16:23
lekernelwpwrak, a simple solution is to store the FN version number in the compiled patch, and ignore cached patches that do not have the same version tag as the current running software16:24
lekernelthe hashing part is easy, storing/loading compiled patches needs a bit of thought16:25
wpwraklekernel: yes, version numbers would work too. delete-on-upgrade would simple reuse the compile-if-not-cached mechanism, which may or may not be a little easier. depends a bit on what else you do when upgrading.16:28
kristianpaulor add regex-core for better speed for patch compilation?16:41
kristianpaulregex or whatever operation when compiling a patch could be improved in hardware16:41
wpwrakhuh ? you mean for the lexical scanner ? that should be O(n) :-) or is there some weird misuse of regexes in the patch compiler ?16:44
kristianpauldunno, just guessing :-)16:45
lekernelnah, the patch compiler is using lemon+re2c (nice tools when the GNU stuff makes it hard to run the generated parsers on a non-GNU system) in a simple way16:49
kristianpaulwhat is basically the procedure? path to magic ecuations that later are looped against the pfpu?16:57
lekernelit is explained in thesis.pdf16:59
kristianpaulyes i _still_ reading16:59
qi-botThe build was successfull, see images here: http://fidelio.qi-hardware.com/~xiangfu/build-milkymist/milkymist-openwrt.minimal-09022011-2351/22:46

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