Skip to content

Update transmit and receive firmware to meet timing requirements#106

Draft
mohamed-dek1 wants to merge 5 commits intofeature/dcp-amds-firmwarefrom
feature/dcp-amds-firmware-improved-transmit
Draft

Update transmit and receive firmware to meet timing requirements#106
mohamed-dek1 wants to merge 5 commits intofeature/dcp-amds-firmwarefrom
feature/dcp-amds-firmware-improved-transmit

Conversation

@mohamed-dek1
Copy link
Copy Markdown
Contributor

@mohamed-dek1 mohamed-dek1 commented Mar 27, 2026 •
edited
Loading

Closes #104

Notes

Anything reviewers should be aware of when reviewing? Other related issues? Known problems? Future work?

Self-Review

In this section, please self-review (answer all questions) on a suitable review checklist prior to requesting review from others. Select a review checklist based on what content is being merged in; see the Review Checklists section.

Reviewer Instructions

Reviewers, please copy and paste a suitable review checklist into your review and answer all questions.

Appendix

This section should be the same for all PRs. Do not edit this section when creating a PR.

Review Checklists

Checklists maintained by the eLev lab for research repositories include:

Standard checklist

1. Are all files under 300 kB (if not, please carefully assess whether it is worth committing them)? **Yes or No**
2. Are all files named according to the appropriate [naming convention](https://github.com/Severson-Group/research-repo-template?tab=readme-ov-file#file-naming), i.e., dash-case, camelCase, snake case? **Yes or No**
3. Do all Markdown files follow the [CONTRIBUTING article template](https://github.com/Severson-Group/.github/blob/main/CONTRIBUTING.md#markdown-documentation-template)? **Yes or No**
4. Do all links work in the material that the PR is adding? **Yes or No**
5. Is the PR configured to close the correct issue(s)? **Yes or No**
6. Did the PR fully address the `Approach` section of the issue(s) it is closing? **Yes or No**

Please work on addressing any **No** items.

@mohamed-dek1 mohamed-dek1 requested a review from elsevers March 27, 2026 16:23
@mohamed-dek1 mohamed-dek1 changed the title add current transmit implementation Update transmit and receive firmware to meet timing requirements Mar 27, 2026
@mohamed-dek1
Copy link
Copy Markdown
Contributor Author

mohamed-dek1 commented Apr 6, 2026

Per 4/6:

With the most recent firmware changes, I've been able to bring the sensor acquisition delay down to about 49us or a max of 20kHz. Since it takes about 6us to send one AMDS worth of data, 2 boards would take about 12us. This is on top of the 11us for a full transmission of one AMDS set of data. Therefore, 3 sets of AMDS data should take approximately 23us. If you add 1-2us for processing incoming data, that would bring us to roughly 27us or a max of 37.04kHz. This means that with a perfect daisy-chain, we still wouldn't be able to meet the timing requirement of 50kHz.

image

@elsevers
Copy link
Copy Markdown
Contributor

elsevers commented Apr 7, 2026

Thanks @mohamed-dek1. I see your approach here with drv_uart_putc_fast.

One minor point in process_single_byte()

AMDS/Mainboard/Firmware/motherboard_v1/Core/Src/drv_uart.c

Lines 94 to 105 in 0e58045

case STATE_GOT_HEADER:
track->data[0] = byte;
track->state = STATE_GOT_MSB;
break;
case STATE_GOT_MSB:
track->data[1] = byte;
// --- CUT-THROUGH TRANSMISSION ---
// The exact microsecond the packet is complete, blast it out
drv_uart_putc_fast(target_uart, track->data[0]);
drv_uart_putc_fast(target_uart, track->data[1]);

Move this function call drv_uart_putc_fast(target_uart, track->data[0]); from line 104 to 95 to slightly speed things up

Bigger point: only send sensor card data that the AMDC needs

Yes, you have hit the crux of the issue: if we daisy chain 3x AMDS's deep and send all 8 sensor cards worth of data, we will never hit timing. As soon as we have this implementation going as fast as we can get it, we need to make the AMDS's only transmit data that the AMDC wants them to send: this could be done by:

  • detecting what sensor cards are present and only transmitting those cards
  • or having the AMDC tell the AMDS which cards to transmit data for (this is the best, of course, but maybe tricky to implement?).

For now, our agreement from our discussion on the whiteboard the other week was to have a variable that in the AMDS code that indicates which sensor cards to try to read/send data on. Later, we can figure out how this variable gets updated. But for now, assume a variable so you can get the logic implemented for how you read ADCs and send their data.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@elsevers elsevers Awaiting requested review from elsevers elsevers is a code owner

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@mohamed-dek1 @elsevers