UC3 with RPi 3 for data logging

Go To Last Post
30 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am very newbie to uc and general programming, yet I have this task to get done, and I am hoping this community will help me. Please all, come to my aid.

 

1. The current status of the project is a custom board with AT32UC3A1512 uc. The board specific is for some radar project, and in the project the uc process the acquired data from antennas and send them over (wireless) Zigbee connection to STK600 with another AT32UC3A1512 uc which connects to MATLAB running on a PC.

 

2. It is now desired to eliminate the Zigbee connection, and instead of sending the acquired data to a PC (with MATLAB), the data should be logged into some SD card which a RPi 3 can easily do.

 

I need help in interpreting the current codes (in C) that I have for the current status of the project, and help with changing these codes around for communicating with the RPi.

 

Note- connection to Zigbee module from the radar board/device is through SPI

This connection is still available to connect to the RPi, while another UART is additionally available too.

 

PS- I have a very lengthy code of about 3000 lines. Pasting them here may be disorderly. Please find in the attachment. A picture of the custom board is as well shown (without the UART connections anyway)

Attachment(s): 

Last Edited: Sat. Sep 9, 2017 - 04:39 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A quick glance indicates that the Zigbee configuration/control is done with trx_reg_write(,) and data is sent with trx_frame_write(,)
If you eliminate the Zigbee (a new circuit board ?), then all that configuration can be removed and trx_frame_write() can be still be used to send data via SPI to the RPi.
Seems to me that lines 1484 to 2906 will never be executed.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

mikech wrote:
A quick glance indicates that the Zigbee configuration/control is done with trx_reg_write(,) and data is sent with trx_frame_write(,) If you eliminate the Zigbee (a new circuit board ?), then all that configuration can be removed and trx_frame_write() can be still be used to send data via SPI to the RPi. Seems to me that lines 1484 to 2906 will never be executed.

 

Hi mikech,

 

thanks for your suggestion/input.

 

I am afraid I may have some hardware problem, and I welcome your further suggestion. From revising RPi SPI configurations, I realised RPi only allows its SPI in Master mode, this looks to me that I may be risking having two (SPI) masters in my setup, since the MCU's SPI is better configured (or as configured in the previous code) as master.

 

Would you suggest I make my MCU SPI into slave? What implications may this have on my setup/the MCU?

 

On the other hand, I made provisions for UART in the board design:

1. would you advise I get started with UART and ditch SPI?

2. will the trx_frame_write() still be suitable to do UART for the MCU to RPi as suggested in your previous response?

 

 

PS- I am a newbie in embedded C, hence, I am taking the shortcut of hacking the codes other than developing on from start. And also hacking may be faster as the project has some deadlines.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A big problem when transferring data from a master to a slave is synchronization of the data stream.
With SPI the slave can use the chip-select line to indicate that a packet of data is being received., but the USART needs different technique(s) to indicate what should be considered a packet of data.,
for example ;
- timing (a long pause could indicate the end of a packet)
- framing (special codes indicate the start and/or end of a packet).
Welcome to the wide world of communications protocols, where there are hundreds of different ways to move data.


trx_frame_write() has been written to send a block of samples so I would modify it to use the USART and do something like ;
- drive a GPIO pin low (to indicate to the RPi that a packet of data is arriving),
- send a data-header to indicate how many bytes are being transmitted,
- send the data,
- drive the GPIO pin high (to indicate that no more data is being transmitted and that the RPi can now process the packet)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

obabarin wrote:
I am very newbie to uc and general programming, yet I have this task to get done

So could you explain a little more why this task has fallen to you, specifically - as it is so obviously a task which requires familiarity microcontrollers & programming?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

mikech wrote:
.... Welcome to the wide world of communications protocols, where there are hundreds of different ways to move data.

 

thanks mikech...this is insightful.

 

i will then get started on how to execute UART on the AVR UC3 mcu and the RPi. Would there be any resource you can recommend?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:

 

So could you explain a little more why this task has fallen to you, specifically - as it is so obviously a task which requires familiarity microcontrollers & programming?

 

