Skip to content

Conversation

tinstructor
Copy link

Contribution description

Basic support for the FSK configuration through the shell.

What it comes down to is that it allows you to set a number of channel spacings (much like you can set a number of symbol rates) and that the center frequency of each channel is adjusted accordingly in order to not have overlap between consecutive channels. I've also added some logic to set the number of available channels each time the channel spacing changes.

Usage example:

ifconfig 4 set phy_mode fsk
2019-10-03 14:09:30,524 - INFO # ifconfig 4 set phy_mode fsk
2019-10-03 14:09:30,525 - INFO # success: set PHY mode of interface 4 to FSK
> ifconfig 4 set channel_spacing 400
2019-10-03 14:09:44,570 - INFO #  ifconfig 4 set channel_spacing 400
2019-10-03 14:09:44,572 - INFO # success: set FSK Channel Spacing on interface 4 to 400
> ifconfig 
2019-10-03 14:09:49,929 - INFO #  ifconfig
2019-10-03 14:09:49,931 - INFO # Iface  4  HWaddr: 22:68  Channel: 2  NID: 0x23  PHY: FSK 
2019-10-03 14:09:49,932 - INFO #            modulation index: 1  2-FSK  symbol rate: 50 kHz  FEC: none  ch_space: 400 kHz 
2019-10-03 14:09:49,946 - INFO #           Long HWaddr: 22:68:31:23:94:F1:96:37 
2019-10-03 14:09:49,947 - INFO #            TX-Power: 0dBm  State: IDLE  max. Retrans.: 3 
2019-10-03 14:09:49,948 - INFO #           L2-PDU:102 Source address length: 2
> 

benpicco and others added 8 commits September 24, 2019 18:17
This patch adds support for setting PHY modes as specified in 802.15.4
as well as those added in IEEE 802.15.4g-2012.

If the driver implements support for it, this adds commands to configure

 - Chip/s & rate mode for O-QPSK
 - Modulation / Coding Scheme and Option for OFDM
 - Modulation Index, Modulation Order, Symbol Rate and Forward Error Correction for FSK

Modulation Index is represented as fractions on 64 to ease implementations.
This adds a driver for the SPI based AT86RF215 transceiver.
The chip supports the IEEE Std 802.15.4-2015 and IEEE Std 802.15.4g-2012 standard.

This driver supports two versions of the chip:
    - AT86RF215:  dual sub-GHz & 2.4 GHz radio & baseband
    - AT86RF215M: sub-GHz radio & baseband only

Both radios support the following PHY modes:
    - MR-FSK
    - MR-OFDM
    - MR-O-QPKS
    - O-QPSK (legacy)

All modulations are implemented, although not all options may be configurable.

The driver defaults to O-QPSK (legacy) at 250 kb/s on both bands for
compatibility with existing 802.15.4 devices.

To use both interfaces, add

GNRC_NETIF_NUMOF := 2

to your Makefile.

The transceiver is able to send frames of up to 2047 bytes according to
IEEE 802.15.4g-2012. This is not used by RIOT just yet.
The Sub-GHz Antenna of the Openmote-B is always connected to the AT86RF215.
It is the 2.4 GHz radial that can be switched between the CC2538 and the AT86RF215.

This changes the name of the defines accordingly.
Openmote-B includes an AT86RF215 radio. This adds support for it.
@benpicco
Copy link
Owner

benpicco commented Oct 7, 2019

Thank you!
I've split up the commit and merged it into my develop branch.

The option can also apply to O-QPSK, so I'll add that.

@benpicco benpicco force-pushed the at86rf215 branch 6 times, most recently from bc39753 to 06e382f Compare October 21, 2019 14:18
@benpicco benpicco force-pushed the at86rf215 branch 4 times, most recently from b25cc00 to bede125 Compare November 27, 2019 18:00
@benpicco
Copy link
Owner

Shouldn't channel spacing be a function of RXBWC?
So whenever I update this register, I should also update the channel spacing?

@benpicco
Copy link
Owner

(Closing since I already merged this PR manually)

@benpicco benpicco closed this Nov 29, 2019
benpicco pushed a commit that referenced this pull request Jun 10, 2020
When CDC ACM is used as stdio the first thread in the test may have a
different ID than #3. The test code will now look at the printed thread
information (id, prio) as they are created. This avoids the need for a
table with ID/prio.
benpicco pushed a commit that referenced this pull request Jun 10, 2020
When CDC ACM is used as stdio the first thread in the test may have a
different ID than #3. The test code will now look at the printed thread
information (id, prio) as they are created. This avoids the need for a
table with ID/prio.
benpicco pushed a commit that referenced this pull request Jun 10, 2020
When CDC ACM is used as stdio the first thread in the test may have a
different ID than #3. The test code will now look at the printed thread
information (id, prio) as they are created. This avoids the need for a
table with ID/prio.
benpicco pushed a commit that referenced this pull request Jun 10, 2020
When CDC ACM is used as stdio the first thread in the test may have a
different ID than #3.
benpicco pushed a commit that referenced this pull request Jun 11, 2020
…d IDs

