@Micka Can you share the snippet of your code that configure the UART? Is it using blocking read on UART? I suspect maybe the problem may have to do with the incorrect configuration, as after start/shutdown minicom, then the UART C program start to run properly.
On Wed, Jul 27, 2016 at 9:01 PM, Micka <[email protected]> wrote: > My application on the beaglebone black are multithread and for the > reception there is a thread. And I don't have any problem receiving data on > this thread. Don't forget to use mutex and semaphore. > > Le mer. 27 juil. 2016 12:11, William Hermans <[email protected]> a écrit : > >> If I recall correctly, typically anything that is related to interrupts, >> and blocking file reads( things of this nature - where you're waiting ) are >> not thread safe as these types of calls can be preempted by another thread. >> So, what I'd do to test if my assumption is correct. Is to write a test >> app without threading. Or perhaps write a callback, but again, callbacks >> are definitely not thread safe. >> >> I'm not seeing all the posts in this discussion for some reason. But is >> there a specific reason why you need threads ? Because if you need this >> sort of process segregation, it may be best to run entirely different >> processes( multiple executables ), and then use some form of IPC mechanism >> such as shared memory. Which POSIX shared memory really is fairly simple >> once you become familiar with it. I had to do this with an application I >> wrote several months back ,myself. Since a library I was using used >> callbacks extensively and was not playing nicely on the stack ( preempting >> my own code routinely ). >> >> On Wed, Jul 27, 2016 at 2:49 AM, Regina Choi <[email protected]> >> wrote: >> >>> >>> I'm not aware of library functions that are not thread safe, can you >>> give some example library function that is not thread safe? So if the >>> library function is not thread safe, what would be the effect if we >>> accidentally use it in our program? >>> >>> Does that means we cannot use the library function completely in pthread >>> if it is not thread safe and resort to polling mechanism? >>> >>> >>> >>> On Wednesday, July 27, 2016 at 1:00:10 PM UTC+8, William Hermans wrote: >>>> >>>> Are you sure everything you're using code wise is thread safe ? There >>>> are a lot of library functions that are not thread safe. >>>> >>>> On Mon, Jul 25, 2016 at 8:31 PM, Regina Choi <[email protected]> >>>> wrote: >>>> >>>>> Thanks for reply. >>>>> >>>>> I'm not sure why, but I don't get timeout error messages from the read >>>>> thread (though I have set it to 1 sec) !? It just freeze there waiting for >>>>> UART input, even though there are UART input coming in. >>>>> >>>>> Yes, I got the Byte sent message printf from TX thread. Please see the >>>>> attachement. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Tue, Jul 26, 2016 at 2:30 AM, Wally Bkg <[email protected]> wrote: >>>>> >>>>>> I'm stumped. Are you now getting timeout error messages from the >>>>>> read thread? >>>>>> >>>>>> Are you getting the Byte sent: message printf from the TX thread? >>>>>> >>>>>> >>>>>> On Sunday, July 24, 2016 at 10:11:57 PM UTC-5, Regina Choi wrote: >>>>>>> >>>>>>> >>>>>>> Apology for late reply. >>>>>>> >>>>>>> I've tried with options.c_cc[VMIN] = 0; it's still the same issue. >>>>>>> >>>>>>> From the datasheet of AM335x, uart rx/tx buffers are 64 bytes. >>>>>>> >>>>>>> I've also tried putting tx command in tx thread that activated later >>>>>>> than rx thread. Nothing changed as well. >>>>>>> >>>>>>> void* uartTxWait(void *param){ >>>>>>> >>>>>>> int count; >>>>>>> usleep(1000000); >>>>>>> unsigned char cmd[] = {0x10, 0x00, 0x32}; //"Tx From >>>>>>> Beaglebone "; >>>>>>> >>>>>>> if ((count = write(file, (char*)cmd, 3))<0){ >>>>>>> perror("Failed to write to the output\n"); >>>>>>> //tcsetattr(file, TCSAFLUSH, &oriopt); >>>>>>> //before exit, undo raw setting >>>>>>> //return -1; >>>>>>> }else{ >>>>>>> printf("Byte sent: %d \n", count); >>>>>>> } >>>>>>> >>>>>>> >>>>>>> pthread_exit(0); >>>>>>> } >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Friday, July 22, 2016 at 10:50:52 PM UTC+8, Wally Bkg wrote: >>>>>>>> >>>>>>>> I noticed you have options.c_cc[VMIN] = 2; If for some reason >>>>>>>> only one character comes in, it'll block forever. Try >>>>>>>> using options.c_cc[VMIN] = 0; so that each char can timeout if its not >>>>>>>> received. >>>>>>>> >>>>>>>> How big are the Beaglebone uart buffers? >>>>>>>> >>>>>>>> You may still have a race between your write of the data and >>>>>>>> starting your RX thread. Try putting the write into your TX thread and >>>>>>>> launch it after you've launched the RX thread. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Thursday, July 21, 2016 at 10:10:11 PM UTC-5, Regina Choi wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> Hi Wally, >>>>>>>>> >>>>>>>>> I have tried adding fflush(stdout and fflush(stderr) in the while >>>>>>>>> loop, however, in the UartRxWait thread, the read( ) function is in >>>>>>>>> block >>>>>>>>> waiting for incoming data. Which doesn't output anything. In the case, >>>>>>>>> after start and shut down minicom, the UartRxWait thread running as >>>>>>>>> usual, >>>>>>>>> there is no output from the fflush(stdout) and fflush(stderr) either. >>>>>>>>> >>>>>>>>> yes, at the moment I have to kill the program to terminate. I >>>>>>>>> have modified the code such that it loop for only 5 times and >>>>>>>>> terminate the >>>>>>>>> thread. >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>> For more options, visit http://beagleboard.org/discuss >>>>>> --- >>>>>> You received this message because you are subscribed to a topic in >>>>>> the Google Groups "BeagleBoard" group. >>>>>> To unsubscribe from this topic, visit >>>>>> https://groups.google.com/d/topic/beagleboard/p_v98aypDfk/unsubscribe >>>>>> . >>>>>> To unsubscribe from this group and all its topics, send an email to >>>>>> [email protected]. >>>>>> To view this discussion on the web visit >>>>>> https://groups.google.com/d/msgid/beagleboard/16a9b1d0-6c0e-4b31-ac7f-490bc091f751%40googlegroups.com >>>>>> <https://groups.google.com/d/msgid/beagleboard/16a9b1d0-6c0e-4b31-ac7f-490bc091f751%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> >>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>> >>>>> >>>>> -- >>>>> For more options, visit http://beagleboard.org/discuss >>>>> --- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "BeagleBoard" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/d/msgid/beagleboard/CAJ5%2BLfyKahyeih3Db50ZP7yOiLPUyKt0f6sn7dwnijJ6gEx07Q%40mail.gmail.com >>>>> <https://groups.google.com/d/msgid/beagleboard/CAJ5%2BLfyKahyeih3Db50ZP7yOiLPUyKt0f6sn7dwnijJ6gEx07Q%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> >>>> -- >>> For more options, visit http://beagleboard.org/discuss >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "BeagleBoard" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/beagleboard/9d7676da-fb51-4ea2-b378-77486ba052bd%40googlegroups.com >>> <https://groups.google.com/d/msgid/beagleboard/9d7676da-fb51-4ea2-b378-77486ba052bd%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- >> For more options, visit http://beagleboard.org/discuss >> --- >> You received this message because you are subscribed to the Google Groups >> "BeagleBoard" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/beagleboard/CALHSORrX555JB43Db_bsajqhGD_nnSOKx8NmoUAnDbjF7HUubQ%40mail.gmail.com >> <https://groups.google.com/d/msgid/beagleboard/CALHSORrX555JB43Db_bsajqhGD_nnSOKx8NmoUAnDbjF7HUubQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > -- > For more options, visit http://beagleboard.org/discuss > --- > You received this message because you are subscribed to a topic in the > Google Groups "BeagleBoard" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/beagleboard/p_v98aypDfk/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/beagleboard/CAF%2BMRtkeVNY5Nb6jOL2ztLTyMhc2E8x_xLghnDe_rgjKgU-YtA%40mail.gmail.com > <https://groups.google.com/d/msgid/beagleboard/CAF%2BMRtkeVNY5Nb6jOL2ztLTyMhc2E8x_xLghnDe_rgjKgU-YtA%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CAJ5%2BLfxJjVjM7ukMhivkXTO5%2BCwRbw0bMbaaEyzex7GtVsYWJg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
