<re_irc>
For ESP32, I do get the board info "espflash board-info", however, when flashing it shows me "Error: espflash::connection_failed ... ╰─▶ Serial port not found"
<re_irc>
Any clues why this is happening? It seems related to my local setup even though I have udev rules for both boards.
<re_irc>
< (@jamesmunns:beeper.com)> I guess for a quick test if it's udev related, does a "sudo probe-run --list-probes" show the probe as attached?
<re_irc>
< (@jamesmunns:beeper.com)> Also, what hardware are you using as a debugger? with probe run, you usually have:
<re_irc>
- The chip you are debugging, e.g. your "target"
<re_irc>
- The board you are using as an SWD adapter
<re_irc>
I know there are some things for the rp2040 to use one chip to flash another, or even use one CPU to flash the other, but what kind of hardware config do you have?
<re_irc>
< (@jamesmunns:beeper.com)> Are you using a debugger?
<re_irc>
<elpiel> hardware config - just the PICO, not sure about the debuger
<re_irc>
<elpiel> * debugger
<re_irc>
< (@jamesmunns:beeper.com)> Gotcha - "probe-run" generally requires an SWD/JTAG debugger - it's a piece of hardware that plugs into the three debug pins at the end of the pico
<re_irc>
< (@jamesmunns:beeper.com)> I think there's a project that puts a "virtual" debugger using the USB and one of the cores of the pico, but I'm not too familar with it. Maybe someone else here knows
<re_irc>
< (@jamesmunns:beeper.com)> The other tool your using uses the uf2 bootloader to flash a new image - but (afaik) probe-run doesn't work with that.
<Darius>
if you have a second pico you can load a debugger onto that and wire it to the first, works well IME
<re_irc>
< (@jamesmunns:beeper.com)> * you're
IlPalazzo-ojiisa has joined #rust-embedded
<re_irc>
< (@ubik:matrix.org)> pico-probe works fine also in my own experience
<re_irc>
< (@ubik:matrix.org)> BTW, we should probably have a page somewhere with probe suggestions? That's one thing which, as I was dipping my toes into rust embedded dev, I wish I had known more about. I initially bough an ST-link, which ended up being more expensive and harder to use than the CMSIS-DAP cheapo probe I now use.
<re_irc>
< (@ubik:matrix.org)> Plus ST-link will only work on ST chips 😡
<re_irc>
< (@ubik:matrix.org)> BTW, we should probably have a page somewhere with probe suggestions? That's one thing which, as I was dipping my toes into rust embedded dev, I wish I had known more about. I initially bought an ST-link, which ended up being more expensive and harder to use than the CMSIS-DAP cheapo probe I now use.
<re_irc>
< (@jamesmunns:beeper.com)> I bought a stack of the cheapo "High quality DAPLINK" boards for 2.50EUR/ea, it's nice to basically have them around for each project
<re_irc>
< (@jamesmunns:beeper.com)> Only downside is that I think they basically all report the same serial number, which makes using multiple at once pretty impossible
<re_irc>
< (@jamesmunns:beeper.com)> I have hex-edited the firmware before tho, when I was using black pill boards for the same purpose
<re_irc>
< (@jamesmunns:beeper.com)> Might be habit, but the AER list is usually still the first place I check.
<re_irc>
< (@jamesmunns:beeper.com)> https://lib.rs/embedded is a lot better for discovery these days than crates io is, but honestly I (personally) like the AER list :)
<re_irc>
<Félix | Totem> As a noob, the hardest part in embedded, IMO, is the ton of acronyms everywhere. Tho base concepts are simple, but half of the types / consts have a cryptic name.
<re_irc>
<Félix | Totem> * The
<re_irc>
< (@ubik:matrix.org)> : Which one, if I may ask?
<re_irc>
< (@jamesmunns:beeper.com)> From a store called "wavegat"
<re_irc>
< (@jamesmunns:beeper.com)> Can vouch for basic SWD and UART functionality, at least. I haven't tried pushing them especially hard.
<re_irc>
< (@jamesmunns:beeper.com)> Félix | Totem: I think this is a common problem in software
<re_irc>
< (@jamesmunns:beeper.com)> when you're new (to a lang, library, concept), you want long, descriptive names. When you deal with it every day, you want short, out of the way names.
<re_irc>
<Félix | Totem> Do you know why I must "constrain" all the device parts in the cortex rtic crate? Like "ctx.device.FLASH.constrain().<etc.>"
<re_irc>
< (@jamesmunns:beeper.com)> the "?" macro went through a whole thing where people wanted the much longer "try!"
<re_irc>
< (@jamesmunns:beeper.com)> Félix | Totem: These are "extension traits"
<re_irc>
<Félix | Totem> : I swear that it's much worse with embedded 😓
<re_irc>
< (@jamesmunns:beeper.com)> they are falling out of style a little bit, the idea was to have a trait that "extended" the PAC struct to make a HAL struct
<re_irc>
<Félix | Totem> : Do you mean that there is a framework which is more up-to-date?
<re_irc>
< (@jamesmunns:beeper.com)> "pac_uart.constrain()" is roughly equivalent to "HalUart::new(pac_uart)", if that helps
<re_irc>
<Félix | Totem> : Oh, I didn't know that page, thanks.
<re_irc>
< (@jamesmunns:beeper.com)> but PAC stands for "Peripheral Access Crate". It's the raw, register-level definitions for a chip. The HAL, or Hardware Abstraction Layer, is higher level.
<re_irc>
< (@jamesmunns:beeper.com)> PAC: "put this 32-bit word at this address"
<re_irc>
HAL: "Send these 8 bytes over the serial port".
<re_irc>
< (@jamesmunns:beeper.com)> PAC is the "raw HAL", and HAL is "the software drivers"
<re_irc>
< (@jamesmunns:beeper.com)> RTIC (or embassy) would be your "task and resource libraries", soooorta comparable to an RTOS
<re_irc>
< (@jamesmunns:beeper.com)> PACs are equivalent to the "register definition headers" in C/C++
<re_irc>
< (@ubik:matrix.org)> : Thanks! Looks better than mine and it's USBC
<re_irc>
< (@jamesmunns:beeper.com)> yeah! I finally lost/broke the set of like five knockoff stlinks that I had been using for a couple years
<re_irc>
< (@ubik:matrix.org)> Which chip is it?
<re_irc>
< (@jamesmunns:beeper.com)> I have a nice jlink, but I am super adhd, and usually have 4-5 projects in various states of "done" at any given time, so it's nice to be able to leave a debugger attached to a project
* Darius
has a blackmagic probe - they're very nice
<re_irc>
< (@jamesmunns:beeper.com)> : Theoretically the stm32f103? But it wouldn't surprise me if it was a clone in actuality
<re_irc>
< (@ubik:matrix.org)> The one with 64K or 128K?
<re_irc>
< (@jamesmunns:beeper.com)> No idea
<re_irc>
< (@ubik:matrix.org)> Cause mine is the former and I can't find newer firmware for it
<re_irc>
<jdtaylor311> Hey everyone,
<re_irc>
Im new to rust and embedded. Currently reading through the Rust book right now, but im also looking to embedded systems so I was wondering if anyone had any recommendations for embedded reading material? I have Making Embedded Systems on the list, the art of electronics so I can learn more about electronics, and embedded systems architecture. Any other good reads you guys could recommend?
<re_irc>
< (@firefrommoonlight:matrix.org)> datasheets and ref mans
<re_irc>
< (@firefrommoonlight:matrix.org)> I concur that AoE is oustanding, although it's fine as a ref if you don't want to read the whole thing
<re_irc>
< (@firefrommoonlight:matrix.org)> *Reading the whole thing will probably be a lot of forgotten material if you don't have practical context for the material. But then if you have a problem or are building something, the relevant sections will make sense and you'll learn
<re_irc>
< (@firefrommoonlight:matrix.org)> The Art of doing Science and Engineering by Hamming is nice
<re_irc>
< (@firefrommoonlight:matrix.org)> For big-picture context
<re_irc>
<jdtaylor311> : Awesome! Thank you!
<re_irc>
<Félix | Totem> I can turn a led on with RTIC on my keyboard. Not sure what the next step can be. Should I straight jump in the matrices stuff?
<re_irc>
<Félix | Totem> I can turn a led on with RTIC on my keyboard. Not sure what the next step can be. Should I jump straight into the matrices stuff?
<re_irc>
< (@jamesmunns:beeper.com)> Félix | Totem: Being able to read the keys is probably a good bet! Did you get the USB serial stuff working too?
<re_irc>
<Félix | Totem> : Nope, but I dunno what I can do to test that. Seeing a LED on is straightforward, how can I test that the USB uses the correct protocol?
<re_irc>
< (@jamesmunns:beeper.com)> I dunno!
<re_irc>
But you could pick a key on the left side, one at a time, and only light up if that one is pressed
<re_irc>
< (@jamesmunns:beeper.com)> Or at least, make sure you can do a few, to verify the layout makes sense, like "1" and "v"
<re_irc>
<Félix | Totem> The idea is that I connect an interrupt on some input (the key line) then when the interrupt is fired, I turn the led on in the callback, right'
<re_irc>
<Félix | Totem> * right?
<re_irc>
< (@jamesmunns:beeper.com)> Once you're pretty sure you have the row/column stuff right, I'd say integrate keyberon
<re_irc>
< (@jamesmunns:beeper.com)> Félix | Totem: Probably more like, once a millisecond, do the scan
<re_irc>
< (@jamesmunns:beeper.com)> You can't exactly use interrupts, because you need to do the row/column scanning
<re_irc>
<Félix | Totem> IIRC, the columns are the output, but the rows are the input, so I thought they must interrupts.
<re_irc>
< (@jamesmunns:beeper.com)> (this isn't TOTALLY true, but a useful simplification, but I can explain if you want)
<re_irc>
<Félix | Totem> * could
<re_irc>
< (@jamesmunns:beeper.com)> Check out that link that shared, it gives a graphical demo of how the inputs and outputs work
<re_irc>
< (@jamesmunns:beeper.com)> You set one output (column) high at a time, and see if any of the corresponding inputs (rows) goes high
<re_irc>
<Félix | Totem> OK, that's how it works. I thought the the row would interrupt after the signal is high.
<re_irc>
< (@jamesmunns:beeper.com)> You CAN set all columns high, then interrupt if a row goes high, but that only tells you if SOMETHING was pressed, not exactly which key
<re_irc>
<Félix | Totem> So, at the beginning, I can set one column always on, then I listen on the rows.
<re_irc>
< (@k900:0upti.me)> If you do that, you won't know if something was pressed on the other columns
<re_irc>
< (@jamesmunns:beeper.com)> But easier to do something like "wake up every millisecond, do a full scan, note what is pressed, go back to sleep"
<re_irc>
<Félix | Totem> : What I meant is that I can set the columns high one after the other, register which one is on, and then when there is a row interrupt, I can read which column is high to get the key
<re_irc>
< (@k900:0upti.me)> It's usually easier to just poll continuously
<re_irc>
< (@k900:0upti.me)> Félix | Totem: At that point you might as well just read the rows directlt
<re_irc>
< (@k900:0upti.me)> * directly
<re_irc>
< (@k900:0upti.me)> Since you'll be polling the columns
<re_irc>
< (@jamesmunns:beeper.com)> To be clear, you're not WRONG Félix | Totem, there are just other/easier ways to do it :)
<re_irc>
<Félix | Totem> Alright. So, I must put in place some kind of ticking, then each time the function is called I loop through the columns, then I read which row is one.
<re_irc>
<Félix | Totem> +putting each one on,
<re_irc>
<Félix | Totem> * on.
<re_irc>
< (@k900:0upti.me)> You use a timer, yeah
<re_irc>
< (@k900:0upti.me)> And you just poll everything every millisecond or whatever
<re_irc>
< (@jamesmunns:beeper.com)> Check out rtics docs, it has a "timer queue" which let's you schedule things pretty easy
<re_irc>
< (@k900:0upti.me)> A millisecond is surprisingly long
<re_irc>
< (@k900:0upti.me)> As it turns out
<re_irc>
< (@jamesmunns:beeper.com)> Just don't use the DWT timer, it only works with the debugger attached on stm32s iirc
<re_irc>
< (@jamesmunns:beeper.com)> Or use one of the hardware timers with an interrupt, the Hal should have a demo/example for that, look for "listen" iirc
<re_irc>
<Félix | Totem> There is TIM7 I think
<re_irc>
< (@jamesmunns:beeper.com)> That should work! 1ms is a reasonable interval since it matches the USB polling interval
<re_irc>
<Félix | Totem> Do you know why there seems to be several timers?
<re_irc>
< (@jamesmunns:beeper.com)> Options! And you might need one for each of many tasks
<re_irc>
<Félix | Totem> Ohh, I cannot reuse the same on on several tasks, then…
<re_irc>
< (@jamesmunns:beeper.com)> Anything is possible! But you might have to write more code :)
<re_irc>
< (@jamesmunns:beeper.com)> Like of you need to poll an adc at 43.9kHz, it will be hard to reuse the same timer as for 1ms
<re_irc>
< (@jamesmunns:beeper.com)> (in the top level docs, there will (should) always be an "Interrupt" enum that lists all the interrupts for that CPU
<re_irc>
< (@jamesmunns:beeper.com)> (if this is too noisy, let me know, I can move to DM)
<re_irc>
< (@jamesmunns:beeper.com)> Hopefully is useful to other folks that haven't done this yet.
<re_irc>
<Félix | Totem> I intend to write my process up in an article, with the different steps. I take notes of what you write ;)
<re_irc>
< (@jamesmunns:beeper.com)> I have a video for "how to write a hal driver from scratch": https://www.youtube.com/watch?v=pj2Rk-ftcWA, I probably need to do a "write a Rust app from scratch" video.
<re_irc>
<Félix | Totem> : This example doesn't use the timer queue, with "spawn_after" and alike
<re_irc>
< (@jamesmunns:beeper.com)> Yeah sorry, if you have a HARDWARE interrupt, you don't need the timer queue. Just define a hardware task.
<re_irc>
<Félix | Totem> Oh, I got it, now.
<re_irc>
< (@jamesmunns:beeper.com)> Timer queue lets you use a more general timer, running at like 1mhz, and you can just spawn tasks at xxkhz speed
<re_irc>
< (@jamesmunns:beeper.com)> it's that "use one timer for many things in software" you were talking about earlier
<re_irc>
< (@jamesmunns:beeper.com)> (you could also do that, if the stm32f3xx-hal has implemented that trait from RTIC (the "Monotonic" trait I think?)
<re_irc>
<Ralph> i was just going to ask: why do you want to use TIM7 for this with hardware interrupts if you can just use a software task in RTIC? the latter sounds simpler to me
<re_irc>
< (@jamesmunns:beeper.com)> IF the hal has that, I agree, that's a good choice!
<re_irc>
< (@jamesmunns:beeper.com)> If not, for one task, hw tasks are just as easy
<re_irc>
< (@jamesmunns:beeper.com)> (and you don't need to impl a trait)
<re_irc>
< (@jamesmunns:beeper.com)> but if it's already there, different ways, same effort basically.
<re_irc>
< (@jamesmunns:beeper.com)> I don't see it pulling in an rtic dep, so it probably doesn't.
<re_irc>
<Félix | Totem> : Why "rtic::pend(Interrupt::UART0);" is called twice: once inside init, once inside idle?
<re_irc>
it shows you how to set up the monotonic and spawn the software task regularly
<re_irc>
< (@jamesmunns:beeper.com)> You don't need to do that
<re_irc>
< (@jamesmunns:beeper.com)> just start the timer, don't worry about it in idle. it's just doing things that aren't relevant for you
<re_irc>
<Félix | Totem> Ralph: I was going to implement it using the HW interrupt which seems simpler, maybe I'll try this method later
<re_irc>
< (@jamesmunns:beeper.com)> I think it's just triggering the interrupt multiple times for demo purposes.
<re_irc>
< (@jamesmunns:beeper.com)> "here are all the places you could do this"
<re_irc>
< (@jamesmunns:beeper.com)> (using a whole hardware timer for this is "wasteful", but if you have enough timers for each, it doesn't really matter)
<re_irc>
<Félix | Totem> : Well, it's a timer, what else could I use it on?
<re_irc>
< (@jamesmunns:beeper.com)> If you needed to track 20 different things, you couldn't with hw timers.
<re_irc>
< (@jamesmunns:beeper.com)> but you are likely to have 1-3 ones with generally wide capabilities.
<re_irc>
< (@jamesmunns:beeper.com)> * hw timers
<re_irc>
< (@jamesmunns:beeper.com)> and a few extra that have limited capabilities but are useful in a pinch/complicated situation
<re_irc>
<Félix | Totem> Oh, so the software interrupt is an abstraction on top of this.
<re_irc>
<Félix | Totem> Maybe Ralph is right, I should use the monotonic timer
<re_irc>
< (@jamesmunns:beeper.com)> Either should work!
<re_irc>
< (@jamesmunns:beeper.com)> Oh, systick monotonic should work! That timer is useful because it exists on (almost?) every cortex-m. There's probably a crate for that, or a feature of RTIC to enable
<re_irc>
<Félix | Totem> I'm totally lost now. There are several ways of creating a software timer?
<re_irc>
< (@jamesmunns:beeper.com)> Yes! The software timer needs an "engine" to feed the software timer/scheduler
<re_irc>
< (@jamesmunns:beeper.com)> So you could feed it from one of many sources, like systick or tim7 or whatever. It's flexible because sometimes you need to use one timer for a specific purpose
<re_irc>
< (@fragadaleta:matrix.org)> : and with "rpc-pico-embassy" only cable i need is the micro usb in the pico ?
<re_irc>
< (@fragadaleta:matrix.org)> bleah... rpc-pico-embassy does not even build
<re_irc>
< (@therealprof:matrix.org)> No idea, sorry. Just happen to find this page where it seems to have all the relevant information in one place. You don't need to follow all of the guides, the steps should be reproducible with any other Rust code, too.
<re_irc>
The code feels insanely high level for an embedded project. There is a small thing I don't understand: why do I need to still put "dispatchers = [TIM7]" in the app definition? I thought that the system timer was in charge of the interrupt. If I remove it, the error says:
<re_irc>
"not enough interrupts to dispatch all software tasks (need: 1; given: 0)"
<re_irc>
< (@jamesmunns:beeper.com)> Félix | Totem: That's... Somewhere in the docs. They use "sacrificial interrupts" to be tied to software tasks of different priorities
<re_irc>
< (@jamesmunns:beeper.com)> I think the RTIC book talks about this in an earlier chapter, I'm afk ahain
<re_irc>
< (@jamesmunns:beeper.com)> * again
<re_irc>
<Félix | Totem> : And how do I know which interrupt they'll use for what? Nowhere it's specified in my code.
<re_irc>
< (@jamesmunns:beeper.com)> Note the "sysclk" func/arg
<re_irc>
< (@jamesmunns:beeper.com)> Systick basically counts CPU cycles, iirc
<re_irc>
<Ralph> Félix | Totem: it doesn't matter which interrupt you give for the software task. you just need one otherwise unused interrupt per priority level used for the software tasks. so it doesn't have to be a timer interrupt ("TIM7" in your case) but can be anything (e.g. if you're not using USART0 for anything else you could give it "USART0"). the link given my James should explain it in more details (i can recommend going...
<re_irc>
... through the RTIC book to understand the basics).
<re_irc>
<Ralph> btw: RTIC also has a dedicated matrix channel: https://matrix.to/#/#rtic:matrix.org
<re_irc>
<Félix | Totem> : In a good way, ofc
<re_irc>
< (@wucke13:matrix.org)> What is the goto crate for binary serialization/deserialization of a custom format? Basically something like deku (https://docs.rs/deku/latest/deku/) (which looks perfect), but I want the implementation to work in a "no_std" environment without alloc. All messages of course have a size known at compile time.
<re_irc>
< (@jamesmunns:beeper.com)> (standard binary "serde" format for nostd)
<re_irc>
< (@jamesmunns:beeper.com)> Do you control both ends? Or are you impling something existing?
<re_irc>
< (@jamesmunns:beeper.com)> * impl'ing
<re_irc>
< (@wucke13:matrix.org)> : Unfortunately this, so I do have to control how the serialization works. If that weren't the case of course I'd use postcard, james 😄
<re_irc>
< (@jamesmunns:beeper.com)> I know rkurte is working on a crate called encdec
<re_irc>
When I input a command, it doesn't output correctly (letters are repeated as if there's a "write" when going through the buffer). This seems to be related to the way I use menu...
<re_irc>
When I input a command, it doesn't output correctly (letters are repeated as if there's a "write" when going through the buffer). This seems to be related to the way I use menu...
<re_irc>
When I input a command, it doesn't output correctly (letters are repeated as if there's a "write" when going through the buffer). This seems to be related to the way I use menu...
<re_irc>
< (@grantm11235:matrix.org)> I think rustdoc is getting confused because it doing a reexport-within-a-reexport
<re_irc>
< (@xiretza:xiretza.xyz)> yeah, rustdoc isn't great at reexports in general (not that finding a canonical name is an easy problem)
<re_irc>
< (@grantm11235:matrix.org)> I'm not sure why it has "pub use embedded_hal as hal;", that just seems confusing
starblue has joined #rust-embedded
<re_irc>
<thejpster> : not sure about defmt-rtt-target, but menu does assume you don't have local echo enabled and so it will echo all the input characters.
<re_irc>
<thejpster> that might explain why you get things twice
<re_irc>
< (@badrb:matrix.org)> thejpster: Even if it appears only after typing the whole command and pressing enter?
<re_irc>
Where is that usually set? Client side or host side (I’m using cargo embed).
<re_irc>
<thejpster> it's a property of whatever software you are using to capture keystokes and send them to the computer running "menu"
<re_irc>
<thejpster> If you connect over serial, you might use "hyperterminal" or "minicom" or "putty". All will have an option to "Disable local echo"
<re_irc>
<thejpster> I'm guessing that up until you press enter, your terminal program has sent nothing to the target device, but is instead buffering locally and offering local-side line editing. When you press enter, it sends over the whole line.
<re_irc>
<thejpster> Character by character, menu then says "I received a character, I'd better write it to the console".
<re_irc>
<thejpster> Feel free to write a PR for menu that disables the printing of received characters, either as a run-time flag or as a feature flag.
DepthDeluxe_ has quit [Ping timeout: 252 seconds]
<re_irc>
< (@ryankurte:matrix.org)> : ahh yeah that’s what encdec is for! only has impls for little endian primitives at the moment but have a half plan to expand this whenever it’s useful
<re_irc>
<thejpster> Even the Unicode Consortium use postcard
<re_irc>
< (@jamesmunns:beeper.com)> Are you talking about ICU4X?
<re_irc>
<thejpster> unless they're using it something else as well now?
<re_irc>
< (@jamesmunns:beeper.com)> That's what I was wondering :D
<re_irc>
< (@jamesmunns:beeper.com)> I didn't realize that icu4x was a unicode-org proper project I guess (rather than some other inter-corp collab?) but yeah
<re_irc>
<thejpster> > This week, after 2½ years of work by Google, Mozilla, Amazon, and community partners, the Unicode Consortium has published ICU4X 1.0, its first stable release
<re_irc>
<thejpster> you are on your way to becoming a random person in nebraska
<re_irc>
<thejpster> I just wish there was an open source licence that was like "if you're an academic, or of average means, help yourself; if you're a trillion dollar mega-corp, you gotta cut me a cheque first"
<re_irc>
< (@jamesmunns:beeper.com)> it returns as soon as the output is set
<re_irc>
< (@jamesmunns:beeper.com)> practically, that's probably fine
<re_irc>
<Félix | Totem> Never mind the last part, the doc says: "*NOTE* this does *not* read the electrical state of the pin"
<re_irc>
< (@xiretza:xiretza.xyz)> "is_set_high()" reads the same register that you set using "set_high()", it will be "true" immediately. what happens electrically is a different matter
<re_irc>
< (@xiretza:xiretza.xyz)> unrelated, but what's "into_ok_()"?
<re_irc>
< (@jamesmunns:beeper.com)> specifically, it depends on your actual circuit, bus capacitance, etc.
<re_irc>
< (@xiretza:xiretza.xyz)> Félix | Totem: ah, I see
<re_irc>
<Félix | Totem> It's an unstable feature from the core
<re_irc>
<Félix | Totem> : I'm far from being sure it's fine then
<re_irc>
<Félix | Totem> I start to read as soon as the state is written, so it may not be fine
<re_irc>
< (@jamesmunns:beeper.com)> honestly, you could stick a "for _ in 0..100 { cortex_m::asm::nop() }"
<re_irc>
<Félix | Totem> : That looks… crappy 😅
<re_irc>
< (@jamesmunns:beeper.com)> I mean, what do you want?
<re_irc>
<Félix | Totem> No, I guess that's alright, it's just a funny way to do so
<re_irc>
< (@jamesmunns:beeper.com)> you could subdivide the 1ms into how many rows you have, and set the NEXT row at the end of polling the current row
<re_irc>
for row in self.rows {
<re_irc>
< (@jamesmunns:beeper.com)> so like at 1/6th of a ms or whatever:
<re_irc>
// ...
<re_irc>
}
<re_irc>
self.shift_col();
<re_irc>
<Félix | Totem> Do you think it's cleaner than something like: