| lekernel | what's the difference between "line out" and "line level out"? | 00:37 |
|---|---|---|
| lekernel | the wm codec has both | 00:37 |
| lekernel | atm we're using the "line out" and it works, so i guess we'll stick with that | 00:37 |
| lekernel | hi aw | 00:38 |
| lekernel | could you get samples of WM9707? we'll probably use it in the end | 00:40 |
| aw | lekernel, hi evening | 00:40 |
| aw | yes, i can order some of them. | 00:41 |
| aw | still reading your email. :-) | 00:41 |
| lekernel | yeah... you should read the IRC log too :) | 00:42 |
| aw | okay...i may change some capacitor with low ESR to have extremely lower ripples from power supplies to check. | 00:43 |
| lekernel | you think the noise might come from power supply caps? | 00:45 |
| lekernel | FYI: I'm using the WM codec without noise now | 00:45 |
| lekernel | I have fixed some problems in the FPGA design that prevented it from working correctly | 00:45 |
| lekernel | and now we have noise free audio | 00:45 |
| aw | yes, WM may have different performance noise reduction tech...yup? also fixed on fpga design?>>> sounds great. | 00:46 |
| aw | you used WM codec in RC1 not RC2, right? | 00:50 |
| roh | aw: ack. it was a fight! | 00:51 |
| roh | not for the wm.. that one came out easy... the video adc was hard | 00:51 |
| roh | i either need nozzles for that tqfp stuff or much more experience ;) | 00:52 |
| roh | aw: can you tell us about your hot-air experiences, give some tips? | 00:53 |
| aw | roh, yup, such skilled tech. you have is great. :-) | 00:53 |
| lekernel | yeah, I took a RC1 board | 00:54 |
| aw | well...last week i just used hot-air to rescue one damaged RC2 board with all ICs, | 00:54 |
| lekernel | roh: well, with the bigger nozzle it wasn't so hard | 00:54 |
| lekernel | and leaded solder doesn't have so much tendency of forming balls behind the pins | 00:55 |
| aw | lekernel, okay..the layout/schematic between rc1 and rc2 is quite different, so i may yes order WM to replace it on my rc2 for confirmation. | 00:55 |
| lekernel | aw: the WM chip requires a few modifications | 00:56 |
| aw | lekernel, yup, can imagine. :-) | 00:56 |
| lekernel | remove 1M resistor on crystal, add capacitor on pin 33 (for 3D effect, optional), add capacitors on pin 32 | 00:56 |
| lekernel | I have uploaded the datasheet to the git repos. please have a look at it | 00:57 |
| aw | okay.. | 00:57 |
| lekernel_ | <lekernel> remove 1M resistor on crystal, add capacitor on pin 33 (for 3D effect, optional), add capacitors on pin 32 | 01:00 |
| lekernel_ | I have uploaded the datasheet to the git repos. please have a look at it | 01:00 |
| lekernel_ | also, we might also want to route SPDIF to the internal connector and DNP the parts for the nonexistent headphones amp | 01:00 |
| lekernel_ | you should also recompile the test program | 01:01 |
| aw | lekernel_, um..seems lot of works to be learn on my side. ;-) | 01:06 |
| lekernel_ | btw i'm running the demo console in 800x600 resolution atm | 01:14 |
| aw | has this changed by SoC or s/w porting enough? | 01:15 |
| lekernel_ | some dirty soc hacks | 01:17 |
| aw | umm.:-) | 01:17 |
| lekernel_ | 1024*768 wouldn't work though. well, maybe with more buffering | 01:19 |
| aw | lekernel_, do you think that we still need U23 if change into WM in the end? or not necessary. | 01:21 |
| lekernel_ | the 4.3V regulator? | 01:22 |
| lekernel_ | well... could be a good idea to protect against incoming power supply noise | 01:22 |
| lekernel_ | at least we have more safety if we happen to pick up a noisy transformer | 01:23 |
| aw | I probably also order some low ESR capacitors to replace C215 10uF. As a recommended part there in datasheet. ;-) yeap, seems use it as a seperated circuitry part. | 01:25 |
| aw | i saw some doc the 'white' noise can come from bad ripples from power supply, but we didn't test though. :-) | 01:28 |
| lekernel_ | power supply? | 01:31 |
| lekernel_ | I checked it on scope... looks clean | 01:31 |
| lekernel_ | but you can still double check :) | 01:31 |
| aw | yeah, double check is good after replace a low ESR capacitor. :-) | 01:32 |
| xiangfu | lekernel_: Hi. I am working on try to create the /dev/flash5 image. then ender user can easy flash that by using urJtag. got more patches and wallpaper.png | 02:06 |
| xiangfu | lekernel_: I think I mis-understand your task about default wallpaper. | 02:06 |
| xiangfu | so I talk with wolfgang about my task on milkymist one. | 02:06 |
| xiangfu | something wrong with the "www.milkymist.org"? always give me connect timeout. and | 06:24 |
| xiangfu | --- www.milkymist.org ping statistics --- | 06:24 |
| xiangfu | 11 packets transmitted, 0 received, 100% packet loss, time 9999ms | 06:24 |
| xiangfu | xiangfu@fidelio:~$ ping www.milkymist.org | 06:25 |
| xiangfu | PING www.milkymist.org (69.163.150.252) 56(84) bytes of data. | 06:25 |
| xiangfu | ^C | 06:25 |
| xiangfu | --- www.milkymist.org ping statistics --- | 06:25 |
| xiangfu | 11 packets transmitted, 0 received, 100% packet loss, time 9999ms | 06:25 |
| rejon | xiangfu might be our location | 06:30 |
| roh | rejon: i can't reach it either. seems down | 06:30 |
| xiangfu | rejon: I tried in qi-hardware.com. in Germany :) | 06:31 |
| rejon | i got sweet vpn running here now at mozilla china office | 06:31 |
| xiangfu | ww.milkymist.org works fine now | 07:02 |
| aw | i also can't reach taipei here 1 hour ago, but now it's ok. | 07:03 |
| xiangfu | how can I copy file from milkymist one to PC? | 07:28 |
| xiangfu | I try the tftp. it's always give me timeout. | 07:28 |
| xiangfu | got it. it's ftp. | 07:37 |
| xiangfu | my first 'fbgrab' in milkymist one : http://downloads.qi-hardware.com/people/xiangfu/tmp/mm1.c.png | 08:11 |
| xiangfu | kristianpaul: wolfspraul. the 'fbgrab' is working :) http://downloads.qi-hardware.com/people/xiangfu/tmp/mm1.2.png | 10:06 |
| xiangfu | http://downloads.qi-hardware.com/people/xiangfu/tmp/mm1.1.png | 10:06 |
| kristianpaul | xiangfu: ohhh | 10:09 |
| kristianpaul | xiangfu: cheers ! | 10:10 |
| xiangfu | kristianpaul: I shoudl connect the camera to which color of video in? | 10:11 |
| Fallenou | well done xiangfu :) thanks ! | 10:13 |
| xiangfu | kristianpaul: http://downloads.qi-hardware.com/people/xiangfu/tmp/mm1.video.in.1.png | 10:25 |
| xiangfu | http://downloads.qi-hardware.com/people/xiangfu/tmp/mm1.video.in.2.png | 10:25 |
| xiangfu | http://downloads.qi-hardware.com/people/xiangfu/tmp/mm1.video.real.picture.jpg | 10:25 |
| xiangfu | this may help find out the video issue. | 10:26 |
| xiangfu | Fallenou: now. I try to send patch to lekernel :) | 10:27 |
| kristianpaul | xiangfu: green i remenber | 10:46 |
| kristianpaul | nice car ;) | 10:46 |
| xiangfu | not in my yard. only in my camera :D | 10:47 |
| lekernel_ | xiangfu: nice shots | 10:47 |
| lekernel_ | i'll replace that on milkymist.org | 10:47 |
| lekernel_ | if you don't mind :) | 10:47 |
| xiangfu | lekernel_: sure. | 10:47 |
| kristianpaul | woah, thats cool http://downloads.qi-hardware.com/people/xiangfu/tmp/mm1.4.png | 10:57 |
| xiangfu | I like this patch very much, thanks lekernel. :) | 11:00 |
| kristianpaul | what's the name of this one? | 11:01 |
| kristianpaul | looks awesome indeed | 11:01 |
| Fallenou | xiangfu: oh you have screenshot feature even in performance mode ? | 11:02 |
| xiangfu | Fallenou: yes. when run 'fbgrab' the performance will stop. | 11:03 |
| xiangfu | I guess it's cause real time os. right? | 11:03 |
| Fallenou | how do I run it ? typing "fbgrab" in the rtems shell ? | 11:03 |
| xiangfu | fbgrab file_name.png | 11:03 |
| Fallenou | in the shell ? | 11:03 |
| xiangfu | yes | 11:04 |
| Fallenou | ok | 11:04 |
| Fallenou | strange that it stops the performance | 11:04 |
| xiangfu | oh. it's stop everything. | 11:04 |
| xiangfu | for example. connect with telnet. ftp. and serial | 11:04 |
| Fallenou | you mean it freezes the board ? :o | 11:04 |
| Fallenou | and then after the screenshot, everything resumes ? | 11:05 |
| xiangfu | when you do 'fbgrab' in serial. the 'telnet' and 'ftp' just stop. until 'fbgrab' finish. | 11:05 |
| xiangfu | Fallenou: yes. | 11:05 |
| Fallenou | oooh ok | 11:05 |
| wolfspraul | xiangfu: wow nice - congrats! | 11:05 |
| xiangfu | Fallenou: this is not normal? | 11:05 |
| Fallenou | it should not | 11:05 |
| xiangfu | oh. | 11:06 |
| Fallenou | ftp and shell should run in separate threads | 11:06 |
| wolfspraul | now we need to be able to do the fbgrab from a (usb) keypress | 11:06 |
| xiangfu | the fbgrab need ~16 seconds. | 11:06 |
| Fallenou | rtems runs several threads | 11:06 |
| Fallenou | and do scheduling among them | 11:06 |
| wolfspraul | and we need to publish flickernoise images that have this included (and get the patches accepted upstream by sebastien) | 11:06 |
| wolfspraul | 16 seconds? :-) | 11:06 |
| wolfspraul | that's the next thing to optimize :-) | 11:06 |
| Fallenou | 16 seconds to read a 640x480 array ? | 11:06 |
| wolfspraul | but one by one, it's great progress, very good! | 11:07 |
| xiangfu | Fallenou: I using the 'time fbgrab a.png' | 11:07 |
| xiangfu | Fallenou: let me run that again. | 11:07 |
| Fallenou | never tested the time in rtems shell | 11:07 |
| xiangfu | Fallenou: I think because write nor flash. | 11:08 |
| xiangfu | I tried copy files from memory card to /dev/flash5. very very slow. | 11:09 |
| xiangfu | 160KB | 11:09 |
| Fallenou | oooh yes maybe | 11:09 |
| Fallenou | try to write to the ramfs | 11:09 |
| Fallenou | just to see the speedup you get | 11:09 |
| Fallenou | it might give you the "incompressible" part of the time | 11:09 |
| Fallenou | to show you what you can optimize and what you cannot | 11:09 |
| Fallenou | (ramfs is mounted on /ramdisk ) | 11:10 |
| Fallenou | I don't know how much ram is mounted there, maybe some 4 kB | 11:10 |
| xiangfu | [/flash] # time fbgrab 7.png | 11:11 |
| xiangfu | 11: time fbgrab 7.png | 11:11 |
| xiangfu | Converting image from 16 | 11:11 |
| xiangfu | Now writing PNG file... | 11:11 |
| xiangfu | time: 0:02:28.670 | 11:11 |
| xiangfu | under flash. I start the performance, ftp, and telnet. some music played in line-in. | 11:12 |
| Fallenou | try to write in /ramdisk (if there is enough space) or just try commenting out the part that actually write) | 11:12 |
| xiangfu | the music not stop. | 11:12 |
| xiangfu | Fallenou: ok. | 11:13 |
| Fallenou | just to confirm the write is the big part | 11:13 |
| Fallenou | which may be incompressible unfortunately :/ | 11:13 |
| lekernel_ | xiangfu: seems you don't close /dev/fb in your fbgrab function | 11:14 |
| lekernel_ | and the fact that the software freezes while fbgrab is running is perfectly normal | 11:14 |
| xiangfu | lekernel_: oh. yes. | 11:14 |
| xiangfu | lekernel_: too bad. :( | 11:15 |
| lekernel_ | fbgrab is running with the shell task priority, which is the highest | 11:15 |
| Fallenou | oh ok so it's a priority thing | 11:15 |
| lekernel_ | so RTEMS will not preempt it as long as it has something to do | 11:15 |
| lekernel_ | if you want to put it in the background, you could spawn a PNG compress/write sub-task | 11:15 |
| lekernel_ | with low priority | 11:15 |
| lekernel_ | also be careful if you read the framebuffer in this subtask | 11:15 |
| lekernel_ | because it can be modified by other tasks while you read it :) | 11:16 |
| xiangfu | (subtask) don't know how to do that now. :( need look into document. | 11:16 |
| xiangfu | wolfspraul: (keyboard shotcut) yes. | 11:17 |
| lekernel_ | so the dirty solution is to take a copy of the framebuffer in a high priority task and then process it in a low priority task | 11:17 |
| xiangfu | kristianpaul: it's "Lekernel - Vibrant Plasma Streams.fnp" | 11:17 |
| lekernel_ | a clean solution can be copy-free (since the framebuffer is already mapped in memory and uses triple buffering) and you'd simply "lock" the current displayed framebuffer from the driver | 11:18 |
| lekernel_ | i.e. you add a 4th buffer | 11:18 |
| lekernel_ | in normal operation, that 4th buffer isn't used, it's the current triple buffering | 11:19 |
| lekernel_ | but when fbgrab requests a still framebuffer you return the currently displayed one and you don't touch it again until fbgrab is done with it | 11:19 |
| lekernel_ | but you can keep rendering using the other 3 remaining buffers | 11:19 |
| lekernel_ | it's a bit more complex to implement, but it would make fbgrab not interfere at all with the rendering | 11:20 |
| lekernel_ | also, keep in mind that the CPU is heavily used by the rendering already | 11:21 |
| lekernel_ | so if you use a background task, your PNG encoding can take forever | 11:21 |
| lekernel_ | about the ramdisk: you can write loads of stuff there, it's allocating on the ~100MB heap | 11:22 |
| wolfspraul | xiangfu - my m1 still has flickernoise 0.1 - what is the easiest way to upgrade? | 11:26 |
| xiangfu | lekernel_: thanks for the info. | 11:27 |
| xiangfu | wolfspraul: urjtag. I think. | 11:27 |
| wolfspraul | ok. need to disassemble my case first then... | 11:28 |
| xiangfu | wolfspraul: or this one: http://lekernel.net/blog/?p=1339 | 11:29 |
| wolfspraul | and find one of those small allen keys for it, argh... | 11:29 |
| xiangfu | but I never tried this method. | 11:29 |
| wolfspraul | which one do you use? | 11:29 |
| xiangfu | urjtag | 11:29 |
| wolfspraul | ok | 11:29 |
| xiangfu | back online in 1 hours. | 11:30 |
| CIA-43 | milkymist: Sebastien Bourdeauducq master * r99b1cfe / software/bios/Makefile : remove duplicate code in makefile (Xiangfu) - http://bit.ly/e5RwfR | 11:49 |
| lekernel_ | got 1024x768 ...with still some bugs though | 12:39 |
| wolfspraul | hey my projector can only do 800x600 | 12:43 |
| wolfspraul | and I bought it because I thought it was 'future-proof' with m1. but you seem to be too fast! | 12:43 |
| wolfspraul | my flickernoise 0.1 does not work with an Apple USB keyboad I have here | 12:44 |
| lekernel_ | is that a keyboard with integrated hub? | 12:44 |
| wolfspraul | is that something that was improved in later flickernoises? | 12:44 |
| wolfspraul | wait, checking... | 12:44 |
| wolfspraul | yes, indeed | 12:45 |
| wolfspraul | when I plug it into LInux, I get 2 new devices, hub and keyboard | 12:45 |
| lekernel_ | keyboards with integrated hubs are fucking extreme bloody pains in the ass that would make you hate USB forever should you even think about trying to develop support for them | 12:45 |
| wolfspraul | good catch! | 12:45 |
| wolfspraul | well, xiangfu can add it to his todo list :-) | 12:45 |
| lekernel_ | and they're not supported atm | 12:45 |
| wolfspraul | (at the bottom though) | 12:45 |
| lekernel_ | well it won't be an easy task | 12:45 |
| wolfspraul | no problem, I will find another keyboard | 12:45 |
| wolfspraul | yes I can imagine | 12:45 |
| wolfspraul | not the right priority now | 12:45 |
| wolfspraul | I will find another keyboard | 12:45 |
| wolfspraul | then I much rather have xiangfu implement usb keyboard support in the Ben NanoNote :-) | 12:46 |
| wolfspraul | without a hub, of course | 12:46 |
| wolfspraul | thanks that was an easy catch. I will find another keyboard. | 12:46 |
| lekernel_ | god, USB is so stupid... how could one even dream about making so complicated and messy the simple task of transmitting key presses and mouse moves down a bit of electric wire? | 12:48 |
| lekernel_ | I don't get it | 12:48 |
| xiangfu | btw. I have a wireless mouse and keyboard. using one usb receiver. the mouse works fine. keyboard not working | 12:48 |
| lekernel_ | xiangfu: also you're not freeing buf_p in fbgrab | 12:52 |
| lekernel_ | and zeroing it should be unnecessary | 12:52 |
| lekernel_ | you could also use an ioctl() interface that gives you the address of the framebuffer... and you wouldn't have to allocate memory anymore | 12:53 |
| xiangfu | lekernel_: thanks. | 12:55 |
| Fallenou | accessing the fb through the driver each time is an overhead | 12:56 |
| Fallenou | accessing directly the memory array is faster | 12:56 |
| xiangfu | is that ok, just read the framebuffer when mm1 do performance ? | 12:56 |
| Fallenou | look at how it is done in fb.c | 12:57 |
| Fallenou | (for the ioctl) | 12:57 |
| lekernel_ | wolfspraul: for the resolution, 800x600 will be supported as well. ideally, we could even detect the supported resolutions with DDC and pick the highest. | 13:00 |
| lekernel_ | and in fact it wouldn't make much difference with the rendering, only with the GUI | 13:00 |
| lekernel_ | I don't believe the current SoC architecture would be able to run the complete rendering system at high resolutions and high frame rate | 13:00 |
| lekernel_ | so the rendering would happen with a limited resolution internal framebuffer that is scaled up on the fly by the VGA controller | 13:01 |
| xiangfu | lekernel_: I will send another patch with fixed 'free' and 'close', I will look into the ioctl, direct read framebuffer. | 13:06 |
| lekernel_ | ok | 13:06 |
| xiangfu | lekernel_: I add the close(fd) to the end of main_fbgrab. the problem. | 13:12 |
| xiangfu | everytime 'fbgrab a.png' finished the screen got no signal. | 13:12 |
| lekernel_ | ah :) | 13:13 |
| lekernel_ | uhm, yes | 13:13 |
| xiangfu | just like the close(fd), close the vga output. | 13:13 |
| lekernel_ | actually the framebuffer driver isn't supposed to be acceded from two different tasks | 13:13 |
| lekernel_ | it enables video out at open() and disables it at close() | 13:13 |
| lekernel_ | you should be able to fix that by adding a reference counter to it | 13:14 |
| xiangfu | yes. when I run the fbgrab again. video out work again. before fbgrab finished. | 13:14 |
| lekernel_ | do you see how? | 13:14 |
| lekernel_ | open: ref_counter++; if(ref_counter == 1) enable_video(); | 13:15 |
| lekernel_ | close: ref_counter--; if(ref_counter == 0) disable_video(); | 13:15 |
| xiangfu | in c/src/lib/libbsp/lm32/shared/milkymist_framebuffer/framebuffer.c right? | 13:16 |
| lekernel_ | yes | 13:16 |
| lekernel_ | and with mutexes if you want something neat | 13:16 |
| xiangfu | lekernel_: I will try to do that. | 13:17 |
| xiangfu | counter first :) | 13:17 |
| lekernel_ | 1024x768 working bug free now :) | 13:19 |
| xiangfu | great. | 13:19 |
| xiangfu | so I can also get the resolution by using ioctl ? | 13:19 |
| lekernel_ | but it collapses when you start rendering | 13:19 |
| lekernel_ | the memory can't keep up | 13:19 |
| lekernel_ | we'll definitely need scaling | 13:19 |
| lekernel_ | hm, don't know. haven't looked at how to implement that in RTEMS yet | 13:20 |
| lekernel_ | but when it's done yes, it'll be with ioctl() | 13:20 |
| xiangfu | (scaling) under verilog code right? (I try to understand more) | 13:20 |
| lekernel_ | yes, when rendering the FPGA will scale the low resolution framebuffer on the fly, at the same time as it generates the video signal | 13:21 |
| lekernel_ | this way the load on the memory system is only that of the low resolution framebuffer | 13:21 |
| lekernel_ | but when using the GUI, the needed memory bandwidth is much lower, and we can enjoy the full resolution | 13:21 |
| lekernel_ | he 14 fps @ 1024x768 | 13:26 |
| lekernel_ | it's not that bad | 13:26 |
| lekernel_ | (i'm using the demo firmware now) | 13:29 |
| xiangfu | lekernel_: http://pastebin.com/E1cVn3WW. is this ok? | 13:30 |
| xiangfu | ref_counter ^ | 13:30 |
| lekernel_ | yeah, looks good | 13:30 |
| xiangfu | lekernel_: ok. I will send out the patch to mailing list. | 13:31 |
| Fallenou | the resolution is held in a struct fb_var_screeninfo | 13:32 |
| Fallenou | dunno if you can get it from ioctl | 13:32 |
| Fallenou | i guess not :x | 13:32 |
| Fallenou | xiangfu: FBIOGET_VSCREENINFO | 13:34 |
| Fallenou | this ioctl will give you the good struct :) | 13:34 |
| Fallenou | to get the resolution | 13:34 |
| xiangfu | Fallenou: ok. try to implement in next fbgrab. 1. direct read fb; 2. get more info by using ioctl | 13:35 |
| xiangfu | Fallenou: thanks. | 13:35 |
| lekernel_ | ok, now the funny part: use partial reconfiguration to let the software change the pixel clock | 13:37 |
| lekernel_ | since it seems xilinx fucked up the normal way to reconfigure clock generators, I guess I'll have to spend the afternoon doing icky fpga hacking | 13:38 |
| Fallenou | lekernel_: will the rtems framebuffer driver have to change its resolution? | 13:40 |
| lekernel_ | hmm... I guess I'll generate a differential bitstream with only the DCM configuration changed and then throw that into the ICAP to change the pixel clock | 13:41 |
| Fallenou | I mean dinamically | 13:41 |
| lekernel_ | yes, sure. we want GUI menus to select the resolution, don't we? | 13:41 |
| lekernel_ | and before on the fly scaling works, we might even have to switch back to 640x480 during rendering | 13:41 |
| Fallenou | ok so we need to implement the FBIOPUT_VSCREENINFO | 13:42 |
| Fallenou | ioctl | 13:42 |
| xiangfu | lekernel_: I have a very small patch to connect mm1 by serial console. but not sure if you would like put it in milkymist.git or flickernoise.git. blow is the small patch | 13:44 |
| xiangfu | +connect: /dev/ttyUSB1 | 13:44 |
| xiangfu | + stty -F $< raw 115200 | 13:44 |
| xiangfu | + while : ; do cat $< ; done & cat > $< | 13:44 |
| xiangfu | + | 13:44 |
| xiangfu | i add it to "milkymist.git/boards/milkymist-one/flash/Makefile" | 13:44 |
| xiangfu | lekernel_: http://pastebin.com/UTgAwWcG. this one is more clear | 13:46 |
| lekernel_ | why not use flterm? | 13:46 |
| lekernel_ | or gtkterm, or...? :) | 13:46 |
| xiangfu | ah. I always using 'kermit' :). | 13:47 |
| xiangfu | this one is just for ender using maybe. | 13:47 |
| xiangfu | lekernel_: a better one. : http://pastebin.com/pgiznE7u | 13:48 |
| xiangfu | I would like this small feature. since some one just bought on mm1. then he connect the usb cable. run 'make connect' he can got the boot log :) | 13:49 |
| CIA-43 | milkymist: Sebastien Bourdeauducq master * rdcef87c / boards/milkymist-one/flash/Makefile : flash: connect target to get boot log (Xiangfu) - http://bit.ly/geWVza | 13:53 |
| xiangfu | lekernel_: thanks. :) | 13:54 |
| xiangfu | lekernel_: sorry. the my terminal make the 'tab' as 'space'. :( | 14:01 |
| lekernel_ | and what's the problem? | 14:02 |
| xiangfu | lekernel_: after you apply my patch from "http://pastebin.com/pgiznE7u" in makefile the front of 'stty ...' and 'while ..' is space not 'tab' | 14:04 |
| lekernel_ | argh | 14:05 |
| lekernel_ | ah, and it should be a phony target too | 14:05 |
| CIA-43 | milkymist: Sebastien Bourdeauducq master * recb9635 / boards/milkymist-one/flash/Makefile : fix connect target - http://bit.ly/g2iX5Z | 14:06 |
| xiangfu | new patches send out. one for rtems-milkymist.git the fb ref counter. another is fbgrab fixed. free and close. | 14:10 |
| lekernel_ | I put your screenshots online: http://www.milkymist.org/flickernoise.html | 14:11 |
| lekernel_ | thanks for those! | 14:11 |
| lekernel_ | we should put some with the video input | 14:11 |
| lekernel_ | preferably with good looking dancers etc. :) | 14:11 |
| kristianpaul | i can find good looking dancers next week at labsurlab ;-) | 14:15 |
| xiangfu | after I update the rtems-milkymist.git. I got some error on network. | 14:16 |
| xiangfu | "No rx buffers left in the pool! We are in big troubles!" | 14:17 |
| xiangfu | ok. not always. after reboot. the ftp works fine again | 14:17 |
| lekernel_ | yeah, there are still several ethernet bugs | 14:18 |
| CIA-43 | rtems-milkymist: Sebastien Bourdeauducq master * r68f1136 / c/src/lib/libbsp/lm32/shared/milkymist_framebuffer/framebuffer.c : add open ref_counter to framebuffer driver (Xiangfu) - http://bit.ly/gAoF3v | 15:09 |
| lekernel_ | xiangfu: could you re-send your fbgrab patch with tabs for indentation? | 15:16 |
| Fallenou | hum I've read somewhere that usually spaces are preferred | 15:22 |
| Fallenou | because tabs can be interpreted by your editor | 15:22 |
| xiangfu | lekernel: sended out. will more carefully next time. | 15:22 |
| xiangfu | Fallenou: linux kernel style is using 'tab' | 15:23 |
| Fallenou | tabs could show up as a different number of spaces depending on the editor | 15:23 |
| Fallenou | whereas spaces are always the same | 15:23 |
| Fallenou | xiangfu: so I guess it's the best :p | 15:24 |
| xiangfu | lekernel: btw. I saw you always manually apply the patch. I always using save the file to .eml, the 'git am PATCH_EMAIL.eml', if the patch is as expect :) | 15:26 |
| xiangfu | Fallenou: the only issue for me is the terminal always replace 'tab' with 'spaces'. | 15:30 |
| CIA-43 | flickernoise: Xiangfu Liu master * r64ea9ad / (src/main.c src/shellext.c src/shellext.h): | 15:31 |
| CIA-43 | flickernoise: add screenshot command fbgrab | 15:31 |
| CIA-43 | flickernoise: add screenshot command fbgrab | 15:31 |
| CIA-43 | flickernoise: add topic 'flickernoise' | 15:31 |
| CIA-43 | flickernoise: TODO: | 15:31 |
| CIA-43 | flickernoise: * direct read fb memory | 15:31 |
| CIA-43 | flickernoise: * get more info by using ioctl - http://bit.ly/i4YvHS | 15:31 |
| lekernel | xiangfu: thanks | 15:31 |
| lekernel | and tab width is 8 | 15:32 |
| lekernel | (to answer Fallenou's concern :p) | 15:32 |
| Fallenou | well if you say you want real tabs | 15:33 |
| Fallenou | there is no width :o | 15:33 |
| Fallenou | the width is the way the editor displays it | 15:33 |
| xiangfu | time for sleep. see you. | 15:35 |
| Fallenou | gn8 ! | 15:35 |
| CIA-43 | milkymist: Sebastien Bourdeauducq master * re758b81 / software/libhal/snd.c : demo: display WM9707 codec when found - http://bit.ly/hT1vau | 15:42 |
| CIA-43 | milkymist: Sebastien Bourdeauducq master * rba6271d / (8 files in 4 dirs): Support video mode switching - http://bit.ly/gzq2DZ | 15:47 |
| Action: lekernel is using the flickernoise GUI in 1024x768 atm :) | 16:04 | |
| CIA-43 | flickernoise: Sebastien Bourdeauducq master * re7498df / src/fb.c : Detect screen resolution at start up - http://bit.ly/gP3CgA | 16:06 |
| CIA-43 | mtk: Sebastien Bourdeauducq master * rf3ff0f5 / lib/scrdrv.c : Remove hardcoded resolution - http://bit.ly/hoX4hv | 16:06 |
| CIA-43 | rtems-milkymist: Sebastien Bourdeauducq master * r6ac350f / c/src/lib/libbsp/lm32/milkymist/include/system_conf.h : Add all definitions for VGA registers - http://bit.ly/eQbLaJ | 16:16 |
| lekernel | http://www.milkymist.org/flickernoise/dmxtable.png | 16:41 |
| CIA-43 | flickernoise: Sebastien Bourdeauducq master * r81bdecd / src/shellext.c : fbgrab: detect screen resolution - http://bit.ly/dSQUzg | 16:43 |
| mwalle | lekernel: btw we wont have to modify the bios serial upload protocol | 20:55 |
| mwalle | im using a BREAK character | 20:56 |
| mwalle | thus i've only needed to add support for that in the uart transceiver | 20:56 |
| lekernel | hm, what's that? keeping the line at 0 for more than one byte and no stop bit? | 20:58 |
| lekernel | can it be done with common serial port hardware and drivers at the other (PC) end? | 20:59 |
| lekernel | http://stackoverflow.com/questions/1279478/rs-232-break-signal | 21:02 |
| mwalle | lekernel: yeah violating the stop bit | 21:03 |
| mwalle | there is a short break (length between one and two frames) and a long break character (longer thatn two frames) | 21:03 |
| mwalle | all modern serial transceivers should be able to generate one :) | 21:04 |
| lekernel | worst case I guess we can 'emulate' it on the PC side by setting a baudrate too low and transmitting a zero character | 21:04 |
| mwalle | yeah, lol :) | 21:04 |
| lekernel | lol: http://www.elmelectronics.com/ebench.html#ELM460 | 21:14 |
| lekernel | I found that crap when looking for info about how to send rs232 breaks | 21:14 |
| lekernel | ELM electronics has a "break detector" circuit | 21:14 |
| lekernel | I guess they're programmed attinys/pic or something like that | 21:14 |
| mwalle | lekernel: lol | 22:26 |
| mwalle | lekernel: the gdb stub will need 6kb/2kb rom/ram | 22:27 |
| lekernel | 8kb in total? | 22:27 |
| mwalle | yes | 22:27 |
| lekernel | bytes? | 22:27 |
| mwalle | bytes | 22:27 |
| lekernel | should be ok i think... | 22:28 |
| lekernel | we have that much spare BRAM afaik | 22:28 |
| mwalle | unfortunately it is hard to mux gdb packets and console.. atm i did a tx redirection with the help of the uart core | 22:30 |
| mwalle | there are some scripts that intercepts the serial port traffic and looking for gdb packets and split them from normal data, but that wont work out of the box | 22:31 |
| mwalle | gdb supports 'systemcalls' eg read and write to stdin/stdout/stderr, but that requires an application that is 'gdb aware' | 22:32 |
| mwalle | gn8 :) | 22:35 |
| mwalle | 12.142ns sys_clk period with one breakpoint | 22:36 |
| mwalle | the new ise seems to be a lot better :)= | 22:39 |
| CIA-43 | mtk: Sebastien Bourdeauducq master * r0789f9d / lib/gfx_functions.h : Fixed text antialiasing - http://bit.ly/hBuztv | 23:04 |
| CIA-43 | mtk: Sebastien Bourdeauducq master * r7a7bc76 / (7 files): Dark blue color theme - http://bit.ly/ijYerq | 23:46 |
| --- Tue Mar 29 2011 | 00:00 | |
Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!
