<re_irc>
<@9names:perthchat.org> Haven't in a while, but it's way easier to get the correct libc and associated compiler-builtins linked in if you're using GCC as the linker - very easy to end up with multiple definition linking errors when not using GCC as linker.
<re_irc>
<@jamesmunns:beeper.com> 9names: Yeah, not currently, but I was writing "a chunk of rust as a staticlib in a C + RTOS project", and was using gcc to link it all together
<re_irc>
<@jamesmunns:beeper.com> though in that case - I still had duplicate symbols from some compiler-builtins intrinsics, some float ops iirc
<re_irc>
<@jamesmunns:beeper.com> (I uh, Got Creative to fix those.)
<re_irc>
<@dkhayes117:matrix.org> : It's used with tinyrlibc in association with nfrxlib-sys
starblue3 has quit [Ping timeout: 246 seconds]
starblue3 has joined #rust-embedded
<cr1901>
>very easy to end up with multiple definition linking errors when not using GCC as linker. <-- why?
<re_irc>
<@jamesmunns:beeper.com> basically: if you aren't careful, llvm and gcc both bring their own compiler-rt/builtins/libc, and the symbol names clash
<cr1901>
I don't really follow... why would an LLVM linker bring in gcc libc and vice-versa?
<re_irc>
<@avery71:matrix.org> A linker just links symbols, I don't know how closely it looks at those symbols
<cr1901>
why would the library search path of a gcc linker be the same as lld. Basically, I can't visualize a case where you get two libcs linked in at once.
<re_irc>
<@jamesmunns:beeper.com> cr1901: if you are creating something like a staticlib in rust, it may include llivm builtins like basic math intrinsic. your binary project that builds the C binary project will also link in gcc's versions of these intrinsics
<re_irc>
<@jamesmunns:beeper.com> so when you link both of them together, they both have some unmangled "fmuladdwhatever" symbol, and linking will fail for duplicate symbols
<re_irc>
<@jamesmunns:beeper.com> you run into this when you have one chunk (usually a staticlib) built by one compiler/linker, and the rest of the project is built by another compiler/linker
<re_irc>
<@jamesmunns:beeper.com> they both very helpfully provide low level intrinsic bits, but then you have low level intrinsic bits that are duplicates.
<cr1901>
Are static libraries supposed to include symbols from other libraries inside them?
<re_irc>
<@jamesmunns:beeper.com> it's less. _other libraries_, and more _compiler-builtins_ type stuff
<re_irc>
<@jamesmunns:beeper.com> there are probably ALSO problems with duplicate libc's, but I haven't run into that recently, whereas I ran into the compiler builtins one like 2-3 months ago.
<cr1901>
9names: I still don't follow your logic. Rust creates LLVM for codegen, LLVM may create calls to compiler-builtins/intrinsics. How does your choice of linker avoid e.g. issue 345?
<cr1901>
(In fact in that linked issue, the OP is using gcc as a linker and getting multiple defs!)
IlPalazzo-ojiisa has joined #rust-embedded
<re_irc>
<@9names:perthchat.org> cr1901: I'm aware of the issues with -Zbuild-std and compiler-builtins and I would like them solved too, but what I'm referring to is GCCs compiler-builtin intrinsics, not rust's.
<re_irc>
<@sourcebox:matrix.org> Cortex-A debugging, especially with multicore, still OpenOCD?
<re_irc>
<@9names:perthchat.org> Yep, that or jlink
<re_irc>
<@sourcebox:matrix.org> Main problem is: with STM32MP1-DK1 dev board, OpenOCD shows all 3 cores, but only opens ports for 1 Cortex-A core on 3333 and another one for the M4 on 3334. How do I get access to the second A7 core?
<re_irc>
<@sourcebox:matrix.org> Btw. OpenOCD recognizes all 3 cores.
<re_irc>
<@sourcebox:matrix.org> Some log output:
<re_irc>
Info : [stm32mp15x.cm4] Cortex-M4 r0p1 processor detected
<re_irc>
Info : [stm32mp15x.cm4] target has 6 breakpoints, 4 watchpoints
<re_irc>
Info : stm32mp15x.cpu0: MPIDR level2 0, cluster 0, core 0, multi core, no SMT
<re_irc>
Info : stm32mp15x.cpu0: hardware has 6 breakpoints, 4 watchpoints
<re_irc>
Info : stm32mp15x.cpu1: hardware has 6 breakpoints, 4 watchpoints
<re_irc>
Info : stm32mp15x.cpu1: MPIDR level2 0, cluster 0, core 1, multi core, no SMT
<re_irc>
Info : gdb port disabled
<re_irc>
Info : gdb port disabled
<re_irc>
Info : gdb port disabled
<re_irc>
Info : starting gdb server for stm32mp15x.cpu0 on 3333
<re_irc>
Info : Listening on port 3333 for gdb connections
<re_irc>
Info : starting gdb server for stm32mp15x.cm4 on 3334
<re_irc>
Info : Listening on port 3334 for gdb connections
<re_irc>
<@like2wise:matrix.org> Hmm, you can select with OpenOCD which of the two cores, as JTAG is daisy chained. But do you want to have access to both M cores at the same time?
<re_irc>
<@9names:perthchat.org> Looks like it's just your config that isn't enabling gdb on one core to be honest
<re_irc>
<@sourcebox:matrix.org> I'm using the config that comes with OpenOCD. I had a look into that script, but that looks quite advanced.
<re_irc>
<@sourcebox:matrix.org> In the project in just having a file with:
<re_irc>
source [find board/stm32mp15x_dk2.cfg]
<re_irc>
<@sourcebox:matrix.org> likewise: The chip has 2 Cortex-A cores and one Cortex-M. I want to have access to one of these cores at a time.
<re_irc>
<@9names:perthchat.org> The default script uses openocd's smp support - that single gdb port supports accessing both cpu0 and cpu1 and will halt both on a breakpoint.
<re_irc>
<@sourcebox:matrix.org> Ah ok. But how do I switch between the cores inside GDB?
<re_irc>
1 stm32mp15x.ap2 mem_ap little stm32mp15x.tap running
<re_irc>
TargetName Type Endian TapName State
<re_irc>
0 stm32mp15x.ap1 mem_ap little stm32mp15x.tap running
<re_irc>
3* stm32mp15x.cpu0 cortex_a little stm32mp15x.tap halted
<re_irc>
2 stm32mp15x.axi mem_ap little stm32mp15x.tap running
<re_irc>
4 stm32mp15x.cpu1 cortex_a little stm32mp15x.tap halted
<re_irc>
5 stm32mp15x.cm4 cortex_m little stm32mp15x.tap reset
<re_irc>
<@sourcebox:matrix.org> I need to find out what cpu1 is currently doing, if it has crashed, sitting in WFI or whatever. Having a look at its registers would maybe help.
<re_irc>
<@sourcebox:matrix.org> I just run a test with some C program where both Cortex-A cores are running. Same issue: only one thread is shown. When I put in breakpoints, they only have effect on the first core.
<re_irc>
<@sourcebox:matrix.org> 9names: Are you sure? The docs you referenced mention the "hwthread" extension, but that is not used in this script.
<re_irc>
<@sourcebox:matrix.org> It is used e.g. in the rp2040.cfg script.
<re_irc>
<@like2wise:matrix.org> Thanks, yes I was referring to that :-) But I then noticed the tracker (from you I think) so it should be up-to-date.
<re_irc>
I was just wondering about recent experiences / well-working approaches and/or native Rust-RTOSs.
<re_irc>
<@adamgreig:matrix.org> mostly people use either something like embassy or rtic to avoid the need for an rtos in the first place, or something like ESP where there's freertos under the hood and your rust tasks can use "std" via their integration, or people like hubris and tock have written their own OS that serves particular niches (especially around isolation/security)
<re_irc>
<@like2wise:matrix.org> I have tuned MCU and Linux RTOS approaches down to sub microsecond latencies and feel I am starting all over again with Rust.
<re_irc>
<@adamgreig:matrix.org> i'd check out rtic then (https://rtic.rs/2/), the execution model is very neat in that most tasks are scheduled as interrupts so the hardware nvic handles scheduling
<re_irc>
<@adamgreig:matrix.org> which gives extremely low latencies without much work
<re_irc>
<@like2wise:matrix.org> So I am really talking fully preemptible systems. No I don't want ISR based execution, in general it does not scale.
<re_irc>
<@adamgreig:matrix.org> hmm, I think you might be disregarding it preemptively here, the model rtic uses works pretty well and isn't quite just "running things in isrs" like you might in c
<re_irc>
<@adamgreig:matrix.org> depends how much scale you need of course! if your microcontroller has 16 interrupt priority levels then you'll only be able to have 16 levels of pre-emption, though you can have more tasks of course
<re_irc>
<@like2wise:matrix.org> OK, I'll reschedule me looking into it again. Thanks for your efforts tracking this and sharing your insights.
<re_irc>
<@adamgreig:matrix.org> in particular, rtic triggers interrupts itself to run software tasks, it's not just interrupt tasks run by hardware events
<re_irc>
<@like2wise:matrix.org> OK, so mixing smolltcp would be no problem then?
<re_irc>
<@adamgreig:matrix.org> absolutely, that's really commonly done (why would it be a problem?)
<re_irc>
<@adamgreig:matrix.org> if you do want a traditional rtos, I think freertos perhaps has the best rust bindings atm? I've not looked into it in any seriousness though, all my use cases for chibios in c are happily replaced by rtic or embassy in rust
<re_irc>
<@like2wise:matrix.org> Because one wants to prevent concurrent access to smolltcp from multiple contexts, so I was assuming an RTOS layer would be in place (much like for lwIP and RTOSs in C).
<re_irc>
<@adamgreig:matrix.org> including things with well-sub-µs latency requirements that are simultaneously running a network stack and such
<re_irc>
<@adamgreig:matrix.org> and message passing between priority levels
<re_irc>
<@dirbaio:matrix.org> with embassy-net (async smoltcp wrapper) you get the same ergonomics you'd get with a traditional C RTOS
<re_irc>
for example, several tasks reading each from a different socket, the executor switches the tasks out when they have nothing to do because they're waiting for data
<re_irc>
<@dirbaio:matrix.org> the reason stackful preemptive RTOSs are rare in Rust is that you don't really need them that much in Rust thanks to async
<re_irc>
<@adamgreig:matrix.org> does embassy-net share between async executors at different priority levels?
<re_irc>
<@like2wise:matrix.org> But I understood async is cooperative multitasking, so I can never guarantee a worst case latency? Or should I run a separate executor for it. Sorry, I am just coming into this field after too long sticking with C solutions.
<re_irc>
<@adamgreig:matrix.org> traditionally yea, async is cooperative
<re_irc>
<@adamgreig:matrix.org> but you can have multiple executors at different priority levels that can pre-empt each other, and choose which tasks are on which executors
<re_irc>
<@adamgreig:matrix.org> (of course then you have to work a bit harder to ensure sound concurrent access to resources)
<re_irc>
<@dirbaio:matrix.org> "real-time networking" is a pipe dream anyway, even if you share sockets across priority levels, the effective priority for them is going to be determined by the priority level of the network task
<re_irc>
<@adamgreig:matrix.org> in rtic, a lower priority task can temporarily raise the priority floor to ensure exclusive access to a resource that's shared with a higher-priority task, but then it can't be pre-empted while doing that
<re_irc>
<@dirbaio:matrix.org> like, even if you write data to a TCP socket from a high prio task, it won't get sent until the lower-prio network task runs
<re_irc>
<@like2wise:matrix.org> I'm not concerned with real-time networking (well I am, but with FPGA's in a different context) -- I am concerned with running the network stack inbetween guaranteed worst-case-latency tasks.
<re_irc>
<@adamgreig:matrix.org> : sure, but usually the concern is more about real-time response to other events while still letting those tasks do some network access
<re_irc>
<@like2wise:matrix.org> Exactly.
<re_irc>
<@dirbaio:matrix.org> you _could_ make embassy-net use a critical section mutex, but it'd actually _hurt_ realtime-ness because lower-prio tasks using network would block higher-prio tasks
<re_irc>
<@adamgreig:matrix.org> like, I need to respond to an interrupt from my fpga in 1µs and read some data out of it that will later get sent out the network, but the important requirement is I finish reading the data asap, not that it's sent asap
<re_irc>
<@dirbaio:matrix.org> so it requires all tasks that use hte network to be at the same priority level
<re_irc>
<@adamgreig:matrix.org> : right, so in that case you probably want a fifo or queue or something to pass data back from high-prio tasks to the low-prio one that sends it into the network stack?
<re_irc>
<@dirbaio:matrix.org> and you use fifos across priority levels
<re_irc>
<@dirbaio:matrix.org> it's literally a 1-line change to make embassy-net use a CS mutex so it's shareable across priority levels
<re_irc>
<@like2wise:matrix.org> : That's exactly what I want to prevent, but I do not really understand why the low prio tasks could block the high prio tasks, if the higher prio tasks are on a different executor it shouldn't matter?
<re_irc>
<@dirbaio:matrix.org> (PRs welcome if someone needs it, it shold be opt-in via a Cargo feature though)
<re_irc>
<@adamgreig:matrix.org> in general a low prio task could take a critical section which prevents pre-emption from higher prio tasks for its duration
<re_irc>
<@dirbaio:matrix.org> likewise: while a low-prio task is accessing network stack internal state, it'd have to enter a CS so a higher-prio task doesn't touch that internal state at the same time causing data races
<re_irc>
<@adamgreig:matrix.org> (and during that CS it can safely access shared resources like network stack state)
<re_irc>
<@like2wise:matrix.org> Yeah, the typical priority inversion problem.
<re_irc>
<@adamgreig:matrix.org> so in practice you'd either bound the worst case time in the CS, or more likely you wouldn't use that, only share network stack among low-prio tasks, and use a message queue to send data from the high prio tasks to the low prio ones
<re_irc>
<@adamgreig:matrix.org> (avoiding the low prio tasks ever needing to block high prio tasks from running)
<re_irc>
<@dirbaio:matrix.org> so to get real-time-ness with async you often do
<re_irc>
<@dirbaio:matrix.org> cooperative async within a priority level
<re_irc>
<@like2wise:matrix.org> : Yes, that's the approach I have been taking in the past with lwIP / uCOS, ChibiOS, FreeRTOS.
<re_irc>
<@dirbaio:matrix.org> and preemption across priority levels, can be hardware accelerated with the NVIC
<re_irc>
<@adamgreig:matrix.org> yea, that continues to work fine, basically
<re_irc>
<@dirbaio:matrix.org> so a higher-prio async task can preempt a lower-prio one
<re_irc>
<@dirbaio:matrix.org> this is what RTIC 2.0 and Embassy's InterruptExecutor do
<re_irc>
<@adamgreig:matrix.org> one nice advantage with rtic is how nicely it manages sharing resources across priority levels, and with both embassy and rtic is that async is much much nicer to write than what you'd have to do in C RTOSs
<re_irc>
<@like2wise:matrix.org> I'm not only targeting ARM, but yes, preemptive interrupts is something I would like on the platform.
<re_irc>
<@jamesmunns:beeper.com> : riot-os is pretty active too IIRC
<re_irc>
<@adamgreig:matrix.org> in the most recent firmware I wrote with this kind of problem I used rtic without any async and it means a lot more bother on the boring low-prio networking tasks, I think next time i'd be using async for those and just have the higher prio tasks be in interrupts
<re_irc>
<@adamgreig:matrix.org> in chibios you usually have quite short interrupts that schedule a task to run in the thread context, and the os pre-empts the running thread when interrupts occur and/or on ticks
<re_irc>
<@like2wise:matrix.org> Thanks for all your insights, and the friendly and active community here. I will look more into a full-Rust approach, probably Embassy all the way, using RTIC executor maybe.
<re_irc>
<@adamgreig:matrix.org> in rtic you run very little in the thread context (maybe the low-prio async tasks for networking) and most of the code is running inside the interrupt handler itself, so the nvic gets to do most of the pre-emption for you, and there's much less overhead for software scheduling as a result
<re_irc>
<@adamgreig:matrix.org> (the choice is mostly embassy or rtic, both provide an async executor)
<re_irc>
<@adamgreig:matrix.org> it used to be that embassy was mostly async and rtic was mostly about different priority tasks, but now embassy does async at lots of priorities and rtic has an async executor, so I'm not really sure how you compare them any more :P
<re_irc>
<@adamgreig:matrix.org> perhaps one bigger difference is that embassy also comes with async HALs for its supported platforms, while rtic users generally use some other HAL, potentially the embassy HAL
<re_irc>
<@adamgreig:matrix.org> (from chibios or freertos you'd be used to the rtos providing the HAL too, always, but in rust typically/historically the HAL is separate from the OS, since we generally have better interfaces/package management/library support/whatever)
corecode_ is now known as corecode
<re_irc>
<@steelph0enix:matrix.org> Hello!
<re_irc>
I want to write a HAL crate for a Cortex-M MCU. I already have PAC generated via svd2rust, and i'm looking for resources on "how to wrap the PAC in a way that will not force me to fight Rust every time i try to use it". Do you know any such resources about wrapping unsafe PAC structs into peripheral structs that will be safe to use?
<re_irc>
<@steelph0enix:matrix.org> anything i could find (and i'm still looking) was about using the HAL libraries, even "embedded-hal" repo has a list of usage examples in many BSP's/drivers, not implementations
<re_irc>
<@steelph0enix:matrix.org> i guess the embedded book has something, but maybe there's a bit more info somewhere else too?
<re_irc>
<@ryan-summers:matrix.org> There are many, many HAL examples out there, such as "stm32f4xx-hal", "stm32h7xx-hal", etc. Have you looked at those yet? Wojciech Olech
<re_irc>
<@steelph0enix:matrix.org> yeah, i'm looking through them right now, but i'd rather have something with actual design commentary as that's what i'm looking for the most
<re_irc>
<@ryan-summers:matrix.org> Probably go with the stream then. I don't know of any resources like that, and many HALs are organically built by many different contributors
<re_irc>
<@jamesmunns:beeper.com> What chip are you using Wojciech Olech ?
<re_irc>
<@steelph0enix:matrix.org> because yeah, i see _how_ STM32 HAL is made, but _why_ is it made that way?
<re_irc>
<@steelph0enix:matrix.org> : SAMV71Q21
<re_irc>
<@steelph0enix:matrix.org> that's Cortex-M7 with FPU
<re_irc>
<@jamesmunns:beeper.com> Also yeah, the stream does aim to cover a lot of those basics, I haven't rewatched it recently to see if there's any outdated recommendations :p
<re_irc>
<@steelph0enix:matrix.org> i know the chip because i've been working with it for last half year, also writing BSP in C for it, but now i'm about to write a BSP for it in Rust
<re_irc>
<@ryan-summers:matrix.org> The "embedded-hal" is used to facilitate cross-crate compatibility (so you can write an I2C driver without caring _which_ i2c implementation is provided). The HALs are generally built to expose those types, and then anything they add on top is just gravy implementation to aid in using the chip
<re_irc>
<@jamesmunns:beeper.com> fwiw I did some work with the SAME70 a bit ago
<re_irc>
<@jamesmunns:beeper.com> Which IIRC is pretty close to the V71
<re_irc>
<@steelph0enix:matrix.org> yeah, i think it's the budget version of similar series
<re_irc>
<@steelph0enix:matrix.org> V71 is the top-end
<re_irc>
<@steelph0enix:matrix.org> +of that specific series
<re_irc>
<@steelph0enix:matrix.org> yeah, fortunately i won't have to touch ethernet there _yet_
<re_irc>
<@steelph0enix:matrix.org> i just need watchdog, timers and UART for now
<re_irc>
<@jamesmunns:beeper.com> I _think_ the atsamx7x has ended up upstreaming most of my work though, so I'd probably start there first, tho if they didn't take my smoltcp stuff, it might help you
<re_irc>
<@omar_u8:matrix.org> Wojciech Olech: I don't know if its going to be of much help, but I wrote a series somewhat related in the past. There is a part that shows how to create abstractions and another how to incorporate the "embedded-hal" heres the link -> https://apollolabsblog.hashnode.dev/series/stm32f4-embedded-rust-pac
<re_irc>
<@steelph0enix:matrix.org> oh yeah, that sounds exactly what i need
<re_irc>
<@jamesmunns:beeper.com> It looks like 's post is already on there, awesome :)
<re_irc>
<@steelph0enix:matrix.org> oh, thanks, i've seen that but i've had an URL that threw me to the list on the bottom so i didn't notice the first links :D
<re_irc>
<@jamesmunns:beeper.com> Yeah, trade off of "everything is there" and "how do I find exactly what I need" :D
<re_irc>
<@guenther_rostig:matrix.org> Hello!
<re_irc>
Does anyone have experience with embedded ethernet and rust for cortex-m4 devices?
<re_irc>
<@guenther_rostig:matrix.org> We use a MSP432E401 MCU and think of changing from C to Rust. So we have to write a driver, thanks for the links.
<re_irc>
<@9names:matrix.org> As far as I'm aware MSP432E401 is basically identical to tm4c1294, you might be able to use tm4c-hal as-is
<re_irc>
<@jamesmunns:beeper.com> I always forget the MSP432 is Cortex-M, and not, well, an MSP430 :D
<re_irc>
<@ryan-summers:matrix.org> Yeah they did their darnedest to make it difficult to follow ;)
<re_irc>
<@jamesmunns:beeper.com> : Yeah, especially since there are all the weird variants like MSP430X too
<re_irc>
<@jamesmunns:beeper.com> pic is even more surprising, where there's a couple different architectures. I think the PIC32s are basically just MIPS processors? It's been a while tho
<re_irc>
<@ryan-summers:matrix.org> I had to learn embedded with PICs, and I've avoided them like the plague ever since
<re_irc>
<@ryan-summers:matrix.org> Microchip's business model is just super strange. buy up all the outdated, older tech and then keep selling it for years. Had a buddy working at an old chip fab that got bought out by Microchip because they wanted the 80s tech on the cheap
<re_irc>
<@jamesmunns:beeper.com> Yeah, I don't think I've written any code for PICs before, we had them in some designs, but usually that was on some module or something where we just treated it like a black box
<re_irc>
<@k900:conduit.0upti.me> I learned on AVR and I'd still pick AVR over any PIC
<re_irc>
<@k900:conduit.0upti.me> And I hate AVR with a passion
<re_irc>
<@jamesmunns:beeper.com> my university used 8051 for teaching in the lower classes, and then we switched to ARM7/ARM9 for the upper level classes
<re_irc>
<@jamesmunns:beeper.com> and I think some TI DSP chip for a DSP class? Can't remember
<re_irc>
<@ryan-summers:matrix.org> My OS class used an emulated arm bare metal in QEMU to have us write an OS in it. Everyone in that class hated it because most were CS majors that had never worked with bare-metal before
<re_irc>
<@k900:conduit.0upti.me> We had a choice between a DSP class and a web class and everyone chose web cause it was new and flashy and stuff
<re_irc>
<@ryan-summers:matrix.org> It was the one class we got ARM in and I loved it
<re_irc>
<@k900:conduit.0upti.me> Should have signed up for the DSP class tbh
<re_irc>
<@jamesmunns:beeper.com> K900: I have some fond early-days-of-arduino memories, but now that cortex-m is so cheap and ubiquitous (and I've already learned how they work), I probably won't ever use one again
<re_irc>
<@k900:conduit.0upti.me> The biggest thing I learned from the web class is that I hate Rails
<re_irc>
<@k900:conduit.0upti.me> I actually never got to work with a real Arduino
<re_irc>
<@ryan-summers:matrix.org> Also, Atmel got bought out by microchip and they killed off AVR, didn't they?
<re_irc>
<@k900:conduit.0upti.me> Some Chinese knockoffs and lots of old Atmel dev boards but never the real thing
<re_irc>
<@jamesmunns:beeper.com> K900: I only passed that lab class because I had a lab partner that was a EE who was really good at matlab+math and really bad at coding, and I was good at coding and really bad at matlab+math
<re_irc>
<@ryan-summers:matrix.org> I mean they still produce the old chips, but nothing new coming out of that line
<re_irc>
<@jamesmunns:beeper.com> : I thought they just released a new one?
<re_irc>
<@k900:conduit.0upti.me> : That's how AVR has been for the past like 20 years
<re_irc>
<@ryan-summers:matrix.org> Did AVR actually release something new? Haven't followed it
<re_irc>
<@k900:conduit.0upti.me> There isn't really much new you can do when you're using an 8 bit ISA from 1980
<re_irc>
<@jamesmunns:beeper.com> maybe it was just an old chip in a new package or something
<re_irc>
<@diondokter:matrix.org> I mean, what are you gonna do with AVR? Who wants a new one?
<re_irc>
<@k900:conduit.0upti.me> Yeah they're basically just there to keep old designs going
<re_irc>
<@ryan-summers:matrix.org> Ah that I understand
<re_irc>
<@marmrt:matrix.org> : Wojciech Olech: We did take James's smoltcp stuff, but it was never merged into the main branch. The pull request is still there https://github.com/atsams-rs/atsamx7x-rust/pull/33
<re_irc>
Let me know if you have any trouble getting it running
<re_irc>
<@jamesmunns:beeper.com> fwiw the smoltcp impl wasn't _great_, there were a lot of things that were very hacky and could likely better use the available buffers. It was for a customer, and it was Good Enough for the demo at the time 😅
<re_irc>
<@jamesmunns:beeper.com> (well, more specifically my EMAC driver wasn't great, smoltcp still worked really well despite that :) )
<re_irc>
<@steelph0enix:matrix.org> : o, no no, i don't need ethernet but thanks :D
<re_irc>
<@steelph0enix:matrix.org> oh god it's broken reply system, isn't it?
<re_irc>
<@marmrt:matrix.org> The offer goes for any other HAL troubles you might have as well
<re_irc>
<@steelph0enix:matrix.org> all right, thanks!
<re_irc>
<@steelph0enix:matrix.org> normally i'd probably use the existing HAL and call it a day, but we're writing kinda-aerospace-related-project and we need to make most stuff in-house :D
<corecode>
how can i run tests in my binary crate on the host?
<corecode>
feels like i need to do something with config.toml and [target.'cfg(...)']
<re_irc>
<@halfbit:matrix.org> : pic's are still being released I believe as well
<re_irc>
<@halfbit:matrix.org> fairly popular little devices, still being used in new designs
<re_irc>
<@ryan-summers:matrix.org> Oh I know. I just don't know _why_
<re_irc>
<@jamesmunns:beeper.com> I think they work really well for EE folks who don't love to write software
<re_irc>
<@ryan-summers:matrix.org> Is it a price point thing?
<re_irc>
<@halfbit:matrix.org> Cheap, abundent sample code, does exactly what is needed
<re_irc>
<@jamesmunns:beeper.com> they are fairly straightfoward and don't change much, which means not much to learn from what I've seen :D
<re_irc>
<@ryan-summers:matrix.org> Fair arguments all around
<re_irc>
<@halfbit:matrix.org> e.g. connect this can bus to this adc in some manner
<re_irc>
<@ryan-summers:matrix.org> Although calling them simple is an overstatement IMO
<re_irc>
<@halfbit:matrix.org> A few hundred lines of C later, and it works
<re_irc>
<@ryan-summers:matrix.org> Maybe in comparison with others thats true. Been years since I used them
<re_irc>
<@jamesmunns:beeper.com> "see feature in datasheet, make chip do that exact thing very quickly" is very compelling if you don't have a lot of swdev muscle in house :D
<re_irc>
<@halfbit:matrix.org> time is money, and exactly
<re_irc>
<@halfbit:matrix.org> if you can literally copy and paste from a datasheet/sample with a few hacks, why go hack your own path in the jungle
<re_irc>
<@jamesmunns:beeper.com> turns out devs are very expensive when you don't have an MoQ of 1M :D
<re_irc>
<@ryan-summers:matrix.org> Yeah, that's actually the argument I use for rust now. Can get a working project in rust with complex stuff in a fraction of the time for C
<re_irc>
<@ryan-summers:matrix.org> Not saying this is true for all projects though
<re_irc>
<@halfbit:matrix.org> : pretty true if you compare to C++ especially from what I've seen... C on a micro is tougher, as again there's lots and lots and lots of existing stuff you can cobble together quickly usually
<re_irc>
<@ryan-summers:matrix.org> Yeah, cobble together doesn't tend to make reliable stuff, but generally these apps aren't looking for reliable
<re_irc>
<@jamesmunns:beeper.com> : tbf: when the scope is small enough, you can get away with a lot of crimes that never catch up with you
<re_irc>
<@ryan-summers:matrix.org> Depends on the industry ;)
<re_irc>
<@ryan-summers:matrix.org> But for sure there's lots of apps where you just need "good enough"
<re_irc>
<@halfbit:matrix.org> often times it _does_ make pretty reliable stuff, or reliable enough for the intent. Exactly as says, if the scope is small, you you can quite quickly validate even the most glued together C code.
<re_irc>
<@jamesmunns:beeper.com> it does get bad when you end up with 50kloc of vendor code for eth and adcs and variable priority and and and
<re_irc>
<@halfbit:matrix.org> and the scope usually is pretty small, hence the continued usage of pic/avr parts in many cases
<re_irc>
<@jamesmunns:beeper.com> but like "read sensor, spin motor", you can make a thing very quickly with a pic and some copy paste
<re_irc>
<@halfbit:matrix.org> yes... add in eth/ble/wifi and now you are talking bug hell
<re_irc>
<@halfbit:matrix.org> 100%
<re_irc>
<@halfbit:matrix.org> or... translate sensor into can bus, take can bus and flip switch
<re_irc>
<@jamesmunns:beeper.com> I've helped a lot of companies that went from 1kloc -> 10kloc -> 100kloc
<re_irc>
<@halfbit:matrix.org> ok... yeah I mean, vendor provides can lib and your C code is like a few hundred lines, who cares
<re_irc>
<@jamesmunns:beeper.com> that 10kloc -> 100kloc step is a DOOZY
<re_irc>
<@halfbit:matrix.org> if there's a problem with the can stuff you call the vendor
<re_irc>
<@jamesmunns:beeper.com> (or even realistically, 5kloc -> 20kloc is where it starts getting real nasty if you've just been copy and pasting or growing without intent :D)
<re_irc>
<@halfbit:matrix.org> I wouldn't put it past people to slap on a part with a small C lib that does feature X to avoid just that in some cases
<re_irc>
<@halfbit:matrix.org> not like mass unit production stuff, but you are making 100 devices? whats cheaper, slap on module X and glue it with 100 lines of C, or... go build a bridge
<re_irc>
<@steelph0enix:matrix.org> corecode: ha, good question - i have the same one lmao
<re_irc>
<@steelph0enix:matrix.org> our current idea is to do it like in C/C++ - just write a script that will flash the binary to MCU and see what it prints, but that's for integration tests
<re_irc>
<@steelph0enix:matrix.org> can't say i know how to make unit tests work on embedded platform, the flashing can be easely done via cargo config i think, but what about verifying whether the test has passed or not?
<re_irc>
<@jamesmunns:beeper.com> So the more general advice is:
<re_irc>
<@jamesmunns:beeper.com> - If you can split out your logic to run in a no-std crate (no hw deps), you can just test it on your host with cargo test. you probably switch "#![no_std]" at the top for `#![cfg_attr(not(test), no_std)]
<re_irc>
<@jamesmunns:beeper.com> - if you can't, then defmt-test is good, you'll need to write "mini firmwares" that do what you want, which might require external cooperation for non-trivial stuff, which makes it a lot more like integration testing
<re_irc>
<@jamesmunns:beeper.com> by "external cooperation" I mean if you're testing ethernet, for example, you'll need something that replies to the test messages you send. Or if you talk to an ADC, you probably want the voltage to change.
<re_irc>
<@ryan-summers:matrix.org> There's nothing like HITL testing though IME
<re_irc>
<@ryan-summers:matrix.org> And by that I mean HITL is by far the biggest value-add
<re_irc>
<@steelph0enix:matrix.org> by "you can test it on your host" you mean just mocking the external deps, right?
<re_irc>
<@ryan-summers:matrix.org> And also the most complex :')
<re_irc>
<@jamesmunns:beeper.com> : eh, depends on the class of tests you're aiming for and the maturity of your project
<re_irc>
<@jamesmunns:beeper.com> Wojciech Olech: In most cases, you can factor out the logic rather than mocking
<re_irc>
<@jamesmunns:beeper.com> for example with smoltcp: it's generic over the "MAC" basically, on the host you could wire it up in a different way
<re_irc>
<@steelph0enix:matrix.org> so just prepare dummy data and test against it instead?
<re_irc>
<@steelph0enix:matrix.org> instead of mocking external logic
<re_irc>
<@jamesmunns:beeper.com> but a lot of this means designing your code to be testable, usually splitting out the "business logic" and "does I/O" parts
<re_irc>
<@jamesmunns:beeper.com> yeah
<re_irc>
<@steelph0enix:matrix.org> sounds sane and logical
<re_irc>
<@jamesmunns:beeper.com> so instead of a struct that does "read()" and "write()" directly, pass data in, so the call looks like::
<re_irc>
let out = struct.process(data);
<re_irc>
let data = read();
<re_irc>
write(data);
<re_irc>
<@jamesmunns:beeper.com> then you can test the "process" function on the desktop, no mocking, and don't test or save the io test for integration testing
<re_irc>
<@jamesmunns:beeper.com> fancy CS people generally call this "Hexagonal architecture" (or a bunch of other fancy names)
<re_irc>
<@jamesmunns:beeper.com> but: logic in the "core", no IO, dumb IO outside of the "core"
<re_irc>
<@steelph0enix:matrix.org> yeah, i have quite different experience from my last project where we utilized mocks pretty heavily
<re_irc>
<@steelph0enix:matrix.org> and i don't mean the architecture there was bad
<re_irc>
<@steelph0enix:matrix.org> most of the code was testable on x86
<re_irc>
<@jamesmunns:beeper.com> Yeah, rust doesn't play _great_ with mocking, because strong types
<re_irc>
<@steelph0enix:matrix.org> yeah, that was C/C++ and we did link-time mocks
<re_irc>
<@jamesmunns:beeper.com> you often end up having to make everything generic so you can "sub in" the parts you want to mock
<re_irc>
<@steelph0enix:matrix.org> so it was pretty easy to write one
<re_irc>
<@steelph0enix:matrix.org> and they were reusable
<re_irc>
<@jamesmunns:beeper.com> which, then can make the code more complex because now its all generic :D
<re_irc>
<@steelph0enix:matrix.org> yeeeeeeeeah
<re_irc>
<@jamesmunns:beeper.com> you could do other, grosser "#[cfg(test)]" trickery, but if you CAN separate logic and I/O, I find it means you can test things WAY easier.
<re_irc>
<@steelph0enix:matrix.org> in our RTOS project we're basically writing a logic that will work everywhere, so our RTOS-dev can do stuff 100% on x86, and we plug HAL to it
<re_irc>
<@jamesmunns:beeper.com> (not saying this is the only way of doing things: just what I've found to be the pass of least resistance)
<re_irc>
<@jamesmunns:beeper.com> * path
<re_irc>
<@steelph0enix:matrix.org> so everything platform-related is behind the HAL
<re_irc>
<@steelph0enix:matrix.org> and logic is testable anywhere
<re_irc>
<@steelph0enix:matrix.org> that's good design i think
<re_irc>
<@jamesmunns:beeper.com> yup! In some cases it is very reasonable, and "Traits" are your degree of freedom there.
<re_irc>
<@steelph0enix:matrix.org> (wish it was as simple to setup in C/C++ as in Rust lmao)
<re_irc>
<@jamesmunns:beeper.com> you'd be generic over "P: SerialPort" or such, and go along
<re_irc>
<@jamesmunns:beeper.com> basically: "how to test embedded, with 'what to expect' cost/return wise". Predates my use of Rust tho :D
<re_irc>
<@ryan-summers:matrix.org> Yeah it depends on the use-case. For my case of class C medical device, the HIL tests have been absolutely invaluable
<re_irc>
<@ryan-summers:matrix.org> Have full on automated thermal phantoms running to verify we aren't damaging tissues with excessive heat etc.
<re_irc>
<@jamesmunns:beeper.com> Yeah, for sure. We had that in avionics and other safety critical fields too :)
<re_irc>
<@jamesmunns:beeper.com> but if you have a 3-7 year project cycle, there's a lot more time to set up HIL rigs than on a 3-6mo consumer/startup dev cycle :)
<re_irc>
<@jamesmunns:beeper.com> especially if you don't have in-house knowledge to build the first version :D
<re_irc>
<@jamesmunns:beeper.com> HIL is DOPE, but expensive. But when it pays off, it pays off.
<re_irc>
<@ryan-summers:matrix.org> Yeah for sure. Although I did set up some HIL for QUARTIQ's firmware as well in a very low-cost manner\
<re_irc>
<@jamesmunns:beeper.com> low cost in parts, or low cost in your time? :D
<re_irc>
<@ryan-summers:matrix.org> Both thankfully
<re_irc>
<@jamesmunns:beeper.com> Nice! I've also used dev boards and raspberry pis to build some sanity checks pretty quickly
<re_irc>
<@jamesmunns:beeper.com> it gets tricky when you have esoteric interfaces, like ARINC429, or whatever absurd sensor bus your project uses, or you're trying to test something super time critical.
<re_irc>
<@ryan-summers:matrix.org> The end product on those systems are already network connected though, so the setup was as easy as "put product in, attach ethernet + debug probe" with a rpi host
<re_irc>
<@jamesmunns:beeper.com> Yeah, that's ideal! If your main backbone is already eth, it makes life so much easier.
<re_irc>
<@jamesmunns:beeper.com> or really, if the backbone(s) are "something you can reasonably get as a USB adapter" lol
<re_irc>
<@steelph0enix:matrix.org> : yeee, good stuff
<re_irc>
we also do full HITL integration tests for our crit B firmware, CI runs the code on all supported platforms and outputs full binaries, docs, coverage, requirement reports, etc - extremely useful
<re_irc>
<@steelph0enix:matrix.org> and the setups are basically raspberry pi's connected to devboards throught unhinged amount of USB hubs which sometimes make JLink do funny stuff and refuse to cooperate if it's connected to wrong USB port
<re_irc>
<@steelph0enix:matrix.org> still, great way to make a chip CI setup!
<re_irc>
<@steelph0enix:matrix.org> * cheap
<re_irc>
<@jamesmunns:beeper.com> but yeah, if I was setting up a project from scratch, with some time to do it, my order of impl would be:
<re_irc>
- make a simulator target with a "fake hal", where stuff is wired up to TCP/UDP ports or files or something for main dev
<re_irc>
- make sure I have unit tests for any business logic'y stuff
<re_irc>
- make sure the firmware has some way (instrumentation commands) to trigger hardware I/O, so you can test specific cases with a scope or logic analyzer attached
<re_irc>
- Make basic HIL tests for the "easy stuff like UART and ethernet" for sanity checks
<re_irc>
- If I'm doing something critical, then I'd probably start building a more intense rig
<re_irc>
<@jamesmunns:beeper.com> fwiw/money where my mouth is:
<re_irc>
mnemos already has the first two, and soooorta has the third as a WIP
<re_irc>
<@jamesmunns:beeper.com> For example, using embedded-graphics-sim for the display, and a fake UART over TCP, so you can use the same tools for talking to the sim as talking to the hardware
<re_irc>
<@jamesmunns:beeper.com> but the kernel itself is all "just a library", so you can write tests however you want. Right now has also already ported it to WASM as a host platform :D
<re_irc>
<@jamesmunns:beeper.com> (you can also open the browser console, and see all of our "tracing" messages too. On the sim, those come out in the console window, on the hardware, they come out over the UART, and in the browser they show up in the browser console)
<re_irc>
<@jamesmunns:beeper.com> Plug to drop by #mnemos-dev:beeper.com (https://matrix.to/#/#mnemos-dev:beeper.com) if anyone is interested in hacking on it :D
<re_irc>
<@2:0x2c.org> this channel is definitely easier to read on matrix
<re_irc>
<@jamesmunns:beeper.com> oh, have I been destroying the IRC bridge with links and long comments? :p
<re_irc>
<@2:0x2c.org> it
<re_irc>
<@2:0x2c.org> * it's just that if everything comes from one nick without highlighting, i can't keep track of things
<re_irc>
<@jamesmunns:beeper.com> Oh neat, it does send edits to messages too, I didn't know it did that
<re_irc>
<@whitequark:matrix.org> : I am now operating a proper double puppeting IRC bridge; if you'd like I can connect it over to IRC side so that names are translated 1:1
<re_irc>
<@whitequark:matrix.org> (theoretically you can do this yourself through a widget in the Matrix chat; in practice it's been unfortunately not very stable and I ended up running my own infra)
<re_irc>
<@jamesmunns:beeper.com> I think runs the IRC infra here, he'd be the one to ask!
<re_irc>
<@whitequark:matrix.org> oh gotcha
dc740 has joined #rust-embedded
<cr1901>
jamesmunns: A while ago, you mentioned a Matrix room you run that you said I'd be interested in, and I can't remember for the life of me what it was. Does this ring a bell?
<cr1901>
It was Rust-potpourri-related I think
<cr1901>
9names: Seems like we're talking about different things. Do you have an example of the gcc behavior you're talking about and how it breaks when used w/ a not-gcc linker?
<re_irc>
<@jamesmunns:beeper.com> #anachro:matrix.org (https://matrix.to/#/#anachro:matrix.org) is my general chat room, started project specific, but it's really just a smaller, shitpostier, more "not just code, also mech/electrical stuff" room. Generally open, probably what I was talking about
<cr1901>
yea that sounds vaguely familiar, thanks for jogging my memory
WSalmon has quit [Ping timeout: 245 seconds]
WSalmon_ has joined #rust-embedded
<re_irc>
<@thejpster:matrix.org> GMQ came out of beta
tafama has joined #rust-embedded
emerent_ has joined #rust-embedded
emerent has quit [Killed (mercury.libera.chat (Nickname regained by services))]
emerent_ is now known as emerent
tafa has quit [*.net *.split]
IlPalazzo-ojiisa has quit [Quit: Leaving.]
<re_irc>
<@2:0x2c.org> so back to using mocks of my vendor library ffi crate; i have no idea how i could make my test code use a host library instead of the vendor library, which is compiled for target
<re_irc>
<@2:0x2c.org> easiest at the moment seems to be to just locally write a mock module and use #[double]
dc740 has quit [Remote host closed the connection]
dc740 has joined #rust-embedded
<re_irc>
<@adamgreig:matrix.org> : oh interesting. we can't do it through the official bridge because too many users in the matrix side (and it took ages to get op on the irc side after the move to libera, at which point we were already running our bridge)
<re_irc>
<@adamgreig:matrix.org> it's a lot of users which I think gives libera some pause for having that many connections, though
<re_irc>
<@whitequark:matrix.org> I have it set up to bridge incrementally
<re_irc>
<@adamgreig:matrix.org> also it seems like it then messages all the matrix-side users (which is most of them) about now being connected to irc and every time it drops etc?
<re_irc>
<@whitequark:matrix.org> only the Matrix users that actually talk show up on IRC, and only for a while
<re_irc>
<@adamgreig:matrix.org> ah cool, that helps
<re_irc>
<@adamgreig:matrix.org> right, that should make it fine, it's not super high traffic really
<re_irc>
<@whitequark:matrix.org> : I think that might only happen if you're registered on libera
<re_irc>
<@whitequark:matrix.org> I've just set up a staging environment and I didn't get anything at all
<re_irc>
<@adamgreig:matrix.org> curious. but how does it know I'm registered on libera when it's a different username?
<re_irc>
<@whitequark:matrix.org> but yeah if you are registered it will send you a bunch of messages on every restart/connection loss/etc
<re_irc>
<@whitequark:matrix.org> by default it takes your Matrix username, makes it syntactically valid for IRC and appends "[m]"
<re_irc>
<@whitequark:matrix.org> if that happens to be a registered IRC username (you can register it), then it's yours
<re_irc>
<@whitequark:matrix.org> otherwise you can send "!nick" to the appservice
<re_irc>
<@adamgreig:matrix.org> ah, 'adamgreig' is an alias for agg on libera, so I guess that's how
<re_irc>
<@adamgreig:matrix.org> hmm, but 'adamgreig[m]1'?
<re_irc>
<@whitequark:matrix.org> it starts appending (not increasing...) numbers until it gets something palatable if the nick already exists and you aren't registered with services
<re_irc>
<@whitequark:matrix.org> so it'll try "adamgreig[m]", "adamgreig[m]1", "adamgreig[m]12", "adamgreig[m]123", ...
<re_irc>
<@whitequark:matrix.org> (don't ask please, I didn't write the goddamn thing, I'm just deploying it)
<re_irc>
<@adamgreig:matrix.org> "adamgreig[m]" exists from the previous amaranth room bridge
<re_irc>
<@whitequark:matrix.org> yes
<re_irc>
<@adamgreig:matrix.org> but I haven't registered it or [m]1, so dunno why the bridge was messaging me on the matrix side after joining the new bridged room?
<re_irc>
<@whitequark:matrix.org> oh
<re_irc>
<@whitequark:matrix.org> what did it message you?
<re_irc>
<@adamgreig:matrix.org> You've joined a Matrix room which is bridged to the IRC network 'irc.libera.chat', where you are now connected as adamgreig[m]. This room shows any errors or status messages from IRC, as well as letting you control the connection. Type !help for more information.
<re_irc>
Connecting to the IRC network 'irc.libera.chat' as adamgreig[m]...
<re_irc>
You've been connected to the IRC network 'irc.libera.chat' as adamgreig[m]1.
<re_irc>
<@adamgreig:matrix.org> then some more about connection lost and re-connected
<re_irc>
<@adamgreig:matrix.org> which bridge software is it?
<re_irc>
<@whitequark:matrix.org> matrix-appservice-irc, the same thing libera.chat matrix homeserver runs
<re_irc>
<@adamgreig:matrix.org> huh, never seen a similar message from the matrix.org one
<re_irc>
<@whitequark:matrix.org> it sends me those!
<re_irc>
<@adamgreig:matrix.org> 🤔
<re_irc>
<@adamgreig:matrix.org> basically i would love to stop hosting the irc bridge for this room, which is the only room it bridges, and having actual nicks on the irc side would be icing on the cake too
<re_irc>
<@adamgreig:matrix.org> but probably not if it messages all thousand people to let them know they're in irc now (without even saying which room!)
<re_irc>
<@adamgreig:matrix.org> or if it starts kicking people from the matrix side for being idle like the matrix.org one does, lol
<re_irc>
<@whitequark:matrix.org> : I don't think it'll message anyone unless you actually _talk_
<re_irc>
<@whitequark:matrix.org> but that's something I can easily check on the staging environment
<re_irc>
<@adamgreig:matrix.org> just joined
<re_irc>
<@adamgreig:matrix.org> I didn't talk in amaranth-lang, iirc
<re_irc>
<@whitequark:matrix.org> I'll check
<re_irc>
<@whitequark:matrix.org> : this is configurable
<re_irc>
<@whitequark:matrix.org> I have all the annoying features of the EMS bridge disabled
<re_irc>
<@adamgreig:matrix.org> seems much better to just have them disappear from irc, but i thought libera didn't like the idea of that because irc users then can't see everyone who's in the room
<re_irc>
<@whitequark:matrix.org> it's up to the chanop
<re_irc>
<@whitequark:matrix.org> this is a public channel anyway, so it doesn't matter
<re_irc>
<@whitequark:matrix.org> : bridging _every_ channel having potentially invisible matrix users on irc side won't fly
<re_irc>
<@adamgreig:matrix.org> certainly not something I worried about. we have public logs so...
<re_irc>
<@whitequark:matrix.org> which is why portaling is being disabled
<re_irc>
<@whitequark:matrix.org> however doing this on a purely opt in basis is fine
<re_irc>
<@whitequark:matrix.org> right now I have the bridge configured such that IRC puppets appear for Matrix users who talk, and then they disappear in LRU order once it hits the connection limit
<re_irc>
<@whitequark:matrix.org> and the Libera folks are happy to adjust the connection limit as needed
<re_irc>
<@adamgreig:matrix.org> sounds good
<re_irc>
<@whitequark:matrix.org> in any case you can simply not give the appservice permission to kick users
<re_irc>
<@whitequark:matrix.org> in my rooms I have it configured with power 70, but you can set it to pretty much anything
<re_irc>
<@adamgreig:matrix.org> I don't think that's an option for the matrix.org-hosted one
<re_irc>
<@whitequark:matrix.org> it is for mine
<re_irc>
<@whitequark:matrix.org> it does not have many of the issues associated with the EMS libera.chat bridge
<re_irc>
<@whitequark:matrix.org> by design
<re_irc>
<@adamgreig:matrix.org> want to try it for this room? my only remaining reservation is it suddenly DMing all 2k people to tell them they're in irc now...
<re_irc>
<@whitequark:matrix.org> I think the message you're referring to gets sent when an IRC side puppet gets created
<re_irc>
<@whitequark:matrix.org> meaning, when someone talks or joins _after the bridge is here_
<re_irc>
<@whitequark:matrix.org> : I'm tired and that's not the best way to try and do things; let's do this in a properly coordinated manner
<re_irc>
<@whitequark:matrix.org> when will you have some free time? I'm thinking weekend might be good
<re_irc>
<@adamgreig:matrix.org> yea, no rush at all, thank you for the offer!
<re_irc>
<@adamgreig:matrix.org> sure
<re_irc>
<@whitequark:matrix.org> I'll double-check everything, talk to the Libera folks, then we can test it
<re_irc>
<@adamgreig:matrix.org> thanks :) just ping me whenever, I should be around all weekend I think
<re_irc>
<@whitequark:matrix.org> gotcha
<re_irc>
<@whitequark:matrix.org> : did some quick testing and it looks like the users who already were in the channel do not receive the junk from the bridge even when they start to talk
<re_irc>
<@whitequark:matrix.org> which is... honestly bizarre and probably a bug but seems to work out in our favor
<re_irc>
<@whitequark:matrix.org> I'm going to run a smaller scale test first and report how it goes
<re_irc>
<@adamgreig:matrix.org> but new users joining the channel still would?
<re_irc>
<@adamgreig:matrix.org> shame the message is so vague and doesn't mention the channel name or the appservices name or anything
dc740 has quit [Remote host closed the connection]
duderonomy has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]