The sampling timer and the timestamping timer have the same period.
The sampling interval and the batch size are powers of two.
If the timestamping timer wraps at a power of two larger than the
batch period, it will wrap in sync with the batch period.
Even if it didn't the RPLL would handle that. But it requires that the
timer wraps at the u32/i32 boundary (or be shifted left to wrap there).
* origin/master:
more nightly clippy lints
clippy lints
gha: clippy-check
build(deps): bump paste from 1.0.2 to 1.0.3
build(deps): bump panic-semihosting from 0.5.4 to 0.5.6
* origin/master:
more nightly clippy lints
clippy lints
gha: clippy-check
build(deps): bump paste from 1.0.2 to 1.0.3
build(deps): bump panic-semihosting from 0.5.4 to 0.5.6
* origin/master:
Adding comment about checking for flag pass completion
Adding comments about execution hanging to transfer complete waits
Removing default parameter settings
Updating DAC SPI structures to own HAL SPI structure for safety guarantees
Moving constants to a new file
Removing copy to DAC buffers, adding in-place borrow of output buffers
Marking AXISRAM as NOLOAD
Refactoring timer channels to macros, adding safety notes
Adding DMA support for DAC writes
Adding sampling_timer file
Adding compile-time management of TIM2 channels
Reverting changeset
Adding documentation
Reverting openocd change
Adding updated docs for adc file
Combining ADC + DAC ISRs
Adding WIP updates
Formatting
Adding ADC/DAC modules
Adding WIP updates to using DMA
This was triggered by moving log_init and adding i2c_init on top of
the existing ethernet setup/init after the timer setup and enable.
Thanks @cjbe for debugging.
Also move the RCC peripheral enable calls out of i2c and eth setup.
close#55
supersedes #62
The CPU is allowed to access normal memory writes out-of-order. Here
the write to the OWN flag in the DMA descriptor (normal memory) was
placed after the DMA tail pointer advance (in device memory, so not
reorderable). This meant the ethernet DMA engine stalled as it saw
a descriptor it did not own, and only restarted and sent the packet
when the next packet was released.
This fix will work as long as the CPU data cache is disabled. If we
want to enable the cache, the simplest method would be to mark SRAM3
as uncacheable via the MPU.
Previously, if a message spanned the end of the
receive ring buffer, the last byte in the buffer
would be missing from the to-be-decoded message,
leading to a parse error or panic.
With this commit, >3M commands were exchanged
over one socket without further issues.
28: Read MAC address from EEPROM r=jordens a=cjbe
Try and read the unique MAC address from EEPROM.
If the EEPROM can not be read (e.g. on the unpatched hardware version 1.0 where the EEPROM is unpowered) a hardcoded default of 10:E2:D5:00:03:00 is used.
The MAC address found / used is logged. At the moment the only way of accessing this log is via semihosting.
Closes#23
30: build(deps): bump serde from 1.0.99 to 1.0.100 r=jordens a=dependabot-preview[bot]
Bumps [serde](https://github.com/serde-rs/serde) from 1.0.99 to 1.0.100.
<details>
<summary>Release notes</summary>
*Sourced from [serde's releases](https://github.com/serde-rs/serde/releases).*
> ## v1.0.100
> - Provide `serde::ser::StdError` and `serde:🇩🇪:StdError` which are either a re-export of `std::error::Error` (if Serde's "std" feature is enabled) or a new identical trait (otherwise).
>
> ```rust
> #[cfg(feature = "std")]
> pub use std::error::Error as StdError;
>
> #[cfg(not(feature = "std"))]
> pub trait StdError: Debug + Display {
> fn source(&self) -> Option<&(StdError + 'static)> { None }
> }
> ```
>
> Serde's error traits `serde::ser::Error` and `serde:🇩🇪:Error` require `std::error::Error` as a supertrait, but only when Serde is built with "std" enabled. Data formats that don't care about no\_std support should generally provide their error types with a `std::error::Error` impl directly:
>
> ```rust
> #[derive(Debug)]
> struct MySerError {...}
>
> impl serde::ser::Error for MySerError {...}
>
> impl std::fmt::Display for MySerError {...}
>
> // We don't support no_std!
> impl std::error::Error for MySerError {}
> ```
>
> Data formats that *do* support no\_std may either have a "std" feature of their own as has been required in the past:
>
> ```toml
> [features]
> std = ["serde/std"]
> ```
>
> ```rust
> #[cfg(feature = "std")]
> impl std::error::Error for MySerError {}
> ```
>
> ... or else now may provide the std Error impl unconditionally via Serde's re-export:
>
> ```rust
> impl serde::ser::StdError for MySerError {}
> ```
</details>
<details>
<summary>Commits</summary>
- [`b6a77c4`](b6a77c4413) Release 1.0.100
- [`3343885`](33438850a6) Merge pull request [#1620](https://github-redirect.dependabot.com/serde-rs/serde/issues/1620) from dtolnay/error
- [`c083cfd`](c083cfd65e) Export std error type so downstream doesn't need "std" feature
- [`4cea81f`](4cea81f93f) Merge pull request [#1615](https://github-redirect.dependabot.com/serde-rs/serde/issues/1615) from jamesmunns/patch-1
- [`2d36be7`](2d36be753a) Add Postcard to the list of Serde Data Formats
- [`738d29e`](738d29eaa9) Update serde_derive_internals to syn 1.0
- [`b536fb6`](b536fb67a4) Merge pull request [#1604](https://github-redirect.dependabot.com/serde-rs/serde/issues/1604) from UnHumbleBen/patch-1
- [`b10c23a`](b10c23a950) Fixed a typo
- [`85a5cf7`](85a5cf7cb1) Document serde_derive minimum rustc
- See full diff in [compare view](https://github.com/serde-rs/serde/compare/v1.0.99...v1.0.100)
</details>
<br />
[](https://dependabot.com/compatibility-score.html?dependency-name=serde&package-manager=cargo&previous-version=1.0.99&new-version=1.0.100)
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
- `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
- `@dependabot use these labels` will set the current labels as the default for future PRs for this repo and language
- `@dependabot use these reviewers` will set the current reviewers as the default for future PRs for this repo and language
- `@dependabot use these assignees` will set the current assignees as the default for future PRs for this repo and language
- `@dependabot use this milestone` will set the current milestone as the default for future PRs for this repo and language
- `@dependabot badge me` will comment on this PR with code to add a "Dependabot enabled" badge to your readme
Additionally, you can set the following in your Dependabot [dashboard](https://app.dependabot.com):
- Update frequency (including time of day and day of week)
- Automerge options (never/patch/minor, and dev/runtime dependencies)
- Pull request limits (per update run and/or open at any time)
- Out-of-range updates (receive only lockfile updates, if desired)
- Security updates (receive only security updates, if desired)
Finally, you can contact us by mentioning @dependabot.
</details>
Co-authored-by: Chris Ballance <chris.ballance@physics.ox.ac.uk>
Co-authored-by: dependabot-preview[bot] <27856297+dependabot-preview[bot]@users.noreply.github.com>
