--- Log for 13.10.117 Server: orwell.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 12 days and 16 hours ago 00.00.33 Quit wodz (Ping timeout: 240 seconds) 00.00.56 Join wodz [0] (~wodz@89-79-40-110.dynamic.chello.pl) 00.04.03 Quit petur (Quit: Leaving) 00.04.18 # <__builtin> user890104: I was hoping to get some way to output PCM through the piezo 00.08.48 # <__builtin> probably through pulse-width modulation 00.20.29 Quit munch (Quit: Let's blast this shit and get naked) 00.27.58 Quit alexweissman (Remote host closed the connection) 00.29.44 Join alexweissman [0] (~alexweiss@c-68-50-12-70.hsd1.in.comcast.net) 00.36.08 # what is the sampling rate you can drive it with? 00.37.30 Quit wodz (Quit: Leaving) 00.39.09 Join munch [0] (pls@gateway/shell/elitebnc/x-jkouwoqptxopphfn) 00.56.29 # pamaury should I keep running the benchmark with autoslow off from earlier? 00.57.08 # oh he went to bed nm 01.06.18 # This is embarrasing not to be able to answer: Which revision is 3.14 based off? 01.06.39 # All of them? 01.07.03 # * jhMikeS slaps Bilgus 01.07.40 # It was branched from something 01.07.52 # I changed that patch to check for else SYS_TIMEOUT it should be good, though is there any plans to ever put back the disk caching code? 01.08.09 # put back? 01.08.44 # its commented out in the SYS_TIMEOUT routine 01.09.47 # line 1673 /* TODO: This needs to be fixed to use the idle callback, disable it 01.09.47 # * for simplicity until its done right */ 01.10.19 # if thats is never going back the !filling timeout for the queue can probably be upped bu a bit 01.11.54 # oh, the fill on idle code? 01.12.05 # yep 01.13.36 # could just remove it since it's probably not going any time soon. it's not like it can't be pulled out of the history if it's really wanted, or perhaps done better after whatever you're fixing. 01.16.23 # i'd just as soon leave it be, it works and I doubt a few less comparisons a second are going to amount to too much 01.19.15 Quit krabador (Quit: Leaving) 01.19.45 Join krabador [0] (~krabador@unaffiliated/krabador) 01.19.57 # it's disabled and probably doesn't quite work correctly 01.20.33 Quit saratoga_ (Ping timeout: 260 seconds) 01.20.33 Quit _meg (Ping timeout: 240 seconds) 01.21.19 # oh I was saying leaving the timeout there at HZ/2 it checks watermark each time through 01.21.58 Quit krabador (Remote host closed the connection) 01.22.05 # you quoted the TODO: so i thought you were talking about that disabled code 01.23.34 # ah sorry no I was wondering if that would be added back in there if/when it came back 01.24.33 Join _meg [0] (~notsure@211.25.203.45) 01.26.43 # I'm pretty sure that code is the reason the !filling timeout is HZ/2 rather than HZ or more 01.28.51 Join _jhMikeS_ [0] (~jethead71@d192-24-173-177.try.wideopenwest.com) 01.28.51 Quit jhMikeS (Disconnected by services) 01.28.52 Nick _jhMikeS_ is now known as jhMikeS (~jethead71@d192-24-173-177.try.wideopenwest.com) 01.29.00 # Not really. The watermarks are set in playback so the timeout better be shorter than the margin before the buffer goes empty. 01.32.11 Quit Ruhan (Quit: Connection closed for inactivity) 01.32.43 # flash has a 1 second margin +0/-0.5 01.35.50 # oh see glad I asked 01.37.01 # It seems to me though that this isn't the only place a call to rebuffer happens though so isn't it kinda redundant to have it checking in the thread and recieving calls from the codec? 01.37.29 # or is it just a CYA kinda situation 01.41.01 # the codec is really concerned with the PCM buffer level more than anything 01.42.22 Quit dys (Ping timeout: 248 seconds) 01.44.20 # do you suppose that could cause the condition I was seeing in high demand during AAC-HE? basically if it wasn't boosted before it hit time to rebuffer it would never catch up even dropping calls for cpu_boost 01.44.51 # the audio thread stays (or is supposed to stay) boosted while adding handles which should keep buffering from getting ahead and unboosting anything just because it doesn't see anything 01.45.17 # yeah that wasn't happening 01.45.17 # <__builtin> jhMikeS: 8817467 I think 01.45.33 # __builtin: 95% confidence interval? 01.46.09 # <__builtin> it's a mess actually 01.46.11 # <__builtin> lemme check 01.47.09 # was that before or after eefc7c7? 01.47.59 # <__builtin> after 01.48.07 # <__builtin> release was 1 May 01.48.32 *** Saving seen data "./dancer.seen" 01.48.40 # hmmm 01.50.55 # <__builtin> yeah, it was the few commits around 8817467 01.51.18 # Bilgus: was it getting overloaded and the thread not getting into buffer_handle on time (that's the only place where it boosts)? 01.53.24 # Bilgus: Is AAC HE particularly CPU intensive? 01.53.34 # <__builtin> saratoga: (re piezo) timer frequency on the 6G is 12MHz I think 01.56.29 # Bilgus: the codec could be going high priority and preventing the buffering thread from running if the target has trouble decoding that 01.57.11 # obviously if it doesn't get scheduled to run, then it can't boost itself 01.57.42 # then again, codec should be boosting itself too if that's the case 01.58.42 # maybe put the trigger before the open and lseek calls? 01.59.55 # it's not like those are lightweigh and don't make a thread block a lot 01.59.58 Quit Rondom (Remote host closed the connection) 02.00.49 Join Rondom [0] (~rondom@modo.nonmodosedetiam.net) 02.04.34 # <__builtin> user890104: do you know any details about how the piezo is controlled beyond what's in piezo-6g.c? 02.24.22 Quit CH23 (Quit: Page closed) 02.59.41 Join deevious_ [0] (~Thunderbi@193.226.142.214) 03.00.59 Quit deevious (Ping timeout: 240 seconds) 03.00.59 Nick deevious_ is now known as deevious (~Thunderbi@193.226.142.214) 03.34.39 # JhmikeS buffer_handle already has a cpu_boost call in it but its essentially ignored according to logging it gets 2 calls for boost and neither does anything 03.35.49 # https://pastebin.com/B47yrQJw 03.37.58 # sorry I have one that shows it better https://pastebin.com/kVhD8iua 03.39.27 # it looses it at line 83. tick: 4493, boost_counter: 84. tick: 4495, boost_counter: 1 03.39.33 # loses* 03.40.19 # each time boost_counter gets called it should increment or decrement the counter 03.41.31 # and just after that you see count: (data_counters.remaining) go nuts 03.48.34 *** Saving seen data "./dancer.seen" 04.10.16 Join Ruhan [0] (uid76353@gateway/web/irccloud.com/x-vucnwziupcgmmsmp) 04.27.17 # __builtin: i'm afraid not, i only know that it's hardwired to a timer pin (E or F) on nano 2g (maybe 3g too?) 04.37.19 # Bilgus: how would it be ignored? 04.37.46 # all I can figure is a race condition 04.38.11 # I'm looking at the audio buffer and pcm buffer noww i'll post it shortly 04.40.49 # was it the same thread that did it in both? 82 looks like it did something 04.44.17 # 82 is just the call to cpu_set freq 04.44.34 # hen it returns it increments boost_count 04.45.21 # the way you have it logged it should always delta +1/-1, right? 04.45.24 # ah you know what it is it got them out of order 04.45.49 # yeah it either + or - 1 04.46.02 # but I think I might know whats happening 04.46.17 # its calling for a unboost and a boost within the sma etick 04.46.50 # hmmm... 04.47.00 # let me get this other log up 04.47.09 # which target is this? 04.47.40 # if the function allows reentrancy that's probably bad 04.47.51 # at least without a mutex 04.48.06 # its the fuze+ 04.49.34 # I see the boost code has if (!cpu_boost_lock()) 04.50.57 # which does nothing if it's not implemented (not needed on most atm) 04.51.24 # if set_cpu_frequency yields though, it better be serialized 04.52.06 # yeah no define its always true ill check that next 04.53.32 # no it doesn't have anything to enforce order 04.54.07 # https://github.com/Rockbox/rockbox/blob/c7f897faa4276ade8fb26a3522ff5b3041b4cd56/firmware/target/arm/imx233/system-imx233.c#L319 04.55.25 # what the heck did i do with my fuze+ 04.59.17 # huh weird I didn't get any data in my log file for the file in question :/ 04.59.37 # imx233_power_set_regulator yields which could let threads pile in there and mess it up 05.00.46 # better implement the boost lock/unlock before moving on 05.01.19 # I'm no low level kinda guy do i just set a mutex at the beginning and release at end? 05.01.38 # or just enable cpu_boost_lock 05.01.45 # well implement 05.03.05 # see system-as3525.c and its header 05.03.28 # set_cpu_frequency__lock/__unlock 05.04.10 # k 05.04.28 # could probably just copy that stuff over 05.10.39 # uh huh lol 05.11.06 # all except for there being lots of targets but ill test it on the fuze= first 05.11.11 # + 05.26.16 Join almog1006 [0] (4d8bf186@gateway/web/freenode/ip.77.139.241.134) 05.27.02 # if they share the same code it's still the right setup 05.27.12 Quit Aldem (Ping timeout: 255 seconds) 05.27.15 # it worked 05.27.48 # I have to do some more testing to say for 100% sure but It hasn't done it once in 3 runs 05.28.08 # so priority inversion? 05.28.21 # is that whats thats called? 05.28.33 # reentrancy but the function isn't reentrant 05.28.42 # lol what that is called 05.29.03 # priority inversion is when a low priority thread keeps a higher one from executing 05.29.17 # ah see thats what I thought it was 05.29.28 # originally.. 05.29.55 # in that case, there's a thread yielding but another thread tries to change the frequency before one already doing it is finished 05.30.02 # ok I'll get this all cleaned up spit out one more log and then abandon the other patch 05.30.27 # yeah you have all the buffers and codecs fighting for the same space 05.30.51 # well the same function 05.31.11 # so, a race condition is basically it 05.33.22 # well thank you very much mike I learned something and you lead me to the real issue 05.41.59 Quit almog1006 (Quit: Page closed) 05.44.45 # Bilgus: you're welcome. you said "race condition" early on which made me check the possibility. 05.48.36 *** Saving seen data "./dancer.seen" 06.08.01 Quit TheSeven (Ping timeout: 258 seconds) 06.09.11 Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) 06.25.39 Quit TheSeven (Ping timeout: 258 seconds) 06.25.54 Join [7] [0] (~quassel@rockbox/developer/TheSeven) 06.45.53 Join ender` [0] (krneki@foo.eternallybored.org) 06.48.54 # Hey saratoga I just ran the test_codec after implementing cpu_boost_lock and there is now little to no difference on the decode speeds between with auto_slow and without it 06.57.24 Quit alexweissman (Remote host closed the connection) 06.57.59 Join alexweissman [0] (~alexweiss@c-68-50-12-70.hsd1.in.comcast.net) 06.59.45 Quit alexweissman (Remote host closed the connection) 07.00.00 Join alexweissman [0] (~alexweiss@c-68-50-12-70.hsd1.in.comcast.net) 07.02.15 # no nevermind : 07.14.25 # fuze+ NO auto slow boosted 095.87s 183.61% 247.66Mhz 07.14.25 # boosted 148.49s 118.54% 383.61MHz 07.14.25 # fuze+ No auto slow no boost 416.36s 042.27% 151.40Mhz 07.14.25 # NO boost 568.89s 030.94% 206.85MHZ 07.19.38 Quit Ruhan (Quit: Connection closed for inactivity) 07.30.36 Quit alexweissman (Remote host closed the connection) 07.48.38 *** Saving seen data "./dancer.seen" 07.57.44 # pamaury when you get a chance can you look at http://gerrit.rockbox.org/r/#/c/1699/ and make sure I implemented it properly specifically mutex_init() 08.11.34 Quit _meg (Ping timeout: 240 seconds) 08.13.13 Join _meg [0] (~notsure@211.25.203.45) 08.26.01 Quit deevious (Ping timeout: 260 seconds) 08.46.54 Quit duo8 (Ping timeout: 248 seconds) 08.47.35 Join almog1006 [0] (4d8bf186@gateway/web/freenode/ip.77.139.241.134) 08.54.38 Quit sielicki (Read error: Connection reset by peer) 08.55.31 Join sielicki [0] (~sielicki@unaffiliated/n1cky) 09.03.16 Join deevious [0] (~Thunderbi@193.226.142.214) 09.06.38 Join wodz [0] (~wodz@iwl138.internetdsl.tpnet.pl) 09.25.09 Quit mapache_ (Quit: Lost terminal) 09.48.39 *** Saving seen data "./dancer.seen" 10.08.58 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 10.11.02 # pamaury: Hi.. Thank you very much! I'm done translating the entire firmware 10.12.42 Quit TheEaterOfSouls (Quit: ChatZilla 0.9.93 [Firefox 56.0/20170926190823]) 10.13.28 Join MrZeus [0] (~MrZeus@81.144.218.162) 10.15.55 # almog1006: I haven't made progress on repackin 10.17.36 # Bilgus: I see, indeed I thought the boost code was locking already, and my code is not reentrant 10.17.45 # did that solve the problem? The code looks good to me 10.24.11 Join petur [0] (~petur@rockbox/developer/petur) 10.28.30 # pamaury: However thank you very much for your unpacking tools:) 10.28.35 # Do you have an estimate when you write the repacking codes? 10.29.04 Join PimpiN8 [0] (~textual@145.132.155.235) 10.29.43 # pamaury: Have you got my email? 10.30.33 # wodz: yes thanks 10.30.46 # great 10.31.01 # almog1006: no, I lost my reverse engineering work on the 10.31.15 # code from which I got the unpacker code 10.31.24 # I have version 5.20 somewhere as well if you are interested. 10.31.38 # and there is something wrong with it I think, I will need to re-disassemble it 10.33.00 # pamaury: any progress with amsv2 rom? 10.33.18 # wodz: a bit, but the code is so intricate I only mke baby steps at a time 10.34.00 # pamaury: Does that mean I'm in a big problem? 10.34.07 Join dys [0] (~dys@x5f71e881.dyn.telefonica.de) 10.34.51 # almog1006: That means you need to stimulate pamaury's motivation 10.37.08 # My luck is that he needs it anyway for Rockbox 10.40.11 # almog1006: Not he. I need this tool for my work on atj213x 10.42.09 # So we're in the same boat 10.43.40 # almog1006: The difference is that I have tons of other work before I'll need repacking working. 10.51.26 Quit pamaury (Ping timeout: 240 seconds) 11.30.34 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 11.48.40 *** Saving seen data "./dancer.seen" 13.15.01 Join CH23 [0] (4dfa0218@gateway/web/freenode/ip.77.250.2.24) 13.16.52 # I have in my hands a sandisk cruzer blade 8gb with a NAND chip SDTNPNAHEM-008 13.18.04 # homerun on first try 13.23.53 Join smoke_fumus [0] (~smoke_fum@37.151.179.94) 13.25.12 # I also have a Sandisk cruzer Edge with same NAND 13.28.48 # and finally Sandisk Cruzer Micro with SDTNMNAHSM-004G 13.33.53 # man_in_shack: do you know how long it usually takes for something to ship from your location to mine> 13.36.38 # CH23: Are you going to transplant nand chip from pendrive into clip/clip+/zip ? 13.36.50 # clip+ indeed 13.37.10 # CH23: might be interesting to decap broken nand chip 13.38.13 # how would i do that 13.41.37 # CH23: Its 'a bit' involved process http://zacsblog.aperturelabs.com/2013/02/decapping-integrated-circuits-using.html 13.43.04 # how about i mail it to you instead :P 13.43.59 # CH23: Currently I have no longer access to lab currently :/ 13.44.31 Quit PimpiN8 (Quit: My MacBook has gone to sleep. ZZZzzz…) 13.45.06 # i'm doing all of this on a 9 year old laptop, and soldering stuff for stained glass soldering lol 13.48.44 *** Saving seen data "./dancer.seen" 14.02.22 # the cruzer blade has sandisk files on it dated 24th of august 2011, so this NAND was still used recently. 14.05.13 # cruzer edge is exactly the same 14.24.49 Quit mmint (Ping timeout: 258 seconds) 14.28.33 Join mmint [0] (~mmint@unaffiliated/mmint) 14.35.10 Quit jhMikeS (Ping timeout: 248 seconds) 14.36.55 # CH23: no, but i haven't sent it yet. will send on monday. is friday 11:30pm here now 14.45.50 # Pamaury it seems to have fixed the problem although I did get a hang at some point in testing but that could just be total coincidence as I couldn't reproduce again after. 14.56.16 # Also FWIW the boost code is locking as far as boost_count only boosts on ++0 and unboosts on --1 where as AFAICT the mutex holds the states per thread and doesn't let other threads unboost 14.57.19 # so It might be more like the codec/buffer/audio code is really the issue and it needs to be reworked 14.57.59 # but maybe we just need to implement boost lock across the code 15.00.56 Quit man_in_shack (Ping timeout: 260 seconds) 15.05.36 # I Imagine its still the case that under high load the other devices would probably exhibit the same behaviour 15.08.24 # maybe it would be a better idea to force inline cpu_boost and have it carry a static bool 15.24.45 # huh trigger_cpu_boost is already doing that ??? 15.24.56 Quit wodz (Ping timeout: 264 seconds) 15.26.54 Join man_in_shack [0] (~chat@unaffiliated/man-in-shack/x-4279753) 15.29.58 Join PimpiN8 [0] (~textual@2a02:a454:38ea:1:e4d3:4538:2553:fd81) 15.34.02 Join alexweissman [0] (~alexweiss@c-68-50-12-70.hsd1.in.comcast.net) 15.44.29 # Bilgus: I'm not sure I'm following you 15.45.04 # trigger_cpu_boost works on a per thread basis 15.45.55 # Bilgus: yes but the locking is done at the global level 15.46.05 # but there are several places where cpu_boost is used in the codebase now its ok when it does a boost ##SOME ACTION## unboost 15.46.33 # but for instance in the backlight fading code it has several calls to unboost 15.47.09 # basically at the thread level, you can't nest calls to {trigger,cance}_cpu_boost, the boosting is just a boolean. But then it calls cpu_boost which is global and counts boost/unboost calls and does the locking 15.47.19 # I'm pretty sure it should only be taking one patch from boost to unboost but if it didn't then it would cause the same problem 15.47.40 # sure when you actually use trigger_cpu_boost 15.48.03 # but if you call cpu_boost directly there is no guarantee.. 15.48.13 # you can call cpu_boost directly, it still does the locking and the counting 15.48.13 Quit petur (Remote host closed the connection) 15.48.22 # no 15.48.34 # just look at the code, system.c 15.48.37 # it does count but not lock 15.48.46 *** Saving seen data "./dancer.seen" 15.48.59 # it does, locking is not done in thread.c, it's done in system.c 15.49.15 # in as far as count+ or count- but it doesn't protect the code that has called trigger_cpu_boost 15.49.30 # protect from what? 15.50.13 # ok ill give you a for instance 15.51.13 # I'm in thread foo I call trigger_cpu_boost(true) ok boost_count+=1 ..BC now == 1 15.51.44 # i'm in thread BAR and I call cpu_boost ok BC ==2 15.52.18 # now I call cpu_boost(false) BC = 1 15.52.29 # I call it again BC == 0 15.52.42 # i go back to thread foo oh wait no cpu boost 15.54.03 # now look at https://github.com/Rockbox/rockbox/blob/03dd4b92be7dcd5c8ab06da3810887060e06abd5/firmware/backlight.c 15.54.46 # Bilgus: but that's broken code you are describing. If you call cpu_boost, you must call cpu_unboost. and if you call trigger_cpu_boost then you must call cancel_cpu_boost. 15.55.04 # I'm just pointing out that cpu_boost and trigger_cpu_boost are not the same, they do not do the same thing 15.56.08 # well they do the same thing as in they both call cpu_boost and ++ or -- the counter 15.56.35 # no 15.56.54 # as I explained before, trigger_cpu_boost tracks per thread with a boolean 15.57.17 # https://github.com/Rockbox/rockbox/blob/03dd4b92be7dcd5c8ab06da3810887060e06abd5/firmware/kernel/thread.c#L1501 15.57.25 # so if a thread does: 15.57.25 # trigger_cpu_boost -> BC=1 15.57.25 # trigger_cpu_boost -> BC=1 (because thread was already boosting, it's ignored) 15.57.25 DBUG Enqueued KICK pamaury 15.57.25 # cancel_cpu_boost -> BC=0 15.58.25 # trigger_cpu_boost is per-thread and means "this thread needs to boost now" whereas cancel_cpu_boost means "this thread doesn't need to boost now" 15.58.46 # sure but if you are boosted with trigger and I call cpu_boot(false) 2x you are no longer boosted 15.59.00 # cpu_boost** 15.59.12 # yeah but you don't want to do that, that's the whole point 15.59.23 # I know look at backlight.c 15.59.47 # I don't see a problem, backlight.c first calls cpu_boost(true) then cpu_boost(false). backlight is not per-thread 15.59.51 # and search for cpu_boost 16.00.12 # how many times can cpu_boost(flase) be called? 16.00.16 # false 16.01.02 # counting the occurrences with grep is just wrong, you may have two code paths that call cpu_boost(false) and which are mutually exclusive 16.01.15 # sur elook at the code though 16.02.05 # and? 16.02.57 # if you see a bug in backlight then fix it, I don't know enough about backlight.c to spot a bug 16.04.33 # ok 16.05.09 # cpu_boost(true) is called when the timer is set. when the timer expies, cpu_boost(false) is called. The other cpu_boost(false) is called on BACKLIGHT_FADE_FINISH but when BACKLIGHT_FADE_FINISH is sent, the timer is unregistered 16.05.17 # thus there is no way cpu_boost(false) can be called twice imo 16.05.43 # at least no obvious way 16.09.49 # well its the first that caught my eye esp since the fuze has backlight fading 16.10.29 # the other is audio_path.c which doesn't apply atm and tag cache thats just a mess 16.11.51 Quit smoke_fumus (Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/) 16.12.43 # I mean even if there was a problem with it, that could not cause a hang though, the boost counter would simply be wrong 16.14.02 # which when you are trying to boost to decode a file would not be the best? 16.16.41 # yeah but have you encountered this bug? (after fixing locking) 16.19.49 # no 16.20.08 # but I just don't see how that could actually be it 16.20.44 # I think it is just covering up (making impossible) the real problem 16.20.48 Join petur [0] (~petur@rockbox/developer/petur) 16.21.20 # but if thats true then every device actually needs locking 16.21.47 # and no the backlight one didn't do it 16.25.00 # Bilgus: the locking is done in cpu_boost, I don't see how backlight has anything to do with locking 16.25.19 # locking needs to be done when set_cpu_frequency is not reentrant 16.25.28 # imx233's code was not reentrant 16.26.19 Join amayer [0] (~amayer@24.152.198.8.res-cmts.eph2.ptd.net) 16.28.43 # well I'm sure you know more than I do but I just don't see how that could actually come into effect with trigger_cpu_boost working the way it does? 16.29.45 Join krabador [0] (~krabador@unaffiliated/krabador) 16.46.13 Quit almog1006 (Quit: Page closed) 16.54.15 # Ok I get it I had to think about it for awhile but I think I grasp what you mean 16.56.53 Quit krabador (Remote host closed the connection) 16.59.56 Join Ruhan [0] (uid76353@gateway/web/irccloud.com/x-pobfgbgrzasazfzw) 17.28.04 Join krabador [0] (~krabador@unaffiliated/krabador) 17.46.18 Quit PimpiN8 (Quit: My MacBook has gone to sleep. ZZZzzz…) 17.48.50 *** Saving seen data "./dancer.seen" 18.06.23 Quit pamaury (Ping timeout: 248 seconds) 18.18.26 Quit krabador (Ping timeout: 240 seconds) 18.34.47 Join TheLemonMan [0] (~lemonboy@irssi/staff/TheLemonMan) 18.41.56 Quit sparetire (Ping timeout: 240 seconds) 18.44.52 Join sparetire [0] (~sparetire@unaffiliated/sparetire) 19.15.46 Join detectiveaoi [0] (~detective@130.218.12.236) 19.16.14 Quit detectiveaoi (Remote host closed the connection) 19.18.59 Join krabador [0] (~krabador@unaffiliated/krabador) 19.38.54 Quit michaelni (Read error: Connection reset by peer) 19.42.33 Join lebellium [0] (~chatzilla@89-93-177-206.hfc.dyn.abo.bbox.fr) 19.48.54 *** Saving seen data "./dancer.seen" 19.55.28 Join michaelni [0] (~michael@213-47-41-20.cable.dynamic.surfer.at) 20.05.26 Quit dys (Ping timeout: 240 seconds) 20.12.24 Quit TheLemonMan (Quit: "It's now safe to turn off your computer.") 20.13.53 Join dys [0] (~dys@x5f71d060.dyn.telefonica.de) 20.28.33 Quit dys (Ping timeout: 255 seconds) 20.42.49 Quit bzed (Remote host closed the connection) 20.43.04 Join bzed [0] (~bzed@shell.bzed.at) 20.51.38 Join p3tur [0] (~petur@78-23-23-252.access.telenet.be) 20.51.38 Quit p3tur (Changing host) 20.51.38 Join p3tur [0] (~petur@rockbox/developer/petur) 20.56.55 Join dys [0] (~dys@x5f72797e.dyn.telefonica.de) 21.48.57 *** Saving seen data "./dancer.seen" 22.20.57 Quit krabador (Quit: Leaving) 22.36.23 # <__builtin> user890104: ok, thanks! 22.36.32 # <__builtin> it's timer A on the 6G, it seems 22.38.20 # <__builtin> I think I should be able to control it directly, though 22.39.10 # <__builtin> the pin is P0_0, which supports GPIO 22.39.30 Quit amayer (Quit: Leaving) 22.41.44 # <__builtin> this datasheet is nice :) 23.02.09 Quit The_Prospector (Quit: when in doubt, kernel panic) 23.05.12 Join The_Prospector [0] (~The_Prosp@unaffiliated/cornman) 23.13.28 Join jhMikeS [0] (~jethead71@d192-24-173-177.try.wideopenwest.com) 23.21.38 # <__builtin> ah, figured it out 23.48.58 *** Saving seen data "./dancer.seen" 23.58.34 Quit lebellium (Quit: ChatZilla 0.9.93 [Firefox 56.0/20170926190823])