v/maiana
1
0
Fork 0
mirror of https://github.com/peterantypas/maiana.git synced 2025-06-01 15:20:40 -07:00
Code Issues Projects Releases Wiki Activity

README

Browse Source
This commit is contained in:
Peter Antypas 2016-06-14 15:02:14 -07:00
parent 5d8df7084a
commit dd98d274fa
1 changed files with 17 additions and 15 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

32
README.md
View File

@ -8,31 +8,33 @@ the source code for the microcontroller. The source code project requires Eclips
else if there is enough interest and participation. else if there is enough interest and participation.
## Overall architecture ## Overall description
### Hardware
On the hardware side, the design is based on two Silicon Labs 4463 transceiver ICs and an STM32F302CBT6 ARM Cortex M4 microcontroller. On the hardware side, the design is based on two Silicon Labs 4463 transceiver ICs and an STM32F302CBT6 ARM Cortex M4 microcontroller.
The GPS is a GlobalTop "LadyBird" unit, but any decent GPS module with NMEA and PPS output should work. The GPS is a GlobalTop "LadyBird" unit, but any decent GPS module with NMEA and PPS output should work.
The receiver incorporates a bandpass / LNA (NXP BGA2869) and a Skyworks 66100 front end (PA/switch). The radio incorporates an external bandpass / LNA (NXP BGA2869) and a Skyworks 66100 front end (PA/switch).
The transmitter output is nominally 0.5Watts (+27dBm) and it has a verified range of 5 nautical miles with a vanilla telescopic antenna (< 3dBi). The transmitter output is nominally 0.5Watts (+27dBm) and it has a verified range of 5 nautical miles with a vanilla telescopic antenna (< 3dBi).
The circuit is powered entirely from a USB connection which also delivers NMEA (GPS + AIS) data to the host. It draws 135 mA in RX mode, The circuit is powered entirely from a 5V connection (USB for now, but leaning against it long term). It draws 135 mA in RX mode,
and spikes up to 350 mA during transmission at full power. For persisting station data there is a 1Kbit Microchip EEPROM on board. and spikes up to 350 mA during transmission at full power. For persisting station data there is a 1Kbit Microchip EEPROM on board.
I intend to use a Raspberry Pi as the front end of the transceiver, as the unit is supposed to be mounted outside, directly connected to its own antenna.
The Pi will act as a source of power, a WiFi Access Point, a NMEA distributor and a web server for configuration and software updates. All communication between the transponder
and the Pi is done over a single serial port.
The microcontroller communicates with the two RF ICs using the same SPI bus (SPI1), so SPI operations cannot overlap. Persistent station data (MMSI, call sign, name, dimensions, etc) is stored on a 1Kbit EEPROM attached to I2C1. Remarkably, it works fine with the MCU's
That's why after initialization and interrupt configuration, *all SPI transactions occur in interrupt mode*. The EEPROM internal pull-ups, but I updated the design to include external pull-up resistors on the SDA and SCL lines. The code should be modified if you choose to
is attached to I2C1. Remarkably, it worked fine with the MCU's internal pull-ups, but I updated
the design to include external pull-up resistors on the SDA and SCL lines anyway. The code should be modified if you choose to
install those. install those.
### Software
On the software side, the microcontroller runs in both thread and interrupt mode. After hardware initialization, There are two programs that need to be installed on the flash. The bootloader and the main application. The bootloader is
optional, but it allows for software update via a very simple (albeit proprietary) serial protocol.
On the software side, unlike most examples you see online the microcontroller runs in _both_ thread and interrupt mode. After hardware initialization,
*main()* dispatches events while keeping the watchdog happy. Interrupt code performs as little work as possible *main()* dispatches events while keeping the watchdog happy. Interrupt code performs as little work as possible
and queues up events for non-real time operations to be processed in thread mode. and queues up events for non-real time operations to be processed in thread mode. There is no operating system, and I could never
justify the overhead of one.
Memory is managed almost entirely using pre-allocated pools of objects (RX and TX packets, NMEA sentences, etc).
Instead of using ST Micro's semihosting for debug output, I implemented *printf2()* (see printf2.cpp) which writes to USART2 at
a very high speed (230400 bps). This allowed me to identify issues when running "release" code with no debugger attached,
which as you might suspect behaves quite differently with respect to timing.
Lastly, I opted for the Standard Peripheral Library instead of HAL/CubeMX because I found it to be more stable. The library is included here. Lastly, I opted for the Standard Peripheral Library instead of HAL/CubeMX because I found it to be more stable. The library is included here.