dgoodlad has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
GenTooMan has joined #rust-embedded
snowyforest has quit [Quit: WeeChat 3.6]
starblue3 has quit [Ping timeout: 246 seconds]
starblue3 has joined #rust-embedded
crabbedhaloablut has quit []
duderonomy has quit [Ping timeout: 245 seconds]
duderonomy has joined #rust-embedded
_whitelogger has joined #rust-embedded
<re_irc>
<@arnoldanderson:matrix.org> Hello there! Guys, can you, please, recommend some UWB module? Cost is not the question, I need some module with range at least 5-10 meters and more accurate for its cost -- better
<re_irc>
<@shakencodes:matrix.org> if I am trying to conditionally compile code that shows up only on my embedded target (an STMicro STM32WLe5 Cortex-M4 core, compiled as thumbv7em-none-eabi), I am trying to use this cfg statement, but am not getting the code included:
<re_irc>
#[cfg(target_arch = "thumbv7em")]
<re_irc>
Where am I going wrong? I thought target_arch is the first third of the target triple.
<re_irc>
<@hanno:braun-odw.eu> : The "cortex-m" crate does some handling of the targets in its "build.rs" (https://github.com/rust-embedded/cortex-m/blob/master/build.rs). I'm not sure how those "cfg"s it generates are scoped. I think "cortex-m" creates them for its own use, but maybe you can access them from your own crate?
<re_irc>
<@hanno:braun-odw.eu> At the very least you could replicate their approach in a "build.rs" of your own, I guess.
<re_irc>
<@shakencodes:matrix.org> : That did it. Thank you! (It is way too late at night to be coding here...)
<Lumpio->
Technically it's a register and not a command
<Lumpio->
And the table specifies the value the register is automatically set to when the chip is reset in various ways
<re_irc>
<@ppavacic:matrix.org> Lumpio-: yes that was what was wird to me, why is it under CommanX_BLKX, thanks!
<Lumpio->
I guess if you want to be pedantically correct it lists the default return value of this read command
<Lumpio->
...but I'm sure internally it's a register. Rather than talking about registers they've just decided to list them as read/write commands.
<re_irc>
<@ppavacic:matrix.org> I want it to be technically correct, the best kind of correct.
<re_irc>
<@larunite:matrix.org> That looks like an ilitek LCD driver datasheet
<re_irc>
<@larunite:matrix.org> In which case command is the general term they use for all i2c endpoints
<re_irc>
<@like2wise:matrix.org> 'Tasks' (Nordic nRF series) or 'Commands' are typically implemented as registers with side-effects (other than storing the written value). These are also the type of registers that must never be accessed out of order, and always with barriers.
<re_irc>
<@azzentys:matrix.org> Hey all! Thanks for always being responsive!
<re_irc>
I was wondering if there's a quickstart for using stm32f4xx-hal or any other hal for a small project.
<re_irc>
<@azzentys:matrix.org> I usually get started, then after a few months forget how things are done again.
<re_irc>
<@azzentys:matrix.org> For me, cortex-m-quickstart was giving linker errors to me. Switched to gcc ld instead.
<re_irc>
<@stephen:crabsin.space> This isn't super rust-related but how do people going about designing SPI slaves?
<re_irc>
My thinking is I could use DMA to set up a big multi-hundred-byte buffer full of garbage, so that when the master clocks the bus, I have time to process the data
<re_irc>
<@stephen:crabsin.space> I.e. the DMA buffer would be full of 0x00 and when the mcu is done processing data, it would switch out the DMA buffer for 0xff followed by the response. And that's how the master would know it's no longer receiving garbage and is instead receiving the real stuff
<re_irc>
<@azzentys:matrix.org> : This is really good for stm32!
<re_irc>
<@azzentys:matrix.org> +Thanks a lot!
<re_irc>
<@larunite:matrix.org> : That would be a fairly odd spi interface. Most devices I've worked with specify something like "clock N bytes out and then you get the actual data"
<re_irc>
<@larunite:matrix.org> The problem with saying "clock me until you get FF and then there's data" is it's non deterministic, so the master has to actively watch the data it's getting to know what to do. So your master can't, for example, just set up a dma spi transaction and then forget about it
<re_irc>
<@larunite:matrix.org> BUT I will also say if you do just want to transfer garbage for a while, you don't need a big buffer. You can just set up the dma to not increment the memory transfer address, it will keep clocking out the same byte over and over
<re_irc>
<@thejpster:matrix.org> I designed my SPI peripheral device to always know how many bytes are coming.
<re_irc>
<@stephen:crabsin.space> FreeKill: The si4463 transceiver chip does that, which is why it's what I thought of first
<re_irc>
<@stephen:crabsin.space> I'm writing the software for both the master and the slave so I'm not too concerned about it being odd. Determinism scares me because if the slave takes too long (i.e. has to service an interrupt that takes a little while) then it could screw things up
dc740 has joined #rust-embedded
<re_irc>
<@larunite:matrix.org> Another way to do it which is more friendly to the master is to include a "busy" line
<re_irc>
<@larunite:matrix.org> So you start the transfer, it raises the busy line. When it goes low again it's ready to read from
<re_irc>
<@larunite:matrix.org> That's reasonably conventional - and it saves you wasted traffic on the spi
<re_irc>
<@stephen:crabsin.space> hmm that's probably a better idea
dc740 has quit [Remote host closed the connection]