[INFO] ChibiOS 2.6->3.0 porting guide

[goeck]

Maybe I am a little lost...I try to migrate from 2.6.4 to 3.0 which I grabbed from SVN. Everything went well, but the migration of the event listening stuff. I do UART event listening...
It seems to me like flags stuff is gone and has somehow been replaced but also reordered. Something is missing to me here...
Can I please get a hand?
One may look at this thread, where I posted what I am doing using ChibiOS/RT c2.6.*.
viewtopic.php?f=16&t=1549&hilit=+event#p13477

Thanks for the help, I really appreciate it.

[Giovanni]

Hi,

The functionalities are all there plus a new feature (capability to wait only for specific flags, not just specific events).

Some functions and types have been renamed but there should be a 1:1 replacement for everything. What are you missing?

Giovanni

[goeck]

Yeah, you're right, Giovanni. I had a look at the new test and demo programs, maybe this disturbed my understanding a little bit. Now I got everything set up again, on flaw is left.
Testing the flag against CHN_INPUT_AVAILABLE doesn't seem to work. I have to skip the test and just do it, hardcoded. This works and brings the requested results...
Another thing is, has Q_TIMEOUT been replaced with STM_TIMEOUT?
I can find this timeout define but not the Q version of it...

Code: Select all

static THD_WORKING_AREA(waThread4, 1024);
static THD_FUNCTION(Thread4, arg) {

   (void)arg;
   chRegSetThreadName("ISDData");

   static uint32_t cnt_received = 0;
   static msg_t charbuf;

   event_listener_t elISDData;
   eventflags_t flags;
   chEvtRegisterMask((event_source_t *)chnGetEventSource(&SD1), &elISDData, EVENT_MASK(1));

   while (TRUE)
   {
      chEvtWaitAll(EVENT_MASK(1));
      flags = chEvtGetAndClearFlags(&elISDData);

      if(flags & SD_PARITY_ERROR)                                 // Parity error happened.
         sdPut(&SD1, 0xE1);
      if(flags & SD_FRAMING_ERROR)                                 // Framing error happened.
         sdPut(&SD1, 0xE2);
      if(flags & SD_OVERRUN_ERROR)                                 // Overflow happened.
         sdPut(&SD1, 0xE3);
      if(flags & SD_NOISE_ERROR)                                 // Noise on the line.
         sdPut(&SD1, 0xE4);
      if(flags & SD_BREAK_DETECTED)                              // Break detected.
         sdPut(&SD1, 0xE5);
      if(1)                              // Data in input buffer available CHN_INPUT_AVAILABLE
      {
         do{                                                // Read all there is in queue into buffer
            charbuf = chnGetTimeout(&SD1, TIME_IMMEDIATE);
            if(charbuf != Q_TIMEOUT){
               rxBuffer[cnt_received++] = ((uint8_t)charbuf);         // Copy received bytes into global input buffer
               if(rxBuffer[cnt_received-1] == ISD_TOKEN_END){
                  cnt_received = 0;

                  if(rxBuffer[0] == ISD_TOKEN_DATA_START)            // Check whether we gathered new 3D data
                     handle_ISDNewData();                        // and call handler if so.

                  //TODO: check for commandechos to approve reception of sent commands here and call callback
               }
            }
         }
         while(charbuf != Q_TIMEOUT);
      }
   }
}

Hope this doesn't reach to deep away from the migration and porting thread.

[Giovanni]

The macro Q_TIMEOUT is defined in chqueues.h as in 2.6.6, it is strange you don't find it.

About CHN_OUTPUT_EMPTY, I see no reason for that, that flag is raised when the queue becomes non-empty so you have to make sure to empty the queue before waiting again for that flag, but apparently this is already your case.

Try putting a breakpoint in sdIncomingDataI() and see what happens there.

Giovanni

[goeck]

ChibiStudio / Eclipse doesn't take me to the source file you mentioned when trying to digg deeper into the code. That's why I was thinking, there might have been a change, though it compiles with Q_TIMEOUT used.

Actually I test the flags against CHN_INPUT_AVAILABLE as this was the proposed solution to this here in the forum.
What about the macro you mentioned, CHN_OUTPUT_EMPTY?

[Giovanni]

Sorry, I meant CHN_INPUT_AVAILABLE. It is generated in the function I mentioned before.

About Eclipse, do right click on the project and reindex it, probably the symbol table is not updated.

Giovanni

[goeck]

Oh alright, so just a misunderstanding. No worries.
I actually kind of found the caus e of my issue, at least at the moment after some simple testing it seems so.
Event catching and reaction worked fine pretty soon, but there was stuff in the input queue that jammed everything.
Somehow the following was just not calculated as TRUE

Code: Select all

if(flags & CHN_INPUT_AVAILABLE) {                           
            do{                                                
               \\read bytes from iqueue
            }
            while(charbuf != Q_TIMEOUT);
         }

After clearing the iqueue during start of the listener thread and after the init of the UART attached devices have happened the UART handler works fine again.
The attached device echoes back all the commands that it receives... After init, it just sends data when it is ready to do so.

Code: Select all

// Clear any content in input que, that might still reside due to echoed bytes from ISD init
   chIQResetI( &SD1.iqueue);

Thanks once more for the help, Giovanni.

[nuft]

Hello,
While porting a STM32 CAN driver form 2.6 to 3.0 I spent some time on an introduced bug because of the API change of nvicSetSystemHandlerPriority() from the ARM Cortex port.
In 2.6 the above function needed an IRQ priority modified by the macro CORTEX_PRIORITY_MASK(). However, in 3.0 the priority has to be passed directly, while a macro similarly named CORTEX_PRIO_MASK() is still present.
I didn't find any documentation of this change. If this was already documented, could you tell me where?
I mention this because I think, this belongs in the porting guide too.
Thanks.

[Giovanni]

Correct, now the priority is always passed unmodified. I will add this to the article.

Giovanni

[fastlink30]

link on [INFO] ChibiOS 2.6->3.0 porting guide thread is missing