@ William Thanks for information, I will have a look at it.
On Thu, Jul 28, 2016 at 4:51 AM, William Hermans <[email protected]> wrote: > @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 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/CALHSORqsx8KX5Ru8ikF4%2Bm%3DZ9HVD38Lx-53NqQmoXc5jjPpECw%40mail.gmail.com > <https://groups.google.com/d/msgid/beagleboard/CALHSORqsx8KX5Ru8ikF4%2Bm%3DZ9HVD38Lx-53NqQmoXc5jjPpECw%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%2BLfyKbBRmq7jtCx-TVuB14OggjvcV2PfUhYoR2__zGGCRYQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
