Atmel Studio also includes a number of example projects that came handy when I was finding out how to make individual peripherals work.
WatchDog ARM_WATCHDOG.c
One thing to do straight away in the script, unless you already know that you want to implement it, is to disable WatchDog which is enabled by default. Otherwise it means that the mcu resets every 8 seconds or so.
1 2 3 4 | int main(void) { SystemInit(); WDT->WDT_MR = WDT_MR_WDDIS; // disable WatchDog (enabled by default) |
This can be done by writing the WDT_MR_WDDIS bit in the WDT_MR register as shown above. The line 4 also demonstrates general way of accessing registers in the code.
#define RTT (0x400E1430U) /**< \brief (RTT ) Base Address */ #define WDT (0x400E1450U) /**< \brief (WDT ) Base Address */ #define RTC (0x400E1460U) /**< \brief (RTC ) Base Address */
The WDT bit represents a specific base address in the memory for all the registers of one peripheral.
typedef struct { WoReg WDT_CR; /**< \brief (Wdt Offset: 0x00) Control Register */ RwReg WDT_MR; /**< \brief (Wdt Offset: 0x04) Mode Register */ RoReg WDT_SR; /**< \brief (Wdt Offset: 0x08) Status Register */ } Wdt;
The WDT_MR part then represents an offset of the specific register from the base address.
#define WDT_MR_WDDIS (0x1u << 15) /**< \brief (WDT_MR) Watchdog Disable */
And finally WDT_MR_WDDIS refers to the desired bit operation. In this case writing the bit 15 to '1' and all the other bits in the register to '0'. All this information is nicely shown by Atmel Studio upon right clicking the part of interest and choosing 'Goto Implementation'.
WatchDog is a safety feature that resets the mcu after a specific time. This is avoided by including commands to reset the WatchDog counter at specific places in the script. In case the execution of the code hangs at some point the counter runs out and resets the mcu. If the execution goes according to the plan the WatchDog reset command stops it from resetting the mcu and starts another round of timing.
The WDT_MR register can be written only once after mcu reset so the decision to use WatchDog or not is permanent. The 12-bit counter runs on the 32.768kHz Slow Clock divided by 128 allowing up to 16s WatchDog period.
Delay ARM_DELAY.c
Another useful thing is to set up a routine to manage delays when needed. The MCU offers the 24-bit SysTick timer for this purpose.
#define SYSTICK_LOAD 12000 // 64000 - 64MHz; 12000 - 12MHz; ...
Depending on the configured processor speed SYSTICK_LOAD in ARM_DELAY.h has to be adjusted. The timer is then used to fire an interrupt every 1ms that increments the 'timestamp' variable which determines whether it is time to exit the SysTick_delay_ms() function. The timer has to be initialized by SysTick_delay_init().
LED ARM_LED.c
The TT7F board has two LEDs. After power up or reset most of the microcontroller pins (general purpose I/O lines - PAx pins) are by default pulled up to the operating voltage (3.3V) and controlled by the Parallel Input/Output Controller (PIO) with the output disabled. The pull up makes one of the LEDs slightly glow without configuring the PIO. The other one doesn't glow because it is located on a System I/O Line (PB5) that by default has the pull up disabled.
PMC->PMC_PCER0 |= (1 << ID_PIOA); // enable clock to the peripheral
Generally, it is necessary to enable the clock to a specific peripheral first before it can be used. Although, there are exceptions such as the RTT, RTC, etc. peripherals that are continuously supplied with clock signal and writing to the PMC_PCER0/1 registers is not required.
1 2 3 4 5 6 7 8 | void LED_PB5_init(void) { MATRIX->CCFG_SYSIO |= (1 << 5); // System I/O lines must be configured here as well PMC->PMC_PCER0 |= (1 << ID_PIOB); // enable clock to the peripheral PIOB->PIO_OER |= PIO_PB5; // enable Output on PB5 PIOB->PIO_PER |= (1 << 5); // enable PIOC control (disable peripheral control) PIOB->PIO_PUDR |= (1 << 5); // disable pull-up } |
As opposed to the LED on PA0, controlling the PB5 requires assigning the System I/O Line to the PIOB controller by writing to MATRIX->CCFG_SYSIO register as can be seen on the line 3.
The LED library contains a couple of functions to either toggle the LEDs or turn them on for x milliseconds.
ADC ARM_ADC.c
TT7F uses three ADC channels to sample voltage on the solar panels (AD3), voltage on the battery (AD9) and the internal temperature sensor (AD15). Compared to the initial ADC script I used in TT7F-UpDw-Tracker I managed to improve on the volatility of the measurements.
ADC->ADC_MR |= (0x01 << 28) | (0x18 << 24) | (0x05 << 16) | (0x05 << 8);
Firstly by properly setting up the ADC_MR register in ADC_start() that should now have the TRACKTIM and TRANSFER timings according to the ADC's Electrical Characteristic bit in the datasheet.
1 2 3 4 5 6 7 8 9 10 | for(uint32_t i = 0; i < n_averaged; i++) { ADC->ADC_CR = ADC_CR_START; // begin AD conversion while(!(ADC->ADC_ISR & (0x01 << channel))); // End of Conversion x ADCdata += ADC->ADC_CDR[channel]; // read the value } ADC->ADC_CHDR = (1 << channel); // channel disable ADCdata = ADCdata / n_averaged; // finish the computation of the average |
Secondly by sampling a number of times (usually about 100) and averaging the result within the ADC_sample() function.
ADC_start(); uint16_t AD3data = ADC_sample(3, 100); uint16_t AD9data = ADC_sample(9, 100); uint16_t AD15data = ADC_sample_temperature(100); ADC_stop();
This is an example of the complete routine as I do it on TT7F.
UART ARM_UART.c
The UART interface is used to communicate with the Ublox module. Specifically the UART1. The UART0 pins are then routed to the side panel of the PCB as a backup programming interface. The Ublox receives and transmits at 9600 baud and this speed has to be matched on the mcu side as well. Specifically in ARM_UART.h the UART1_BAUD define directive that represents a master clock divisor. As such its value to achieve 9600Hz is dependent on the master clock speed (64MHz by default, however, the mcu offers a wide range of possible frequencies at which it can run) and must reflect that.
PIOB->PIO_PDR |= PIO_PB2; // disable PIO control on RX line PIOB->PIO_PDR |= PIO_PB3; // disable PIO control on TX line PIOB->PIO_ABCDSR[0] &= ~(1 << 2); // select Peripheral A function on PB2 PIOB->PIO_ABCDSR[1] &= ~(1 << 2); // select Peripheral A function on PB2 PIOB->PIO_ABCDSR[0] &= ~(1 << 3); // select Peripheral A function on PB3 PIOB->PIO_ABCDSR[1] &= ~(1 << 3); // select Peripheral A function on PB3
Unlike in the LED example, the UART1 interface is located in the 'Peripheral A' domain and the pins have to be switched from PIO control to Peripheral A. This is done by disabling the PIO control in PIO_PDR register and selecting the desired Peripheral in the PIO_ABCDSR[0] and PIO_ABCDSR[1] registers.
UART1->UART_IER |= UART_IER_RXRDY; // enable RXRDY interrupt NVIC_EnableIRQ(UART1_IRQn);
While transmitting on the UART lines is done manually byte by byte. Receiving, due to its nature, utilizes an RX interrupt routine. Interrupts in general have to be enabled both in the specific peripheral and the Nested Vectored Interrupt Controller (NVIC) as seen above. In some case (other peripherals) it is necessary to enable the interrupt in NVIC first and then set up the peripheral's registers.
The RXRDY interrupt fires when a complete character is received and the result can be read in the UART_RHR register.
1 2 3 4 5 6 7 8 9 10 | void UART1_Handler(void) { if(UART1_buffer_pointer < UART1_BUFFER_SIZE) { UART1_RX_buffer[UART1_buffer_pointer] = UART1->UART_RHR; UART1_buffer_pointer++; }else{ UART1_temp = UART1->UART_RHR; } } |
When an interrupt fires, the processor enters the proper Handler (UART1_Handler() in this case). Given its specific use, I opted for a simple solution and set up a large enough buffer to hold any one sentence the Ublox module may send. This buffer is then automatically filled byte by byte as they are received and in the end should hold a complete sentence ready to be processed. After that the buffer is cleared and the
'UART1_buffer_pointer' reset to '0'.
UBLOX ARM_UBLOX.c
This library contains a variety of functions ranging from UBX and NMEA parsers, RTTY telemetry constructors to ASCII converter routines. After reset the Ublox module, by default, periodically outputs a number of standard NMEA sentences. At the same time it is open to receive commands consistent with the UBX protocol.
static uint8_t request0107[8] = {0xB5, 0x62, 0x01, 0x07, 0x00, 0x00, 0x08, 0x19}; static uint8_t requestGNGGA[15] = "$EIGNQ,GGA*39\r\n";
Using the UART1_TX() function repeatedly to send all the bytes within one of the arrays above equates to sending a command to the GPS module. In this case the module would respond by sending back one UBX-NAV-PVT message that contains numerous information about the module's position, current time, number of satellites, etc., or by sending back a GNGGA NMEA message that contains similar information. The main difference between the two protocols is that UBX communicates in binary values while NMEA in human readable ASCII format. That presents different challenges to the subsequent parsers.
static uint8_t setNMEAoff[28] = {0xB5, 0x62, 0x06, 0x00, 0x14, 0x00, 0x01, 0x00, 0x00, 0x00, 0xD0, 0x08, 0x00, 0x00, 0x80, 0x25, 0x00, 0x00, 0x07, 0x00, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0xA0, 0xA9}; static uint8_t setNAVmode[44] = {0xB5, 0x62, 0x06, 0x24, 0x24, 0x00, 0xFF, 0xFF, 0x06, 0x03, 0x00, 0x00, 0x00, 0x00, 0x10, 0x27, 0x00, 0x00, 0x05, 0x00, 0xFA, 0x00, 0xFA, 0x00, 0x64, 0x00, 0x2C, 0x01, 0x00, 0x3C, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x52, 0xE8};
As mentioned above, the default settings result in periodic NMEA message updates. That is not very handy for simple parsing nor potential power saving. Generally, the first thing I do is to send 'setNMEAoff' command to the module to stop these periodic updates, followed by 'setNAVmode' command to set the module in airborne mode. An important thing for high altitude ballooning. Otherwise the module stops outputting position data above approximately 12000 meters in altitude. Then I simply request the UBX or NMEA messages as I need them.
1 2 3 | UBLOX_send_message(request0107, 8); UBLOX_fill_buffer_UBX(GPSbuffer, 100); UBLOX_parse_0107(GPSbuffer); |
This is an example sequence of commands. First it requests the UBX-NAV-PVT message from Ublox (line 1). Then it waits for the response by expecting a specific number of bytes to arrive in the UART1_RX_buffer[] or it times out (line 2). If the expected number of bytes arrives, it copies them into 'GPSbuffer'. And finally it runs the respective parser (line 3). Within the parser routine it verifies that the received data actually represent the requested message, checks the checksum and parses individual data into respective global variables. The NMEA procedure is very similar.
$$$$TT7F1,1,20:31:15,49.49171,18.22271,1131,11,3,2048,4120,15, *0C5D\n
After having the current data prepared in appropriate variables, all that remains is running the UBLOX_construct_telemetry_UBX() function. The result is a telemetry string such as the one above in the desired output buffer.
In telemetry construction, it is necessary to make sure any potential '0's right after decimal point are handled properly and the software doesn't omit them. This is predominantly a latitude/longitude issue. In my case, I use ASCII_8bit_transmit() for the integer part of the coordinate and ASCII_32bit_LATLON_DECIMAL_transmit() for the decimal part. I make sure the 'figures' parameter matches the input's number of decimal places. For testing the parser and telemetry constructor, I wrote UBX_Generator to have something for an input.
$GPGGA,092725.00,4717.11399,N,00833.91590,E,1,08,1.01,499.6,M,48.0,M,,*5B
One unpleasant difference between UBX and NMEA protocols is that the latter outputs latitude and longitude data in degrees and decimal minutes format (see above) while UBX provides nice and handy 32-bit integers representing decimal degrees such as 472852330 85652670 for the above coordinates.
All the different messages that the module outputs or can be used as commands are described in detail in the documentation provided by u-blox. Just google for: 'u-blox 8 Receiver Description Including Protocol Specification'. Another option is to install u-blox's software called 'u-center' and copy the messages from there. Generally, it can be used to connect to a u-blox module and send the commands from the GUI, however, TT7F board doesn't provide any simple way to connect just the module to a PC.
SPI ARM_SPI.c
The SPI interface is used to communicate with Si4060. Similarly to UART its speed is defined by a master clock divider (SPI_SCBR in ARM_SPI.h) hence it's current processor frequency dependent. The Si4060's SPI interface can run at up to 10MHz which is useful for the more elaborate modulations (GFSK utilized in APRS requires quick communication). I used 8MHz (SPI_SCBR 8) when running of the 64MHz PLL and 6MHz (SPI_SCBR 2) with a 12MHz crystal oscillator.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | uint16_t SPI_write(uint16_t data, uint8_t lastxfer) { ... if (lastxfer) { val = data; SPI->SPI_CSR[0] &= ~(SPI_CSR_CSAAT); }else{ val = data; SPI->SPI_CSR[0] |= SPI_CSR_CSAAT; } ... } |
The library contains a simple function SPI_write() that sends a byte of data and returns the byte received from the other device. The 'lastxfer' parameter is used to mark the last byte in a series of SPI_writes to de-assert the Chip Select line.
Si4060 ARM_SI4060.c
The transmitter's documentation describes numerous ways to construct packets with preamble, sync word, header, CRC checksum, etc. to transmit in the 'FIFO mode'. I haven't tested this method at all. All my implementations used the 'TX Direct mode' exclusively. In this mode, the data to be transmitted are fed to the device in real time through the GPIO1 pin. Thus all the timing and bit streaming is done by the TT7F's microcontroller.
1 2 3 4 5 | SPI_write(0x20, 0); // CMD: GET_INT_STATUS SPI_write(0x00, 0); // PH_CLR_PEND SPI_write(0x00, 0); // RESERVED0 SPI_write(0x00, 1); // CHIP_CLR_PEND SI4060_CTS_check_and_read(9); // check clear-to-send (CTS) |
After mandatory initialization of the Si4060 transmitter via SI4060_init() which temporarily sets the SDN pin HIGH and runs the POWER_UP command, the device is ready. Above is a typical command structure. First byte is the command itself followed by a few arguments (in this case clearing interrupts). After the last byte and de-asserting SPI's Chip Select pin, check clear-to-send routine is entered.
1 2 3 4 5 6 7 8 9 10 | while(dt != 0xFF && CTS_timeout) { CTS_timeout--; SPI->SPI_CR = SPI_CR_SPIEN; // enable SPI if disabled SPI_write(0x44, 0); // READ_CMD_BUFF data = SPI_write(0x00, 0); dt = (uint8_t)data; if(dt == 0xFF) break; SPI->SPI_CR = SPI_CR_SPIDIS; // workaround to de-assert chip select } |
The function repeatedly sends the READ_CMD_BUFF command until Si4060 responds with 0xFF signalling the command was executed and any potential data is ready to be clocked out.
The detailed API documentation is up for download at www.silabs.com as 'EZRadioPRO API Rev C2A-A2A'.
#define FREQUENCY_RTTY 434287000UL #define TX_DEVIATION_RTTY 16 #define POWER_LEVEL 0x7F #define COMPARE_VALUE_RTTY 2500 #define TIMER_CLOCK_RTTY 0x03 SI4060_init(); SI4060_setup_pins(0x02, 0x04, 0x02, 0x02, 0x00, 0x00); SI4060_frequency_offset(0); SI4060_frequency(FREQUENCY_RTTY); SI4060_frequency_deviation(TX_DEVIATION_RTTY); SI4060_power_level(POWER_LEVEL); SI4060_modulation(2, 1); // FSK, asynchronous SI4060_change_state(0x07); // TX state TC0_init_RTTY_NORMAL(); SI4060_tx_RTTY_string_TC0("$$$$TT7F,2,tc0*A55D\n\0"); TC0_stop(); SI4060_deinit();
These are the typical steps to initiate a simple RTTY transmission. The code first sets all sorts of parameters such as selecting FSK modulation, the deviation of the two frequencies, the power of the output signal and commands the transmitter to begin transmission by entering 'TX state'. Right after that it configures TimerCounter0 to handle the timing of individual bits. The 'TIMER_CLOCK_RTTY' and 'COMPARE_VALUE_RTTY' define directives are responsible for transmission's baud rate. The former selects the clock utilized by the timer (in this case MCK/128) while the latter defines the number of clock periods until rising the CPCS flag in the TC0 status register and reseting the counter (2500 resulting in 200 baud rate).
Example Implementation
Putting it all together, the main() function may look something like this.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 | int main(void) { SystemInit(); // initialize the Main CLK at 64MHz WDT->WDT_MR = WDT_MR_WDDIS; // disable WatchDog SysTick_delay_init(); // configure the delay timer LED_PA0_disable(); LED_PB5_disable(); UART1_init(); // initialize communication to u-blox SPI_init(); // initialize communication to Si4060 ADC_init(); // initialize ADC pins UBLOX_request_UBX(setNMEAoff, 28, 10, UBLOX_parse_ACK); UBLOX_request_UBX(setNAVmode, 44, 10, UBLOX_parse_ACK); while(1) { telemCount++; ADC_start(); AD3data = ADC_sample(3, 100); AD9data = ADC_sample(9, 100); AD15data = ADC_sample_temperature(100); ADC_stop(); UBLOX_request_UBX(request0107, 8, 100, UBLOX_parse_0107); UBLOX_construct_telemetry_UBX(TXbuffer, sequence); SI4060_init(); SI4060_setup_pins(0x02, 0x04, 0x02, 0x02, 0x00, 0x00); SI4060_frequency_offset(0); SI4060_frequency(FREQUENCY_RTTY); SI4060_frequency_deviation(TX_DEVIATION_RTTY); SI4060_power_level(POWER_LEVEL); SI4060_modulation(2, 1); SI4060_change_state(0x07); TC0_init_RTTY_NORMAL(); SI4060_tx_RTTY_string_TC0(TXbuffer); TC0_stop(); SI4060_deinit(); } } |
After the opening initializations the script enters a while loop that repeatedly steps through data collection (ADC measurements, ublox requests), transmitter initialization, transmission and transmitter de-initialization. Then it starts another round.
#include "sam.h" #include "ARM_ADC.h" #include "ARM_DELAY.h" #include "ARM_LED.h" #include "ARM_SI4060.h" #include "ARM_SPI.h" #include "ARM_UART.h" #include "ARM_UBLOX.h"
To make the basic code complete, it requires the involved libraries to be included at top of the script.
uint32_t sequence = 0; uint16_t AD3data = 0; uint16_t AD9data = 0; uint16_t AD15data = 0; volatile uint32_t SI4060_buffer[16]; volatile uint8_t TC_rtty_gfsk_lookup = 0; volatile uint32_t TXdone_get_data = 1; volatile uint8_t TXdata_ready = 0; uint32_t TXmessageLEN = 0; uint16_t APRS_packet_size = 0; uint8_t TXbuffer[TX_BUFFER_SIZE]; uint8_t APRSpacket[APRS_BUFFER_SIZE]; volatile uint8_t UART0_RX_buffer[UART0_BUFFER_SIZE]; volatile uint8_t UART1_RX_buffer[UART1_BUFFER_SIZE]; volatile uint32_t UART0_buffer_pointer = 0; volatile uint32_t UART1_buffer_pointer = 0; volatile uint32_t UART0_temp = 0; volatile uint32_t UART1_temp = 0; uint8_t GPS_UBX_error_bitfield = 0b00100000; uint16_t GPS_NMEA_latitude_int = 0; uint32_t GPS_NMEA_latitude_dec = 0; uint16_t GPS_NMEA_longitude_int = 0; uint32_t GPS_NMEA_longitude_dec = 0; uint8_t GPS_NMEA_NS = 1; uint8_t GPS_NMEA_EW = 1; int32_t GPS_UBX_latitude = 0; int32_t GPS_UBX_longitude = 0; float GPS_UBX_latitude_Float = 0.0; float GPS_UBX_longitude_Float = 0.0; int32_t GPSaltitude = 0; uint8_t GPShour = 0; uint8_t GPSminute = 0; uint8_t GPSsecond = 0; uint8_t GPSday = 0; uint8_t GPSmonth = 0; uint16_t GPSyear = 0; uint8_t GPSsats = 0; uint8_t GPSfix = 0; uint8_t GPSnavigation = 0; uint8_t GPSpowermode = 0; uint8_t GPSpowersavemodestate = 0; int32_t GPSgroundspeed = 0; int32_t GPSheading = 0; uint32_t telemCount = 0; uint32_t telemetry_len = 0; int32_t GPS_UBX_latitude_L = 0; int32_t GPS_UBX_longitude_L = 0; int32_t GPSaltitude_L = 0; uint8_t GPS_NMEA_NS_L = 0; uint8_t GPS_NMEA_EW_L = 0; uint16_t GPS_NMEA_latitude_int_L = 0; uint32_t GPS_NMEA_latitude_dec_L = 0; uint16_t GPS_NMEA_longitude_int_L = 0; uint32_t GPS_NMEA_longitude_dec_L = 0;
And a number of variables and arrays defined ahead of the main() function.
This article hopefully outlined some of the basics in programming TT7F and SAM3S8 in general. A couple more specialized blog posts concerning software may appear in the future.
No comments:
Post a Comment