Yeah, this is not something I've personally experienced or tested. Was simply a guess on my behalf. However, I am seeing a lot of code in the groups here lately that over complicates reading, and writing to / from UARTs on the Beaglebone.
For example, this is how simple it is to read from a serial device in Nodejs: https://github.com/wphermans/Bonejs/blob/master/examples/serial-read-example.js Granted, C is not exactly event driven like javascript. It could be, but essentially it all boils down to polling via a "message pump" ( a loop ). So basically, all one needs to do is open() on the serial device path, and perform a blocking read(), or write a callback that acts on received data *somehow*. Both methods have similar issues, at least in the context that this process should be handled, or run all by it's self. As far as setting serial device parameters. This can be done via an external cmd line tool such as getty, fgetty, or similar. If it must be dynamic . . . then you could even wrap these same already existent cmd line tools. I think that ideally, a very simple demo app, should be less than 100 lines of code, and very easy to read. SO yeah, maybe I'll eventually write up an example in C, and blog on it. But it probably won't be today. On Wed, Jul 27, 2016 at 6:01 AM, 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 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/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/CALHSORoR6ns8aT50f7LT%2BjSSbYG5eQmUQuL9PbjL_6QqWykekQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
