Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

clarify dump bit behavior #6

Closed

Conversation

Poofjunior
Copy link

Addresses #5

Clarifies the behavior of what Harp devices do when the R_OPERATION_CTRL DUMP bit is written to.

filcarv and others added 30 commits July 12, 2020 16:01
@filcarv
Copy link
Contributor

filcarv commented Oct 12, 2023

I'm not sure if we need to have this part in the text, because reply to a WRITE message is part (bold) of the default communication.

When written to 1, the device replies with a harp WRITE reply from this register, followed by a series of READ replies for all core and app registers, one reply per register. This bit is always read as 0.

@Poofjunior
Copy link
Author

@filcarv right, but since writing to this message additionally includes one READ reply per register, it's unclear whether the default WRITE reply should happen at the beginning, the end, at any point, or even at all.

@glopesdev
Copy link
Collaborator

Feedback from SRM meeting:

  • Should registers be returned in order (feedback was that it doesn't
  • Device should return a WRITE reply to the command
  • Device should then return N replies. Should registers be returned in order? Currently in ATMEL implementation common and user registers are in different places:
    • From 1 to 15, then 32 to N
    • Replies are interleaved in time not to overload the CPU
      • also some registers might take non-insignificant time to read, e.g. ADC

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants