A technology question related to Bit Cloud Based System - Page 1
Forum section: electronics / general

author: charlie918
author_rank: Newbie
timestamp: June 27, 2016, 01:21:53 pm
content: Hello guys,I am debugging a system based on: BitCloud_XMEGA_1_14_0; AVR STUDIO 5; Target IC: ATxmeag256A3; Debugger JTAGICE3;I need to use the UART port to send data reading commands to a RS485 sensor and gets it readings back. To do so, the following code is used.However, by using the Debugger JTAGICE3 and hook up a Oscilloscope to watch the UART signals, the coding inside the ATOMIC_BLOCK and WRITE_USART is not executed right away as expected..It's executed later after my coding that waits for response from the RS485 sensor.See the following coding for details:////////////////////////////////////////////////Coding for read in RS485 sensors data//////////////////////////////////////////////////////case SOIL_SENSOR1:{// Use atomic block to force execution: Coding for sending the command to the RS485 sensor in Black bold:ATOMIC_BLOCK(ATOMIC_RESTORESTATE ){PORTD_OUT |= 0x20;memset(cmd,0x00,sizeof(cmd));cmd=0x15;//0x15;//fixture addresscmd=0x03;cmd=0x00;cmd=0x00;cmd=0x00;cmd=0x01;cmd=0x09;cmd=0x10;rs485_recv_flag=2;//ATOMIC_BLOCK(ATOMIC_FORCEON){//sendRS485Message(cmd,8);rs485_wait_steady=1;//ATOMIC_BLOCK(ATOMIC_FORCEON){WRITE_USART(&usartDescriptor1,cmd,8); // It's not executed right away although I have added it into the ATOMIC_BLOCK!}// End of atomic block and now we wait for 485 to response.// However, by using the Debugger JTAGICE3 and hook up a Oscilloscope to watch the UART signals, the coding defined by ATOMIC_BLOCK is not executed right away.// It's executed later though but my following coding that waits for the response from the RS485 sensor can't get readings:// Coding waiting response from RS485:TimerValue = HAL_GetSystemTime();while(rs485_recv_flag!=0){if((HAL_GetSystemTime()-TimerValue)>=200)break;}flagValue=rs485_recv_flag;if((sensorSoil==parameterData)&&(sensorSoil==parameterData)){dealWithRS485Data(2);break;}}break;// WRITE_USART is not executed!// WRITE_USART command is executed later after Coding waiting response from RS485 therefore I can't read data.////////////////////////////////////////////////Above Coding is for read in RS485 sensors data//////////////////////////////////////////////////////Have any clue? I think this problem might be related to stack structure of the Bitcloud, but not sure. How to force the WRITE_USART to be executed right away so that the coding waiting for response from the sensor can get readings?Thanks,

author: ataradov
author_rank: Super Contributor
timestamp: June 27, 2016, 05:09:31 pm
content: All atomic sections do is disable interrupts. They will not magically change code written to work asynchronously to work synchronously. You need to write a new driver for that.But that's a bad thing to do, since you will be blocking the stack for significant amounts of time, which will interfere with normal operation.It is better to write your application in a non-blocking way.

author: charlie918
author_rank: Newbie
timestamp: June 28, 2016, 07:33:07 pm
content: Hi Alex,I have rewritten the program and now I process the data at the UART RX event call back function. It looks like for the Bit Cloud system, it's an event driven system and you can't wait for things to happen, but need to wait for event to happen.Thanks,Charlie

author: ataradov
author_rank: Super Contributor
timestamp: June 28, 2016, 08:16:09 pm
content: Quote from: charlie918 on June 28, 2016, 07:33:07 pmThat's exactly it.The whole stack is designed in a way that no task takes more than 10 ms at a time and no critical section is more than 10 us. The rules can be relaxed a bit for the final application, of course, but in general you want to avoid explicit delays.

author: charlie918
author_rank: Newbie
timestamp: June 29, 2016, 02:03:27 pm
content: Hi Alex,Another weird thing I saw is that when using READ_USART ( #define READ_USART HAL_ReadUart) to read USART,sometimes negative values are returned although the array dedicated to store data from the USART is uint8_t:static uint8_t strippedCmd;//Receive the dataAny way we can set it up so that it only store data in positive format?Thanks,Charlie//////////////////////////if((rs485_recv_flag == 2) && (bytesReceived >= APP_SENSOR_RS485_LIQ_SOIL)){READ_USART(&usartDescriptor1, strippedCmd, bytesReceived);for(i=0;i<bytesReceived;i++){sensorSoil=strippedCmd;}PORTD_OUT |= 0x20;rs485_recv_flag=0;dealWithRS485Data(); /// Process data here after data received. CXU}///////////////////////////

author: ataradov
author_rank: Super Contributor
timestamp: June 29, 2016, 04:15:44 pm
content: Quote from: charlie918 on June 29, 2016, 02:03:27 pmSigned or unsigned is a matter of interpretation for display. How do you check that values are signed?

author: charlie918
author_rank: Newbie
timestamp: June 30, 2016, 12:37:58 pm
content: Alex,I set a break point and when checking the values read by the HAL_UART_READ stored in a array , the values are -122....which is FF86.. I guess this is just how the system interpret it....But you know, when you have a negative values, it make it difficult to do bit operation.Charlie

author: ataradov
author_rank: Super Contributor
timestamp: June 30, 2016, 03:38:02 pm
content: Quote from: charlie918 on June 30, 2016, 12:37:58 pmRight click on the array or variable you are looking at and there must be a setting to interpret it as unsigned integer.

author: charlie918
author_rank: Newbie
timestamp: July 01, 2016, 06:45:23 pm
content: Alex,It turns out that I defined a int8_variable t to receive the uint8_t readings by the HAL_USART. The GCC then converts the uint8_t type into a signed value. That's what happened.Thank you,Charlie

author: ataradov
author_rank: Super Contributor
timestamp: July 01, 2016, 06:47:23 pm
content: Quote from: charlie918 on July 01, 2016, 06:45:23 pmThere is no conversion, it is a matter of interpretation. And GCC will never do anything like this on its own.