| 00:00:05 | speachy | it's all about the LCD controller and video-related stuff |
| 00:00:28 | speachy | we can't use the LCD controller on this thing, alas. :/ |
| 00:00:44 | speachy | (I mean with the SSD1306) |
| 00:01:42 | _Bilgus_ | another one whats up with people not using the onboard stuff |
| 00:02:20 | speachy | well, it's not a standard LCD interface. though why they didn't attach it via spi or i2c is beyond me |
| 00:02:51 | speachy | we could at least had a HW peripheral DMAing the data out instead having to bitbang everything. |
| 00:07:57 | speachy | g#2713 and g#2714 |
| 00:08:01 | fs-bluebot | Gerrit review #2713 at http://gerrit.rockbox.org/r/2713 : jz4760: Prioritize Audio DMA above all others by Solomon Peachy |
| 00:08:01 | fs-bluebot | Gerrit review #2714 at http://gerrit.rockbox.org/r/2714 : xduoox3: Use correct "ms_clk" divider for SADC and be smarter with plling by Solomon Peachy |
| 00:13:27 | _Bilgus_ | i'll give er a rip |
| 00:13:50 | speachy | hand on for the sadc patch, gotta rev it due to checking the wrong thing |
| 00:15:23 | _Bilgus_ | k |
| 00:17:54 | | Join Oksana_ [0] (~Wikiwide@Maemo/community/ex-council/Wikiwide) |
| 00:20:47 | speachy | great! documentation is wrong. |
| 00:21:19 | speachy | ADCFG_VBAT_SEL doesn't exist in the programming manual. |
| 00:21:56 | speachy | ok, updated patch pushed. |
| 00:24:17 | _Bilgus_ | looping if there are other IRqs good catch |
| 00:25:31 | _Bilgus_ | still compiling OH how I miss my home PC |
| 00:25:58 | speachy | not sure if that's strictly required but due to how the HW IRQs are shared and then mapped out into that "irq_num" multiple "irq" from the same physical IRQ might get lost. |
| 00:27:16 | _Bilgus_ | I feel like thats pretty typical though |
| 00:27:29 | speachy | I need to try the SD command interrupt operation again. |
| 00:28:19 | speachy | huh, that's no longer hanging. still doesn't work, but now it looks like IRQs are making it through. |
| 00:28:47 | speachy | I wonder how hard it would be to wire up a JTAG probe to this thing |
| 00:30:28 | _Bilgus_ | cube crashed it HARD and fast |
| 00:31:54 | speachy | excellent! MSC interrupts are definitely making it through, which proves my code is broken instead of the IRQ delivery stuff. |
| 00:32:29 | speachy | yay for panicf() :) |
| 00:32:39 | _Bilgus_ | LCd results fps: full 1921fps gslib 4664.5 |
| 00:32:59 | speachy | that's.. kinda insane |
| 00:33:20 | _Bilgus_ | that thing is just going so much fastyer than the screen can even display |
| 00:34:00 | _Bilgus_ | maybe we can yield out of the update function |
| 00:35:47 | speachy | in the lcd_grey_data() helper you mean? or in the core? |
| 00:36:08 | _Bilgus_ | grey helper |
| 00:37:07 | speachy | amy objections to me pushing those two patches? (I just fixed the tabs in the irq patch) |
| 00:37:59 | _Bilgus_ | IDK cube crashes now let me try slowing down grey lib and see if it helps |
| 00:38:21 | *** | Saving seen data "./dancer.seen" |
| 00:38:44 | _Bilgus_ | I also can't seem to exit from the boost test plugin |
| 00:40:35 | _Bilgus_ | yeah it can't pick up the press release |
| 00:41:03 | speachy | current git master has no boost |
| 00:41:17 | _Bilgus_ | doesn't matter to the plugin |
| 00:42:02 | speachy | doesn't the cpu_boost plugin API function require HAVE_ADJUSTABLE_CPU_FREQ to even be present? |
| 00:42:50 | _Bilgus_ | for the boost part it should still allow you to exit |
| 00:43:18 | speachy | I mean, the test_boost plugin doesn't even get compiled without adjustable_cpu_freq |
| 00:45:07 | _Bilgus_ | oh maybe its a bad plugin then |
| 00:45:42 | _Bilgus_ | ok test mem does it too just not so bad that I can't quit |
| 00:46:42 | speachy | it took a few to break out but I was able to quit. test_mem also stalled audio playback when running. |
| 00:47:33 | _Bilgus_ | yeah all the intensive ones do |
| 00:48:09 | speachy | given that keypresses are handled by the main tick thread, it's not surprising it stalls |
| 00:48:38 | speachy | ...the limit of a cooperative scheduler, eh? |
| 00:48:41 | _Bilgus_ | lua script rliimage the twist stops playback too |
| 00:48:52 | _Bilgus_ | the clip+ handles it flawless |
| 00:49:28 | speachy | the clip+ also has sane IRQ handling |
| 00:49:48 | _Bilgus_ | touche |
| 00:51:26 | speachy | I think the clip+ also directly polls GPIOs for keypresses. not irq driven either. |
| 00:58:05 | _Bilgus_ | that sounds about right |
| 00:58:26 | speachy | it seems the common failure here is very high CPU loading. |
| 00:58:43 | _Bilgus_ | I'm not overly worried about the key stuff yet I think I can probably get it a bit better |
| 00:59:31 | _Bilgus_ | unfortunately that probably points to something being wrong |
| 00:59:47 | _Bilgus_ | but damned if grey lib needs to run at 4khz |
| 00:59:47 | speachy | "something" |
| 01:00 |
| 01:00:09 | _Bilgus_ | yeah and that sucks *something* |
| 01:01:27 | speachy | a failure that only happens under heavy load could also be something more mundane like the power supply |
| 01:02:47 | speachy | johnb's player acting up where ours did not, on the same firmware and file, is quite suspicious. Though there's the SD card variable. |
| 01:03:18 | speachy | also there's a bug report in teh tracker about HP pause/resume not working but .. itworksfineforme(tm). |
| 01:05:19 | _Bilgus_ | nope cube is still crashing |
| 01:05:28 | _Bilgus_ | lets try even slower |
| 01:06:01 | speachy | are you using the cache changes too? |
| 01:08:16 | _Bilgus_ | head + 2713 2714 |
| 01:10:52 | _Bilgus_ | well slowing it way down helped it no crashes but it needs to be faster |
| 01:14:01 | | Quit massiveH (Quit: Leaving) |
| 01:14:47 | _Bilgus_ | also oddly the grey screen starts out with random data + lines |
| 01:18:28 | _Bilgus_ | at 5HZ which is about as slow as I can make it and have it look OK |
| 01:18:43 | _Bilgus_ | fire runs for about 1 minute before it crashes |
| 01:19:24 | _Bilgus_ | fps tells me 1% cpu load so its not a loading issue I don't think |
| 01:19:50 | _Bilgus_ | lets try setting grey to display the regular image |
| 01:23:51 | _Bilgus_ | still crashes |
| 01:25:08 | _Bilgus_ | so maybe something is mis configured we keep toggling the CS pin maybe its mapped to the wrong gpio |
| 01:30:34 | speachy | chagned the IRQ patch again, priorities are now Audio DMA and TCU0 (for our systick) |
| 01:31:46 | speachy | but at this point I'd love to know if it's a crash, hang, deadlock, or what... |
| 01:32:38 | speachy | wait. |
| 01:32:43 | _Bilgus_ | ok |
| 01:33:02 | speachy | this might be self-inflicted |
| 01:34:22 | speachy | comment out USE_HW_UDELAY in system-jz4760.c |
| 01:40:54 | _Bilgus_ | behaves much better |
| 01:40:59 | _Bilgus_ | no cube crash |
| 01:41:00 | speachy | yeah |
| 01:41:31 | speachy | systick and my udelay code used the same hw timer |
| 01:41:39 | _Bilgus_ | lets see if fire crashes after a bit |
| 01:41:46 | _Bilgus_ | but its wayyyyyy better |
| 01:42:05 | _Bilgus_ | still stutters a bit |
| 01:45:28 | fs-bluebot | Build Server message: New build round started. Revision b01e929, 280 builds, 8 clients. |
| 01:46:44 | speachy | I'm packing it in. way past pumpkin time. |
| 01:47:20 | _Bilgus_ | ok thanks and have a good night |
| 01:47:30 | speachy | I'll fix udelay to use a different timer in the morning. bleh. |
| 01:47:39 | _Bilgus_ | are you pushing the 2713/14? |
| 01:47:47 | speachy | yeah, they'll land after this one. |
| 01:47:53 | speachy | s/land/build/ |
| 01:48:39 | _Bilgus_ | ok I'm going to slow down greylib a bit and get the cpu% down, some dma things before I pack it in |
| 01:53:46 | speachy | I think the reason for the audio glitches was that we'd hit a udelay() somewhere aroudn the time we trip over an os tick, and we'd never meet the delay criteria. |
| 01:53:56 | speachy | s/glitch/hang |
| 01:54:09 | speachy | so we'd block forever. |
| 02:00 |
| 02:04:12 | fs-bluebot | Build Server message: Build round completed after 1124 seconds. |
| 02:04:13 | fs-bluebot | Build Server message: Revision b01e929 result: All green |
| 02:04:14 | fs-bluebot | Build Server message: New build round started. Revision cc5b043, 280 builds, 7 clients. |
| 02:14:54 | | Join Rower- [0] (~Rower@78-73-72-39-no2340.tbcn.telia.com) |
| 02:16:35 | | Quit Rower (Ping timeout: 240 seconds) |
| 02:19:55 | fs-bluebot | Build Server message: Build round completed after 943 seconds. |
| 02:19:56 | fs-bluebot | Build Server message: Revision cc5b043 result: All green |
| 02:19:57 | fs-bluebot | Build Server message: New build round started. Revision e06ab68, 280 builds, 7 clients. |
| 02:37:00 | fs-bluebot | Build Server message: Build round completed after 1023 seconds. |
| 02:37:01 | fs-bluebot | Build Server message: Revision e06ab68 result: All green |
| 02:38:22 | *** | Saving seen data "./dancer.seen" |
| 03:00 |
| 03:23:27 | | Quit ufdm (Remote host closed the connection) |
| 04:00 |
| 04:15:04 | | Join Huntereb [0] (~Huntereb@174.226.2.53) |
| 04:20:01 | | Quit _Bilgus_ (Remote host closed the connection) |
| 04:28:02 | | Join johnb4 [0] (~johnb2@91.58.243.148) |
| 04:38:23 | *** | Saving seen data "./dancer.seen" |
| 04:50:55 | | Quit johnb4 (Ping timeout: 240 seconds) |
| 04:54:24 | | Quit prof_wolfff (Ping timeout: 240 seconds) |
| 05:00 |
| 05:41:56 | | Quit Huntereb (Ping timeout: 240 seconds) |
| 05:44:58 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
| 05:45:53 | pamaury | speachy: did you manage to download a PDF from this chinese website ? |
| 05:52:07 | | Quit pamaury (Quit: this->disconnect()) |
| 05:53:19 | | Join johnb4 [0] (~johnb2@p5b3af394.dip0.t-ipconnect.de) |
| 05:57:06 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
| 06:00 |
| 06:05:27 | | Join advcomp2019_ [0] (~advcomp20@65-131-168-14.sxct.qwest.net) |
| 06:05:28 | | Quit advcomp2019_ (Changing host) |
| 06:05:28 | | Join advcomp2019_ [0] (~advcomp20@unaffiliated/advcomp2019) |
| 06:07:15 | | Quit advcomp2019__ (Ping timeout: 258 seconds) |
| 06:07:55 | | Quit J_Darnley (Read error: Connection reset by peer) |
| 06:08:19 | | Join J_Darnley [0] (~J_Darnley@d51a44418.access.telenet.be) |
| 06:09:25 | | Quit johnb4 (Ping timeout: 240 seconds) |
| 06:09:58 | | Join johnb4 [0] (~johnb2@p5b3af394.dip0.t-ipconnect.de) |
| 06:12:18 | | Quit TorC (Ping timeout: 256 seconds) |
| 06:14:51 | | Join TorC [0] (~Tor@fsf/member/TorC) |
| 06:18:58 | | Quit toruvinn (Ping timeout: 260 seconds) |
| 06:22:40 | | Quit johnb4 (Ping timeout: 246 seconds) |
| 06:25:07 | | Join ZincAlloy [0] (~Adium@ip5f5acf9f.dynamic.kabel-deutschland.de) |
| 06:26:22 | pamaury | Your work almost makes me wan to finish the Fiio X1 first gen port, even though it's old |
| 06:27:33 | | Join lebellium [0] (~lebellium@2a01cb080a0f0b00e44e1c68a1faaac4.ipv6.abo.wanadoo.fr) |
| 06:31:10 | | Join toruvinn [0] (~toruvinn@178-37-200-229.adsl.inetia.pl) |
| 06:32:22 | | Quit SovietShaman (Ping timeout: 256 seconds) |
| 06:33:04 | | Quit advcomp2019_ (Ping timeout: 240 seconds) |
| 06:38:26 | *** | Saving seen data "./dancer.seen" |
| 07:00 |
| 07:16:02 | | Quit Oksana_ (Ping timeout: 265 seconds) |
| 07:25:02 | | Join lebellium_ [0] (~lebellium@2a01cb080a0f0b0060e62403ebba4ace.ipv6.abo.wanadoo.fr) |
| 07:29:15 | | Quit lebellium (Ping timeout: 272 seconds) |
| 07:32:32 | | Join ufdm [0] (~ufdm@c-73-164-63-214.hsd1.mn.comcast.net) |
| 07:43:48 | | Quit livvy (Remote host closed the connection) |
| 07:45:32 | | Join Oksana_ [0] (~Wikiwide@Maemo/community/ex-council/Wikiwide) |
| 07:48:48 | | Join prof_wolfff [0] (~prof_wolf@240.red-88-19-58.staticip.rima-tde.net) |
| 07:49:23 | | Quit beencubed (Ping timeout: 265 seconds) |
| 07:53:06 | | Join lemon_jesus5 [0] (~lemon_jes@c-73-9-49-209.hsd1.il.comcast.net) |
| 07:54:52 | | Quit toruvinn (Ping timeout: 256 seconds) |
| 07:54:53 | | Quit scorche (Ping timeout: 256 seconds) |
| 07:55:26 | | Quit lemon_jesus (Ping timeout: 256 seconds) |
| 07:55:27 | | Nick lemon_jesus5 is now known as lemon_jesus (~lemon_jes@c-73-9-49-209.hsd1.il.comcast.net) |
| 07:58:05 | | Join johnb2 [0] (~johnb2@p5b3af394.dip0.t-ipconnect.de) |
| 07:58:33 | | Join scorche [0] (~scorche@rockbox/administrator/scorche) |
| 08:00 |
| 08:03:13 | | Quit scorche (Ping timeout: 264 seconds) |
| 08:16:02 | | Join toruvinn [0] (~toruvinn@178-37-200-229.adsl.inetia.pl) |
| 08:22:08 | | Join ac_laptop [0] (~ac_laptop@186.2.247.129) |
| 08:27:12 | | Join sakax [0] (~r0b0t@unaffiliated/r0b0t) |
| 08:32:50 | | Join scorche [0] (~scorche@rockbox/administrator/scorche) |
| 08:35:04 | | Quit johnb2 (Ping timeout: 240 seconds) |
| 08:38:29 | *** | Saving seen data "./dancer.seen" |
| 08:39:44 | | Quit scorche (Ping timeout: 240 seconds) |
| 08:40:34 | | Quit mikroflops (Quit: Lost terminal) |
| 09:00 |
| 09:12:16 | | Join livvy [0] (~livvy@gateway/tor-sasl/livvy) |
| 09:15:48 | | Join scorche [0] (~scorche@rockbox/administrator/scorche) |
| 09:17:03 | | Quit livvy (Ping timeout: 240 seconds) |
| 09:30:14 | | Join livvy [0] (~livvy@gateway/tor-sasl/livvy) |
| 10:00 |
| 10:03:24 | | Join __Bilgus [0] (41ba23be@65.186.35.190) |
| 10:04:48 | __Bilgus | pamaury unfortunately no such luck and It cuts off the real juicy stuff but it EXIUSTS! |
| 10:12:42 | | Join Huntereb [0] (~Huntereb@174.226.2.53) |
| 10:16:47 | __Bilgus | Hunterb long time no see got any agptek goodies? |
| 10:22:25 | | Join mikroflops [0] (~yogurt@c188-150-217-176.bredband.comhem.se) |
| 10:23:24 | speachy | pamaury: I actually bought one of those a few years ago −− got it for cheap as the rotary encoder on the wheel is flaky. |
| 10:25:27 | speachy | pamaury: dusting off your incomplete port is one of the eventual goals of what I'm trying to do now.. |
| 10:27:38 | | Join johnb4 [0] (~johnb2@p5b3af394.dip0.t-ipconnect.de) |
| 10:28:45 | speachy | johnb4: latest build ought to behave better. |
| 10:30:13 | johnb4 | ok, will try |
| 10:37:51 | | Join advcomp2019 [0] (~advcomp20@65-131-168-14.sxct.qwest.net) |
| 10:37:51 | | Quit advcomp2019 (Changing host) |
| 10:37:51 | | Join advcomp2019 [0] (~advcomp20@unaffiliated/advcomp2019) |
| 10:38:30 | *** | Saving seen data "./dancer.seen" |
| 10:39:13 | | Join johnb2 [0] (~johnb2@p5b3af394.dip0.t-ipconnect.de) |
| 10:54:23 | | Quit johnb2 (Quit: Nettalk6 - www.ntalk.de) |
| 10:55:58 | | Quit scorche (Read error: Connection reset by peer) |
| 10:59:41 | | Quit johnb4 (Quit: Nettalk6 - www.ntalk.de) |
| 11:00 |
| 11:00:46 | | Join johnb2 [0] (~johnb2@p5b3af394.dip0.t-ipconnect.de) |
| 11:00:59 | johnb2 | speachy |
| 11:01:20 | johnb2 | : the previous build would not mount anymore on Windows ... |
| 11:01:28 | johnb2 | I had to use the card reader. |
| 11:01:43 | johnb2 | Audio playback seems fine. |
| 11:02:16 | johnb2 | Anything in particular you want me to test? |
| 11:02:50 | speachy | no, just establishing a new baseline |
| 11:03:58 | speachy | http://www.shaftnet.org/~pizza/x3-test-a1.zip <−− Now this is the one that I'm curious about. :) |
| 11:08:04 | | Join scorche [0] (~scorche@rockbox/administrator/scorche) |
| 11:14:48 | johnb2 | I paused an mp3, vol +1 froze the player |
| 11:17:50 | johnb2 | when it goes from 480 to 192 I hear the single clicks again, e.g. Vol- |
| 11:18:15 | johnb2 | Boosting/unboosting in debug->freq just froze the player |
| 11:19:30 | johnb2 | but the click is not always reproducible from WPS and vol change |
| 11:20:42 | speachy | ok. please go back to the dev build then |
| 11:21:12 | speachy | oh, on the dev build, can you do one other test? enable "pause/resume on headphone unplug/plug" in the settings/playback stuff |
| 11:21:17 | speachy | and see if that works |
| 11:22:59 | __Bilgus | slowing down greylib seems to have quelled the worst of it |
| 11:24:40 | __Bilgus | spoke too soon crashed on fire |
| 11:27:30 | johnb2 | speachy : both pause and pause/resume work |
| 11:27:52 | speachy | ok, thank you. there's a bug ticket claiming they don't. I can't recreate it either. |
| 11:31:46 | johnb2 | __Bilgus: I am not familiar with display physics. Are all the brightness and contrast settings safe/in spec or are the prone to age the display/controller? |
| 11:31:59 | johnb2 | *are they |
| 11:32:19 | __Bilgus | johnb who knows |
| 11:32:24 | johnb2 | :-) |
| 11:32:26 | speachy | johnb2: it's an OLED, so use will age the display pixels. brighter == more age. basic physica, alas. |
| 11:32:42 | __Bilgus | extra brightness on an OLED will always make it age faster |
| 11:33:44 | johnb2 | So I better get the other screen mounted soon, instead of maxing contrast and brightness |
| 11:34:08 | __Bilgus | 10000 hrs |
| 11:34:30 | __Bilgus | where did the rest of my sentence go |
| 11:36:06 | __Bilgus | I bet lifetime is probably 10000 hrs at best anyways |
| 11:36:32 | speachy | the OLED panel can be replaced too if it comes to that, though I'd imagine the buttons/etc would have fallen off well before that |
| 11:37:07 | speachy | there's no shortage of 128x64 SSD1306-based OLED units out there.. :) |
| 11:37:42 | johnb2 | But I am not sure if I was able to replace it, if needed ;-) |
| 11:37:56 | __Bilgus | my driving of the panel shouldn't cause any issues either average power should still be pretty close I just give it longer to display in current mode it is therefore brighter |
| 12:00 |
| 12:06:33 | | Nick mendelmunkis is now known as mendel_munkis (~mendelmun@ool-ae2cb138.dyn.optonline.net) |
| 12:38:33 | *** | Saving seen data "./dancer.seen" |
| 12:44:25 | | Quit johnb2 (Quit: Nettalk6 - www.ntalk.de) |
| 13:00 |
| 13:27:59 | | Quit __Bilgus (Ping timeout: 245 seconds) |
| 14:00 |
| 14:14:48 | | Quit ac_laptop (Quit: WeeChat 2.9) |
| 14:15:05 | | Join ac_laptop [0] (~ac_laptop@186.2.247.129) |
| 14:15:34 | | Quit Moarc (Quit: i znowu NADMUCHAŁ BALONA) |
| 14:17:44 | | Join __Bilgus [0] (41ba23be@65.186.35.190) |
| 14:19:48 | | Join Moarc [0] (~chujko@a105.net128.okay.pl) |
| 14:20:33 | __Bilgus | speachy I'm messing with changing the drive strength on the pins going to the LCD but I did notice 2709 runs much less stable at head now |
| 14:24:34 | | Join johnb4 [0] (~johnb2@p5b3af394.dip0.t-ipconnect.de) |
| 14:28:28 | | Quit ac_laptop (Ping timeout: 246 seconds) |
| 14:36:21 | | Quit johnb4 (Ping timeout: 265 seconds) |
| 14:38:37 | *** | Saving seen data "./dancer.seen" |
| 14:46:40 | | Join Rower [0] (~Rower@185.246.208.202) |
| 14:48:49 | | Quit Rower- (Ping timeout: 264 seconds) |
| 15:00 |
| 15:02:28 | | Join Rower- [0] (~Rower@78-73-72-39-no2340.tbcn.telia.com) |
| 15:02:35 | | Quit Rower- (Remote host closed the connection) |
| 15:05:13 | | Quit Rower (Ping timeout: 246 seconds) |
| 15:25:00 | | Quit mendel_munkis (Ping timeout: 258 seconds) |
| 15:38:16 | | Join mendelmunkis [0] (~mendelmun@ool-ae2cb138.dyn.optonline.net) |
| 16:00 |
| 16:05:28 | | Join johnb4 [0] (~johnb2@p5b3af394.dip0.t-ipconnect.de) |
| 16:09:48 | | Quit johnb4 (Ping timeout: 256 seconds) |
| 16:12:28 | | Join ac_laptop [0] (~ac_laptop@186.2.247.129) |
| 16:28:18 | | Quit JanC (Remote host closed the connection) |
| 16:38:40 | *** | Saving seen data "./dancer.seen" |
| 16:38:51 | | Join JanC [0] (~janc@lugwv/member/JanC) |
| 16:47:31 | speachy | __Bilgus: ...lovely |
| 16:48:58 | | Quit JanC (Ping timeout: 244 seconds) |
| 16:50:19 | | Join JanC [0] (~janc@lugwv/member/JanC) |
| 17:00 |
| 17:04:48 | | Quit JanC (Remote host closed the connection) |
| 17:05:19 | | Join JanC [0] (~janc@lugwv/member/JanC) |
| 17:27:28 | fs-bluebot | Build Server message: New build round started. Revision 06e9abc, 280 builds, 8 clients. |
| 17:41:22 | speachy | __Bilgus: the CPU load % you were reporting for greylib, how is that derived? |
| 17:43:53 | fs-bluebot | Build Server message: Build round completed after 984 seconds. |
| 17:43:53 | __Bilgus | its the difference between time taken to display wireframe versus greylib I believe |
| 17:43:55 | fs-bluebot | Build Server message: Revision 06e9abc result: All green |
| 17:46:11 | __Bilgus | looking at the ADC code I think an interrupt might help here |
| 17:46:39 | __Bilgus | decouple the read_data command from running the adc |
| 17:47:01 | speachy | it is does use an IRQ...? |
| 17:47:05 | speachy | s/is// |
| 17:47:22 | __Bilgus | theres something abou polling the KEY data so no interrupt needed |
| 17:47:54 | speachy | key data is polled in interrupt context (ie system tick handler) |
| 17:48:45 | speachy | it returns the last ADC value while kicking off a new ADC read, which then trips an IRQ when it's done, updating the state |
| 17:49:32 | speachy | so we effectively lag input and battery by 1 tick. |
| 17:49:44 | speachy | (ie 10ms) |
| 17:52:33 | __Bilgus | I don't think we know what actually feeds the button array then |
| 17:54:00 | __Bilgus | I figured the KEY_INT was driving through the button matrix |
| 17:56:15 | speachy | it might be that all the keys feed both the ADC and a GPIO pin, but doing an blocking ADC sample in interrupt context probably isn't wise. |
| 17:56:30 | speachy | a single GPIO, that is |
| 17:57:21 | __Bilgus | we'd just kick it off then |
| 17:58:13 | | Join meatloaf [0] (~ambassado@2601:246:4400:b3c0:7593:e6ad:5904:25dd) |
| 17:58:42 | speachy | I wonder if instead of constantly having the ADC sampling, you mean? |
| 17:59:17 | __Bilgus | I'll test later if my idea is right but I see it floats high when no buttons are pressed so i'll start futzing gpios till it turns off |
| 17:59:53 | __Bilgus | if we drop below the threshold on button press we can use that falling sig to kick off the adc |
| 18:00 |
| 18:00:22 | __Bilgus | then we just keep a few state vars and last sample tick |
| 18:00:42 | speachy | might that also cause issues if the user fat-fingers keypresses? they'd have to let go of everything in order for the level to reset for a new trigger |
| 18:00:56 | | Quit ZincAlloy (Quit: Leaving.) |
| 18:01:08 | __Bilgus | possible but thats where pullups come in |
| 18:01:37 | speachy | we can't power down the ADC so I don't really see this making much of a difference. |
| 18:03:07 | speachy | hmm. we have peak stack reporting, right? |
| 18:03:29 | __Bilgus | maybe but I figure it removes some load to not be doing adc interrupts when unneeded |
| 18:04:00 | __Bilgus | yes? |
| 18:04:44 | speachy | oh, here's an idea −− use the gpio as the trigger to start sampling via the tick/button handler, but when the GPIO is removed stop sampling. |
| 18:06:05 | __Bilgus | oh short circuit them? |
| 18:06:12 | speachy | so only initiate sampling if GPIO141 is asserted, and when it deasserts.. BTN_NONE |
| 18:07:11 | | Quit lebellium_ (Quit: Leaving) |
| 18:08:06 | __Bilgus | I'll throw together a gpio sampler for the debug menu |
| 18:08:33 | speachy | I need to see about reporting the irq stack watermark |
| 18:14:41 | speachy | I don't like that we hang. audio dropout sure, but hang? is it a deadlock? a non-panic crash? |
| 18:14:54 | speachy | stuck in an IRQ handler? |
| 18:15:53 | | Quit JanC (Remote host closed the connection) |
| 18:16:14 | | Join JanC [0] (~janc@lugwv/member/JanC) |
| 18:34:24 | | Quit pamaury (Ping timeout: 240 seconds) |
| 18:38:43 | *** | Saving seen data "./dancer.seen" |
| 18:51:52 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
| 18:52:47 | | Quit meatloaf (Ping timeout: 260 seconds) |
| 19:00 |
| 19:00:29 | | Quit __Bilgus (Remote host closed the connection) |
| 19:05:02 | | Quit pamaury (Ping timeout: 258 seconds) |
| 19:18:36 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
| 19:26:19 | | Quit bluebrother (Disconnected by services) |
| 19:26:24 | | Join bluebrother^ [0] (~dom@rockbox/developer/bluebrother) |
| 19:27:42 | | Join fs-bluebot_ [0] (~fs-bluebo@55d4a844.access.ecotel.net) |
| 19:29:57 | | Quit fs-bluebot (Ping timeout: 258 seconds) |
| 19:33:58 | | Quit ac_laptop (Quit: WeeChat 2.9) |
| 19:34:53 | | Join ac_laptop [0] (~ac_laptop@186.2.247.129) |
| 19:34:59 | | Quit pamaury (Ping timeout: 240 seconds) |
| 19:55:53 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
| 20:00 |
| 20:05:25 | | Quit pamaury (Ping timeout: 240 seconds) |
| 20:19:06 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
| 20:35:25 | | Quit pamaury (Ping timeout: 240 seconds) |
| 20:38:47 | *** | Saving seen data "./dancer.seen" |
| 20:52:33 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
| 21:00 |
| 21:01:10 | speachy | huh, that's unexpected. supposeddly the irqstack max depth is only 152 bytes. seems quite low given the irqhandler asm sucks down 132 bytes before it hands off to C. |
| 21:02:11 | speachy | and the first C function sucks down 32 bytes. |
| 21:04:39 | speachy | make that 50 |
| 21:05:55 | | Quit pamaury (Ping timeout: 240 seconds) |
| 21:08:01 | speachy | counting from the beginning works better. 356 bytes after bootup. |
| 21:09:19 | speachy | 372 after USB hotplug.. |
| 21:09:44 | | Join _BILGUS [0] (41ba23be@65.186.35.190) |
| 21:10:47 | | Quit sakax (Quit: Leaving) |
| 21:10:53 | _BILGUS | so are you counting wrong or is it ovflow? |
| 21:12:16 | speachy | I was counting wrong. well, not "wrong" per se but not every address on the stack gets written to |
| 21:14:28 | speachy | my build has full reclocking, changes that explicltly disable the UARTs, and... fire's still running 30 seconds later. |
| 21:17:01 | speachy | this isn't crashing on me. |
| 21:18:42 | speachy | still going.. |
| 21:22:46 | speachy | still going... |
| 21:23:28 | | Join massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net) |
| 21:37:05 | fs-bluebot_ | Build Server message: New build round started. Revision 8dadce5, 280 builds, 8 clients. |
| 21:38:12 | _BILGUS | cool does it still click in your ear? |
| 21:38:20 | speachy | nope. fire's still going. |
| 21:38:28 | speachy | it's what's building now |
| 21:38:46 | speachy | (plus re-enabling the reclocking) |
| 21:38:53 | _BILGUS | I'm adding gpio to the debug menu atm |
| 21:39:20 | _BILGUS | so uart like for serial? |
| 21:39:37 | speachy | I intend to rewrite the debug hwinfo to be scrollable.. there's far more output in the 4760's dump than fits on screen |
| 21:39:41 | speachy | yeah, serial output. |
| 21:40:15 | _BILGUS | oh I already added the pieces for scrolling |
| 21:40:23 | speachy | oh awesome. :) |
| 21:40:35 | speachy | didn't know how to do it so I was actually looking it up |
| 21:40:38 | _BILGUS | yeah it gets annoying quick having cut off data |
| 21:40:48 | _BILGUS | check out the clip+ one |
| 21:41:04 | _BILGUS | well + zip .... |
| 21:41:47 | speachy | wonder if high load (or high lcd update rate) was inducing noise on the floating UART lines |
| 21:43:11 | _BILGUS | or they just need to be forced to input with a pullup |
| 21:43:24 | speachy | interrupts weren't turned on though.. so none of this should have mattered. |
| 21:44:05 | speachy | but even if this was (yet another) red herring the UARTs aren't needed, so disabling the code and turning 'em off is Right and Proper (tm) |
| 21:44:32 | speachy | I was able to crash the player within seconds before and now it's still going. |
| 21:45:13 | speachy | when johnb's back I'll send him another reclocked build and see what happens. I wonder if he has defective hardware or something.. |
| 21:46:03 | _BILGUS | it works fine in OF so I guess possible but more probably we have a shoddy setup |
| 21:46:26 | speachy | I don't think the OF reclocks at all, if the battery life is any indication |
| 21:46:39 | _BILGUS | not that I could point to the specific instance but it all starts smelling like shit |
| 21:47:16 | _BILGUS | I'm dying for more documentation it sucks having to test to figure out values |
| 21:47:41 | speachy | (or heck, the kernel sources for the OF..) |
| 21:47:54 | speachy | (and probably more importantly, uboot) |
| 21:50:13 | speachy | _BILGUS: but hey, you "enjoy" this sort of thing... :D |
| 21:50:40 | _BILGUS | indeed but it still is nice to have something to check |
| 21:52:10 | speachy | yeah. a lot of unnecessary effort. |
| 21:52:25 | fs-bluebot_ | Build Server message: Build round completed after 919 seconds. |
| 21:52:27 | fs-bluebot_ | Build Server message: Revision 8dadce5 result: 5 errors 0 warnings |
| 21:52:59 | speachy | grrr. |
| 21:53:35 | _BILGUS | hmm no changing on the gpio or the actual direction I wonder if the docs lie |
| 21:54:36 | _BILGUS | nope just me being dumb\ |
| 21:55:34 | speachy | I need to fix the mikmod crash |
| 21:55:54 | speachy | there's a missing nullptry check somewhere |
| 21:56:05 | speachy | in the instrument/etc display screens |
| 21:56:48 | fs-bluebot_ | Build Server message: New build round started. Revision 748133c, 280 builds, 8 clients. |
| 21:56:59 | speachy | there, that'll fix the x3 bootloader. |
| 21:59:41 | _BILGUS | so no gpio activity on the button presses but it gets all kinds of activity when the hold button is switched |
| 22:00 |
| 22:00:11 | _BILGUS | gonna keep investigating a bit more before I give up on the idea |
| 22:00:11 | | Quit livvy (Remote host closed the connection) |
| 22:08:01 | | Quit ac_laptop (Ping timeout: 246 seconds) |
| 22:12:27 | fs-bluebot_ | Build Server message: Build round completed after 940 seconds. |
| 22:12:29 | fs-bluebot_ | Build Server message: Revision 748133c result: All green |
| 22:14:48 | | Quit JanC (Remote host closed the connection) |
| 22:15:41 | | Join JanC [0] (~janc@lugwv/member/JanC) |
| 22:16:49 | | Quit JanC (Remote host closed the connection) |
| 22:17:41 | | Join JanC [0] (~janc@lugwv/member/JanC) |
| 22:25:54 | | Quit JanC (Killed (rajaniemi.freenode.net (Nickname regained by services))) |
| 22:25:58 | | Join JanC [0] (~janc@lugwv/member/JanC) |
| 22:38:49 | *** | Saving seen data "./dancer.seen" |
| 22:40:07 | _BILGUS | Ok So I am correct KEY_INT does trigger when a button is pressed |
| 22:40:52 | _BILGUS | PORT E pin 13 |
| 23:00 |
| 23:03:39 | _BILGUS | and I think we can now do multiple buttons with at least some buttons |
| 23:04:07 | _BILGUS | play back option all toggle another gpio it appears |
| 23:07:18 | fs-bluebot_ | Build Server message: New build round started. Revision 63e6aec, 280 builds, 8 clients. |
| 23:16:27 | | Quit TheSeven (Ping timeout: 260 seconds) |
| 23:16:40 | | Join [7] [0] (~quassel@rockbox/developer/TheSeven) |
| 23:23:11 | fs-bluebot_ | Build Server message: Build round completed after 952 seconds. |
| 23:23:12 | fs-bluebot_ | Build Server message: Revision 63e6aec result: 3 errors 0 warnings |
| 23:41:49 | | Quit _BILGUS (Remote host closed the connection) |
icon identifies that the person is a core developer (has commit access).