AES electronic codebook implementation and example #145
Conversation
|
No fmt on nightly :/ |
Well, it will always be moved to RAM during runtime anyways, because access in flash surely is slower, no? |
|
Also see: https://github.com/nrf-rs/nrf51-hal/blob/master/src/ecb.rs (looks like it was missed by the port) |
It has to be in RAM because of the EasyDMA, otherwise it can cause hardfaults or memory corruptions. @jonas-schievink Oh, I didn't know about that. Do you prefer that API ? It seems more straight forward than mine, but with more copying (possibly). Anyway, I should also add a method to change the key. |
|
The nRF51 API has no persistent memory usage, that part as least seems preferable to me. |
I changed the API, let me know what you think. |
| # This is exclusive and cannot be used with RTT at the moment. | ||
| enabled = false | ||
| # The connection string in host:port format wher the GDB server will open a socket. | ||
| # gdb_connection_string |
There was a problem hiding this comment.
Is it normal to check this file into git?
There was a problem hiding this comment.
Yes, this file is meant to be checked into git, assuming you/your users use cargo embed :)
| 51 = ["nrf51-hal"] | ||
| 52810 = ["nrf52810-hal"] | ||
| 52832 = ["nrf52832-hal"] | ||
| 52840 = ["nrf52840-hal"] |
There was a problem hiding this comment.
We now have support for the 52833 as well
There was a problem hiding this comment.
Also the new HAL needs to reexport this
Pretty straight forward implementation.
There's just one thing that I want a confirmation, I'm not checking if the data structure is in RAM since neither the method for creating
EcbDatanorEcbareconst, am I wrong in assuming thatEcbDatawill always be in RAM ?