<re_irc_> <@f​irefrommoonlight:m​atrix.org> I'm still struggling with indirect, so it may be a bit!
<re_irc_> <@f​irefrommoonlight:m​atrix.org> What MCU?
<re_irc_> <@f​irefrommoonlight:m​atrix.org> I'm testing with WB55 on Cypress S25 NOR Flash, but the principles should be similar
<re_irc_> <@w​illeml:m​atrix.org> firefrommoonlight: STM32F730
<re_irc_> <@w​illeml:m​atrix.org> With an AT25SF641 flash chip
<re_irc_> <@w​illeml:m​atrix.org> I don't know if its NOR though
fabic has joined #rust-embedded
fabic has quit [Remote host closed the connection]
fabic has joined #rust-embedded
emerent has quit [Ping timeout: 250 seconds]
emerent has joined #rust-embedded
<re_irc_> <@f​irefrommoonlight:m​atrix.org> Have you gotten indirect mode working?
aquijoule_ has joined #rust-embedded
richbridger has quit [Ping timeout: 268 seconds]
<re_irc_> <@f​irefrommoonlight:m​atrix.org> AFAIK, it seems like you need to do your writes in indirect mode (Maybe Status polling too?). Then you can set memory-mapped mode and do reads. I assume it's similar to the onboard Flash, so code like this for reading 1 word, although I'm confident some details here are wrong, and I haven't got the...
<re_irc_> ... writes working, so can't test it yet:
<re_irc_> <@f​irefrommoonlight:m​atrix.org> ```rust
<re_irc_> <@f​irefrommoonlight:m​atrix.org> /// Read a chunk of memory in memory-mapped mode
<re_irc_> <@f​irefrommoonlight:m​atrix.org> There are also evidently subtleties in mapping your flash's addressing using whatever its system is, with STM32's QSPI flash area
<re_irc_> <@f​irefrommoonlight:m​atrix.org> If I've understood correctly
<re_irc_> <@f​irefrommoonlight:m​atrix.org> Per Dirbaio's spreadsheet, F7 and WB have the same QSPI peripheral, so I imagine the code will be near-identical on the MCU side, but there will be differences in how our external flash registers work
fabic has quit [Ping timeout: 265 seconds]
fabic has joined #rust-embedded
fabic_ has joined #rust-embedded
fabic has quit [Ping timeout: 268 seconds]
fooker has quit [Ping timeout: 252 seconds]
<re_irc_> <@t​herealprof:m​atrix.org> willeml: Has to be, otherwise you couldn't run code from it. NAND has a vastly different organisation and requires a dedicated Controller chip.
<re_irc_> <@w​illeml:m​atrix.org> Oh, good to know, I have been trying to find out what kind it was for a while as it is not written in any of the docs that I could find for the device its in or the chip...
fooker has joined #rust-embedded
tokomak has joined #rust-embedded
<re_irc_> <@w​illeml:m​atrix.org> Does anyone know of an easy way of converting a slice of u8 to a slice of u32?
<re_irc_> <@w​illeml:m​atrix.org> and ideally back again
<re_irc_> <@h​untc:m​atrix.org> `map`
<re_irc_> <@w​illeml:m​atrix.org> I mean, I want 4 u8 to turn into one u32
<re_irc_> <@w​illeml:m​atrix.org> And I want to be able to accept odd numbers of u8
<re_irc_> <@i​an_rees:m​atrix.org> If endianness works out and the length of the u8 slice is a multiple of 4, https://doc.rust-lang.org/core/slice/fn.from_raw_parts.html
<re_irc_> <@w​illeml:m​atrix.org> Well, I managed to break my program
<re_irc_> <@w​illeml:m​atrix.org> this line being present causes the binary size to go down to 11K
<re_irc_> <@i​an_rees:m​atrix.org> ah, yeah, I don't know offhand but first attempt would be to use https://doc.rust-lang.org/core/slice/struct.ArrayChunks.html and map
<re_irc_> <@i​an_rees:m​atrix.org> once you've got 4 bytes and want a u32, use u32::from_le_bytes() for little endian, be for big
<re_irc_> <@9​names:m​atrix.org> what do you mean by odd numbers of u8?
<re_irc_> <@w​illeml:m​atrix.org> meaning, I could have `[1u8; 7]` and it would be turned into `[0b00010001, 0b00010000]`
starblue1 has quit [Quit: WeeChat 2.3]
<re_irc_> <@9​names:m​atrix.org> I'm not sure what would be the best way to deal with that in a generic way. going to need to having padding byte(s) if using the from_*_bytes methods, which means you're going to need to allocate a new slice.
<re_irc_> <@9​names:m​atrix.org> or maybe using bitwise ops? i guess it depends on what you're most comfortable with.
<re_irc_> <@w​illeml:m​atrix.org> I guess I will probably attempt to use bitwise ops to loop through it
<re_irc_> <@i​an_rees:m​atrix.org> that ArrayChunks has a remainder() method which gives the last few elements, I presume the result of it could be matched on
<re_irc_> <@w​illeml:m​atrix.org> Yeah, that sounds good, thanks! Ill check it out tomorrow.
fabic_ has quit [Ping timeout: 268 seconds]
starblue has joined #rust-embedded
<re_irc_> <@j​amesmunns:m​atrix.org> therealprof: Is this true? I could have sworn I've worked on an ARM9 product that stored it's code in a NOR flash part (avionics)
<re_irc_> <@t​herealprof:m​atrix.org> NAND you mean?
<re_irc_> <@j​amesmunns:m​atrix.org> Nah, pretty sure it was explicitly NOR fladh
<re_irc_> <@t​herealprof:m​atrix.org> Yes, that's what I'm saying. Only NOR can XIP.
<re_irc_> <@j​amesmunns:m​atrix.org> Ahhh
<re_irc_> <@j​amesmunns:m​atrix.org> Had it backwards, still early for me :)
<re_irc_> <@t​herealprof:m​atrix.org> No worries.
<re_irc_> <@b​radleyharden:m​atrix.org> willeml, the cleanest way I've found to do that on stable is an outer while loop over all bytes and an inner for loop to copy the 4 bytes to an array you initialize. You need to initialize to control the padding bytes, and you need to copy in case of alignment problems.
<re_irc_> <@b​radleyharden:m​atrix.org> I can't wait until array_chunks is stable
<re_irc_> <@f​irefrommoonlight:m​atrix.org> When working with this flash chip, it appears to get the Indirect writes and read working eg on config registers, setting the AR register has no effect; setting the first word to the address, as in normal SPI, seems to choose the address instead
<re_irc_> <@f​irefrommoonlight:m​atrix.org> Although MCU RM says this: *". In indirect and automatic-polling modes, the address bytes
<re_irc_> <@f​irefrommoonlight:m​atrix.org> to be sent are specified in the ADDRESS[31:0] field of QUADSPI_AR register, while in
<re_irc_> <@f​irefrommoonlight:m​atrix.org> memory-mapped mode the address is given directly via the AHB (from the Cortex® or from
<re_irc_> <@f​irefrommoonlight:m​atrix.org> a DMA)."*
fabic_ has joined #rust-embedded
SomeWeirdAnon has joined #rust-embedded
fabic_ has quit [Remote host closed the connection]
fabic has joined #rust-embedded
fabic has quit [Read error: Connection reset by peer]
fabic has joined #rust-embedded
<re_irc_> <@w​illeml:m​atrix.org> Is there a way of writing to memory mapped flash? Like, instead of erasing a sector, write zeros to it?
<re_irc_> <@w​illeml:m​atrix.org> Or is that just a no go in general?
<re_irc_> <@x​norman:m​atrix.org> AFAIK, flash doesn't work that way.. you can flip bits but you can't unflip them
<re_irc_> <@x​norman:m​atrix.org> without an erase..
<re_irc_> <@x​norman:m​atrix.org> with memory mapping, it seems unlikely that that would change?
<re_irc_> <@w​illeml:m​atrix.org> Do you have to erase the whole chip to write a sector or can you erase just that sector?
<re_irc_> <@w​illeml:m​atrix.org> Or is that dependant on the chip?
<re_irc_> <@d​irbaio:m​atrix.org> that's how NOR flash works
<re_irc_> <@d​irbaio:m​atrix.org> you can "erase" big chunks (sometimes called "sectors" or "pages"), erasing sets all bits to 1
<re_irc_> <@d​irbaio:m​atrix.org> you can "write" individual bytes (or sometimes small "words", of eg 4 bytes), but writing can only change bits to 0
<re_irc_> <@d​irbaio:m​atrix.org> you usually can write to the same word multiple times, but only changing 1 bits to 0 bits
<re_irc_> <@d​irbaio:m​atrix.org> eg the final result is the bitwise AND of what was there before and what you write
<re_irc_> <@d​irbaio:m​atrix.org> if you want to change 1 bit from 0 to 1, you can only do that by erasing entire page/sector
<cr1901> Has anyone used the embedded HAL traits to implement a peripheral- i.e. I2C slave mode?
<cr1901> I'm having trouble visualizing how to do it- the traits seem to be all from the point of view of the bus controller
<re_irc_> <@s​ajattack:m​atrix.org> like bitbang-hal?
<cr1901> Well yes, that's one of the crates I was looking at
<re_irc_> <@d​irbaio:m​atrix.org> embedded-hal doesn't have traits for i2c/spi slaves
<cr1901> Hrm
<cr1901> Is it that nobody has created them yet or i2c/spi peripherals are rare?
<re_irc_> <@d​irbaio:m​atrix.org> they're used less often
<re_irc_> <@d​irbaio:m​atrix.org> and maybe harder to abstract since you don't control the clock so timing is harder
<re_irc_> <@d​irbaio:m​atrix.org> there are HALs out there implementing i2c/spi slave, they just don't implement any e-h trait
<re_irc_> <@d​irbaio:m​atrix.org> they do their own API
<cr1901> Another thing about peripherals is that one valid approach to implementing them is interrupt-driven. And as we discussed a while back, the embedded HAL traits don't necessarily always play nice w/ that
<cr1901> (they can, but they seem to be developed more for "blocking" or "async event loop")
<cr1901> Look, I'm trying to shoehorn the HAL into my msp430 stuff, but I just haven't been able to :P
<re_irc_> <@d​irbaio:m​atrix.org> yeah they leave irqs up to the user
<re_irc_> <@d​irbaio:m​atrix.org> with async traits it's finally possible for the HALs to completely abstract the IRQs away from the user
<cr1901> If you have the space for the event loop :)
<re_irc_> <@d​irbaio:m​atrix.org> yeah
<re_irc_> <@d​irbaio:m​atrix.org> codesize is pretty similar between async and nb-based handwritten state machines though
<re_irc_> <@d​irbaio:m​atrix.org> blocking will always be smaller
Bogdnaos has joined #rust-embedded
<cr1901> I don't always want to async everything either. I'm certainly more comfortable writing code w/ "main thread plus interrupt handlers".
<re_irc_> <@d​irbaio:m​atrix.org> if you do everything blocking you can simply pretend interrupts don't exist though 🤣
Bogdnaos has quit [Client Quit]
<cr1901> eww
<re_irc_> <@d​irbaio:m​atrix.org> that's what most people do lol
<re_irc_> <@d​irbaio:m​atrix.org> otherwise it sucks
<re_irc_> <@d​irbaio:m​atrix.org> like
<re_irc_> <@d​irbaio:m​atrix.org> e-h traits for uart abstract the actual reading/writing
<re_irc_> <@d​irbaio:m​atrix.org> but not the interrupt signaling "I've receoved data, please read now"
<cr1901> It doesn't bother me, in the context of an interrupt handler, to recreate an object representing a UART trait to respond to an interrupt that says "data has been received".
<re_irc_> <@d​irbaio:m​atrix.org> yeah
<re_irc_> <@d​irbaio:m​atrix.org> I mean that works *okay* if you're using a particular HAL directly
<re_irc_> <@d​irbaio:m​atrix.org> and call the hal's listen/unlisten/enable_interrupt or whatever methods
<cr1901> listen/unlisten?
<re_irc_> <@d​irbaio:m​atrix.org> but it's impossible to write a "hal-independent" driver that uses uart in an interrupt-driven way
<cr1901> well, the driver could provide a "this must be called from the interrupt handler" function that takes something that implements HAL trait
<re_irc_> <@d​irbaio:m​atrix.org> yeah some HALs call thes things "listen" https://github.com/stm32-rs/stm32f4xx-hal/blob/d4cc782a270fcc63d088b8576f6967b4eca555dd/src/serial.rs#L982
<re_irc_> <@d​irbaio:m​atrix.org> > driver could provide a "this must be called from the interrupt handler"
<re_irc_> <@d​irbaio:m​atrix.org> Sure sure, but what do you do if your hardware doesn't use interrupts? like an UART from linux?
<re_irc_> <@d​irbaio:m​atrix.org> with async traits you can do that
<re_irc_> <@d​irbaio:m​atrix.org> because interrupts are abstracted away inside the HAL
<re_irc_> <@d​irbaio:m​atrix.org> the HAL <-> driver interface uses the waker to signal "I'm ready to do work, please poll me"
<re_irc_> <@d​irbaio:m​atrix.org> an embedded HAL can wire the interrupt to the waker
<re_irc_> <@d​irbaio:m​atrix.org> a Linux HAL can wire an epoll reactor to the waker
<cr1901> You will need a second driver for that (since mutex features- interrupt-driven vs no-interrupts is discouraged). And there's no reason both can't exist other than 'async is the New Hotness" and "Rust ppl don't care for interrupts"?
<cr1901> Not every application needs the complexity of an event loop, but being locked out of any abstractions because the HAL traits opted for "blocking" or "async only" as intentional design decisions also seems short-sighted
<re_irc_> <@d​irbaio:m​atrix.org> There's already been talks of extending e-h traits to allow hal-independent drivers to use interrupts
<cr1901> That would be nice... and something I could use (for e.g. the tcn75a crate). What would such a trait impl look like?
<re_irc_> <@d​irbaio:m​atrix.org> https://github.com/rust-embedded/embedded-hal/issues/57
<cr1901> (Can you tell I miss the "callback plus void ptr context" style of C? :P.)
<re_irc_> <@d​irbaio:m​atrix.org> It hasn't happened it's crazy hard to do in a truly hardware-independent way
<re_irc_> <@d​irbaio:m​atrix.org> interrupts work very differently in different chips
<re_irc_> <@d​irbaio:m​atrix.org> and in some the "interrupt" concept doesn't even exist (linux)
<re_irc_> <@d​irbaio:m​atrix.org> and if it did happen, it'd still be not very nice
<re_irc_> <@d​irbaio:m​atrix.org> drivers doing the "please call me this method when an irq happens" is not nice after all
<re_irc_> <@d​irbaio:m​atrix.org> it pushes all the interrupt setup and mutexing and stuff on the end user
<cr1901> Which can STILL be easier than debugging an event loop for small applications. Also, I'm biased against "one true method" for anything. Or "two true methods" here (blocking or async). So I don't think we'll be seeing eye to eye here :P
<cr1901> This isn't unique to embedded Rust tho
<re_irc_> <@d​irbaio:m​atrix.org> async wakers abstract it at a "higher level" so it is possible for HAL themselves to setup the interrupt handler and then wire that to wakres
<re_irc_> <@d​irbaio:m​atrix.org> yeah of course there's no One True Way
<re_irc_> <@d​irbaio:m​atrix.org> e-h gives you blocking, nb and soon async
<re_irc_> <@d​irbaio:m​atrix.org> HALs aditionally give you interrupt-driven stuff (listen methods), just not hardware-independent
<re_irc_> <@f​irefrommoonlight:m​atrix.org> willeml is your experience with indirect write addressing the same as I posted, or are you using the AR reg on your stm32?
<re_irc_> <@d​irbaio:m​atrix.org> because doing interrupt-driven stuff *in a hardware independent way* is hard
<re_irc_> <@d​irbaio:m​atrix.org> you can totally do that, just not using e-h
<cr1901> I don't think interrupts should be done in a hardware independent way.
<cr1901> But when embedded-hal drivers take ownership of the only object which can read and write registers, and don't provide a "sans-io" version of the driver, then I get locked out of a bunch of platform-independent Rust code
<cr1901> because they don't provide a mechanism for me to more finely control when the driver's routines are called (as in within an interrupt)
<cr1901> Maybe I could leverage nb and manual state machines to fake interrupt-driven I/O tho
<re_irc_> <@d​irbaio:m​atrix.org> HALs give you listen/unlisten stuff which is usually waht you need to do interrupt-driven stuff
<re_irc_> <@d​irbaio:m​atrix.org> it's just custom methods, not part of any e-h trait
<cr1901> Sure, that's fine... I think I'm explaining my issue badly
* cr1901 needs time to think this over
<re_irc_> <@f​irefrommoonlight:m​atrix.org> I've been treating EH traits and drivers as a basic test if hardware functionality, and a way for new users to get hardware working quickly. I've only been able to use one in product code
<re_irc_> <@f​irefrommoonlight:m​atrix.org> Usual reasons are lack of interrupt handling, DMA, owning busses, and they're are generally missing at least one feature
<re_irc_> <@f​irefrommoonlight:m​atrix.org> They also make debugging and troubleshooting tougher if they use too many abstractions
<cr1901> In a sentence, "I want more sans-io drivers, but drivers tend to own things that require embedded HAL traits to be implemented and call it a day"
<re_irc_> <@f​irefrommoonlight:m​atrix.org> Ie, starting an adc conversion, and reading when ready is I2C calls, I'd rather debug 2 lines of code than spellunk multiple files and abstractions to add something or find a problem
<cr1901> firefrommoonlight: Yea, the owning busses thing is ultimately my problem. But I also don't want to write the code that creates the buffers to be sent/received either
<cr1901> I suppose I should create a sans-io API for tcn75a https://github.com/cr1901/i2c-server/blob/master/tcn75a/src/lib.rs#L88-L96
<re_irc_> <@d​irbaio:m​atrix.org> what does "sans io" mean in this context?
<cr1901> "Do everything except that actual I/O"
<re_irc_> <@d​irbaio:m​atrix.org> so it gives you the bytes you have to read/write to i2c, you as the end user do it?
<cr1901> yes
<re_irc_> <@d​irbaio:m​atrix.org> hm
<re_irc_> <@d​irbaio:m​atrix.org> what do you gain with that?
<cr1901> I can do interrupt driven I/O and have full control over when the actual I/O is done. Either in main loop or in interrupt handler
<re_irc_> <@d​irbaio:m​atrix.org> oof, seems ultra cumbersome to use
<re_irc_> <@d​irbaio:m​atrix.org> in the end you want the driver to give you a "just gimme the temperature!" method
<re_irc_> <@w​illeml:m​atrix.org> firefrommoonlight: Currently I don’t have working write or erasing, it just crashes the controller and probe rs
<cr1901> I guess using nb accomplishes what I want (when an nb API exists) if I want interrupt driven I/O. It's just not as zero cost (because of state machine traversal) as if I had a sans-io API
<cr1901> and it's not possible for nb to zero cost, because the driver has no idea whether the embedded HAL "read" is only ever going to be called in a context where it will always be ready (interrupt handler)
<re_irc_> <@d​irbaio:m​atrix.org> with async the driver can tell the HAL "hey please write this &[u8] whenever you can`
<re_irc_> <@d​irbaio:m​atrix.org> and the HAL can setup interrupts and write the actual bytes in the "tx ready" interrupt
<re_irc_> <@d​irbaio:m​atrix.org> and then wake the task when all bytes have been written
<re_irc_> <@d​irbaio:m​atrix.org> so it's interrupt-driven but abstracted away, the driver doesn't care how the bytes get written
<cr1901> Yes, that works if you have the space or the desire to completely structure your application around an event loop.
<cr1901> an async* event loop
<re_irc_> <@d​irbaio:m​atrix.org> I insist, async doesn't have to be bloated :)
<re_irc_> <@d​irbaio:m​atrix.org> the "async event loop" can be just `loop { fut.poll() }`
<cr1901> Also, I _like_ writing code of the form "main thread plus interrupts" :P
<re_irc_> <@d​irbaio:m​atrix.org> and the future is a compiler-generated state machine that's the same as you'd have written manually
<re_irc_> <@d​irbaio:m​atrix.org> :D
<re_irc_> <@d​irbaio:m​atrix.org> so similar code size
<cr1901> Anyways, if async can fit into 2 kbytes, well... https://github.com/cr1901/AT2XT/blob/master/src/main.rs
<re_irc_> <@d​irbaio:m​atrix.org> you *can* use a fancier executor that supports multiple tasks but you don't *have to*
<cr1901> I don't use HALs in this crate, but in principle I could be using CountDown and digital
<re_irc_> <@d​irbaio:m​atrix.org> 2kb ram or flash?
<cr1901> flash
<cr1901> 128 bytes of RAM
<re_irc_> <@d​irbaio:m​atrix.org> lol
<re_irc_> <@d​irbaio:m​atrix.org> it *might* be possible haha
<cr1901> Of course, that's your reaction- everything is an ARM to you :)
<re_irc_> <@d​irbaio:m​atrix.org> it'd be a fun challenge to prove the "async doesn't have to be bloated" thing
<cr1901> I'm not actually interested in trying to get an event loop to run on a 2kB part.
<cr1901> I just want the choice to use embedded HAL drivers on these small micros without size penalty, but the slant towards async/nonblocking means I _don't_ get to
<re_irc_> <@d​irbaio:m​atrix.org> I see your point now :D
<re_irc_> <@f​irefrommoonlight:m​atrix.org> dirbaio: I've been handling this with a fn in the main program, eg `fn read_temp(i2c: i2c: @mut I2c)`
<re_irc_> <@d​irbaio:m​atrix.org> but the point of having a driver is that you don't have to do that yourself 🤣
<re_irc_> <@d​irbaio:m​atrix.org> you give an i2c bus to the driver, and then you get to read the temp
<re_irc_> <@j​amesmunns:m​atrix.org> cr1901: I fit an async bootloader in 2.2KiB of flash or so
<re_irc_> <@j​amesmunns:m​atrix.org> Pretty much no attempt to optimize
<re_irc_> <@j​amesmunns:m​atrix.org> Probably uses more than 128B of RAM tho :p
<re_irc_> <@j​amesmunns:m​atrix.org> https://github.com/sprocket-board/sprocket-boot
<cr1901> yea... it might be possible, but it's not my priority right now to try. msp430 parts go up to 128kB flash and 8kB RAM
<cr1901> those parts could almost certainly run an event loop
<cr1901> (though accessing all 128kB of flash is difficult because PC is not the same size as a data register and LLVM seems allergic to any arch where PC != size of data reg)
<cr1901> sans-io drivers and/or smaller granularity functions that stop at the point where a user is expected to wait for an interrupt to arrive, instead of blocking, or state machine management to return to the "yield point", would solve my problems :P
<re_irc_> <@f​irefrommoonlight:m​atrix.org> And then you add another dependency when you need to use the i2c line elsewhere
<re_irc_> <@f​irefrommoonlight:m​atrix.org> And hope your PR gets merged when you need it to enter a low pwr mode etc
<re_irc_> <@d​irbaio:m​atrix.org> stm32-rs being slow to merge PRs and having 10 HALs with mostly copypasted code is a separate issue 🤣
<re_irc_> <@j​amesmunns:m​atrix.org> I realized this chip has a VTOR, so I could remove that whole boot patching chunk, which should shrink the code a lot, and I can fit in a single 2KiB flash page
<cr1901> msp430s have a built-in bootloader. One of my bucket list ideas is to make Rust tools for it or a Rust driver for it. But that's a long way off
<re_irc_> <@f​irefrommoonlight:m​atrix.org> It's something different every time!
fabic has quit [Ping timeout: 272 seconds]
<re_irc_> <@d​irbaio:m​atrix.org> woot
<re_irc_> <@j​acobrosenthal:m​atrix.org> Also started thalesfragoso a nice discussion it would be nice to continue https://rust-lang.zulipchat.com/#narrow/stream/187312-wg-async-foundations/topic/mem.3A.3Aforget.2C.20borrowed.20buffers.20and.20DMA
<re_irc_> <@d​irbaio:m​atrix.org> is that the full GATs? not just lifetimes?
creich has quit [Remote host closed the connection]
<re_irc_> <@p​inkhatbeard:m​atrix.org> I have been away from the Rust Embedded world for over a year. In the past I've done some fairly simple projects (bluepill, discovery, the book, etc), but things seem to have changed quite a bit since I last touched it. I have a really simple telemetry project that I need to demo this week using the NRF9160...
<re_irc_> ... (requires cellular data). Does anyone have a recommendation of a good resource to get me up to speed reasonably quickly?
<re_irc_> <@t​halesfragoso:m​atrix.org> cr1901 128 bytes of ram is complicated, hehe. But I'm planning on fitting embassy + app + 1k frame buffer + 1k RTT buffer in 4k of RAM
<re_irc_> <@t​halesfragoso:m​atrix.org> It seems like it might fit, right now I have a simple temperature app plus RTT and things are going smoothly
<re_irc_> <@t​halesfragoso:m​atrix.org> I might get rid of the RTT buffer if it doesn't fit
tokomak has quit [Ping timeout: 250 seconds]
<re_irc_> <@l​achlansneff:m​atrix.org> pinkhatbeard: Try [nrfxlib](https://docs.rs/nrfxlib/0.6.0/nrfxlib/)
<re_irc_> <@p​inkhatbeard:m​atrix.org> That's what I've been working on for the last hour. I cannot get it to build in `no_std` because of a dependency on `log`.
<re_irc_> <@p​inkhatbeard:m​atrix.org> Lachlan Sneff: That's what I've been working on for the last hour. I cannot get it to build in no_std because of a dependency on log.
<re_irc_> <@l​achlansneff:m​atrix.org> Yes, I was hitting the same issue.
<re_irc_> <@l​achlansneff:m​atrix.org> You need to turn on resolver 2
<re_irc_> <@l​achlansneff:m​atrix.org> pinkhatbeard: In Cargo.toml, [package], add `resolver = 2`
<re_irc_> <@l​achlansneff:m​atrix.org> The original resolver is combining the two uses of the log crate (the second is in dev/build-dependencies
<re_irc_> <@p​inkhatbeard:m​atrix.org> Lachlan Sneff: I'm still running into the same error. Let me try a cargo clean and see.
<re_irc_> <@l​achlansneff:m​atrix.org> pinkhatbeard: Any luck?
<re_irc_> <@p​inkhatbeard:m​atrix.org> pinkhatbeard: No luck, even with a clean project with the only dependency being `nrfxlib`.
<re_irc_> <@l​achlansneff:m​atrix.org> That's really odd
<re_irc_> <@l​achlansneff:m​atrix.org> I'm using nrfxlib just fine
<re_irc_> <@l​achlansneff:m​atrix.org> And having other issues that are related to nrf being dumb, but not the rust bindings to nrfxlib
<re_irc_> <@d​irbaio:m​atrix.org> post output of `cargo tree --format '{p} {f}'`
<re_irc_> <@d​irbaio:m​atrix.org> there's no `std` outside build-dependencies
<re_irc_> <@d​irbaio:m​atrix.org> what error are you getting when compiling exactly?
<re_irc_> <@p​inkhatbeard:m​atrix.org> Compiling tester v0.1.0 (/home/usr/Dev/IotLab/bucket/tester)
<re_irc_> <@p​inkhatbeard:m​atrix.org> error: could not compile `tester`
<re_irc_> <@p​inkhatbeard:m​atrix.org> error[E0463]: can't find crate for `std`
<re_irc_> <@p​inkhatbeard:m​atrix.org> To learn more, run the command again with --verbose.
<re_irc_> <@d​irbaio:m​atrix.org> do you have `#[no_std]` in your crate?
<re_irc_> <@l​achlansneff:m​atrix.org> tester?
<re_irc_> <@d​irbaio:m​atrix.org> `tester` is their toplevel crate
<re_irc_> <@p​inkhatbeard:m​atrix.org> Whoops. Give me a second. When I copied everything over into a clean project I might have missed something.
<re_irc_> <@p​inkhatbeard:m​atrix.org> I'm unclear what wasn't working with my original repo. I copied things over to a new project and that led to the classic copy & paste error. I still don't have it working correctly, but I've got a new error at least. Let me sort through this and see if I still end up having questions.
<re_irc_> <@p​inkhatbeard:m​atrix.org> Thank you. I would have never figured out to add `resolver = "2"` to my `Cargo.toml`. My demo code is working again now using the `nrfxlib" crate. Now onto figuring out how to read some pins.
<re_irc_> <@d​khayes117:m​atrix.org> Looking for advise on a good dev board to deepen my embedded, and rust, knowledge using a popular chip. I want to look at linking and bootloading to the hal and any run time crates to firmware and rtos'.
<re_irc_> <@t​halesfragoso:m​atrix.org> dkhayes117: STM32F4, H7, or a nRF board
<re_irc_> <@t​halesfragoso:m​atrix.org> for the STs you have discovery boards which are nice, if you want to go cheaper you can get some boards on ali
<re_irc_> <@t​halesfragoso:m​atrix.org> WeAct boards are very nice
<re_irc_> <@d​khayes117:m​atrix.org> I alreasy have a stm32f3 discovery, tm4c123g, msp432, and a nRF52840 dk. I have some others too, lol. Just wondering which would have the most rust support so I can dig deep.
<re_irc_> <@t​halesfragoso:m​atrix.org> maybe nRF
<re_irc_> <@d​khayes117:m​atrix.org> Does rtic support nRF?
<re_irc_> <@d​irbaio:m​atrix.org> yes (it supports all cortex-m's)
<re_irc_> <@j​acobrosenthal:m​atrix.org> the makerdiary nrf52mdk has a cmsis dap onboard. also the new microbit v2
<re_irc_> <@d​khayes117:m​atrix.org> jacobrosenthal: Might habe add this one to the collection 😀
<re_irc_> <@f​irefrommoonlight:m​atrix.org> Imo you will learn more if you think of a project that genuinely interests you, or you think would be useful to people, and pick the MCU/dev board that is most suitable for the project
<re_irc_> <@d​khayes117:m​atrix.org> Looks like the repos for it are C, don't see any rust.
<re_irc_> <@f​irefrommoonlight:m​atrix.org> Nrf and Stm32 are the most well supported MCUs by the Rust OSS community
<re_irc_> <@d​khayes117:m​atrix.org> Hmm, I like projects with a purpose. Now what to choose? I am working on building my own home automation system with SCADA. Maybe I could incorporate some kind of sensor network.
<re_irc_> <@d​khayes117:m​atrix.org> Im a big fan of RISC-V tech too, maybe could do some trailblazing for that.
<re_irc_> <@j​acobrosenthal:m​atrix.org> There's a microbit nrf rust repo somewhere. I have an mdk quick start somewhere as well
<re_irc_> <@j​acobrosenthal:m​atrix.org> But in general you can just fork an nrf example
<re_irc_> <@j​acobrosenthal:m​atrix.org> https://github.com/nrf-rs/nrf52840-mdk-rs or this one
<re_irc_> <@j​acobrosenthal:m​atrix.org> https://github.com/nrf-rs/microbit
<re_irc_> <@d​khayes117:m​atrix.org> Looks fun too
<re_irc_> <@d​khayes117:m​atrix.org> jacobrosenthal: Is this the one?
<re_irc_> <@d​irbaio:m​atrix.org> I'd go for something with the nrf52840
<re_irc_> <@d​irbaio:m​atrix.org> compared with the '832 it has more ram/flash, usb, +8dbm tx power (vs +4), BLE Coded PHY (much more radio range)
<re_irc_> <@d​irbaio:m​atrix.org> ah you say you already got one :D
<re_irc_> <@d​khayes117:m​atrix.org> Yep, the one they use for Ferrous Sytems embedded training
<re_irc_> <@d​irbaio:m​atrix.org> there's no better nordic devboard than the nordic DKs :D
<re_irc_> <@h​untc:m​atrix.org> I think it is hard to go past the micro:bit v2 - its simply awesome and so cheap.
<re_irc_> <@j​acobrosenthal:m​atrix.org> Not that I'd buy it on ebay :)
<re_irc_> <@h​untc:m​atrix.org> It has an nRF52833
<re_irc_> <@h​untc:m​atrix.org> Christopher Hunt: sub US$20
<re_irc_> <@d​khayes117:m​atrix.org> Side Q, How are typical state machines done in rust? Ive done several simple ones in C using the case statement switching on a static enum `state`
<re_irc_> <@h​untc:m​atrix.org> Also: https://github.com/titanclass/stage
<re_irc_> <@h​untc:m​atrix.org> Actors are great for hosting state machines
<re_irc_> <@d​irbaio:m​atrix.org> dkhayes117: you do `async fn` and let the compiler write the state machines for you :D
<re_irc_> <@d​khayes117:m​atrix.org> Christopher Hunt: Definately need to read through that later. Thx
<re_irc_> <@d​khayes117:m​atrix.org> dirbaio: Would that be more complex than needed for simple implementations? I know nothing of async ATM
<re_irc_> <@b​arafael:m​atrix.org> I've done a few state machines :) usually I had a type for each state, and then a wrapper type that has a generic marker for the state. Then, to switch between the states, you can define methods that take `self` and return the new state. This is known as type state programming and I like it a lot :)
<re_irc_> <@d​irbaio:m​atrix.org> yeah it depends on what you want to do, of course
<re_irc_> <@d​irbaio:m​atrix.org> often in C when you write a state machine you do it for nonblocking IO
<re_irc_> <@d​irbaio:m​atrix.org> and then stick it in your main loop to get polled
<re_irc_> <@d​irbaio:m​atrix.org> for these async is awesome
<re_irc_> <@b​arafael:m​atrix.org> Hmm, you could even do that same C thing but with nice enums
<re_irc_> <@d​irbaio:m​atrix.org> you write code that "looks" blocking (therefore much more readable) but is not
<re_irc_> <@b​arafael:m​atrix.org> using heapless queues and wfi, might be quite nice :D
<re_irc_> <@h​untc:m​atrix.org> Embassy-rs is also interesting on the embedded side. I'm presently implementing channels for it so that we can have our little state machines receive events from interrupts etc.
<re_irc_> <@h​untc:m​atrix.org> barafael: Yes, heapless is great.
<re_irc_> <@d​khayes117:m​atrix.org> Sounds cool, but you guys are getting a tad bit over my head 😳. Need the matrix plug in (from the movie)
<re_irc_> <@d​irbaio:m​atrix.org> hahaha 🔌
<re_irc_> <@b​arafael:m​atrix.org> dkhayes117: what kind of state machine do you have?
<re_irc_> <@d​khayes117:m​atrix.org> Just noob ones in C that are in a infinite case statment loop to control a little TI RSLK robot kit for line following and maze stuff.
<re_irc_> <@b​arafael:m​atrix.org> I'd say for that, start with enum :) use it in a match-in-a-loop like you would in C. You might encounter some difficulties with changing the data of the enum while matching on it.
<re_irc_> <@d​khayes117:m​atrix.org> I have an arduino nano running a walk behind, motorized golf cart. I thought about replacing it with a something using rust and do a state machine for motor control.
<re_irc_> <@l​achlansneff:m​atrix.org> Can a global allocator really not be set without nightly?
<re_irc_> <@f​irefrommoonlight:m​atrix.org> dkhayes117: RISC-V trailblazing would be great for the community, but of course, if you run into trouble, you may be on your own
<re_irc_> <@t​halesfragoso:m​atrix.org> Lachlan Sneff: You cant set the OOM handler which is mandatory in no_std
<re_irc_> <@l​achlansneff:m​atrix.org> :/
<re_irc_> <@l​achlansneff:m​atrix.org> I guess I'll use those
<re_irc_> <@l​achlansneff:m​atrix.org> Or maybe use nightly and `unsized_locals`.
<re_irc_> <@l​achlansneff:m​atrix.org> Oh, VLAs don't seem to be implemented yet
<re_irc_> <@w​illeml:m​atrix.org> Any ideas on why unsetting the flash from memory mapped causes a crash?
<re_irc_> <@w​illeml:m​atrix.org> (qspi flash)
<re_irc_> <@w​illeml:m​atrix.org> Although, now I am very unsure, because even though I know that there is data somewhere in the external flash, it thinks that there is none...
<re_irc_> <@w​illeml:m​atrix.org> (then entire flash reads as zeros)
<re_irc_> <@a​damgreig:m​atrix.org> if anything you might expect it to read as all-ones if it's not programmed :/
<re_irc_> <@w​illeml:m​atrix.org> And this is using known working firmware (firmware running from the qspi flash)
<re_irc_> <@o​ddstr13:m​atrix.org> all zeroes sound like it could be a solder bridge to GND on MISO
<re_irc_> <@o​ddstr13:m​atrix.org> or CS/SCL
<re_irc_> <@w​illeml:m​atrix.org> You mean on the debug port?
<re_irc_> <@o​ddstr13:m​atrix.org> I mean on the interface between the MCU and the flash chip
<re_irc_> <@w​illeml:m​atrix.org> Because i know that the OS is working (the current firmware (written in C++) is installed on the QSPI flash chip, and the device (calculator) is booting properly and I can use it)
<re_irc_> <@w​illeml:m​atrix.org> This is STM32CubeProgrammer interfacing with the MCU dumping the memory mapped flash
<re_irc_> <@o​ddstr13:m​atrix.org> alright, if different firmware can work it, then nvm my suggestion (I recently had a derp with a radio and a soldering iron myself)
<re_irc_> <@w​illeml:m​atrix.org> Oh, lol
<re_irc_> <@w​illeml:m​atrix.org> Oh, I know what my problem is, stm32cubeprogrammer is not reading it correcly (if I use probe-rs-cli to dump it gives the expected results of some being 0xff and others being the data that I want)
<re_irc_> <@o​ddstr13:m​atrix.org> took me only half an hour or so to figure out that I had shorted SCL to ground thanks to a logic analyzer :P
<re_irc_> <@w​illeml:m​atrix.org> although that means that reading from inside the MCU on memory mapped is broken, because the mcu thinks that everything is zeroes...
<re_irc_> <@w​illeml:m​atrix.org> Oddstr13: "only" half an hour
<re_irc_> <@w​illeml:m​atrix.org> that sounds like a long time
<re_irc_> <@o​ddstr13:m​atrix.org> well, 15-20 minutes of that was finding, connecting and configuring the logic analyzer, so not that bad :P
<re_irc_> <@o​ddstr13:m​atrix.org> add another 5 minutes of "why isn't it working?" first
<re_irc_> <@w​illeml:m​atrix.org> Oh, right, the whole, finding the equipment part, yeah, that's usually a considerable part of most of my debugging time...
<re_irc_> <@w​illeml:m​atrix.org> (except active projects, because each one gets its own desk space with all needed equipment) ;)
<re_irc_> <@o​ddstr13:m​atrix.org> willeml: …I wish I had that much desk space.
<re_irc_> <@w​illeml:m​atrix.org> I have few projects, I only have like 2 square meters of desk space
<re_irc_> <@w​illeml:m​atrix.org> everything else gets dumped into cardboard boxes, or onto a bed or something
xnor has quit [Ping timeout: 265 seconds]
<re_irc_> <@o​ddstr13:m​atrix.org> Depends on the definition of active project I guess, yea
<re_irc_> <@o​ddstr13:m​atrix.org> anyways, I can't help with the memory map stuff, so I should probably stop distracting :P
<re_irc_> <@w​illeml:m​atrix.org> Lol, no worries 🙂
<re_irc_> <@w​illeml:m​atrix.org> Ill come back and reformulate my question properly later, this room is too hot... It's gotta be like 36C...
emerent has quit [Ping timeout: 250 seconds]
<re_irc_> <@f​irefrommoonlight:m​atrix.org> willeml: I am going through a similar battle, but you need to post details
<re_irc_> <@f​irefrommoonlight:m​atrix.org> Your posts have been too vague to do anythign with
emerent has joined #rust-embedded
<re_irc_> <@f​irefrommoonlight:m​atrix.org> You've posted 0 code
<re_irc_> <@f​irefrommoonlight:m​atrix.org> Or talks about regs and data to write
Darius has quit [Read error: Connection reset by peer]
Darius has joined #rust-embedded