staging: pi433: Fixed typos and grammar in documentation
Some typos and grammar issues were found in the documentation. These mistakes were fixed. Signed-off-by: Shannon Booth <shannon.ml.booth@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This commit is contained in:
parent
3be5d1cb3f
commit
fb407e32ea
|
@ -46,10 +46,10 @@ It consists of the three gpio pins and an spi interface (here chip select 0)
|
|||
|
||||
For Raspbian users only
|
||||
=======================
|
||||
Since Raspbian supports device tree overlays, you may use and overlay, instead
|
||||
Since Raspbian supports device tree overlays, you may use an overlay instead
|
||||
of editing your boards device tree.
|
||||
For using the overlay, you need to compile the file pi433-overlay.dts you can
|
||||
find aside to this documentation.
|
||||
To use the overlay, you need to compile the file pi433-overlay.dts which can
|
||||
be found alongside this documentation.
|
||||
The file needs to be compiled - either manually or by integration in your kernel
|
||||
source tree. For a manual compile, you may use a command line like the following:
|
||||
'linux/scripts/dtc/dtc -@ -I dts -O dtb -o pi433.dtbo pi433-overlay.dts'
|
||||
|
|
|
@ -8,11 +8,11 @@ Introduction
|
|||
This driver is for controlling pi433, a radio module for the Raspberry Pi
|
||||
(www.pi433.de). It supports transmission and reception. It can be opened
|
||||
by multiple applications for transmission and reception. While transmit
|
||||
jobs were queued and process automatically in the background, the first
|
||||
jobs are queued and processed automatically in the background, the first
|
||||
application asking for reception will block out all other applications
|
||||
until something gets received terminates the read request.
|
||||
The driver supports on the fly reloading of the hardware fifo of the rf
|
||||
chip, thus enabling for much longer telegrams then hardware fifo size.
|
||||
chip, thus enabling for much longer telegrams than the hardware fifo size.
|
||||
|
||||
Discription of driver operation
|
||||
===============================
|
||||
|
@ -46,10 +46,10 @@ configuration set is written to the rf module and it gets set into receiving mod
|
|||
Now the driver is waiting, that a predefined RSSI level (signal strength at the
|
||||
receiver) is reached. Until this hasn't happened, the reception can be
|
||||
interrupted by the transmission thread at any time to insert a transmission cycle.
|
||||
As soon as the predefined RSSI level is meat, a receiving cycle starts. Similar
|
||||
As soon as the predefined RSSI level is met, a receiving cycle starts. Similar
|
||||
as described for the transmission cycle the read out of the hardware fifo is done
|
||||
dynamically. Upon each hardware fifo threshold interrupt, a portion of data gets
|
||||
read. So also for reception it is possible to receive more data then the hardware
|
||||
read. So also for reception it is possible to receive more data than the hardware
|
||||
fifo can hold.
|
||||
|
||||
|
||||
|
@ -225,7 +225,7 @@ rf params:
|
|||
isn't found, telegram will be internally discarded
|
||||
optionOff - sync detection is disabled.
|
||||
enable_length_byte
|
||||
optionOn - First byte of payload will be used as length byte,
|
||||
optionOn - First byte of payload will be used as a length byte,
|
||||
regardless of the amount of bytes that were requested
|
||||
by the read request.
|
||||
optionOff - Number of bytes to be read will be set according to
|
||||
|
|
Loading…
Reference in a new issue