Previous day | Jump to hour: 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | Next day

Seconds: Show Hide | Joins: Show Hide | View raw
Font: Serif Sans-Serif Monospace | Size: Small Medium Large

Click in the nick column to highlight everything a person has said.
The Logo icon identifies that the person is a core developer (has commit access).

Notice: Only Gecko based browsers prior to FF4 support the multipart/mixed "server push" method used by this log reader to auto-update. Since you do not appear to use such a browser, this page will simply show the current log, and not automatically update.

#rockbox log for 2020-08-29

00:09:35 Join TheEaterOfSouls [0] (~souls@unaffiliated/theeaterofsouls)
00:31:02fs-bluebot_Build Server message: New build round started. Revision 5e335f5, 280 builds, 7 clients.
00:37:51***Saving seen data "./dancer.seen"
00:45:03fs-bluebot_Build Server message: Build round completed after 842 seconds.
00:45:05fs-bluebot_Build Server message: Revision 5e335f5 result: All green
00:45:06fs-bluebot_Build Server message: New build round started. Revision 31a1a29, 280 builds, 7 clients.
00:59:36fs-bluebot_Build Server message: Build round completed after 872 seconds.
00:59:37fs-bluebot_Build Server message: Revision 31a1a29 result: All green
01:00
01:01:35 Quit TheSeven (Ping timeout: 240 seconds)
01:02:17 Join TheSeven [0] (~quassel@rockbox/developer/TheSeven)
02:00
02:37:53***Saving seen data "./dancer.seen"
03:00
03:10:12 Join johnb2 [0] (~johnb2@p5b3af8aa.dip0.t-ipconnect.de)
03:18:43johnb2speachy : firmware/export/jz4740-codec.h -> The build (without any config.cfg) comes up with headphone volume @ 0dB. Can you please set this to a safe value like -25 or -30?
03:21:01johnb2I just tested 31a1a29004: As soon as GUI BOOST kicks in, the crackling is back during mp3 playback
03:24:30johnb2Volume, make it -30, please.
04:00
04:37:54***No seen item changed, no save performed.
05:00
05:09:06 Quit johnb2 (Quit: Nettalk6 - www.ntalk.de)
06:00
06:27:51 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
06:37:57***Saving seen data "./dancer.seen"
07:00
07:35:30 Join lebellium [0] (~lebellium@aaubervilliers-653-1-153-110.w86-218.abo.wanadoo.fr)
07:36:13 Quit St3ak (Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net)
07:42:45 Join __Bilgus [0] (41ba23be@65.186.35.190)
07:45:17 Join St3ak [0] (~st3ak@st3ak3000.powered.by.lunarbnc.net)
07:48:23 Join MrZeus [0] (~MrZeus@05467834.skybroadband.com)
08:00
08:19:32 Join ZincAlloy [0] (~Adium@2a02:8108:943f:d824:f8e7:d463:5890:b863)
08:35:57 Quit St3ak (Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net)
08:37:59***Saving seen data "./dancer.seen"
08:42:04 Join St3ak [0] (~st3ak@st3ak3000.powered.by.lunarbnc.net)
08:52:06fs-bluebot_Build Server message: New build round started. Revision 6296b22, 280 builds, 8 clients.
08:53:51speachyjohnb2, the good news is that I think I'm able to recreate the "crackle" problem −− but the bad news is that I believe the underlying issue has nothing to do with CPU clocking.
08:54:55speachydefault volume lowered, in this build.
08:55:38__Bilgusany thing change with cube and fire in your clocking tests?
08:56:44speachyI might have fixed those crashes −− or at least I was unable to make cube crash after more than a minute (as opposed to seconds prior)
08:57:11speachyBUT with those fixes audio artifacts are (nearly always) there
08:58:12speachyg#2709
08:58:13fs-bluebot_Gerrit review #2709 at http://gerrit.rockbox.org/r/2709 : mips: Heavily rework caching (WIP) by Solomon Peachy
08:58:24__Bilgushe said only mp3 exhibited the behavior so perhaps there is something about init
08:58:59speachymp3 only makes no sense to me, unless it's purely a matter of relative system load.
08:59:59__Bilgusquite possible , if 2709 is more stable then it probably makes sense to work on the artifacts
09:00
09:04:11speachyI was going to disable the asm memcpy/memset next.
09:04:57speachy(the glitching I was hearing was clearly bad data in an audio buffer...)
09:05:19fs-bluebot_Build Server message: Build round completed after 793 seconds.
09:05:20fs-bluebot_Build Server message: Revision 6296b22 result: All green
09:06:25 Join sakax [0] (~r0b0t@unaffiliated/r0b0t)
09:06:51__Bilgusspeachy I get some hanging running test_mem it almost acts like the audio buffer has the same or lower priority
09:09:01speachythat may very well be. I haven't looked at the DMA priority settings yet.
09:09:26speachybut the audio is only single-buffered too, which I find quite odd
09:10:38speachyit only seems to affect audio
09:10:50speachy(corruption I mean)
09:11:06speachyso it might be that there's been an audio problem here all along but it's been masked by other stuff
09:14:48speachythe caching stuff only affects DMA transfers (plus rolo and early boot where we want to drop everything)
09:17:47 Quit sakax (Quit: Leaving)
09:20:31speachyI think this new cache code is buggy with respect to actions on buffers that aren't aligned with a cacheline. but trying to find the appropriate MIPS/xburst documentation has proven challenging.
09:20:53 Join johnb2 [0] (~johnb2@p5b3af8aa.dip0.t-ipconnect.de)
09:23:22 Join ac_laptop [0] (~ac_laptop@186.2.247.129)
09:31:02 Quit __Bilgus (Remote host closed the connection)
09:34:12 Join _Bilgus_ [0] (41ba23be@65.186.35.190)
09:38:29pamauryspeachy: we usually make sure that DMA are aligned on cachelines
09:46:40johnb2speachy: as for system load (on MP3 vs opus, flac), I just created a opus track with 480kBit/s and have and 8 band EQ active: no crackle, even if I increase the boost counter manually in debug.
09:49:46_Bilgus_speachy Indeed it doesn't crash but the noise there during pb gets repolaced with the sound of the cube phases and once the screen turns off it gets quiet sometimes??
09:51:02_Bilgus_oh weird try this playback with 2709 its noisy , run cube do the greyscale high speed let screen turn off playback goes perfect
09:51:50_Bilgus_press option to turn screen back on and switch to wireframe let screen turn off noise from boot returns
09:52:15speachyI wonder if we're having DMA stalls due to bus contention?
09:52:43_Bilgus_go back to greyscale it makes that clicking, let scren turn off its perfect again
09:53:39speachyor maybe it's purely a function of high CPU load causing thread starvation?
09:54:03speachy2079 is more stable though, correct?
09:54:15_Bilgus_why does the greyscale loop clear it though
09:54:36_Bilgus_oh no crash at all letting it thrash
09:54:53_Bilgus_I want to try to boot with no screen and see if it helps
09:55:30speachy(I wonder if we have an IRQ delivery issue?) (Is something locking out interrupts?)
09:56:58pamauryspeachy: if you are interested, I have some document regarding the xburst ISA but it's very incomplete. Mostly it contains info about the MXU instructions
09:57:49speachypamaury: is it the one linked off the 4760b wiki page?
09:58:44pamauryspeachy: ah yes, apparently I already uploaded it
09:59:03speachy_Bilgus_: could also be an IRQ hierarchy issue. bleh. I hate it when test results _expand_ the potential problem space.
10:00
10:11:26pamauryspeachy: what is your problem with the cache ?
10:24:54speachypamaury, trying to hunt down some stability problems. dragging your old cache rework patches into the present seems to have helped a lot, at the expense of audible audio crackling.
10:26:08speachythough the interaction with the display points at resource contention instead
10:27:10_Bilgus_speachy when you get a chance could you rebase ontop of 2710?
10:27:56speachy_Bilgus_: commit it, I'll fix up my stuff later today.
10:28:26fs-bluebot_Build Server message: New build round started. Revision 3867f0b, 280 builds, 8 clients.
10:28:39pamauryspeachy: have you tried reverting memset and friends to put software versions? I am not sure the code in discard_dcache_range correctly handles edges not in cache lines
10:28:47speachypamaury: that's also on my todo list.
10:29:25speachypamaury: both are, actually. I have the latter in my working tree though I haven't loaded it up yet, and given that memset/memcpy have already proven to be (badly) broken in the past, I was going to disable them too
10:29:32pamauryand made sure all dma buffers are aligned? On imx233, I endedup introducing macros to check this because it bite me more times than I could count
10:30:31speachyin theory MIPS allows unaligned cache flushes.
10:31:09speachythere's no danger if you wb+invalidate too much, only if you only invalidate things
10:31:38pamauryspeachy: yeah but memset for example invalidates, it could invaliate some bytes outside the range but in the cache line no ?
10:32:00pamauryI didn't know MIPS could do unaligned cache flushes. But I learned the hard way with JZ4760 that "MIPS" is some vague word that gives very little guarantees so I am quite paranoid
10:32:21speachypamaury: fair enough. :)
10:33:18speachyI don't see any reference to the cache instruction in the memset code?
10:33:47speachythere's a memset_dma() C function but AFAICT nothing actually calls it..
10:33:52pamauryI mean in the hardware based version on gerrit
10:34:12pamauryhttps://gerrit.rockbox.org/r/#/c/2709/1/firmware/target/mips/ingenic_jz47xx/dma_acc-jz4740.c
10:35:22speachydma_acc-jz4740.c isn't present in SOURCES (or #include-d) anywhere
10:35:38speachydma_acc-jz4760 is, but nothing actually calls the memset_dma/memcpy_dma functions it contains.
10:36:11pamauryah ok, should nuke it then ^^
10:37:08speachy_Bilgus_: is there a upper cap on display updates or is it pretty much "use all avaiable oomph"
10:37:29pamaurystill something must be wrong with caches/dma if you have some audio crackling. On ARM I debugged those issues by the running the code without cache so see if it fixes issues (it's slow as hell). But on MIPS it's not necessarily easy to do so.
10:38:03***Saving seen data "./dancer.seen"
10:38:13_Bilgus_I don't think there is any limiting beyond what it can do
10:38:16speachyhow large is the audio buffer typically passed to the dma engine? a few kb or larger?
10:38:52_Bilgus_i mean most code has timeout or yield
10:38:59pamauryspeachy: stupid question but are we 100% sure about the cache size ? And what if you replace all instances about commit/discard_range by just commit_discard_cache(), ie writeback the entire cache everytime instead of being smart ?
10:39:23speachyall of injenic's docs say it's a 16KB cache for I and D
10:39:29pamauryspeachy: depends a lot on the codec, on imx233 the driver has to cut it in little piece to keep it manageable
10:40:17speachyand the cacheline is 32 bytes. so sayth the linux kernel too, btw
10:40:48 Quit _Bilgus_ (Remote host closed the connection)
10:41:21speachypamaury: I tried that last night, it didn't make the crackle go away.
10:41:31speachy(and no L2/L3 cache on these parts)
10:41:43speachyotherwise we'd have to flush the L2/L3 too...)
10:41:47fs-bluebot_Build Server message: Build round completed after 800 seconds.
10:41:49fs-bluebot_Build Server message: Revision 3867f0b result: All green
10:42:26pamauryspeachy: does the AIC support pushing the audio data manual via a fifo register ? That way you can avoid DMA with audio and confirm that the problem indeed is the dma
10:42:55speachythe I2S controller uses a fifo, yeah.
10:44:01speachyI forget how deep it is.. but not very.
10:46:24speachyonly seems to affect audio though. sd & usb are okay.
10:47:05 Join __Bilgus [0] (41ba23be@65.186.35.190)
10:47:49pamauryspeachy: apparently the FIFO is 32 entries deep (an entry is 24-bit so I assume just one channel). So at 48KHz you would need to to refill 3000 times a second, which is doable (for debug purpose) especially if you push the cpu clock high enough
10:48:08speachyhuh, the 4760 doesn't like a 144MHz bus speed.
10:48:10pamauryI assume there is so IRQ mecanism for this
10:50:34pamaurymore things you can try: create a smallish buffer (a few kb) in the audio driver, copy the data there in bursts and DMA'it (so you have full control of the buffer alignment and cache stuff)
10:52:07speachyhuh... I lowered the clock to 528, upped the bus to 132 (from 96) and the crackle is gone. oh, with the guard test to make sure we don't invalidate unaligned cache lines
10:52:54speachyso we bounce between 528/132 and 192/96 now
10:53:30speachymight have genuinely been DMA contention due to the CPU clocking so high relative to the bus & memory.
10:54:05speachyaaaand cube makes it go kaboom.
10:55:35__Bilgusthe fire plugin is even faster
10:55:45__Bilgusfor crashes
11:00
11:17:17 Quit __Bilgus (Remote host closed the connection)
11:30:13speachy__Bilgus: updated. there's a second patch there that tweaks the cpu freq too
11:30:59 Join bilgus_ [0] (41ba23be@65.186.35.190)
11:37:55 Quit MrZeus (Ping timeout: 240 seconds)
11:41:19 Join sakax [0] (~r0b0t@unaffiliated/r0b0t)
11:53:37 Quit ac_laptop (Ping timeout: 264 seconds)
11:59:25 Quit johnb2 (Ping timeout: 240 seconds)
12:00
12:38:04***Saving seen data "./dancer.seen"
12:55:51speachynow that's annoying. the vol-up button just broke. and taking it apart to figure out why, the vol-dn button followed.
13:00
13:09:20bilgus_well luckily thats remapped as a menu item
13:11:14 Join johnb4 [0] (~johnb2@p5b3af8aa.dip0.t-ipconnect.de)
13:13:45johnb4speachy : as for the screen replacement, there were reports where people broke (sheared off) those volume buttons when trying to remove the pcb from the case. They found some easy to replace buttons.
13:13:56speachythat ebay link is no good now
13:14:09johnb4That's somewhere in the head-fi thread.
13:14:20speachytrying to find something equivalent on mouser right now.
13:14:45johnb4ah, I haven't checked myself.
13:15:32johnb4I also ordered the Nintendo screen
13:15:58speachyin a strange coindidence, I have a brand new X3 supposed to be delivered within the hour.
13:17:02speachyvol up/dn isn't a big deal; I tend to use the line out anyway. it's the functions mapped onto those buttons that will be more challenging.
13:18:31speachy3.5x2.9x1.3mm
13:23:18speachyhttps://www.mouser.com/ProductDetail/Panasonic/EVQ-P7A01P looks like it'll do
13:34:51speachyjohnb4: one more for you. current git head with the dynamic clocking disabled. cpu is maxed out, unlike the older one I sent you.
13:35:33speachyhttp://www.shaftnet.org/~pizza/x3-test6.zip
13:36:30johnb4will test it in 20min
13:52:03 Join ac_laptop [0] (~ac_laptop@186.2.247.129)
14:00
14:10:27 Quit johnb4 (Ping timeout: 258 seconds)
14:11:44 Join johnb2 [0] (~johnb2@p5b3af8aa.dip0.t-ipconnect.de)
14:13:04 Quit bilgus_ (Remote host closed the connection)
14:17:36johnb2speachy The crackle doesn't cease (e.g. after 3s), but continues throughout the entire track (no matter whether display is on or off).
14:17:45speachyok, that's what I actually expected
14:18:20speachyI wonder if you somehow have a different hardware variant. is your unit black or silver?
14:19:35speachyone more coming for ya.
14:19:41johnb2black
14:20:07speachythere's now a test7
14:20:42speachydynamic clocking, but lower max speed (with a higher bus speed)
14:21:18johnb2In the OF, it says VTX5 (so maybe I patched a Vortex version instead of original 1.1), but that shouldn't matter when in rockbox, right?
14:22:52speachyyeah.
14:23:03speachyhttp://www.shaftnet.org/~pizza/x3-test7.zip
14:25:13johnb2That one works.
14:25:48johnb2spoke too soon.
14:26:02johnb2The notorious crackle is gone.
14:27:01johnb2but there is a brief blob sound when resuming and then a few seconds later during playback
14:27:30johnb2but the symptoms are completely different.
14:28:22johnb2let me do more experiments
14:28:23speachyok
14:29:52johnb2turning down volume (1dB) causes the same (mostly just in one channel).
14:30:16johnb2while playing
14:31:00johnb2but again just in mp3, not flac
14:35:46johnb2It is correlated to the frequency change: I monitore it in debug-> freq and buffering thread.
14:36:21johnb2the volume change boosts to 534MHz, same for track change.
14:37:01johnb2524
14:37:18johnb2528
14:37:20speachyshould be 528?
14:37:26johnb2I need new glasses
14:38:06***Saving seen data "./dancer.seen"
14:38:29speachyI can drop it down another notch (480) to see if that helps.
14:38:32johnb2yeah, I think this is it.
14:38:38johnb2ok
14:39:27speachyI still don't see why mp3 is special. :/
14:39:40speachyhttp://www.shaftnet.org/~pizza/x3-test8.zip
14:45:47johnb2It doesn't seem to make a difference.
14:49:41johnb2playing with the vol keys I managed to freeze the player
14:55:40speachyone more: http://www.shaftnet.org/~pizza/x3-test9.zip
14:57:11johnb2Froze once more (still with #8)
15:00
15:01:39fs-bluebot_Build Server message: New build round started. Revision 3dc4f81, 280 builds, 8 clients.
15:02:19speachythe build running is equivalent to test9. I've disabled reclocking altogether. I still don't think the reclocking itself is the problem, but there's clearly something else going on that reclocking is exacerbating.
15:02:49johnb2I don't notice any artefacts now with #9 running at 400MHz
15:03:58johnb2wasn't #3 running @ 192 constantly? This sounded fine, too.
15:04:18speachyyeah, #3 was. sounded fine but would have problems with more intensive codecs.
15:11:40johnb2Running cube while playing audio produces the original crackle, but at a lower rate.
15:13:37 Join mutnai [0] (b2849e75@178.132.158.117)
15:14:33fs-bluebot_Build Server message: Build round completed after 773 seconds.
15:14:34fs-bluebot_Build Server message: Revision 3dc4f81 result: All green
15:14:40johnb2and fire crashes it.
15:15:10johnb2But solely doing audio playback is fine.
15:15:11speachyintensive display stuff destabilizes things, basically.
15:15:55speachythe display works by bitbanging things, so it's pretty cpu-intensive, especially for stuff like fire or cube that runs as fast as it can.
15:22:25 Quit mutnai (Remote host closed the connection)
15:24:07speachypamaury: do you have any idea where the irq vector list came from? it doesn't correspond with what's in the 4760's programming manual.
15:25:19speachy(as in, it's _very_ different..)
15:28:31speachyugh, the vector table is a complete software construct that only loosely corresponds to the HW vector.
15:29:18 Quit johnb2 (Quit: Nettalk6 - www.ntalk.de)
15:57:28speachyif I'm reading this correctly the IRQ handler treats the i2c as the highest priority..
15:58:16speachyeverything on the second bank (which includes the audio and SD controllers) is treated as lower priority than nearly everything else.
16:00
16:15:04speachyalso might have a fix for the ROLO hang.
16:16:46speachy...the code prioritized I2C, of all things.
16:18:43 Quit mikroflops (Quit: <(^_^)>)
16:29:16 Quit pamaury (Quit: this->disconnect())
16:29:37 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
16:30:36pamauryspeachy: no, I didn't pay attention to the existing jz4740 code to be honest, I am doing more of a rewrite from scratch
16:31:05speachywell, I've redone the interrupt priorization to be a little less insane.
16:32:26speachyno provision for IRQ preemption though
16:33:55 Quit ac_laptop (Ping timeout: 240 seconds)
16:34:18speachyhaven't crashed it yet with the cube plugin, which is progress.
16:34:30speachythough fire seems to introduce a bit of crackle (irony!)
16:36:30speachyI've really been spoiled with the NVIC on "newer" ARMs.
16:37:23pamauryI think I tried to implement nested IRQ on MIPS but I couldn't make it work
16:38:07***Saving seen data "./dancer.seen"
16:54:52speachyI think I have basic nested irqs going, though there's no sense of priority other than the AIC is not preemptible.
16:59:51 Join mikroflops [0] (~yogurt@c188-150-217-176.bredband.comhem.se)
17:00
17:03:27speachyI'm not sure what ingenic means by "enable the system interrupt to allow the interrupt masking" −− set ST0_IE?
17:12:57 Quit lebellium (Quit: Leaving)
17:26:53fs-bluebot_Build Server message: New build round started. Revision 733821b, 280 builds, 8 clients.
17:39:42fs-bluebot_Build Server message: Build round completed after 770 seconds.
17:39:44fs-bluebot_Build Server message: Revision 733821b result: All green
18:00
18:11:37 Quit pamaury (Ping timeout: 264 seconds)
18:23:21 Join cockroach [0] (~blattodea@pdpc/supporter/active/cockroach)
18:38:10***Saving seen data "./dancer.seen"
19:00
19:04:48 Quit ZincAlloy (Quit: Leaving.)
19:17:00 Join livvy [0] (~livvy@gateway/tor-sasl/livvy)
19:18:57 Join ac_laptop [0] (~ac_laptop@186.2.247.129)
19:27:39 Join fs-bluebot [0] (~fs-bluebo@55d4b614.access.ecotel.net)
19:29:44 Quit fs-bluebot_ (Ping timeout: 240 seconds)
19:30:22 Quit bluebrother^ (Ping timeout: 265 seconds)
19:32:11 Join bluebrother [0] (~dom@rockbox/developer/bluebrother)
19:44:14 Quit ac_laptop (Quit: WeeChat 2.8)
19:44:33 Join ac_laptop [0] (~ac_laptop@186.2.247.129)
20:00
20:38:12***Saving seen data "./dancer.seen"
21:00
21:14:27 Join massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net)
21:31:12 Quit cockroach (Quit: leaving)
22:00
22:13:51 Quit sakax (Quit: Leaving)
22:35:25 Quit ac_laptop (Ping timeout: 240 seconds)
22:38:17***Saving seen data "./dancer.seen"
22:40:37 Join _Bilgus_ [0] (41ba23be@65.186.35.190)
22:47:29_Bilgus_speachy the audio priority makes sense
22:47:38speachyit does but I got it wrong. :D
22:47:45_Bilgus_oh?
22:48:07speachythe AIC isn't actually used... all we actually care about is the DMA channel used to transfer audio
22:48:17_Bilgus_before I left for the day I determined its not anything the cache rework did
22:48:29speachyyeah, the cache rework does change the timings around a bit though.
22:48:37_Bilgus_there were a few things that were missing from the sources I found
22:48:54_Bilgus_versus−−
22:49:23speachythe code I'm working on moves the SD DMA onto the second DMA controller, so only audio (and USB) is on the first.
22:49:47_Bilgus_like ones was copying K0 to K1 and K1 to K0, the other was saving pagemask
22:51:00_Bilgus_well usb will never be needed with audi so that sounds good
22:52:19speachyright now I'm trying to figure out how often the ADC (ie battery and button) is actually sampling
22:55:06_Bilgus_do we have info on the adc? maybe a way to lower the sample time too
22:55:15speachywe do, but the docs are... lacking.
22:55:24_Bilgus_heh
22:56:33speachybasically there are three dividers, the base clock speed (ie from the XTAL), and then two more to derive us and ms times, but no mention of what they actually do. the touchscreen port on the SADC can use DMA but the battery and aux can't.
22:56:44speachyso the thing runs as fast as it runs, interrupting the CPU each time
22:57:51speachyright now the base clock is 200KHz, aka the max the SADC supports.
23:00
23:00:16speachyor "us" and "ms" rather. still trying to figure out they mean.
23:01:49speachyso the "us" clock is ~100KHz, and "ms" clock is ~20KHz
23:03:09speachy(also means the keymaps that require two buttons being held down won't work, unless the other button is power!)
23:06:00speachyclk_us is "interval time between repeated sampling the same point" and clk_ms drives "the interval time among the different point"
23:06:17_Bilgus_I found it in the manual, I think we can still do multiple buttons
23:06:34_Bilgus_we just need to figure out the way they have it wired
23:06:56speachyI think the keymap is sane though I might have broken a few things inadvertantly. :)
23:07:30_Bilgus_I can play with that I'm at least semi familar with adcs
23:14:40speachythe code does overdrive the SADC slightly, 203KHz nominal versus 200K max.
23:15:56_Bilgus_is the clock shared with something else?
23:16:08speachyit's derived from the XTAL, so no.
23:16:55speachythe base divisor goes all the way to 255 ie a ~47KHz base clock
23:17:20speachythere's just no explanation of the other divisors.
23:17:57 Quit TheSeven (Ping timeout: 260 seconds)
23:18:14 Join TheSeven [0] (~quassel@rockbox/developer/TheSeven)
23:20:34speachywonder if it might just make more sense to only initiate the ADC query when button_read_device() is called.
23:20:52speachyand set up a timer to poll the battery oh, once a second.
23:26:43speachydocs appear to be wrong about the "ms" clock; it is supposed to key off the main sadc clock, not the us clock.
23:26:58speachyif I believe the linux kernel sources. :)
23:30:44speachyso, I infer that the ADC samples every ms for 10us.
23:35:07speachythe 4740 targets only poll the battery when the core requests it
23:55:13_Bilgus_we could move the battery to tick task
23:55:58speachy... no..
23:56:12speachyI mis-read this. the aux and battery adc query is a oneshot
23:56:18_Bilgus_I found a jz4760b UI programming manual on some chinese file sharing site
23:56:26_Bilgus_I wonder if it applies to us
23:56:41speachyevery time the button tick fires it triggers a bat+keypad read
23:57:04speachybut (here's the funny part) we don't actually _wait_ for it to finish.
23:57:20_Bilgus_oh do we get an interrupt?
23:57:21speachyand there's nothing that prevents them from getting stacked on each other
23:57:28_Bilgus_oh :/
23:57:47speachywe get an interrupt and update the global state. so on a subsequent tick/call to button_read_device, the values are pulled.
23:58:34_Bilgus_https://max.book118.com/html/2016/0309/37235681.shtm

Previous day | Next day