[Oberon] FPGA - nRF24L01 `RPI Net' server

[Jörg Straube]

Tomas

As Paul said: RTFM :-) For low level programming this is VERY important to understand the meaning of every single bit.
And in addition study SCC.Mod.

What does SCC do? As the chip is meant to reliably transmit a maximum of 32 byte at once, you need some kind of additional mechanism or logic (could be called „protocol“) on top of the chips capability to enable packet transfer of arbitrary length (especially >32 byte)
SCC implement this additional logic.

What is the approach SCC takes? By studying the code, you will find that SCC defines an own header (that will be transported as part of the first 32 byte chunk) to communicate to the other side the overall length of the packet.
This info helps the receiver to know upfront how many 32 byte chunks it has to receive to assemble the whole packet.

Let’s assume the sender and receiver constantly exchange a stream of 32 byte. Without having exchanged the packet length, the receiver has no chance to decide whether the 32 byte chunk it just received is part of the previous packet or is the start of a new packet.

There are other methods to do it (eg time based interpacket gap) but the header methods is in my view easier to start with.

br
Jörg

> Am 29.04.2018 um 00:25 schrieb Paul Reed <paulreed at paddedcell.com>:
> 
> Hi Tomas,
> 
>> I am somehow led to believe I chase some bad timing loops...
>> ...Not any wiser.
> 
> By now you have, I think, already achieved the equivalent of the most we
> ask of our students in the time protocol example, and then some.  To go
> beyond the reception of a simple regular broadcast message is indeed, as
> you have found, very challenging.
> 
> What I'm a bit concerned about is that you are describing a lot about the
> (assumed) operation of code, and very little about the specifics of the
> operation of the chip.  A better understanding of the chip at the
> low-level would, I think, allow you to verify more, and assume less.
> 
> For example, as described in section 7 of the datasheet, the nRF24L01
> packet-transfer protocol in the chip (Nordic calls it "Enhanced
> ShockBurst[TM]") uses error-checking (a configurable-length CRC) to verify
> the packet contents, and drops the packet if the CRC does not match.
> 
> So you won't be dealing with corrupt data (or control information), only
> missed packets - your "bogus length" is surely just data from later in the
> transmission, and somehow you have missed the packet containing the first
> 32 bytes - a framing error at a higher level, you might say.
> 
> If you have the stamina (and it certainly seems you do) I would certainly
> encourage you to continue, because you are sharpening some very general
> skills on a very real-world problem!
> 
> If you haven't already, I would advise you to make a very detailed study
> of section 9 of the datasheet, the register map.  There's lots of
> interesting stuff here.  For example, register 8, OBSERVE_TX, will give
> you a count of lost packets, ie packets transmitted but not acknowledged
> by the receiver (from the transmitter's point of view - the ack might have
> been sent but not received by the transmitter of course).  In a simple
> test, this count should of course match the number of packets lost as
> inferred from the software trace.
> 
> I hope you have by now dispensed with the library on the Pi and are
> talking to the chip yourself, controlling every aspect of its programming.
> After all, you have been doing this on the Oberon side, so the library
> offers little and is probably getting in the way of understanding - it may
> have helped in the beginning but I'm guessing you won't really be sure of
> some things unless you completely control them.  And you do need to be
> sure. :)
> 
> HTH
> Paul
> 
> 
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon