| 23 May 2020 |
| 17:24:49 |  jamesmunns | Saw that, awesome, thank you! |
| 17:25:42 | jamesmunns | Unrelated, does anyone have any objections to having the "automatic copy to RAM if you give a .text reference" for all embedded-hal trait impls? |
| 17:26:14 | jamesmunns | Right now we do it on some interfaces (like UARTE), but not all (like TWIM). This can cause drivers to break |
| 17:26:36 | jamesmunns | The decision we made before was "Okay for embedded-hal, not for 'native' interfaces" |
| 17:27:10 | jamesmunns | e.g. for direct HAL calls, return an error if the slice is in flash, but for embedded-hal, implicitly copy like 16 bytes at a time to RAM |
| 17:37:32 |  jschievink | I think that's the only way to not have device drivers randomly break on us, which would suck |
| 17:38:07 | jschievink | Hmm, what happens if a drivers does a 17 byte I²C transaction? can the hardware do that in 2 chunks? |
| 17:38:10 | jamesmunns | Yeah, I got bitten on the keyboard, I know Tanks got bit on the sensirion drivers |
| 17:38:33 | jamesmunns | Yeah, you can. You just don't trigger the STOP event |
| 17:38:36 | jamesmunns | err, task |
| 17:38:55 | jamesmunns | easier on SPI/I2C, because master controls the clock pulses anyway |
| 17:39:33 | jamesmunns | Some devices might not like the master pausing, but it should all be within spec |
| 17:41:17 | jschievink | cool, sounds good then |
| 18:33:05 |  yatekii | I am ok toi have implicit copies with embedded-hal as it's a tradeoff anyways :) |
| 20:25:31 |  therealprof | Definitely. |
| 24 May 2020 |
| 08:57:10 |  blueluna | Not very well versed in github collaboration. I would like to publish the nrf52833-pac crate for use in nrf52833-hal. Can I do that adding nrf-rs:nrf52 as owner? |
| 08:57:50 | blueluna | I also found some small errors, so I created a PR, https://github.com/nrf-rs/nrf52833-pac/pull/1 |
| 12:23:10 | |  trembel joined the room. |
| 25 May 2020 |
| 07:18:45 |  Hanno Braun | In reply to @blueluna:matrix.org
Not very well versed in github collaboration. I would like to publish the nrf52833-pac crate for use in nrf52833-hal. Can I do that adding nrf-rs:nrf52 as owner? Yes, nrf-rs crates should be co-owned by a nrf-rs team on crates.io. It might be better to use nrf-rs:all though and phase out the other teams (I think there is some agreement that the current team structure doesn't make sense anymore). |
| 07:47:12 | blueluna | Understood, thanks. |
| 09:38:58 | jamesmunns | Opened these issues, I plan to submit PRs for them this week:
- https://github.com/nrf-rs/nrf-hal/issues/149
- https://github.com/nrf-rs/nrf-hal/issues/150
|
| 09:39:27 | jamesmunns | Does anyone know if any of the other targets support SPIM3 or SPIM speeds faster than 8MHz? |
| 10:04:26 | jschievink | blueluna: I believe you might need to give crates.io access to the repo in order to add GH teams as owners |
| 10:04:51 | jschievink | I think there's instructions somewhere, but it isn't terribly obvious how it works |
| 10:12:47 |  korken89 | In reply to @jamesmunns:matrix.org
Does anyone know if any of the other targets support SPIM3 or SPIM speeds faster than 8MHz? I did a look before when we looked at designing a new product that needed > 16 MHz and none of the cheaper had this. Only nRF52840 from what I found :/ |
| 10:13:38 | blueluna | The nRF52833 have a 32 Mbps SPIM3. |
| 10:14:10 | jamesmunns | It might be applicable to the 5340 or 9160, yeah, i thought the 833 might as well. |
| 10:14:20 | jamesmunns | Thanks @blueluna! |
| 10:20:10 | korken89 | Would have loved atleast 16 MHz on the cheaper ones :P |
| 10:20:18 | korken89 | Now here I am using STM32L4s instead |
