<mtthwmeyer[m]> I released my libdaisy crate https://crates.io/crates/libdaisy 🎉
<richarde1> mtthwmeyer[m]: nice!
richarde1 is now known as richardeoin
kevlan[m] has quit [Quit: Idle for 30+ days]
<dirbaio[m]> > Bits 24, 18, 8, 2 DMEIFx: Stream x direct mode error interrupt flag (x=3..0)
<dirbaio[m]> they're not evenly spaced! why, st, WHY?!
<dirbaio[m]> what do I do lol
<dirbaio[m]> add support for "cursed arrays" where indices can be anything? 😂
<thalesfragoso[m]> Hmm, I see you're going to play with DMA with your meta-pac, do you plan to do a per peripheral thing or something like the current HAL ?
<dirbaio[m]> no idea yet
<dirbaio[m]> but I guess reusing code for setting up the transfers
<dirbaio[m]> and awaiting them (?)
<thalesfragoso[m]> I think the HAL approach is interesting, but I still need to work on it to try to reduce monomophirzation
<thalesfragoso[m]> Today, it's far from great
<thalesfragoso[m]> It's easier to use and hard to mis-use, but the codegen might not be ideal
<dirbaio[m]> because macros :D
<dirbaio[m]> and macros are because there's no way to arrayify these damn registers :S
<thalesfragoso[m]> Not sure if that is the bigger problem on the DMA code right now, since the traits methods (that use macros) are pretty much all just one register access anyway
<thalesfragoso[m]> But then the methods on Transfer that really setup stuff are the problem
<thalesfragoso[m]> But yeah, meta-pac might be able to make things easier
<thalesfragoso[m]> There are a lot of generic parameters on transfer, and I didn't do a good job on creating free functions to do all the work instead of doing in the methods
<thalesfragoso[m]> But I think I can make things better, and I plan to
<thalesfragoso[m]> Hmm, thinking if I can pull off a chess clock with with 4kB of RAM and embassy, the idea was to use two of those ssd1306 oled, which eats 2kB already...
<thalesfragoso[m]> What do you think dirbaio ?
<thalesfragoso[m]> 16kB flash and 4kB RAM
<dirbaio[m]> uuh very tight (with and without embassy) lol
<thalesfragoso[m]> Maybe I can do terminal mode on those displays using big letters, hmm
<thalesfragoso[m]> Otherwise I will jump from the F030 to the F103
<thalesfragoso[m]> The idea is to use the meta-pac as I go, so I hope I can implement a few things and re-use some between the F0 and F1 if needed
<dirbaio[m]> =D
<thalesfragoso[m]> Although I think they use different peripheral versions, hmm
<dirbaio[m]> xISR and xIFCR are so weird
<dirbaio[m]> it's like they split the 32bit reg in 2x 16bit regs and packed each half independently, wtf
<dirbaio[m]> oh well, let's add support for irregular arrays
<dirbaio[m]> >_<
<dirbaio[m]> * >_<
<dirbaio[m]> * .... >_<
<thalesfragoso[m]> Heh, go for it :) I will need DMA to implement the i2c driver
<dirbaio[m]> svd doesn't support irregular arrays right?
<thalesfragoso[m]> Btw, great job dirbaio, I don't think I thank you enough
<dirbaio[m]> =D thanks!
<dirbaio[m]> it's early to know if it'll be any good tho :S
<dirbaio[m]> and it's going to be slow because I don't do stm32 stuff on company time
<thalesfragoso[m]> Nah, I'm pretty sure it will be good
<thalesfragoso[m]> <dirbaio[m] "and it's going to be slow becaus"> That's fine, make sure to take real breaks from time to time though :)
<dirbaio[m]> yea... ðŸĪĢ
<dirbaio[m]> pandemic-driven development
<dirbaio[m]> ðŸĪ” 😂
kevlan[m] has joined ##stm32-rs
<yatekii[m]> <thalesfragoso[m] "16kB flash and 4kB RAM"> how is this too little? people did stuff like this on 8b cpus with even less resources?
<yatekii[m]> well ok, maybe with less resolution on the display :D
<therealprof[m]> <thalesfragoso[m] "16kB flash and 4kB RAM"> Tough challenge but not impossible. My MCUmeter firmware clocks in at 15,2kB.
<thalesfragoso[m]> Yeah, it's 2*1024 of frame buffers, I probably can do without it though
<yatekii[m]> isn't it mostly static frames?
<yatekii[m]> aka just numbers you stream out to twi?
<yatekii[m]> which you could do from a buffer in ram. except with nrfs :D
<therealprof[m]> I wouldn't be worried about the framebuffer. RAM is usually plenty unless you do async stuff. 😛
<thalesfragoso[m]> You can with nrf, you can't from flash
<thalesfragoso[m]> <therealprof[m] "I wouldn't be worried about the "> It will be async, statically allocated, heh
<yatekii[m]> <thalesfragoso[m] "You can with nrf, you can't from"> that's what I mean :) if you just stream the pixel data from flash directly you wont need a framebuffer :)
<therealprof[m]> Yes and no.
<dirbaio[m]> I guess you can render one display, send it, render the other, send it?
<dirbaio[m]> so you only need 1 framebuffer?
<therealprof[m]> SSD1306 has a framebuffer, unfortunately it's write only.
<therealprof[m]> So unless you are good with always clocking out full frames you'll need a framebuffer.
<yatekii[m]> well I do not see why you need to render :/
<therealprof[m]> In addition it's monochrome so 1 byte of data equals 8 pixels.
<thalesfragoso[m]> > <@dirbaio:matrix.org> I guess you can render one display, send it, render the other, send it?
<thalesfragoso[m]> > so you only need 1 framebuffer?
<thalesfragoso[m]> That would need some bigger changes in the driver, but I will have to change it anyway
<therealprof[m]> Heh.
<yatekii[m]> you can just iterate through the pixels of each number and send blanks inbetween for padding without ever copying into a buffer
<thalesfragoso[m]> No hard requirement for it to fit on the F030, tbh
<yatekii[m]> if you wanna have fancy text or the likes it's harder ofc
<thalesfragoso[m]> I'm just curious, I will only make one :)
<yatekii[m]> (I was assuming a simple chess clock)
<thalesfragoso[m]> And I have plenty of F103 blue pills
<therealprof[m]> <yatekii[m] "you can just iterate through the"> ?
<yatekii[m]> <therealprof[m] "?"> nvm
<thalesfragoso[m]> And maybe I want to print some hearts or stuff
<therealprof[m]> This display controller is a double whammy, you can't read back and you can't set inidividual pixels.
<therealprof[m]> * This display controller is a double whammy, you can't read back and you can't set individual pixels.
<thalesfragoso[m]> But for sure I need to change the driver to take the framebuffer as &mut instead of creating its own
<thalesfragoso[m]> With 4kB of RAM and paying double for the frame buffer, my stack wouldn't be no more
<therealprof[m]> Yeah, if you have a RAM eater in your application... Most of my applications only use like 100bytes of RAM. On one I application I decided to fill up the whole 4kB of RAM with lookup tables -- because, why not...
<jamwaffles[m]> I've been thinking about this for a while
<jamwaffles[m]> I'd love to find an API solution that allows both "just give me a display with a framebuffer idc" as well as being able to pass in the framebuffer
<jamwaffles[m]> The other option is to not support a framebuffer at all and draw chunks from iterators
<jamwaffles[m]> But I don't know if a framebuffer is a feature some people actually want
<thalesfragoso[m]> I think framebuffers are cool
<therealprof[m]> Yeah, sometimes it would be nice to just pass in the chunks.
<therealprof[m]> If you know what to draw you really don't need the framebuffer.
<thalesfragoso[m]> But, unfortunately you probably need to take it as a reference, to not use double the RAM
<therealprof[m]> <thalesfragoso[m] "I think framebuffers are cool"> The nasty thing here is: There're actually 2 framebuffers, one in your RAM and one in the display driver itself; you just can't read it out.
<therealprof[m]> <thalesfragoso[m] "But, unfortunately you probably "> jamwaffles is talking about an immediate drawing mode.
<thalesfragoso[m]> Yeah, I get it, I was talking about the current drawing mode though
<thalesfragoso[m]> Unfortunately, NRVO in rust isn't that good yet, so if you create large structs and want to place them in statics you better have a const constructor
<therealprof[m]> Right, but instead of changing the driver to use a framebuffer but in a completely different way; maybe implementing another mode would be a good idea. 😉
<thalesfragoso[m]> Yeah, seems like a good idea, even it's capable of replacing the old method completely
<thalesfragoso[m]> But not sure if it's the case, once I used a modified version of the ssd1306 crate to use the frame buffer as my tetris field
<thalesfragoso[m]> So I needed to read it to see if the pieces would collide
<thalesfragoso[m]> Although I guess I could just use use my own frame buffer in that case
<thalesfragoso[m]> Since it the driver wouldn't have it anymore
<thalesfragoso[m]> Yeah, seems okay
<dirbaio[m]> so, what f1 calls "channels", f4 calls "streams"? what
<therealprof[m]> The tricky part is, you can't simply do the simple pixel iterators because you have to set multiple of 8 pixels at once.
<thalesfragoso[m]> <dirbaio[m] "so, what f1 calls "channels", f4"> Something like that, f4 still have channels, but streams are more like the channels of the F1
<thalesfragoso[m]> IIRC
<dirbaio[m]> the fuck st ðŸĪŠ
<dirbaio[m]> everyone calls these things "channels"
<thalesfragoso[m]> I guess they needed two names, but yeah, far from consistent
<jamwaffles[m]> <therealprof[m] "The tricky part is, you can't si"> SSD1306 would need a 128byte chunk buffer (max) to stream out each set of 8 rows. Still a decent chunk of memory but not 1KB at least
<dirbaio[m]> why not stick with channels and name the other thing something else? "source", "connection"???
<dirbaio[m]> :(
<therealprof[m]> <jamwaffles[m] "SSD1306 would need a 128byte chu"> Huh? You can draw at random locations IIRC.
<jamwaffles[m]> I meant if you wanted to emulate framebuffer-like behaviour using less memory
<jamwaffles[m]> I think there's a bit of complexity around 8 Y pixels being one byte though, so drawing randomly isn't so easy
<therealprof[m]> That's pretty much the only complexity. If you know what to render on the screen for each frame it should be easy to do without any RAM based framebuffer. You can also select between row based or column based addressing so if one is a better fit.
<jamwaffles[m]> Ye true
<therealprof[m]> But the 8 pixel at once is super annoying and thwarts any simple implementation... might be worth going color just because of that. 😀