Roadmap

Roadmap

This list describes the things that would be needed to create a platform on which an alternative firmware implementation could be provided, roughly in the right order.

• Creating an inventory of the components on the Barracuda board and their functions, and gathering technical information about these componentes where available.

• Find out what the testpads on the Barracuda PCB do - Identifying JTAG and UART would be really helpful here.

• Get a linux (console) shell to work on the current firmware to be able to get info about how the official software connects to the hardware. Memory maps, device drivers, etc

• Figure out which pieces are missing to drive the hardware - Does Reciva provide drivers to all hardware ? Is a bootloader provided ?

• Try to put as much pieces of the provided GPL code together to get a basic OS up and running. Find out how much Reciva added or modified of the original software packages.

• Get all the hardware components working: GPIO, LCD display, LEDs, buttons, usb, network, audio

Architecture

A first rough graph of the software architecture.

libreciva

Libreciva is a C library handling the communication with the reciva device drivers for LCD, keys, LEDs, mute, etc

(more here)

• A wrapper is created to access libreciva from the Lua scripting language

• A small test utility is available for testing the libreciva functionality while developing

Sharpfin control app

The sharpfin control application handles :

• User interface: The userinterface consists of a menu structure for configuring the radio. The menu is controlled using keys and LCD using libreciva

• Configuration database: The reciva control app manages a central configuration database with a friendly API to store and retrieve configuration data. Actual storage can be plain text files or any other format.

• Network configuration: The control app is responsible for configuring the wireless network using wpa_supplicant, dhcpclient, ifconfig, etc

Sharpfin audio app

This application handles the playing of audio. It is implemented as a daemon process which takes commands from the control app. The audio application handles:

• Retrieving audio from disk or network (libcurl?)

• Decoding audio using various libraries (libmad, libogg, etc)

• Resampling the audio to the fixed samplerate used by /dev/dsp

• Sending audio to /dev/dsp

Webserver

The HTTP server can be used to control and configure the radio using a web browser.