When CDC ACM is used as stdio the first thread in the test may have a
different ID than #3. The test code will now look at the printed thread
information (id, prio) as they are created. This avoids the need for a
table with ID/prio.
benpicco added a commit that referenced this pull request Jan 28, 2022
The ENTROPY test always fails on this board

main(): This is RIOT! (Version: buildtest)
mbedtls test

  SHA-224 test #1: passed
  SHA-224 test #2: passed
  SHA-224 test #3: passed
  SHA-256 test #1: passed
  SHA-256 test #2: passed
  SHA-256 test #3: passed

  ENTROPY test: failed
benpicco pushed a commit that referenced this pull request Feb 15, 2023
19270: drivers/at24cxxx: implement _mtd_at24cxxx_read_page r=benpicco a=HendrikVE

### Contribution description

The function `read_page` was missing which lead to (from a user perspective) undefined behavior on the MTD layer.

### Testing procedure

Any application using MTD in conjunction with a board with an at24cxxx.


19271: core/xfa: disable asan on llvm r=benpicco a=Teufelchen1

### Contribution description
Hi! 🦎

When using llvm and address sanitation, the XFA trip the sanitizer.
This PR attempts to fix this by adding the `no_sanitize` attribute to the XFA macros. Sadly, this attribute is not known by gnu, a guard is hence needed. I'm open for alternatives as I dislike this solution but it is the best I could come up with.

### Testing procedure

Before this patch:

Go to `examples/gnrc_minimal` and run `TOOLCHAIN=llvm make all-asan` and then `make term`.
You should see an error similar to this:
```
==3374719==ERROR: AddressSanitizer: global-buffer-overflow on address 0x080774e0 at pc 0x0804af5e bp 0x0808eb88 sp 0x0808eb78
READ of size 4 at 0x080774e0 thread T0
    #0 0x804af5d in _auto_init_module /RIOT/sys/auto_init/auto_init.c:40
    #1 0x804af5d in auto_init /RIOT/sys/auto_init/auto_init.c:339
    #2 0x804b375 in main_trampoline /RIOT/core/lib/init.c:56
    #3 0xf76bc7b8 in makecontext (/lib32/libc.so.6+0x4a7b8)
...
``` 
After applying this PR, the example can be build and run with llvm or gcc, with or without asan.



Co-authored-by: Hendrik van Essen <hendrik.vanessen@ml-pa.com>
Co-authored-by: Teufelchen1 <bennet.blischke@haw-hamburg.de>
benpicco pushed a commit that referenced this pull request Feb 23, 2023
18392: drivers/servo: reimplement with high level interface r=benpicco a=maribu

### Contribution description

The previous servo driver didn't provide any benefit over using PWM directly, as users controlled the servo in terms of PWM duty cycles. This changes the interface to provide a high level interface that abstracts the gory PWM details.

In addition, a SAUL layer and auto-initialization is provided.

### Testing procedure

The test application provides access to the servo driver via the `saul` shell command.

```
> saul
2022-08-02 22:12:31,826 # saul
2022-08-02 22:12:31,827 # ID	Class		Name
2022-08-02 22:12:31,830 # #0	ACT_SWITCH	LD1(green)
2022-08-02 22:12:31,832 # #1	ACT_SWITCH	LD2(blue)
2022-08-02 22:12:31,834 # #2	ACT_SWITCH	LD3(red)
2022-08-02 22:12:31,837 # #3	SENSE_BTN	B1(User button)
2022-08-02 22:12:31,838 # #4	ACT_SERVO	servo
> saul write 4 0
2022-08-02 22:12:41,443 # saul write 4 0
2022-08-02 22:12:41,445 # Writing to device #4 - servo
2022-08-02 22:12:41,447 # Data:	             0 
2022-08-02 22:12:41,450 # [servo] setting 0 to 2949 (0 / 255)
2022-08-02 22:12:41,453 # data successfully written to device #4
> saul write 4 256
2022-08-02 22:12:45,343 # saul write 4 256
2022-08-02 22:12:45,346 # Writing to device #4 - servo
2022-08-02 22:12:45,347 # Data:	           256 
2022-08-02 22:12:45,351 # [servo] setting 0 to 6865 (255 / 255)
2022-08-02 22:12:45,354 # data successfully written to device #4
```

Each write resulted in the MG90S servo that I connected to move to the corresponding position.

### Issues/PRs references

Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
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.

2 participants