Roadmap

From Sharpfin
Jump to navigation Jump to search

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.


Architecture

A first rough graph of the software architecture.

Sharpfin.svg


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

The sharpfin audio 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.