A technology question related to Bit Cloud Based System

[charlie918]

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[0]=0x15;//0x15;//fixture address
    cmd[1]=0x03;
    cmd[2]=0x00;
    cmd[3]=0x00;
    cmd[4]=0x00;
    cmd[5]=0x01;
    cmd[6]=0x09;
    cmd[7]=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[0]==parameterData[0])&&(sensorSoil[1]==parameterData[1]))
                {
                    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,
 

[ataradov]

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.

[charlie918]

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

[ataradov]

t 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.

That'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.

[charlie918]

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[RX_SIZE];//Receive the data

Any 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
         
      }

///////////////////////////

[ataradov]

sometimes negative values are returned although the array dedicated to store data from the USART is uint8_t:

Signed or unsigned is a matter of interpretation for display. How do you check that values are signed?

[charlie918]

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

[ataradov]

I set a break point

Right click on the array or variable you are looking at and there must be a setting to interpret it as unsigned integer.

[charlie918]

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

[ataradov]

The GCC then converts the uint8_t type into a signed value.

There is no conversion, it is a matter of interpretation. And GCC will never do anything like this on its own.