Why do you need the actual ACK frame? It's only like 3 bytes + FCS and
doesn't really contain anything interesting. The only interesting
information is that the frame with the given sequence id was received
properly, which is exactly the same information you get from the
transceiver hardware.
Hi Craig,
That's great news and I am stoked to see support for RISC-V in RIOT.
To my knowledge nobody put real effort into that yet. (I'm happy to be
corrected!)
If you need help or guidance on porting please don't hesitate to ask on
this list.
Thanks and good luck for your funding
Hi Baptiste,
you could try reading out the frame buffer after that
although I am not sure the current mode of operation actually
updates the frame buffer with the ACK frame.
(The data sheet is also kind of unspecific on this.)
Other than that I don't see an easy solution, only porting
the
I am preparing a funding proposal in the U.S., and am contemplating a
port of RIOT to the 32-bit RISC-V architecture. We have HiFive
development boards from SiFive.com, as well as FPGA platforms, to
work on a project trying to provide hardware security support for
32-bit RISC-V MCU variants.
Which mean that automated ACK by the transceiver is fine.
1 - RIOT sends a frame
2 - Transceiver receives an ACK and transmit a AT86RF2XX_TRX_STATE__TRAC_SUCCESS
3 - Here I want to get the ACK frame content
4 - Use it with openthread (Have a look here [1] to understand why we need it)
[1]
