Synchronous/Asynchronous CC430 Radio Support

[kb1lqd]

Overview

It is likely that in the future Faraday will split into two main projects:

• A smart node digital radio with radio and communication processes controls on the CC430
• A (mostly) dumb radio module that allows a more powerful processor perform the communications such as a Raspberry Pi. Interactions with Faraday in this mode would largely be that of a raw modem interface through UART/SPI/CC1101 GDx pins

Texas Instruments provides a basic overview of the radio operations possible with the CC430: http://www.ti.com/lit/an/slaa465c/slaa465c.pdf

The example RF code is located here: http://www.ti.com/lit/zip/slac525

Actions

Since all the default port mapping is used for RF GDx pins and it's a secondary function we should implement port mapping. Port mapping is supported on P1, P2, and P3. We should swap 3 of the GPIO pins using port 4 with port 3 pins to allow a GPIO pin to become an RF GD0 pin.

Swap with basic I/O pins used on GPS and other devices:

Recommend swapping:

4.0 <-> 3.2 4.1 <-> 3.3 4.2 <-> 3.4

This Should allow for low risk swapping and peripheral operation while allowing a port mapped GDx signals to the external pins.

Details

Hardware Packet Handling (Less Than/Greater Than FIFO)

No changes needed, all of this is handled in the firmware. Key points:

• Really simple 64 byte FIFO operation
• Capability to have unlimited packet size operation
• Must still use general packet hardware structure and sync headers

  Synchronous/Asynchronous Operations

Synchronous/Asynchronous operation allows for direct access to the CC1101 radio core. This allows for the most flexibility in radio protocols as well as the ability to perform low level protocol processing on a more powerful platform.

Asynchronous

Requires the use of internal timers.

Synchronous

Port Mapping

Radio GD0 Pins

Examples

Clock timer output to 2.7 Data output 2.6

The CC430 header file snippet above shows Port 3 but Port 2 is the same.

[kb1lqc]

Upon inspection, I'd much rather use signals already traveling to the general CC1190 and GPIO pin area so I minimally affect my routing scheme. This means initially I'd like to perform the following IO changes:

• P3.0 to P4.5
• P3.1 to P4.6
• P3.2 to P4.7

This forces the CC1190 control signals to be moved over to GPIO channels. Since these signals generally route to the same area of the PCB this then results in minimal impact to the design.

[kb1lqd]

@kb1lqc OK that makes sense. I should double check that all P4 GPIO do infact work as intended.

[kb1lqc]

OK I updated and swapped the mentioned P3 and P4 signals. This was much easier to route since the channels all went to the same area of the PCB. This was changed in 4786a6094c6b3ada832c1a492106f61978195773.

[kb1lqc]

Closing this issue as it was addressed in Issue #1