it is a school project awneil. and it is expected of me to learn on the 'job'....i don't personally see any problem with that (my level of skills), getting this done is a matter of devotion and getting the right information/resources to work with.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It appears to me (from the arrangement of the .h header files) that the project is not exactly what the Atmel-Studio ASF-Wizard produces.,
therefore you might need to do some sleuthing to find the ASF files usart.h and usart.c and add them to your project.
(or use the Wizard to add the 'USART driver' and then move the files from where the Wizard puts them)


The USART has many operating modes, but 'normal' mode at (say) 115200 baud with 8 bits per character, 1 stop bit and no parity, would be a reasonable starting point.
usart.c will contain functions such as usart_init_rs232_tx_only(,,) and usart_putchar(,) which you can then use.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

mikech wrote:

It appears to me ......... which you can then use.

 

Thanks for the tips and the interests to help. Expect my updates in the coming week.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My Update with USART

 

I had been looking up pages on the internet (and everywhere?). Yet to figure out much about the USART of a procedure. My updates are in the line below. Any suggestion on where I am right or wrong? What will my next step be?

#include <avr32/io.h>

#include <asf.h>
#include <parts.h>
#include <stdint.h>
#include <stdbool.h>

#include "stdio.h"
#include "gpio.h"
//#include "sysclk.h"
//#include "conf_clock.h"
#include "board.h"
#include "user_board.h"
//#include "pm.h"
//#include "delay.h"

#include "usart.h"
//#include "conf_usart.h"


// USART pins and Functions

#define USART               (&AVR32_USART3)

#define USART_RX_PIN        AVR32_USART3_RXD_0_0_PIN
#define USART_TX_PIN        AVR32_USART3_TXD_0_0_PIN

#define USART_RX_FUNCTION   AVR32_USART3_RXD_0_0_FUNCTION
#define USART_TX_FUNCTION   AVR32_USART3_TXD_0_0_FUNCTION

//#  define USART_CLOCK_MASK    AVR32_USART3_CLK_PBA
//#  define USART_IRQ           AVR32_USART3_IRQ // not sure i want to use interrupt

static const gpio_map_t USART_GPIO_MAP =
{
	{USART_RX_PIN, USART_RX_FUNCTION},
	{USART_TX_PIN, USART_TX_FUNCTION}
}; // I will need to do PIN assignment



// USART OPTIONS

#define USART_BAUDRATE						9600
#define USART_CHANNELMODE					USART_NORMAL_CHMODE
#define USART_CHAR_LENGTH					8
#define USART_PARITY_TYPE					USART_NO_PARITY
#define USART_STOP_BITS						USART_1_STOPBIT					



//create USART options struct

static usart_options_t USART_OPTIONS = {
	.baudrate = USART_BAUDRATE,
	.channelmode = USART_CHANNELMODE,
	.charlength = USART_CHAR_LENGTH,
	.paritytype = USART_PARITY_TYPE,
	.stopbits = USART_STOP_BITS
};


// CLOCK DEFINITIONS

#define CLOCK_PBA_FREQ				15000000 //need to find value for PBA Hz






// RPi Definitions








int main (void)
{
	// Insert system clock initialization code here (sysclk_init()).

	board_init();

	// Insert application code here, after the board has been initialized.
	
	// USART GPIO MAP
	
	//static const gpio_map_t USART_GPIO_MAP = 
	//{
		//{USART_RX_PIN, USART_RX_FUNCTION},
		//{USART_TX_PIN, USART_RX_FUNCTION}
	//};
	
	
	//ASSIGN GPIO TO USART
	
	gpio_enable_module(USART_GPIO_MAP, sizeof(USART_GPIO_MAP)/ 
	sizeof(USART_GPIO_MAP[2]));
	
	// Initialize USART RS232 mode
	usart_init_rs232(USART, &USART_OPTIONS, CLOCK_PBA_FREQ); //need to change this clock later
	
	//Usart write out line
	usart_write_line(USART, "Hello");
	
	
}

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

mikech wrote:
or (sic) use the Wizard to add the 'USART driver' 

My experience is that this is not just an option - it is the only way to do it.

 

Simply adding the files is, IME, not sufficient; there is other - undocumented, yet essential - stuff which the Wizard also does.

 

