<re_irc>
trying to do this, but vertical alignment actually isnt taking hold? if i comment out the alignment it doesnt do vertical. but if i do "TextBox::with_vertical_alignment()" and specify it then, i can get it to center vertically but not horizontally since then it doesnt let me specify a horizontal alignment option. what the heck am i doing wrong?
starblue3 has quit [Ping timeout: 245 seconds]
starblue3 has joined #rust-embedded
<re_irc>
<@firefrommoonlight:matrix.org> Hi! Does anyone know how to use probe-run when there are multiple probes connected?
<re_irc>
found enum `core::result::Result<heapless::Vec<_, _>, ()>`
<re_irc>
For more information about this error, try `rustc --explain E0308`.
<re_irc>
error: could not compile `mqttrpc` (lib) due to previous error
<re_irc>
<@louis.renuart.qteal:matrix.org> * error, and I cannot modify the type of "payload"
<re_irc>
<@diondokter:matrix.org> Because a slice can be bigger than the capacity of your Vec, it returns a result. If it's bigger, then you get an error.
<re_irc>
If you know that will never happen, you can simply do "Vec::from_slice(payload).unwrap()";
<re_irc>
<@lavanya10010010:matrix.org> : Hi, thank you for this, it works. But I need help in coming up with logic to do 1 byte write operation (Currently I'm doing 64-bit doubleword write to page buffer to write to my flash, as directed by the datasheet). I need to write code for the case where the data is not word aligned. Say, user wants to write data of 103 bytes. Then my 'if' block executes till 96 bytes and then my 'else' block should execute to...
<re_irc>
... write the final word. I have a 'temp' array which has '0xffffffff' filled for 8 bytes. I need to perform 1-byte write operation to fill up my temp till 103 bytes and by default the 104th byte will be filled with 0xffffffff and I should write this doubleword to flash.
<re_irc>
Need help in writing the else block and writing the tempword contents to flash
<re_irc>
<@diondokter:matrix.org> : Create the array, then copy the data you need into it and then write it
<re_irc>
self.write_nvm_word(address + i * 8 as u32, &buffer);
<re_irc>
}
<re_irc>
}
<re_irc>
}
<re_irc>
<@diondokter:matrix.org> Not sure if you need the volatile writes here, but they won't hurt
<re_irc>
<@lavanya10010010:matrix.org> : I'm still learning Rust (and the only other language I know is C) and will definitely want to write in Rust as Rust!
<re_irc>
For the volatile_write, I'm getting error: no method named "volatile_write" found for raw pointer "*mut u32" in the current scope
<re_irc>
How do I fix this?
<re_irc>
<@diondokter:matrix.org> Oh, maybe I got it in reverse. Is it "write_volatile"?
<re_irc>
<@diondokter:matrix.org> Not as a pointer, but as a slice: "updater.write_nvm_words(0x00043800, &data);"
<re_irc>
<@lavanya10010010:matrix.org> I see, Thank you very much for your help!
IlPalazzo-ojiisa has joined #rust-embedded
Dr_Who has joined #rust-embedded
<re_irc>
<@thejpster:matrix.org> > There is no physical memory located in the CPUs’ Arm SRAM regions.
<re_irc>
😢
<re_irc>
<@thejpster:matrix.org> From the PSoC6 data sheet
<re_irc>
<@mali:grusbv.com> Hi, today an issue made me wonder about something.
<re_irc>
<@mali:grusbv.com> We realized that our boards that defmt_log is not none, when the debugger is remove mid operation the boards reset only a few minutes later than that
<re_irc>
<@mali:grusbv.com> but it does not happen when defmt = none, or does not happen after the reset either.
<re_irc>
<@mali:grusbv.com> So, I wonder, is there a resouce that explains how defmt uses the resources (RTT, I guess?)
<re_irc>
<@mali:grusbv.com> Now that I think thins might be better suited for the probe-rs room
<re_irc>
<@mali:grusbv.com> If I find out something, will share.
<re_irc>
<@guenther_rostig:matrix.org> MSP432E401Y: You suggested to use the TM4C Hal. So I cloned the repo and found a project with this MCU in the examples folder. After following the instructions in the Discovery book I found resulting machine code file in the build folder. Flashing with the J-Link did'nt work (unrecognized file), so I tested it with the Debugger MCU already placed on the launchpad. From UniFlash (GUI program) I got the message that it...
<re_irc>
... was trying to write outside the memory. In the config file in the .cargo folder I found following line:
<re_irc>
<@guenther_rostig:matrix.org> I commented it and uncommented the line with arm-none-eabi-gdb, but this didn't work either. The MSP432E411Y is another chip, but it has the same flahs size as the MSP432E401Y, so this should'nt be a problem. Both habe 1024kByte.
<re_irc>
<@guenther_rostig:matrix.org> * have
<re_irc>
<@ryan-summers:matrix.org> : Check the memory.x file being used instead. It could be that the linker memory is incorrectly specified for the chip
<re_irc>
<@guenther_rostig:matrix.org> Thanks for the fast reply. But I cannot load this file into the MCU via J-Link and the Command Line Program: File is of unknown / supported format. And UniFlash also doesn't recognize the format...
<re_irc>
<@ryan-summers:matrix.org> It's an ELF. You can convert it to a format they support or add the .elf ending
<re_irc>
<@ryan-summers:matrix.org> FYI if you're on *nix systems you can run "file" on the output to figure out what it is too
<re_irc>
<@mali:grusbv.com> Thanks to , defmt-rtt starts the rtt as NON_BLOCKING, but then the defaults of probe-run sets it to BLOCKING.
<re_irc>
<@2:0x2c.org> looks like i need to implement something like channels for micriumos
<re_irc>
<@2:0x2c.org> how do you usually solve allocating task data structures that are immovable (TCB, stack)?
<re_irc>
<@2:0x2c.org> i guess my reflex of statically allocating things like task stacks is not so easy in rust
<re_irc>
<@ryan-summers:matrix.org> Why not? What are you trying to do?
emerent is now known as Guest4417
emerent_ has joined #rust-embedded
Guest4417 has quit [Killed (mercury.libera.chat (Nickname regained by services))]
<re_irc>
<@2:0x2c.org> broadly, use micriumos on the silabs gecko platform, and implement my application logic in rust
<re_irc>
<@ryan-summers:matrix.org> Ew, I'm sorry. I have no idea how micrium manages tasks or memory
<re_irc>
<@2:0x2c.org> i'm about to find out :)
<re_irc>
<@2:0x2c.org> i think it is similar to freertos
<re_irc>
<@ryan-summers:matrix.org> I'm very sorry in advance then
<re_irc>
<@2:0x2c.org> real world stuff, still better than writing the whole app in c++
<re_irc>
<@2:0x2c.org> i guess for my task stack, if i take a "&mut [usize]", i can use that as the stack, and nobody can stomp around on it
<re_irc>
<@2:0x2c.org> and it could come from a static allocation or a box
<re_irc>
<@ryan-summers:matrix.org> Yeah as long as you hold the reference, I don't think it can move
duderonomy has joined #rust-embedded
<re_irc>
<@2:0x2c.org> i don't know what it means to be dropped tho, do i kill the task?
<re_irc>
<@2:0x2c.org> how can i phrase a task type that owns itself, i.e. even if the task handle goes out of scope, it doesn't get dropped?
<re_irc>
<@9names:perthchat.org> : probe-rs support for flashing those chips is in git, you can install that version if you want to try it but attach after flash isn't working correctly yet. The gdb runner is set up for taking to openocd. There's an openocd config in that example folder that works with the launchpad debugger, try that first.
<re_irc>
<@fuse117:matrix.org> how do i receive an unknown amount of data from a host? specifically, im using https://docs.rs/nrf-modem/latest/nrf_modem/struct.UdpSocket.html#method.receive_from. i do know the upper bound on what i can receive. if i create a buffer of that size and give that to "receive_from" then my app basically hangs waiting for data that will never arrive.
<re_irc>
<@fuse117:matrix.org> timeout based cancellation token?
<re_irc>
<@diondokter:matrix.org> : With UDP you should give it the upper bound. It will return to you a slice with the actual length of the message that was received
<re_irc>
<@diondokter:matrix.org> By any chance, do you use a split socket?
<re_irc>
<@diondokter:matrix.org> (Especially where you TX and RX in different tasks?)
<re_irc>
<@fuse117:matrix.org> not at this stage. hacking on some test code with a new API
<re_irc>
<@diondokter:matrix.org> Ok, cause there's a bug with that that is fixed on master
<re_irc>
<@diondokter:matrix.org> In your case it shouldn't hang
<re_irc>
<@diondokter:matrix.org> If you give it a smaller size it doesn't hang?
dc740 has joined #rust-embedded
crabbedhaloablut has quit []
dc740 has quit [Remote host closed the connection]