@Regina, Here is a discussion I started on the subject last year as I was experimenting with POSIX shared memory. On 43oh.com forums. I have lots of examples here as I was experimenting: http://forum.43oh.com/topic/8686-posix-ipc-shared-memory-mmap/
On Wed, Jul 27, 2016 at 1:43 PM, William Hermans <[email protected]> wrote: > 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/CALHSORqsx8KX5Ru8ikF4%2Bm%3DZ9HVD38Lx-53NqQmoXc5jjPpECw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