EDIT

 

See: http://www.avrfreaks.net/comment...

Last Edited: Wed. Sep 20, 2017 - 05:45 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You can do it all yourself, but it does take a considerable amount of time and effort to find and organize files into a particular layout, and then configure the IDE.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

First step would be to ensure that the pin multiplexing is correct for your target hardware.

 

Second step would be to modify your main() so that it doesn't try to 'finish' after it sends that "Hello" message., eg. add a

while ( 1 )  // many non-OS projects will do most of their work inside this endless loop.
  {
  usart_write_line( USART, "this is a test\r\n" );
  };

 

The decision as to whether to use interrupts (or not) will depend on your application, ie.

- how frequently do you need to send data ?

- how much data is sent ?

- do you have time-critical actions in your project that must be performed at regular intervals ?

- etc. etc.

 

 

 

 

<begin minor rant>

I find the ASF pin-naming system confusing.

The GPIO Controller Function Multiplexing table says that the USART3 Rx on a UC3A can be function B on PB10, or function B on PX08.

The ASF AVR32_USART3_RXD_0_0_PIN definition is not very explanatory, whereas AVR32_PIN_PB10 or AVR32_PIN_PX08 are.

Similarly AVR32_USART3_RXD_0_0_FUNCTION is rather opaque (is it 0, 1 or 2 ?) , but if you use 1 (= Function B) it is clearer.

<end minor rant>

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

mikech wrote:

 

<begin minor rant>

 

<end minor rant>

 

 

It took me some while to figure out what your rant was about. But when I did, it helped clarify my confusions too. I modified the pin-naming as follows

#define USART               (&AVR32_USART3)


#define USART_RX_PIN        AVR32_PIN_PB10 //GPIO 42
#define USART_TX_PIN        AVR32_PIN_PB11 //GPIO 43

#define USART_RX_FUNCTION   AVR32_USART3_RXD_0_0_FUNCTION
#define USART_TX_FUNCTION   AVR32_USART3_TXD_0_0_FUNCTION

Function B is given as FUNCTION 1 in the ASF and since my device is 100 pin, I can only use the TQFP100 numbering of page 45 of the Datasheet. Looks like I have figured out the pins and their functions correctly. kindly help confirm this.

 

I am not yet sure if interrupt is crucial to my application. The data are to be logged to SD card through the RPi at all times- without need for any trigger other  than external power, after a booting sequence. If there will be a change in specifications, I may consider interrupt later.

 

One major question I have is the use of put_char and write_line functions. Is USART limited to writing text only?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My apologies... my rant was not directed at you, but at those who created that extra layer of confusion with the pin names


