00:03:53 | | Join amayer [0] (~alex@h210.53.213.151.dynamic.ip.windstream.net) |
00:09:41 | | Quit lorenzo92 (Quit: ChatZilla 0.9.89 [Firefox 15.0.1/20120907231657]) |
00:28:26 | | Quit ender` (Quit: There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. -- C.A.R. Hoare) |
00:28:44 | sakax | hello all - any news regarding the nano2g usb issue ? :D |
00:39:03 | | Quit ChanServ (*.net *.split) |
00:39:33 | | Quit mgottschlag (Ping timeout: 240 seconds) |
00:46:31 | | Join ChanServ [0] (ChanServ@services.) |
00:46:31 | Mode | "#rockbox +o ChanServ " by leguin.freenode.net |
00:50:00 | | Quit scorche (Ping timeout: 245 seconds) |
00:53:08 | | Join scorche [0] (~scorche@rockbox/administrator/scorche) |
01:00 |
01:26:07 | | Quit lebellium (Quit: ChatZilla 0.9.89 [Firefox 16.0/20120919065210]) |
01:40:54 | | Quit eckoit (Quit: eckoit) |
01:41:31 | | Quit amayer (Quit: amayer) |
01:42:13 | | Quit n1s (Quit: Ex-Chat) |
01:42:17 | | Join amayer [0] (~alex@h210.53.213.151.dynamic.ip.windstream.net) |
01:50:20 | *** | Saving seen data "./dancer.seen" |
01:52:42 | | Quit XavierGr (Ping timeout: 260 seconds) |
01:58:57 | | Join XavierGr [0] (XavierGr@rockbox/staff/XavierGr) |
02:00 |
02:53:55 | [Saint] | sakax: I'm guessing "it's still fudged" won't satisfy? |
02:54:01 | [Saint] | ;) |
02:57:09 | [Saint] | Long story short, as I know it: USB in git HEAD is broken; attempts have been made to disable rockbox USB and reboot to the OF on USB insertion but the code that handles this isn't functioning as it was prior to the driver rework that broke USB in the first place. |
03:00 |
03:02:38 | [Saint] | even though it's a bit of a hassle, one can still reboot to the OF and use USB there, or force Emergency Disk Mode and use USB there (either by menu+select; play+select in a traditional installation or from the emCORE menu directly in an emCORE enabled setup). |
03:20:00 | | Quit Syconaut (Ping timeout: 245 seconds) |
03:47:41 | | Quit bootinfdsds (Read error: Connection reset by peer) |
03:48:15 | | Join bootlkjkgf [0] (~Prmhfhfx@92.39.204.151) |
03:50:21 | *** | Saving seen data "./dancer.seen" |
03:58:36 | | Join eckoit [0] (~ryan@50.65.10.24) |
04:00 |
04:06:32 | | Join ser [0] (~ser@host1.tldp.ibiblio.org) |
04:06:36 | | Quit ser (Read error: Connection reset by peer) |
04:09:25 | | Join ser [0] (~ser@host1.tldp.ibiblio.org) |
04:18:47 | | Quit Jack87 (Ping timeout: 260 seconds) |
04:20:22 | | Join pixelma_ [0] (pixelma@rockbox/staff/pixelma) |
04:20:22 | | Join amiconn_ [0] (amiconn@rockbox/developer/amiconn) |
04:20:22 | | Quit pixelma (Disconnected by services) |
04:20:22 | | Quit amiconn (Disconnected by services) |
04:20:24 | | Nick pixelma_ is now known as pixelma (pixelma@rockbox/staff/pixelma) |
04:20:26 | | Nick amiconn_ is now known as amiconn (amiconn@rockbox/developer/amiconn) |
04:38:57 | | Quit TheSphinX^ (Read error: Operation timed out) |
04:41:10 | | Join Jack87 [0] (Jack87@nasadmin/admin/jack87) |
04:46:39 | | Join TheSphinX^ [0] (~briehl@p5B322B6E.dip.t-dialin.net) |
05:00 |
05:25:07 | | Part amayer |
05:26:34 | | Quit TheSeven (Disconnected by services) |
05:26:43 | | Join [7] [0] (~quassel@rockbox/developer/TheSeven) |
05:50:23 | *** | Saving seen data "./dancer.seen" |
06:00 |
06:51:22 | | Quit soap (Ping timeout: 256 seconds) |
06:56:12 | | Join Totalled [0] (~Totalled@c-98-245-9-211.hsd1.co.comcast.net) |
07:00 |
07:04:58 | | Quit eckoit (Quit: eckoit) |
07:05:54 | | Quit pedro_angelo (Read error: Connection reset by peer) |
07:13:48 | | Join eckoit [0] (~ryan@50.65.10.24) |
07:13:57 | | Quit factor (Read error: Connection reset by peer) |
07:21:16 | | Quit sciopath (Read error: Connection reset by peer) |
07:29:35 | | Join mortalis [0] (~mortalis@195.34.194.126.kalibroao.ru) |
07:32:08 | | Join factor [0] (~factor@r74-195-187-142.msk1cmtc01.mskgok.ok.dh.suddenlink.net) |
07:36:23 | | Quit the-kyle (Quit: Leaving.) |
07:38:49 | | Join soap [0] (~soap@cpe-174-102-110-153.woh.res.rr.com) |
07:38:50 | | Quit soap (Changing host) |
07:38:50 | | Join soap [0] (~soap@rockbox/staff/soap) |
07:50:24 | *** | Saving seen data "./dancer.seen" |
07:54:29 | | Quit pixelma (Read error: Connection reset by peer) |
07:54:29 | | Quit amiconn (Write error: Connection reset by peer) |
07:54:48 | | Join amiconn [0] (amiconn@rockbox/developer/amiconn) |
07:54:49 | | Join pixelma [0] (pixelma@rockbox/staff/pixelma) |
08:00 |
08:39:35 | | Join Zagor [0] (~bjst@sestofw01.enea.se) |
08:39:35 | | Quit Zagor (Changing host) |
08:39:35 | | Join Zagor [242] (~bjst@rockbox/developer/Zagor) |
08:39:37 | | Join bertrik [0] (~quassel@rockbox/developer/bertrik) |
08:49:57 | | Quit Rower85 (Read error: Connection reset by peer) |
09:00 |
09:07:54 | | Join LinusN [0] (~linus@giant.haxx.se) |
09:20:19 | | Quit bertrik (Ping timeout: 248 seconds) |
09:24:41 | | Join mgottschlag [0] (~quassel@reactos/tester/phoenix64) |
09:24:54 | | Join webguest319 [0] (~3e8ec2cb@www.haxx.se) |
09:25:56 | webguest319 | Hello |
09:27:02 | webguest319 | I noticed that both the Clip+ and Clip v1 referres to http://download.rockbox. org/bootloader/sandisk-sansa/mkamsboot/ |
09:27:19 | webguest319 | I ran the executable, and it is version 1.5. |
09:28:03 | webguest319 | But I also found http://download.rockbox.org/bootloader/sandisk-sansa/mkamsboot-1.6/ |
09:30:12 | webguest319 | Is 1.6 beta, or is the PDF out of date, or has someone just forgot to replace the 1.5 executables in /mkamsboot with the ones from /mkamsboot-1.6 ? |
09:35:20 | | Join petur [0] (~petur@rockbox/developer/petur) |
09:36:04 | | Join Buschel [0] (~chatzilla@p57905E53.dip.t-dialin.net) |
09:50:28 | *** | Saving seen data "./dancer.seen" |
10:00 |
10:19:17 | | Quit XavierGr (Ping timeout: 260 seconds) |
10:19:54 | | Join Thra11_ [0] (~thrall@31.185.128.199) |
10:35:45 | | Join n1s [0] (~n1s@nl118-168-30.student.uu.se) |
10:35:46 | | Quit n1s (Changing host) |
10:35:46 | | Join n1s [0] (~n1s@rockbox/developer/n1s) |
10:40:20 | | Quit [Saint] (Remote host closed the connection) |
10:41:57 | | Join [Saint] [0] (~saint@rockbox/user/saint) |
10:45:05 | | Quit Prodicus (Ping timeout: 264 seconds) |
10:49:11 | | Join wodz [0] (~wodz@iwl138.internetdsl.tpnet.pl) |
10:50:09 | wodz | mortalis: ping |
10:50:33 | mortalis | wodz: pong |
10:51:23 | wodz | mortalis: I played a bit with the patch. Definitely there is improvement with current init sequence as various glitches go away. |
10:51:51 | wodz | mortalis: Although 'guarding' part is incorrect imo. |
10:52:21 | wodz | All in all it almost work |
10:52:29 | mortalis | irq trigger only 1 time during single lcd_update |
10:52:47 | wodz | have you confirmed this on the target? |
10:53:26 | mortalis | yes, i checked this by comparing lcd_update counts and interrupts count |
10:54:13 | | Quit funman (Quit: Lost terminal) |
10:54:56 | mortalis | anyway, version with irqs doesn't work for me when i start playing mp3, ape or wv |
10:55:17 | | Join funman [0] (~fun@rockbox/developer/funman) |
10:58:12 | wodz | http://pastie.org/4805446 this DOESN'T work. First update is correct (as I can see rockbox logo) but second messes up the screen |
10:58:19 | mortalis | in version with while i discovered that frequent lcd updates during playback cause glitches. IIRC i don't have glitches when i use full lcd_update instead of partial. I'll check this latter |
10:59:21 | wodz | you need to protect partial updates to occure when full screen update is still in progress |
10:59:46 | mortalis | indeed |
11:00 |
11:01:15 | wodz | Reading manual once more it seems like lcdif can generate irq on successful buffer write. Maybe we should explore this route? |
11:02:10 | | Join lebellium [0] (~chatzilla@e178184159.adsl.alicedsl.de) |
11:06:37 | mortalis | wodz: code that you pasted doesn't work, and with semaphores it works? I think this is because while(lcd_updating); isn't safe in multithreaded environment. |
11:08:22 | wodz | with semaphore no lcd_update takes effect. It sits on blocking semaphore and because dma is not activated yet it dedlocks |
11:10:53 | mortalis | if you talking about clear patchset 5 then semaphore initialization incorrect there. Try this semaphore_init(&lcd_updating, 1, 1); |
11:11:56 | wodz | will try later |
11:17:06 | mortalis | i guess my problem with irq version could be solved by protecting partial updates. |
11:18:20 | | Quit mgottschlag (Ping timeout: 244 seconds) |
11:18:44 | wodz | hopefully |
11:23:22 | wodz | mortalis: With this approach semaphore_init(&lcd_updating, 1, 1) it is basically the same as mutex. If mutex version doesn't work for you semaphore should fail as well |
11:46:02 | | Quit bluebrother (Ping timeout: 256 seconds) |
11:46:52 | | Quit fs-bluebot (Ping timeout: 264 seconds) |
11:47:55 | | Join bluebrother [0] (~dom@rockbox/developer/bluebrother) |
11:48:18 | | Join fs-bluebot [0] (~fs-bluebo@g231121134.adsl.alicedsl.de) |
11:50:01 | mortalis | wodz: When i said that mutex doesn't work i didn't mean that "version with mutex doesn't work". I meant that mutex itself doesn't work. |
11:50:12 | mortalis | in other words mutex_lock doesn't lock |
11:50:32 | *** | Saving seen data "./dancer.seen" |
11:52:29 | wodz | what? |
11:53:53 | wodz | that would mean serious bug in kernel |
11:58:01 | mortalis | i know, maybe i just updated rb incorrectly (forget to unmount before ejecting sd card or something) so i had old binary. i'll check it once more later |
12:00 |
12:03:43 | lebellium | hum has anyone noticed a strange RDS behaviour on the Zip (latest build)? |
12:05:44 | lebellium | it starts displaying the right RDS info but after a few seconds it displays the RB virtual keyboard (abcdefghig etc) and strange caracters |
12:08:53 | | Join mgottschlag [0] (~quassel@reactos/tester/phoenix64) |
12:09:20 | wodz | Heh looks like mem corruption. Segfaults have been seen associated with RDS on hosted targets (R0) recently. This could be the same |
12:10:26 | lebellium | hum ok |
12:10:38 | lebellium | so it's a known issue? |
12:11:15 | wodz | not much - you are the first one to report such behavior on native target |
12:12:34 | Buschel | n1s: you've added several performance optimizations to the opus decocer. can you give some numbers on the current performance? your commit messages only state deltas :) |
12:13:39 | n1s | Buschel: the 64kbps test file i've been using is now 77.96% realtime on cf, 88.48% realtime on pp and 220% realtime on amsv1 |
12:14:52 | Buschel | still some way to go ;) |
12:15:51 | n1s | yeah, better iram use gives a nice further speedup on cf but i haven't done it in a clean way yet :) |
12:16:52 | n1s | for arm i guess, more/better asm for some of the hot functions might be needed |
12:20:49 | Buschel | yep. you have added asm for MULT16_32_Q15 only. are the other operations not significantly used? |
12:23:47 | wodz | hmm, sim just crashed with message: queue_post ovf q=082A27A0 |
12:24:13 | wodz | I just pressed mapped button a few times |
12:25:39 | wodz | lebellium: You should highlight this to bertrik and kugel |
12:26:27 | lebellium | okay |
12:26:28 | lebellium | I'll do that |
12:28:16 | kugel | wodz: sometimes the sim cannot keep up with poping input events, then the event queue overflows |
12:28:48 | wodz | kugel: with like 10 consecutive key presses? |
12:29:57 | kugel | normally a single press leads to more input events (since polling happens at tick rate) |
12:30:11 | kugel | i don't know the queue limit |
12:31:31 | wodz | hmm, in regular binary it doesn't crash. Plugins tends to crash though |
12:35:00 | kugel | the keyboard buffer isnt on the buflib buffer but static storage |
12:36:16 | kugel | lebellium: what happens if you open the keyboard after this happens? |
12:36:53 | | Quit scorche (Disconnected by services) |
12:36:57 | | Join scorche` [0] (~scorche@rockbox/administrator/scorche) |
12:37:06 | n1s | Buschel: it's the most common one, and one which gave crap code for both arm and cf |
12:38:11 | n1s | the fft uses complex multiplies which in turn uses the MULT16_32_Q15 but they could probably be made faster by writing them as asm directly (using mac capabilities) |
12:38:36 | n1s | i haven't gotten around to doing that yet |
12:38:52 | Buschel | n1s: clt_mdct_backward looks like it could be further optimized as well... as you just said using multiply-add. |
12:39:06 | Buschel | there seems to be quite some potential :) |
12:39:46 | Buschel | do we have official test files? |
12:40:02 | wodz | On the other topic- I have mostly working bFLT on PP. I found only pitch_detector to hang. Doom complaints on missing wad file correctly. Other 'problematic' plugins randomly tested work. All this is with hacked version of elf2flt and code compiled with -mlong-calls |
12:40:26 | Buschel | brb |
12:40:41 | wodz | Buschel: we have IIRC |
12:41:17 | n1s | Buschel: yes, jmspeex suggested the biggest win for the mdct would probably come from replacing it with a better implementation |
12:41:43 | n1s | Buschel: bertrik made some test files that i'm using but i'm not sure if they got uploaded to the site |
12:42:30 | n1s | Buschel: are you planning to work on something? (just so we don't do the same thing :)) |
12:42:32 | lebellium | kugel: like for example adding a preset name? the keyboard displays properly. |
12:47:42 | wodz | do I read correctly that opus suffers from resampling in our case? |
12:52:15 | lebellium | kugel & wodz: here's a screen of the bug on my device: http://imageshack.us/a/img855/8724/dump120926124155.png and http://imageshack.us/a/img837/2154/dump120926124439.png |
12:52:27 | | Quit Synergist (Ping timeout: 268 seconds) |
13:00 |
13:02:29 | Buschel | n1s: I do not see any opus test files on the rockbxo site. can you upload your test files somewhere? |
13:03:13 | | Quit petur (Quit: *plop*) |
13:03:25 | Buschel | n1s: changing the mdct might be a good idea. but I've heard the opus does not use N^2 sizes? |
13:03:52 | Buschel | n1s: maybe I will spend some time on this. in which area are you working right now? |
13:04:36 | | Join the-kyle [0] (~kyle@cpe-024-211-185-030.nc.res.rr.com) |
13:06:44 | | Join dfkt [0] (dfkt@unaffiliated/dfkt) |
13:13:48 | | Join lebellium_ [0] (~chatzilla@e178184159.adsl.alicedsl.de) |
13:15:19 | kugel | wodz: i think -mlong-calls is an acceptable work around until the bug is resolved (if at all) |
13:15:45 | kugel | only codecs/plugins need that flag right? |
13:16:52 | | Quit lebellium (Ping timeout: 264 seconds) |
13:16:53 | n1s | Buschel: mostly looking at iram and cf asm, also made some changes suggested by jmspeex to the deemphasis loop |
13:16:58 | | Nick lebellium_ is now known as lebellium (~chatzilla@e178184159.adsl.alicedsl.de) |
13:18:53 | n1s | Buschel: bertrik uploaded them here https://docs.google.com/file/d/0ByItZAj1MynOUmJOWVl6Xy1QSG8/edit?pli=1 |
13:19:14 | wodz | kugel: For now only plugins (as I didn't work on converting codecs to bflt). When bflt loader will work with -mlong-calls builded plugins we could dive into ld internals. Looking at ld code it should be fairly easy. |
13:19:51 | wodz | The provide internally reloc info for the symbols introduced by veneer insertion. They just don't bother to insert this info in final elf |
13:19:54 | kugel | huh? without alcohol? |
13:20:21 | wodz | ok, realistically alcohol is still needed :P |
13:20:28 | kugel | :) |
13:21:53 | wodz | The blocker is lack of documentation about ld/as internals. |
13:23:30 | kugel | perhaps it's worth posting that find to the bug report |
13:23:43 | kugel | then hopefully someone can be bothered with a quick fix |
13:24:39 | Buschel | n1s: thanks |
13:27:29 | wodz | kugel: Don't think so. They call elf32_arm_final_link_relocate() for inserted veneers. This function performs final relocation (all addresses are known at this point) using associated internal reloc info. They discard anything intermediate (like reloc info) just because it is final link. |
13:28:13 | wodz | The file of question is bfd/elf32-arm.c in binutils if you are interested. |
13:29:55 | wodz | On the other hand there is gas/write.c where is code used by assembler to output relocations. The solution is probably to still part of it and insert in elf32_arm_final_link_relocate() |
13:30:28 | Buschel | n1s: do you have any kind of profiling information or an idea which parts of the decoder consume the most cpu time? |
13:30:54 | wodz | I am unable however to much arguments needed. |
13:31:57 | wodz | Buschel: http://www.rockbox.org/irc/log-20120922#10:50:39 |
13:37:25 | n1s | Buschel: those are on coldfire before i made any changes but i think the rough areas eating cpu are the same |
13:38:35 | n1s | i guess i should try running a profile on arm too |
13:39:22 | wodz | from your optimizations it is obvious that cf suffers badly from the lack of dcache |
13:39:51 | n1s | yes, the combination of slow ram and no dcache |
13:39:58 | | Join Synergist [0] (~synfn@node1.customhost.org.uk) |
13:39:58 | | Quit Synergist (Changing host) |
13:39:58 | | Join Synergist [0] (~synfn@unaffiliated/synergist) |
13:40:07 | Buschel | this silk-stuff is only used for very low bitrates? |
13:40:18 | wodz | so I would expect profiling on arm differ significantly |
13:41:17 | n1s | Buschel: afaik, yes and those seem to be comfortably realtime everywhere |
13:41:38 | wodz | Buschel: no. There is mixed mode also: https://wiki.xiph.org/OpusFAQ#Why_not_keep_the_SILK_and_CELT_codecs_separate.3F |
13:41:38 | Buschel | so, we better don't care about that :) |
13:44:27 | n1s | i just ran the profiles on 16 and 64 kbps and the 16 seems to be only silk and 64 only celt so perhaps i should run 32kbps too to see how hybrid does (benchmarking, it was slightly faster than 64kbps but not by that much while 16kbps was several times faster) |
13:46:26 | wodz | again, do we resample output from opus decoder? |
13:46:32 | | Join XavierGr [0] (XavierGr@rockbox/staff/XavierGr) |
13:50:33 | *** | Saving seen data "./dancer.seen" |
14:00 |
14:01:48 | | Quit mgottschlag (Ping timeout: 246 seconds) |
14:05:06 | | Quit webguest319 (Quit: CGI:IRC (Ping timeout)) |
14:05:30 | | Join mgottschlag [0] (~quassel@reactos/tester/phoenix64) |
14:08:41 | | Quit wodz (Quit: Leaving) |
14:13:00 | | Quit mgottschlag (Ping timeout: 246 seconds) |
14:13:44 | | Join megal0maniac [0] (~root@dsl-244-148-217.telkomadsl.co.za) |
14:14:20 | megal0maniac | Hi all. I was just wondering, is there a reason that there isn't a bootloader USB mode on the clipplus? Or that there is one on the fuzeplus? |
14:15:09 | megal0maniac | Experience has shown that USB still isn't exactly stable on the clipplus, and on the fuzeplus it is more reliable in bootloader mode. Less (or no) data aborts and the like. |
14:19:29 | Torne | we generally only have bootloader usb on targets where it's required to install (like the gigabeat S) |
14:19:48 | Torne | i have previously pondered trying to enable it on more platforms but never got around to doing anything |
14:19:59 | Torne | it shouldn't actually be more reliable. |
14:20:09 | Torne | it's teh exact same code doing all the USB/storage bits. |
14:20:28 | megal0maniac | But less other stuff running simultaneously. |
14:20:37 | Torne | Very little runs when in usb mode anyway |
14:20:49 | Torne | but yes, there is a difference |
14:21:05 | Torne | the kind of issue there should be pretty easy to fix though (things like, stuff trying to read from files while in usb mode) |
14:21:13 | Torne | (the font cache did this for a long time) :) |
14:21:54 | | Join amayer_ [0] (~alex@mail.weberadvertising.com) |
14:22:24 | Torne | but yes, for reasons of recovering from rockbox being broken i would quite like having bootloader usb on more targets |
14:22:44 | | Join hietanen [0] (hietanen@mustatilhi.cs.tut.fi) |
14:22:52 | megal0maniac | Torne: Also, amsv2 targets seem to need all the help they can get :) |
14:23:04 | | Nick hietanen is now known as herrandy (hietanen@mustatilhi.cs.tut.fi) |
14:23:05 | Torne | usb works fine on my clipv2 :) |
14:23:24 | megal0maniac | On my clipplus, it works 70-80% of the time |
14:24:01 | Torne | right, but the thing is, most of the possible reasons for it to not work reliably are problems in the usb stack, not problems caused by running in the full system |
14:24:22 | Torne | if a given target really *is* more reliable in bootloader, then that's probably something we can track down and fix fairly easily |
14:24:28 | Torne | and then you don't need bootloader usb :) |
14:24:34 | * | the-kyle seems to be having better luck with the clip+ in USB mode. It appears to work a bit more reliably for me. |
14:24:59 | megal0maniac | Sometimes the USB logo will remain when disconnected, and the player needs to be hard reset |
14:25:19 | megal0maniac | Last time it did this, I didn't notice. And it killed the battery dead :) |
14:25:26 | the-kyle | Yes, I did see that yesterday, running from git with some mods of my own. |
14:25:40 | the-kyle | My mods aren't related to USB. |
14:25:47 | megal0maniac | Torne: But I hear you. Thanks |
14:27:02 | Torne | megal0maniac: feel free to try and get it enabled and try it out |
14:27:21 | megal0maniac | Torne: Heh. You overestimate my coding ability :P |
14:27:31 | Torne | i am in fvour of it being enabled on any target that doesn't have either 1) a rom-based disk mode like the ipod or 2) too little space to make the bootloader larger for it |
14:27:55 | Torne | purely so it can be used to recover from accidentally deleting .rockbox or whatever, without having to dualboot the OF |
14:27:57 | the-kyle | Sounds like the Clip+ is the ideal target. |
14:28:12 | megal0maniac | Why is it enabled on the fuzeplus anyway? |
14:28:24 | Torne | megal0maniac: no idea. possibly someone just wanted it during development |
14:28:36 | Torne | the only target i know of where it's required is the Beast, where it's needed to install |
14:28:43 | Torne | because the default firmware doesn't have MSC, only MTP |
14:28:47 | Torne | and thus you can't copy .rockbox on there |
14:29:02 | Torne | (possibly also other gigabeat devices, iunno) |
14:29:33 | megal0maniac | Interestingly, on the fuzeplus, it doesn't notice if you drop firmware.sb on it while in bootloader USB mode. You *have* to be in OF USB mode |
14:29:41 | Torne | "doesn't notice"? |
14:29:54 | Torne | oh, you mean it won't flash it |
14:29:56 | Torne | no, of course not |
14:30:08 | Torne | we don't have any of the code to reflash the device |
14:30:11 | Torne | only the OF does |
14:30:34 | megal0maniac | But you can boot into OF and it still won't flash |
14:30:47 | Torne | it probably only checks for the file after usb unplug |
14:30:51 | Torne | not at boot |
14:31:54 | megal0maniac | I'll try copying it in bootloader mode, then going into OF USB mode and unplugging. I don't recall that working either, but I'll check |
14:32:33 | Torne | i don't think we care |
14:32:42 | Torne | what the OF's weird logic is doesn't really matter :) |
14:33:08 | megal0maniac | Yeah.. I think it's documented anyway. If not, I'll add it |
14:33:32 | Torne | unless the OF's limitations actually cause a problem following our install instructions it's not really important |
14:40:53 | | Join Prodicus [0] (~chatzilla@69.169.144.239.provo.static.broadweavenetworks.net) |
14:43:40 | | Join mgottschlag [0] (~quassel@reactos/tester/phoenix64) |
14:52:13 | Buschel | n1s: I will take a look at comb_filter(). This function takes ~10% of CPU (based on the profiling results) and seems to have some opportunities for optimization |
14:58:12 | Buschel | see you later |
14:58:15 | | Quit Buschel (Quit: ChatZilla 0.9.88.2 [Firefox 15.0.1/20120905151427]) |
15:00 |
15:00:57 | | Quit mgottschlag (Ping timeout: 246 seconds) |
15:03:50 | | Join mgottschlag [0] (~quassel@reactos/tester/phoenix64) |
15:05:53 | | Join wodz [0] (~wodz@89-76-32-53.dynamic.chello.pl) |
15:06:44 | wodz | mortalis: both mutex version and semaphore version with your fix produce glitches. |
15:07:15 | wodz | well semaphore version hangs on second lcd_update |
15:11:35 | mortalis | for me it hangs only on starting playback (semaphore version with my fix). Same thing happens with semaphore version with your fix. |
15:13:55 | mortalis | btw, what would happen if transfer complete when irq are disabled? Interrupt just skipped or it will trigger after irqs enabled? |
15:14:13 | wodz | dunno |
15:22:38 | | Join test [0] (~57ee5441@www.haxx.se) |
15:24:06 | | Quit test (Client Quit) |
15:25:12 | mortalis | wodz: what if without partial updates? |
15:26:11 | wodz | mortalis: you mean with lcd_update() as partial updates? |
15:26:18 | mortalis | yes |
15:27:04 | | Quit factor (Ping timeout: 264 seconds) |
15:27:50 | wodz | It does second lcd_update() with a glitch and hangs (it sits on rockbox logo which is displayed twice) |
15:28:18 | | Join pystar89 [0] (~pystar89@ip-5-146-40-148.unitymediagroup.de) |
15:29:40 | n1s | wodz: yes, we resample. it always outputs 48kHz |
15:30:30 | wodz | n1s: So I guess we mitigate any quality advantage of opus with our current resampler :-) |
15:33:57 | n1s | probably :) |
15:35:33 | | Join kevku [0] (x@indeed.tastes.like.everything.mm.am) |
15:50:35 | *** | Saving seen data "./dancer.seen" |
15:52:58 | | Join japc [0] (~japc@194.65.5.235) |
16:00 |
16:02:39 | | Quit japc (Quit: Ex-Chat) |
16:08:17 | | Quit mortalis (Quit: Leaving) |
16:31:15 | | Quit XavierGr (Ping timeout: 240 seconds) |
16:33:00 | | Nick megal0maniac is now known as megal0maniac_afk (~root@dsl-244-148-217.telkomadsl.co.za) |
16:39:45 | | Quit swiftkick (Read error: Connection reset by peer) |
16:45:52 | | Join factor [0] (~factor@r74-195-187-142.msk1cmtc01.mskgok.ok.dh.suddenlink.net) |
16:52:03 | | Join Rower85 [0] (husvagn@v-413-alfarv-90.bitnet.nu) |
16:58:53 | | Quit Zagor (Quit: Clint excited) |
17:00 |
17:04:51 | | Nick megal0maniac_afk is now known as megal0maniac (~root@dsl-244-148-217.telkomadsl.co.za) |
17:13:04 | | Quit thegeek_ (Read error: No route to host) |
17:13:30 | | Join thegeek [0] (~thegeek@171.17.9.46.customer.cdi.no) |
17:16:20 | | Nick scorche` is now known as scorche (~scorche@rockbox/administrator/scorche) |
17:33:43 | | Join y4n [0] (~y4n@unaffiliated/y4ndexx) |
17:43:22 | | Join Scr0mple [0] (~Simon@161.43.73.67) |
17:45:47 | | Join benedikt93 [0] (~benedikt9@unaffiliated/benedikt93) |
17:46:52 | | Quit Scromple (Ping timeout: 244 seconds) |
17:50:39 | *** | Saving seen data "./dancer.seen" |
18:00 |
18:25:11 | | Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de) |
18:32:08 | | Join Wardo [0] (~Mirandaha@176-120-190-109.dsl.ovh.fr) |
18:37:07 | | Join pedro_angelo [0] (~pedro_ang@201-29-245-101.user.veloxzone.com.br) |
18:40:42 | | Join bertrik [0] (~quassel@rockbox/developer/bertrik) |
18:47:02 | | Join mortalis [0] (~4d6c62b1@www.haxx.se) |
18:53:04 | | Join dfkt_ [0] (dfkt@unaffiliated/dfkt) |
18:54:11 | | Quit dfkt (Ping timeout: 248 seconds) |
18:56:04 | | Quit amayer_ (Quit: going ~/) |
19:00 |
19:04:17 | | Part LinusN |
19:04:21 | | Quit factor (Read error: Connection reset by peer) |
19:06:44 | | Join factor [0] (~factor@r74-195-187-142.msk1cmtc01.mskgok.ok.dh.suddenlink.net) |
19:13:18 | | Quit mgottschlag (Ping timeout: 246 seconds) |
19:15:50 | mortalis | mutexes doesn't work |
19:15:56 | mortalis | at least on rk27xx |
19:16:23 | mortalis | code after http://pastie.org/4810120 executed |
19:17:50 | | Quit dfkt_ (Quit: -= SysReset 2.55=- Sic gorgiamus allos subjectatos nunc.) |
19:20:33 | bertrik | mortalis: I think that's exactly the difference between a mutex and a 1-token semaphore |
19:21:15 | bertrik | the thread holding the mutex does not block on mutex_lock |
19:23:06 | | Join dfkt [0] (dfkt@unaffiliated/dfkt) |
19:25:06 | mortalis | so second mutex_lock will block only if it called by another thread, rigth? |
19:30:31 | bertrik | the holding thread can call mutex_lock as many times as it likes, any other thread will block on it, the mutex will be available again if mutex_unlock is called exactly as many times as mutex_lock before it |
19:34:09 | | Join LinusN [0] (~linus@giant.haxx.se) |
19:36:59 | | Part LinusN |
19:42:00 | | Nick kugel is now known as kugelp (~kugel@rockbox/developer/kugel) |
19:42:33 | kugelp | mutexes are recursive indeed |
19:47:32 | | Join amayer_ [0] (~alex@mail.weberadvertising.com) |
19:50:42 | *** | Saving seen data "./dancer.seen" |
19:57:18 | | Nick LittleCreature is now known as Slartibartfast (~fearofmus@unaffiliated/fearofmusic) |
20:00 |
20:00:07 | | Join ender` [0] (krneki@foo.eternallybored.org) |
20:01:55 | | Quit factor (Ping timeout: 248 seconds) |
20:02:28 | | Nick Slartibartfast is now known as LittleCreature (~fearofmus@unaffiliated/fearofmusic) |
20:04:06 | | Quit benedikt93 (Quit: Bye ;)) |
20:04:47 | | Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) |
20:19:34 | | Join pretty_function [0] (~sigBART@123.252.215.33) |
20:22:54 | | Quit einhirn (Read error: Connection reset by peer) |
20:28:12 | | Join Viper^ [0] (viper@c-60fd72d5.162-1-64736c10.cust.bredbandsbolaget.se) |
20:31:04 | | Join Syconaut [0] (viper@c-60fd72d5.162-1-64736c10.cust.bredbandsbolaget.se) |
20:36:34 | wodz | bertrik: have you seen reports about recent problems with rds? |
20:36:45 | bootlkjkgf | Anything could happen in the next 90 minutes [bookmark] http://www.kickstarter.com/projects/Musopen/open-source-bug-tracking |
20:37:14 | bertrik | vaguely |
20:38:27 | | Nick kugelp is now known as kugel (~kugel@rockbox/developer/kugel) |
20:40:48 | | Nick megal0maniac is now known as megal0maniac_afk (~root@dsl-244-148-217.telkomadsl.co.za) |
20:43:33 | | Nick megal0maniac_afk is now known as megal0maniac (~root@dsl-244-148-217.telkomadsl.co.za) |
20:50:58 | | Join lorenzo92 [0] (~chatzilla@95.232.111.82) |
20:52:02 | lorenzo92 | kugel: this is the trace, rockbox with debug symbols, bt command: http://pastebin.com/NZ72cpRD |
20:59:56 | wodz | not very useful |
21:00 |
21:01:58 | | Nick megal0maniac is now known as megal0maniac_afk (~root@dsl-244-148-217.telkomadsl.co.za) |
21:02:16 | | Part megal0maniac_afk |
21:08:11 | funman | d |
21:08:21 | lorenzo92 | wodz: some ideas to make it useful? need to say that I get a warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available. |
21:11:04 | | Quit ser (Remote host closed the connection) |
21:12:30 | | Quit shai (Ping timeout: 244 seconds) |
21:12:40 | mortalis | wodz: I updated g306. It's works for without any issues, also i removed some unnecessary things. |
21:12:41 | fs-bluebot | Gerrit review #306 at http://gerrit.rockbox.org/r/306 : rk27xx lcd code rework by Andrew Ryabinin (changes/06/306/6) |
21:13:31 | | Join shai [0] (~Shai@l192-117-110-233.cable.actcom.net.il) |
21:13:38 | mortalis | *for me |
21:13:59 | lorenzo92 | wodz: trying to do coredump and the analysis.. |
21:19:03 | wodz | mortalis: So no locking at all, right? You simply poll for dma finish bit |
21:20:08 | mortalis | yes |
21:20:57 | lorenzo92 | kugel: http://pastebin.com/uPTf0Cip ; to show the segmentation fault... |
21:22:33 | wodz | mortalis: Will test tomorrow morning |
21:23:27 | | Quit wodz (Quit: Leaving) |
21:24:01 | | Quit y4n (Quit: only amiga makes it possible) |
21:28:58 | | Join ser [0] (~ser@2610:28:3090:3001:a:a:a:dead) |
21:32:15 | lorenzo92 | kugel: 0x00056f08 is lcd_alpha_bitmap_part_mix, while 0x00056e90 is something in the function around line 895 |
21:34:35 | | Quit mortalis (Quit: CGI:IRC (Ping timeout)) |
21:35:37 | lorenzo92 | kugel: :o :o doesn't crash if I keep the player running in the main menu, I'll try now with another theme (cabbie, previously using lebellium's theme!) |
21:36:08 | lorenzo92 | kugel: oh! strange characters...no crash but strange carachters at a times... |
21:36:25 | lorenzo92 | i'll get a capture |
21:36:28 | lorenzo92 | *picture |
21:38:09 | lorenzo92 | lebellium: yep, exactly the same issue as for the sansa or so... |
21:39:20 | | Join mgottschlag [0] (~quassel@reactos/tester/phoenix64) |
21:39:29 | lorenzo92 | lebellium: rds on R0 crashes with segmentation fault with your theme |
21:39:38 | | Join Buschel [0] (~chatzilla@p57905E53.dip.t-dialin.net) |
21:48:27 | lorenzo92 | kugel, lebellium: definitely. Problems with lebellium's theme! without it, I don't notice anything strange. Now I'll try with the interrupt way of capture signal packet arrived... |
21:50:34 | lebellium | It's always my theme's fault on any target. Damn it :( |
21:50:46 | *** | Saving seen data "./dancer.seen" |
21:51:30 | | Quit shamus (Read error: Connection reset by peer) |
21:51:59 | lorenzo92 | lebellium: too much professonal :p ;) |
21:53:56 | | Join shamus [0] (~shamus@ip-206-192-195-49.marylandheights.ip.cablemo.net) |
21:56:28 | lorenzo92 | kugel: indeed, with cabbie works perfectly also the interrupt way, no problems at all. Hence, semaphores are working also on R0 apparently |
21:57:15 | | Quit ender` (Quit: And I don't offend religious people, they offend themselves. -- Markus Persson (notch)) |
22:00 |
22:02:34 | | Quit pedro_angelo (Remote host closed the connection) |
22:04:05 | | Join ender` [0] (krneki@foo.eternallybored.org) |
22:06:21 | | Join Horscht [0] (~Horscht@p54946283.dip.t-dialin.net) |
22:06:24 | | Quit Horscht (Changing host) |
22:06:24 | | Join Horscht [0] (~Horscht@xbmc/user/horscht) |
22:11:34 | lebellium | my theme seems to cause various issues on many targets including Clip Zip, Fuze, Fuze+, R0 etc... anyone willing to investigate a bit further?. The only difference I see with the other themes is that the code is generally more complicated and the BMP resources may be bigger. But it should work :( |
22:13:40 | amayer_ | lebellium: what is your theme and target(link?) |
22:13:42 | amayer_ | i dont have time right now but i might later tonight |
22:15:54 | lebellium | Just type "lebellium Samsung-like" as theme name on http://themes.rockbox.org/ and you'll find 6 themes. They all cause various issues, typically USB connection (Clip Zip and also Fuze+ I guess), and now RDS on Clip Zip and R0? |
22:16:49 | lebellium | As if my code always reached the skin engine or rockbox limitations? :( |
22:17:25 | amayer_ | what is rds? |
22:18:02 | lebellium | Radio Data System |
22:18:15 | amayer_ | got it. thats what google said but i wasnt sure |
22:18:16 | lebellium | supported by Clip Zip/ Fuze+ and R0 |
22:19:43 | amayer_ | so it only breaks on the RDS or breaks ramdomly? |
22:21:38 | lebellium | Lorenzo just said it breaks on the RDS with the R0. I can't try myself as he's currently working on the RDS patch, therefore I don't have RDS on my R0. |
22:21:50 | lebellium | yet* |
22:22:42 | lebellium | and the USB connection still doesn't work on the Clip Zip with my theme. The situation has not changed over the year :( |
22:23:38 | lorenzo92 | lebellium: USB connection????!!! |
22:23:50 | lorenzo92 | lebellium: I got some crashes with usb too -.- |
22:24:48 | lebellium | blasted theme, it's so frustrating... |
22:25:17 | lorenzo92 | I don't know for USB, will test out. Don't think that's about you're theme |
22:25:18 | lorenzo92 | ;) |
22:27:30 | amayer_ | lorenzo92: are sure you have all the correct fonts loaded(not all of them are included in the font folder) |
22:28:58 | | Quit pretty_function (Remote host closed the connection) |
22:29:06 | lebellium | without the correct fonts, Rockbox immediately crash so that's not the cause ;) |
22:30:01 | amayer_ | so your theme is being displayed in RDS then it crashes? |
22:31:20 | lebellium | that's what Lorenzo noticed indeed |
22:31:30 | lorenzo92 | not correctly, it crashes after a little time, say 1 minute or so |
22:31:51 | amayer_ | hmm... does the theme engine have a specific amount of memory it can use? |
22:32:14 | lorenzo92 | amayer_: I don't know anything about that, but I'm quite sure the segfault happens in lcd_alpha_bitmap_part_mix |
22:32:17 | | Quit eckoit (Quit: eckoit) |
22:32:21 | lorenzo92 | (gdb) |
22:33:14 | amayer_ | lebellium: are all your themes exactly the same? |
22:33:16 | amayer_ | i noticed they have v1.xx |
22:33:18 | amayer_ | what is the resolution of the device in question? |
22:33:48 | lebellium | I find your question quite strange :) |
22:33:55 | amayer_ | seperate topic: |
22:33:57 | amayer_ | should RDS be in http://www.rockbox.org/wiki/ProjectGlossary ? |
22:34:11 | amayer_ | lebellium: how so? |
22:34:28 | kugel | lorenzo92: the bt suggests debug symbols aren't proper |
22:34:35 | lebellium | type "lebellium samsung-like" as theme name on the theme page and then it will display the 6 themes with the indication "designed for LCD size: " |
22:34:39 | kugel | properly compiled in |
22:35:32 | | Join Prodicus_ [0] (~chatzilla@69.169.144.239.provo.static.broadweavenetworks.net) |
22:35:36 | lorenzo92 | kugel: okay, anyways my implementation works ... the bug is somewhere else :) so final question: it's better the implementation with interrupt or the one with register polling? I guess the first, right? |
22:35:41 | kugel | there's probably a bug in the radio/rds related skin code. I don't think it received a lot of testing |
22:35:44 | | Quit Prodicus (Ping timeout: 252 seconds) |
22:35:57 | | Nick Prodicus_ is now known as Prodicus (~chatzilla@69.169.144.239.provo.static.broadweavenetworks.net) |
22:36:10 | gevaerts | amayer_: RDS isn't a rockbox term. It's quite commonly used... |
22:36:20 | kugel | normally yes, but I think its not safe at the moment |
22:36:47 | gevaerts | Feel free to add it if you like though |
22:37:09 | kugel | lorenzo92: ^ |
22:37:12 | amayer_ | lebellium: i did that. |
22:37:14 | amayer_ | but all your themes say they are different versions.(v1.00, 1.50, 1.30,...) |
22:37:16 | amayer_ | im wondering if they are all exactly the same, or if they each different features. |
22:37:18 | amayer_ | the theme page doesnt tell me what the target is. so thats why i asked for the resolution of the device that is actin up |
22:37:26 | amayer_ | s/actin/acting/ |
22:39:50 | | Join factor [0] (~factor@r74-195-187-142.msk1cmtc01.mskgok.ok.dh.suddenlink.net) |
22:40:19 | kugel | lorenzo92: do you know in which context the callback is called by the kernel? I guess its like a signal handler, I.e. the process current stack is used? |
22:41:14 | lebellium | they are not exactly the same of course but they share many features, the code is more or less similar on each target. The different version number is just because they have not been made at the same time. The new clip+ theme I made yesterday includes features in v1.00 that the Clip Zip had to wait for v1.30 to get as the 1st version was made last year ;) |
22:42:09 | lebellium | the Clip Zip has a 96*96 display and the R0 has a 240*320 display |
22:42:25 | lorenzo92 | kugel: well safe or not, it hasn't crashed for more than 10 mins. anyways that doesn't tell us anything :) the callback is the address of the function in rockbox |
22:42:50 | lorenzo92 | at first I used also a workqueue of linux kernel, don't know precisely how does it work |
22:42:59 | lorenzo92 | now I tried to remove it and works anyways |
22:43:16 | lorenzo92 | the callback releases the semaphore only! |
22:43:16 | kugel | did you modify the kernel module? |
22:43:19 | lorenzo92 | yep |
22:43:36 | lorenzo92 | kugel: do you want to see the code? |
22:43:56 | kugel | with polling that wouldn't be necessary right? |
22:44:08 | kugel | sure |
22:44:11 | lorenzo92 | kugel: exactly! |
22:44:33 | lorenzo92 | maybe it's better, need to see from the cpu usage point of view, but it's surely around 2% more |
22:44:37 | lorenzo92 | nothing important then |
22:44:43 | | Join eckoit [0] (~ryan@96.53.108.182) |
22:45:16 | kugel | you wouldnt need to poll every tick would you? |
22:45:36 | * | kugel doesnt know anything about RDS, e.g. how often new data comes in |
22:45:39 | lorenzo92 | kugel: nono! it's just every sleep(1) for the moment |
22:45:47 | lorenzo92 | I'll explain |
22:46:09 | lorenzo92 | si4709 radio module gpio pin goes to low for at least 5 ms when data is ready to be read |
22:46:26 | lorenzo92 | either using the interrupt or using register poll I guess |
22:46:41 | lorenzo92 | need to see the doc for that |
22:47:58 | lorenzo92 | how many seconds are sleep(1), you think? 1/100? |
22:48:27 | | Join XavierGr [0] (XavierGr@rockbox/staff/XavierGr) |
22:48:55 | kugel | the parameter is in ticks, so yes 1/100 |
22:50:19 | kugel | can you post the new kernel module code somehwere nevertheless? I want to see how the callback mechanism works |
22:50:20 | n1s | technically it's at least 1 |
22:50:28 | n1s | well, 1 to almost 2 |
22:50:36 | lorenzo92 | n1s: thanks :) |
22:50:45 | lorenzo92 | kugel: yes, of course!! |
22:52:06 | lorenzo92 | kugel: perhaps it's a little naive, but works ^^ http://pastie.org/4811270 |
22:52:22 | lorenzo92 | kugel: notice that I've just removed workqueue, commented! |
22:53:05 | kugel | lorenzo92: uh oh, I'm surprised this works |
22:53:21 | kugel | I dont think it would on x86 or newer ARM architectures |
22:53:34 | lorenzo92 | kugel: ah! xD nice to know hehe |
22:53:52 | lorenzo92 | kugel: is the function calling evil, right? |
22:54:12 | kugel | normally you cannot (and shouldn't) use user-space pointers directly |
22:54:56 | lorenzo92 | I've tought about that, but then another possibility is? |
22:55:27 | | Join lebellium_ [0] (~chatzilla@g231191239.adsl.alicedsl.de) |
22:56:45 | kugel | it's evil for 2 reasons; a) the callback is executed in kernel space (i.e. it could possibly access kernel internals and mess the entire kernel up) and 2) kernel-space and user-space pointers are incompatible (user-space pointers are usually virtual addresses, other measures might be applied too) and cannot be derefenced directly |
22:57:11 | lorenzo92 | kugel: clear, indeed. |
22:57:23 | | Quit lebellium (Ping timeout: 244 seconds) |
22:57:37 | | Nick lebellium_ is now known as lebellium (~chatzilla@g231191239.adsl.alicedsl.de) |
22:57:41 | lorenzo92 | kugel: I copied the way structs are sent through ioctls |
22:57:48 | kugel | I don't know if there's any possibility to execute userspace code other than through signals |
22:58:01 | lorenzo92 | oh well right copy_from_user |
22:58:12 | lorenzo92 | perhaps this does something? |
22:59:13 | | Quit liar (Ping timeout: 256 seconds) |
22:59:38 | kugel | it at the very least converts the user-space pointer to kernel space; but the arg parameter, not the data arg points to |
23:00 |
23:00:01 | kugel | you pass the function address as data so I don't expect it gets fixed |
23:00:38 | | Quit kevku (Ping timeout: 260 seconds) |
23:00:57 | | Join kevku [0] (x@indeed.tastes.like.everything.mm.am) |
23:01:03 | lorenzo92 | okay. perhaps there are other tecniques like event devices (or how they're called), more suitable. I understood that I need to cleanup the register polling way :D |
23:02:27 | lorenzo92 | lebellium: one thing I'm missing: is your device displaying bad data also with cabbie/other themes? |
23:03:32 | kugel | i think the simplest for now is keeping the polling, perhaps at a lower rate |
23:03:53 | lorenzo92 | yes, I think sleep(10) or greater is enough! |
23:03:55 | | Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) |
23:04:02 | lorenzo92 | but |
23:04:26 | lorenzo92 | the way I'm getting the register isn't nice...can I do something on the si470x header file? |
23:04:38 | lorenzo92 | perhaps externalizing register getting/setting |
23:06:42 | lorenzo92 | i.e. writing prototype in the header ^^ |
23:08:37 | lorenzo92 | I would also disable the interrupt! |
23:09:40 | | Quit amayer_ (Ping timeout: 264 seconds) |
23:09:42 | | Quit liar (Remote host closed the connection) |
23:15:26 | lebellium | lorenzo92: on the clip zip the dfkt theme also displays bad RDS data. I did not try other themes |
23:15:56 | lorenzo92 | lebellium: okay, good to know, perhaps try also with cabbie when possible... |
23:16:30 | lorenzo92 | kugel: do you think creating a new thread and destroying it when enabling/disabling radio is good or not? |
23:17:03 | lebellium | I guess there is no cabbiev2 FMS on the clip zip |
23:17:12 | kugel | you can set it to sleep forever when radio is disabled |
23:18:03 | kugel | lorenzo92: what do you mean with the way you get the registers? |
23:18:31 | lorenzo92 | ah right you did not see the code... |
23:21:03 | lorenzo92 | kugel: to explain. si4700_read_reg is available within si4700.c code, the prototype isn't in the header file si4700.h. I put it in the header file to access the function from my target code! |
23:23:09 | kugel | you call si4700_rds_read_raw() |
23:23:38 | lorenzo92 | kugel: ah no, nevermind...found out ;) |
23:27:14 | kugel | ??? |
23:28:13 | lorenzo92 | kugel: nothing nothing, don't care :) |
23:35:43 | kugel | well, alright :) |
23:37:52 | | Quit dfkt (Quit: -= SysReset 2.55=- Sic gorgiamus allos subjectatos nunc.) |
23:41:53 | lorenzo92 | kugel: btw, do you still have the R0 device? :) |
23:44:05 | kugel | sure |
23:44:12 | lorenzo92 | kugel: cpu usage okay, seems working fine. Good for R0 ;) |
23:45:38 | lorenzo92 | kugel: apart screen corruption, happens sometimes |
23:50:47 | *** | Saving seen data "./dancer.seen" |
23:50:48 | kugel | lorenzo92: i hope to see a patch on gerrit soon :) |
23:54:58 | kugel | lorenzo92: which skin tag is causing the trouble? |
23:55:21 | kugel | lebellium: ? |
23:55:26 | lebellium | we just did a test |
23:55:47 | lebellium | it seems that %tz (RDS text) is causing issues |
23:56:07 | lebellium | Need further testing but %ty (RDS name) should be OK |
23:57:39 | kugel | strange. the %tz code directly calls a low level function which returns the string from a static array |
23:58:27 | lorenzo92 | isn't that perhaps a string isn't \x00 ending? |