--- Log for 30.03.123  Server: iridium.libera.chat  Channel: #rockbox
--- Nick: rb-logbot  Version: Dancer V4.16  Started: 3 days and 11 hours ago

00.37.11 Quit    m01 (Quit: Konversation terminated.)
00.39.33 Join    m01 [0] (~quassel@vps-b172b88b.vps.ovh.net)
01.19.14 ***     Saving seen data "./dancer.seen"
01.27.04 Join    othello7 [0] (~Thunderbi@pool-100-36-166-8.washdc.fios.verizon.net)
02.01.24 Quit    othello7 (Ping timeout: 255 seconds)
03.19.17 ***     Saving seen data "./dancer.seen"
04.18.08 Quit    jacobk (Ping timeout: 248 seconds)
04.24.18 Quit    cnx (Remote host closed the connection)
04.25.05 Join    cnx [0] (~cnx@2a03:3b40:100::1:2)
05.19.18 ***     Saving seen data "./dancer.seen"
06.59.06 #       <buZz> the mcu is more powerful yeah
06.59.13 #       <buZz> but the interfaces arent really :)
06.59.37 #       <buZz> if you dont need 'native ram' you dont need to use that PSRAM stuff, there's people who hooked up '30 pin simms' to it and just used that
06.59.50 #       <jssfr> yeah, I looked into the ESP32 a few weeks back and came to the same conclusion (re RAM availability).
07.00.12 #       <buZz> like this person did with a AVR mcu; http://dangerousprototypes.com/blog/2012/03/29/running-linux-on-a-8bit-avr/
07.00.25 Quit    Romster (Ping timeout: 265 seconds)
07.00.53 Join    Romster [0] (~romster@202-169-118-85.ip4.superloop.au)
07.03.37 #       <buZz> https://web.archive.org/web/20150605062417/http://dmitry.gr/index.php?r=05.Projects&proj=07.%20Linux%20on%208bit
07.04.05 #       <buZz> they used a 16MB simm, yet that mcu cant address it natively :)
07.19.20 ***     Saving seen data "./dancer.seen"
08.10.07 #       <speachy> lizzie: the SoC in the sansa devices was a full-featured SoC capable of running a real OS, needing only external DRAM.  
08.10.34 #       <speachy> the BT and wifi stuff was handled by a completely separate module (with its own embedded processor) that handles all the protocol and even TCP/IP stuff.
08.11.10 #       <speachy> so you tell it to connect to network X, establish a TCP connection to <Whatever> and all you have to worry about is sendng data back and forth to a logical endpoint.
08.12.10 #       <speachy> buZz: a large-package STM32 part will work nicely; there are cheap chinesium boards out there that have 8M or 16M DRAM onboard, with a metric f-ton of I/Os.
08.12.50 #       <speachy> but just teh MCU alone costs more than an RPI Zero.  :(
08.14.11 #       <speachy> native rockbox (or heck, even hosted) rockbox on an RPI Zero would be ludicrously capable, it's just that the RPI Zero doesn't lend itself well towards a sane power/battery management solution.
08.15.10 #       <speachy> plus of course the problem of physical enclosures.  A sane enclosure is the main thing holding back an effort to build one ourselves.
08.15.30 #       <speachy> because tooling is a significant up-front cost.
08.15.49 #       <buZz> if only 3d printers existed eh
08.16.22 #       <speachy> would be good for a prototype only; they don't work well for fine-ish detail, which is what you'd need for decent buttons and the like.
08.16.34 #       <buZz> yeah most ppl indeed dont care about finish
08.16.44 #       <buZz> so 3d printed prototypes are often just 'finished product'
08.16.56 #       <speachy> ....not for something that you're constantly touching
08.17.04 #       <buZz> case in point; anyone making a DIY mp3 player doesnt want to make 18971283748237897232 mp3 players
08.17.30 #       <buZz> speachy: i use 3d printed object all the time, i'm not sure what you're on about :D
08.17.46 #       <buZz> you can -sand- prints too if you're so worried about surface finish :)
08.17.50 #       <speachy> it's labor intensive
08.17.56 #       <buZz> oh boohoo :D
08.18.05 #       <buZz> and making a mp3 player yourself isnt :D
08.18.11 Quit    JanC (Ping timeout: 264 seconds)
08.18.19 #       <jssfr> fwiw, I'd totally build meself a rockbox player if I could. living off second hand is going to only go well for so long
08.18.34 #       <jssfr> but I haven't found a SoC whose architecture I'm familiar enough with that I'd dare
08.18.46 #       <speachy> I'm coning at this from a product that one has a realistic chance of at least breaking even, _including_ labor costs.
08.18.50 #       <jssfr> (I only know STM32 well, I'm interested which SoCs you found there which would be viable, speachy)
08.19.01 #       <buZz> speachy: right, not the topic then :D
08.19.05 #       <jssfr> :-)
08.19.24 #       <buZz> stm32f1 i guess :D if its so expensive
08.19.25 #       <speachy> the current high-end STM32s (H series0 are pretty sweet.
08.19.31 #       <jssfr> stm32f1 is cheap, isn't it
08.19.44 #       <jssfr> those seemed all unviable, those were those I checked because I know the F103 pretty well
08.19.45 #       <speachy> F1 is quite cheap but I don't think it's going to have enough oommh to be viable.
08.20.25 #       <speachy> I we'd need an F3/F4 minumim (as that would get us to, what, 192MHz vs 64/72 max for the F1)
08.21.31 #       <speachy> we'd want a part with enough onboard RAM to hold a complete framebuffer, display drawing, and codec code.
08.22.28 #       <speachy> the F3/F4 has much faster onboard flash than F1 too, capable of zero-wait-state operation
08.22.37 #       <buZz> doesnt rockbox have a 1bit videomode too?
08.22.47 #       <buZz> 1bit framebuffers take a lot less ram :)
08.23.17 #       <speachy> so we could probably only leave the codec plugins (and framebuffers) loaded into IRAM, leaving the rest of the code elsewhere.
08.23.30 #       <speachy> (== flash)
08.24.58 #       <buZz> yeah execute-in-place, or whatever its called
08.25.08 #       <speachy> jssfr: the STM32s are my favorite MCUs.  they're quite a bit less ... questionably quirky than their competition, their docs are good, and bakc in the day they supplied peripheral libraries you could use instead of an all-singing IDE+HAL.
08.25.36 #       <buZz> i kinda love the TM4C line from TI
08.25.54 #       <buZz> kinda doubt ST has more documentation that TI, they publish -so much-
08.27.08 #       <jssfr> speachy, yes, that mirrors my experience with them exactly
08.32.38 #       <speachy> as long as it's not a Motorola/Freescale/NXP part.  Just thinking about those docs makes my blood pressure go up.
09.19.22 ***     Saving seen data "./dancer.seen"
09.31.49 #       <rb-bluebot> Build Server message: 3New build round started. Revision 2456d28e21, 303 builds, 9 clients.
09.31.49 #       <rb-bluebot> 3[BugFix] open_plugin didn't recognize opx shortcuts by William Wilgus
09.32.20 #       <jssfr> my hacking order goes STM32* > AT{mega,tiny}* > everything else.
09.41.23 Quit    tchan (Ping timeout: 260 seconds)
09.46.12 #       <_bilgus_> could you do ram bank switching to expand that esp32 couldn't you?
09.52.03 #       <speachy> _bilgus_: I don't think so; the limitation is in the PSRAM controller on the ESP32.
09.52.10 #       <rb-bluebot> Build Server message: 3Build round completed after 1221 seconds.
09.52.11 #       <rb-bluebot> Build Server message: 3Revision 2456d28e21 result: All green
09.52.24 #       <_bilgus_> https://github.com/platformio/platform-espressif32/issues/185
09.52.26 #       <speachy> ...is that the first build on the new server?  
09.52.49 #       <_bilgus_> mybe the second
09.52.56 #       <speachy> and one of my builders isn't running.  let me fix that.
09.56.21 #       <speachy> and the outbound email didn't happen. hmm.
10.00.32 #       <speachy> didn't go out to twitter either.  manually invoking the script sorta worked, makes me think the hook script barfed.
10.04.20 Join    tchan [0] (~tchan@c-98-206-114-113.hsd1.il.comcast.net)
10.04.45 #       <speachy> hmm, don't know wtf is going on with this.  will have to monitor things.
10.06.15 #       <_bilgus_> bad permissions?
10.14.02 #       <_bilgus_> re the ESP32 bank switching found the ref sketch its called himem https://github.com/espressif/esp-idf/tree/master/examples/system/himem
10.17.08 Join    JanC [0] (~janc@user/janc)
10.27.08 Join    othello7 [0] (~Thunderbi@pool-100-36-166-8.washdc.fios.verizon.net)
11.01.29 Join    jacobk [0] (~quassel@64.189.201.150)
11.17.46 #       <speachy> regardless, I don't think we're going to be able to take advantage of bank switching without a lot of pain; we assume a flat address space.
11.18.20 #       <speachy> permissions are ok, the first of three scripts referenced from the commit hook ran successfully.
11.18.38 #       <speachy> I manually invoked the others and they "worked"
11.19.25 ***     Saving seen data "./dancer.seen"
11.22.26 #       <speachy> huh, maybe it's an SELinux permission thing.  checking now.
11.49.03 Quit    othello7 (Quit: othello7)
11.59.03 Join    lebellium [0] (~lebellium@2a01cb040109a60044dcd4a7afdf37a9.ipv6.abo.wanadoo.fr)
12.03.01 Quit    zem (Ping timeout: 240 seconds)
12.06.48 Join    hactar|ant [0] (~zem@c-71-59-213-215.hsd1.or.comcast.net)
12.08.08 Quit    jacobk (Quit: No Ping reply in 180 seconds.)
12.09.46 Join    jacobk [0] (~quassel@64.189.201.150)
12.14.24 Quit    jacobk (Ping timeout: 248 seconds)
13.19.27 ***     Saving seen data "./dancer.seen"
13.28.35 Nick    launchd is now known as l (launchd@bitbot/launchd)
13.35.37 Join    othello7 [0] (~Thunderbi@pool-100-36-166-8.washdc.fios.verizon.net)
14.20.21 Join    jacobk [0] (~quassel@64.189.201.150)
15.19.31 ***     No seen item changed, no save performed.
15.24.22 Quit    jacobk (Ping timeout: 252 seconds)
15.29.49 Nick    l is now known as launchd (launchd@bitbot/launchd)
15.37.22 Join    jacobk [0] (~quassel@utdpat242068.utdallas.edu)
15.47.07 Quit    jacobk (Ping timeout: 276 seconds)
16.35.23 Quit    TorC (Ping timeout: 248 seconds)
17.02.48 Join    TorC [0] (~Tor@fsf/member/TorC)
17.19.34 ***     Saving seen data "./dancer.seen"
17.33.04 Quit    Romster (Ping timeout: 276 seconds)
17.34.48 Join    Romster [0] (~romster@202-169-118-85.ip4.superloop.au)
17.47.17 Quit    lebellium (Quit: Leaving)
17.48.36 Join    troglodito [0] (~cave@81.4.123.134)
18.08.23 Quit    rb-bluebot (Ping timeout: 265 seconds)
18.08.38 Quit    bluebrother (Ping timeout: 268 seconds)
18.09.48 Join    bluebrother [0] (~dom@user/bluebrother)
18.22.20 Join    rb-bluebot [0] (~rb-bluebo@rockbox/bot/utility)
18.39.03 Join    massiveH [0] (~massiveH@2600:4040:a99f:1f00:6529:c318:b6ae:2f5)
19.01.45 Quit    Romster (Ping timeout: 260 seconds)
19.03.33 Join    Romster [0] (~romster@202-169-118-85.ip4.superloop.au)
19.19.37 ***     Saving seen data "./dancer.seen"
21.19.41 ***     No seen item changed, no save performed.
21.28.59 Quit    Ckat (Ping timeout: 264 seconds)
21.29.53 Join    Ckat [0] (~Ckat@xn--z7x.xn--6frz82g)
21.44.54 Quit    rb-bluebot (Ping timeout: 255 seconds)
21.45.02 Quit    bluebrother (Ping timeout: 250 seconds)
21.45.10 Join    jacobk [0] (~quassel@utdpat241106.utdallas.edu)
21.46.39 Join    bluebrother [0] (~dom@user/bluebrother)
21.57.38 Quit    massiveH (Quit: Leaving)
21.59.40 Join    rb-bluebot [0] (~rb-bluebo@rockbox/bot/utility)
22.08.40 Quit    jacobk (Ping timeout: 276 seconds)
22.18.49 Join    jacobk [0] (~quassel@utdpat241106.utdallas.edu)
22.24.03 Quit    othello7 (Quit: othello7)
22.24.19 Join    othello7 [0] (~Thunderbi@pool-100-36-166-8.washdc.fios.verizon.net)
22.32.36 Quit    othello7 (Ping timeout: 255 seconds)
22.38.40 Quit    troglodito (Read error: Connection reset by peer)
22.39.50 Join    troglodito [0] (~cave@81.4.123.134)
22.40.31 Quit    jacobk (Ping timeout: 252 seconds)
23.19.46 ***     Saving seen data "./dancer.seen"
23.32.14 Join    jacobk [0] (~quassel@64.189.201.150)
23.41.36 Quit    jacobk (Ping timeout: 250 seconds)
23.50.59 Join    jacobk [0] (~quassel@64.189.201.150)