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.
[INFO] ChibiOS 2.6->3.0 porting guide
- Giovanni
- Site Admin
- Posts: 14455
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: [INFO] ChibiOS 2.6->3.0 porting guide
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
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
Re: [INFO] ChibiOS 2.6->3.0 porting guide
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...
Hope this doesn't reach to deep away from the migration and porting thread.
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
- Site Admin
- Posts: 14455
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: [INFO] ChibiOS 2.6->3.0 porting guide
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
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
Re: [INFO] ChibiOS 2.6->3.0 porting guide
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?
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
- Site Admin
- Posts: 14455
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: [INFO] ChibiOS 2.6->3.0 porting guide
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
About Eclipse, do right click on the project and reindex it, probably the symbol table is not updated.
Giovanni
Re: [INFO] ChibiOS 2.6->3.0 porting guide
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
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.
Thanks once more for the help, Giovanni.
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.
Re: [INFO] ChibiOS 2.6->3.0 porting guide
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.
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
- Site Admin
- Posts: 14455
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: [INFO] ChibiOS 2.6->3.0 porting guide
Correct, now the priority is always passed unmodified. I will add this to the article.
Giovanni
Giovanni
-
- Posts: 42
- Joined: Tue Aug 12, 2014 1:25 pm
- Location: Brescia, Italy
- Contact:
Re: [INFO] ChibiOS 2.6->3.0 porting guide
link on [INFO] ChibiOS 2.6->3.0 porting guide thread is missing
Return to “Development and Feedback”
Who is online
Users browsing this forum: No registered users and 16 guests