Actually I had tried using the sigaction(SIGIO, &saio, NULL) with signal handler function on UART receive. Still there is no triggering/running on the signal handler function. I believe this is quite similar to the callback function that you mention.
The reason of me using the pthread is that I would like the UART receive to run in asynchronous while my main function can do other stuff, and not polling on UART receive. Anyway, your suggestion of running multiple executables is insightful. I've never used that before, any get started material can you recommend? On Wednesday, July 27, 2016 at 6:11:21 PM UTC+8, William Hermans wrote: > > 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] > <javascript:>> 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] <javascript:>. >> 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/8981d8cb-19a7-4f78-9c6c-65c0cfdf6559%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