You are correct to use GPIO42,43 for USART3. (I'd forgotten that you were using the UC3A1512).


Creating meaningful names for functions is somewhat of an art.
The ASF usart_putchar(,) will transmit one byte, it doesn't care if it is human-readable text (eg. Z (hex 5A)), or not (eg. binary 11111111).
The ASF usart_write_line(,) transmits bytes (text or binary) from a buffer until it finds a binary zero., the name is misleading because it is actually a 'write-a-C-string' routine.
To transmit a block/packet of bytes you can create your own 'usart_write_buffer(,,)' routine which uses usart_putchar(,) or usart_write_char(,)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

mikech wrote:

You are correct to use GPIO42,43 for USART3. (I'd forgotten that you were using the UC3A1512).
[/i]

 

UPDATES

 

I managed to be able to send characters over USART1 (of UC3A1512 and STK600 development kit)- so excited for the small but meaningful progress.

 

Unfortunately, my custom board is configured to use USART3 on Function B, but I could not get this to work.

 

How to i rewrite this line to turn on to Function B?

 


#define USART_RX_FUNCTION   AVR32_USART3_RXD_0_0_FUNCTION
#define USART_TX_FUNCTION   AVR32_USART3_TXD_0_0_FUNCTION

I guess I am missing something- I tried many manipulations of the 0_0 to no avail.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I would just do
#define USART_RX_FUNCTION 1
#define USART_TX_FUNCTION 1


AVR32_USART3_RXD_0_0_FUNCTION and AVR32_USART3_TXD_0_0_FUNCTION are defined as 1 (=function B)


Basic questions ;
Does your custom board work ? ie. can you toggle an output pin (or LED) ?
How is USART3 connected to whatever you are using to monitor the communication ?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

mikech wrote:
I would just do #define USART_RX_FUNCTION 1 #define USART_TX_FUNCTION 1

 

Thank you always for your tips and readiness to share your expertise.

 

Here are my updates-

1. I realised i made a little wiring connection. I fixed such and was able to see data from both my development and custom boards on PC.

2. I am using the USART-USB bridge adapter, and RealTerm for display on a Windows PC. But I cant see real data in any format given by the Realterm software- ASCII display wobbled texts, HEX, Binary and other display options give bunch of zero. I read on some other blogs that I may need to check my buad rate- will be doing that over the coming week.

 

Now trying to establish U(S)ART on RPi. If I may ask (minding that this is not a RPi forum), would you suggest using C or Python for this? I have seen several tutorials on this, and was wondering which is better suited for my application?

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

And the answer is ..... Whatever you like !


Seriously though, either C/C++ or Python will work, the deciding factors would be ;
- the volume of data that your board generates, and
- the learning-curve for writing code on the RPi.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There's plenty of examples of arduinos connected to raspis. If it is via serial (be it usb or actual serial) the technique is the same. My choice of language on the pi would be node-js, but any is suitable. Performance using an interpreted language should not be an issue on the pi.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello Contributors,

 

Here are my update and further seek for help. I had been trying to fix these issues on my own for the past days- but then i am eating the humble pie again to ask for help.

 

1. I have some python scripts running on my Rpi to which i confirm that the UART port of the RPI are fully functional- i could move data from the TX to RX and display on a console- both on the RPi using Minicom and a Windows PC using RealTerm client and a UART2USB bridge

 

2. I followed some sample ASF codes in Atmel Studio 6 to have working codes for testing my UC32 UART ports. I am certain my connections are correct- both using the UART2USB bridge and RS232 cable. My coding on the UC32 are as follows:

#include <asf.h>

#include <avr32/io.h>
#include "compiler.h"
#include "board.h"
#include "power_clocks_lib.h"
#include "gpio.h"
#include "usart.h"


#define USART				(&AVR32_USART3)
#define USART_RX_PIN		AVR32_USART3_RXD_0_0_PIN
#define USART_RX_FUNCTION	AVR32_USART3_RXD_0_0_FUNCTION
#define USART_TX_PIN		AVR32_USART3_TXD_0_0_PIN
#define USART_TX_FUNCTION	AVR32_USART3_TXD_0_0_FUNCTION
//#define	TARGET_PBACLK_FREQ_HZ	16000000
#define	TARGET_PBACLK_FREQ_HZ	12000000

int main (void)
{
	// Insert system clock initialization code here (sysclk_init()).

	board_init();

	// Insert application code here, after the board has been initialized.
	
	
	
	static const gpio_map_t USART_GPIO_MAP =
	{
		{USART_RX_PIN, USART_RX_FUNCTION},
		{USART_TX_PIN, USART_TX_FUNCTION}
	};

	// USART options.
	static const usart_options_t USART_OPTIONS =
	{
		.baudrate     = 115200,
		//.baudrate     = 57600,
		//.baudrate     = 9600,
		.charlength   = 8,
		.paritytype   = USART_NO_PARITY,
		.stopbits     = USART_1_STOPBIT,
		.channelmode  = USART_NORMAL_CHMODE
	};

	// Assign GPIO to USART.
	gpio_enable_module(USART_GPIO_MAP,
	sizeof(USART_GPIO_MAP) / sizeof(USART_GPIO_MAP[0]));

	// Initialize USART in RS232 mode.
	usart_init_rs232(USART, &USART_OPTIONS, TARGET_PBACLK_FREQ_HZ);

        //usart_init_rs232_tx_only(USART, &USART_OPTIONS, TARGET_PBACLK_FREQ_HZ);
	
	while (true){
	
	
	// Hello world!
	usart_write_line(USART, "Hello, this is the AVR UC3 MCU saying hello! (press enter)\r\n");

        //usart_putchar(USART, "1111111");            


	// Press enter to continue.
	//while (usart_get_echo_line(USART) == USART_FAILURE);  // Get and echo characters until end of line.

	//usart_write_line(USART, "Goodbye.\r\n");
	
	}
	
	
}

Here are my issues-

1. Whatever the text/char/numbers I put in usart_write_line or in usart_putchar, my console (Realterm via Serial or UART2USB bridge) always display the same thing in both ASCII, BIN or HEX format of the console software. Please see attached images. I am certain my baudrate was correctly set.

 

Can you suggest/troubleshoot this for me please? All suggestions are welcome- why is my UC32 not sending out the correct data?

 

2. Moving on, since I felt my UC32 was still spewing out some data- correct/otherwise, I connected it over UART to the RPi. But the RPi does not read or sense any data on the UART pins, hence, does not log any data to file. My python code is as below

#!/usr/bin/env python

import time
import serial
import os

ser = serial.Serial(
	#port='/dev/ttyAMA0',
	port =  '/dev/ttyS0',
	#baudrate = 9600,
	#baudrate = 57600,
	baudrate = 115200,
	parity = serial.PARITY_NONE,
	stopbits = serial.STOPBITS_ONE,
	bytesize = serial.EIGHTBITS,
	timeout = 1
	)
counter = 0

#logging

file = open("/home/pi/Documents/myPython/Data/log1.csv", "a")

if os.stat("/home/pi/Documents/myPython/Data/log1.csv").st_size==0:
	file.write("Data\n")

while 1:
	x = ser.readline()
	print x

	file.write(str(x)+ "\n")
	file.flush()
file.close()

What could be happening? Any suggestions/tips please?

 

I am not certain of what the output voltage level of the UC32 is, but I checked with a voltmeter and it was varying 1.0 to 1.8 V. I understand that Rpi takes in 3.3V, could this be where my problem lies? Knowing of certain that the code up there works perfectly?

 

Also, any suggestions on the relation between baudrate (of the UC32) and CPU clock? How could this affect my transmission or reception at the Rpi side? Someone please help me.

 

Thanks in advance.

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Most of the ASF routines have a return-code to indicate the result of calling a function, therefore it would be a 'good idea' to check that usart_init_rs232(,,) returns USART_SUCCESS (0)


What is the actual system clock frequency ?.
Do you have a 12 MHz crystal oscillator on your board ? (a #define TARGET_PBACLK_FREQ_HZ 12000000 does not guarantee that that is what you will actually get).
I am guessing that there is a sysclock_init() inside board_init() but sysclk_init() uses it's own set of #defines to configure the system clock(s).
The ASF has sysclk_get_cpu_hz() which would be better to use in usart_init_rs232(,,)


For historical reasons, serial baudrates have queer values, (4800, 19200, 57600) which are hard to achieve exactly with a clock-source that is not an almost-integer multiple of the baudrate.
eg. you might want 57600 baud, but with a 12 MHz system-clock you will actually get 57692 baud, which is a 0.16% error.
If there is more than about 3% baudrate mismatch between the sender and receiver it will cause problems with asynchronous serial communications and can often be detected in the receiver as a 'framing' error.
Receiver errors will probably (it depends on who wrote the code), cause the character with the error to be ignored.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

mikech wrote:
...I am guessing that there is a sysclk_init() inside board_init() but sysclk_init() uses it's own set of #defines to configure the system clock(s). ......

 

Yes mikech, thanks for hinting this. Took me a while to figure that out, thanks to this thread and this link. I now have my mcu and rpi sending and receiving known data.

 

Moving on to the next stage....testing out all the functionality of my custom board, and creating better programs on Rpi for better logging.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello @mikech

 

1. I am asking for some tips and help. My UART worked well over the weekend- sending data over to PC Terminal program correctly which i was able to Rpi using python script. All went well over the weekend till i resumed on Monday morning and I began to experience errors, specifically UART Receiver Framing Error as detailed my the RealTerm Terminal Emulator. I have done all I could, from changing cables to ensuring good grounding between devices, this error persist, though it doesn't show up some times. And with this error, my RPi, does not detect any data on the RX line and hence, won't log. Any suggestions to check this error? Mind that I specified baudrate/bits/parity correctly on both devices.

 

2. I need some tip on how to write a UART frame function similar to this code:

void trx_frame_write(uint8_t * data, uint8_t length){

	uint8_t temp = TRX_CMD_FW;
	

	/* Start SPI transaction by pulling SEL low */
	spi_select_device(&AVR32_SPI1, &SPI_DEVICE_EXAMPLE);

	/* Send the command byte */
	spi_write_packet(&AVR32_SPI1, &temp, 1);

	spi_write_packet(&AVR32_SPI1, data, length);

	/* Stop the SPI transaction by setting SEL high */
	spi_deselect_device(&AVR32_SPI1, &SPI_DEVICE_EXAMPLE);

	
}

You suggested this earlier in one of your responses, but I have not been able to find adequate resources to get this done. I have been able to successfully use usart_write_line and usart_putchar before i start experiencing framing errors .

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

obabarin wrote:
 UART Receiver Framing Error ... I specified baudrate/bits/parity correctly on both devices.

Most likely means your baud rate is out, then - but only slightly out if it's "infrequent"

 

2. I need some tip on how to write a UART frame function

What makes you think that?

 

The "framing" is all done in hardware by the UART

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:

 

 

Surprising thing is the baud rate and everything else worked perfectly just over the weekend, but since yesterday without changing anything, i began to experience errors. I do not even know where to look- cables, hardware or even the codes.

 

What makes you think that?

 

I do not really mean i wanna do the framing myself, what I intend to have is a function that will 'format' my data in format suitable for uart. my data is (supposedly) of the form of 3 bytes to be transmitted in every cycle of transmission.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

obabarin wrote:
worked perfectly just over the weekend, but since yesterday without changing anything, i began to experience errors. 

was it working before the weekend?

 

does your office get cold(er) over the weekend - while nobody's there ... ?

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

was it working before the weekend?

Well, it took me about a week to figure how to get that part of initializing UART about 5 days -poor me. I only succeeded late friday evening, and was back on saturday to confirm progress and document the process. But by monday morning, I could not believe what was happening- wrong data being sent to pc, rpi refusing to log and the uart framing errors. as at today, my pc lost the driver to the STK 600 development board. I lost my sanity as I just could not explain what was happening.

 

I managed to fix the drivers and the likes. Mind that i was certain i shut everything down properly, so the possibility of voltage surge is ruled out. And my office dont really get colder nor hotter- and would crystals have been that sensitive to environment temperature?

 

About nobody's there.....i cant really say. But i know my colleagues wont have messed with my desk. Whatever could have happened anyway-forging ahead.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If your data contains bytes that are binary zero then you cannot use the ASF usart_write_line() because it will stop when it finds that zero value and not transmit it.

void usart_write_line(volatile avr32_usart_t *usart, const char *string)
{
  while (*string != '\0')
    usart_putchar(usart, *string++);
}

It is not difficult to use that as a basis to write your own routine to send a given number of bytes from a buffer.

There is still the issue of synchronising the data-flow, because you cannot simply transmit a stream of bytes and expect the receiver to interpret that stream correctly (data can be corrupted in transit, or the receiver loses data because it cannot cope, etc. etc)
With SPI, synchronisation is automatic because the chip-select line tells the slave when data is being transmitted
With USART there is no such automatic mechanism, hence you need to somehow 'tell' the target when a packet/block/burst of data is about to arrive., how you do that depends on many factors, such as ;

- how much data is in each 'packet/block/burst' ?

- how often are those packets transmitted ?

- is the data human-readable or binary ?

- how 'smart' is the receiving system ? (can the receiver tell the sender to pause for a while ?)

- what is the communications infrastructure and environment that the data is flowing through ? (eg. copper wire, optical, radio, ...)

Last Edited: Wed. Oct 4, 2017 - 01:00 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What baudrate are you using ?
Try something slower as an experiment.
A high baudrate might be too much for the target and hence causing overrun errors. (but the target might be coalescing overrun and framing errors as one generic error).