I am trying to write a program that accepts user input from the keyboard and a joystick and then sends out the data using the rs232 port of my system to other hardware. I need to send out about 10 bytes every 20 milliseconds. The thing is I need to also keep on reading data from the same port and display it on an opengl screen. This visualizes the hardware data coming in.
So the way I did it was by spinning everything around opengl…I setup GLUT - as follows :
/* register call back functions */
glutDisplayFunc(redraw);
glutReshapeFunc(resize);
glutIdleFunc(visualize);
glutKeyboardFunc(getkey);
glutSpecialFunc(getspecialkey);
and in the idle function visualize() …I currently do the joystick reading and rs232 packet sending and recv stuff.
I also call redraw after I am done so if I have received new data above, then it gets drawn on the screen.
Everything works fine except that calling redraw() from visualize() is logical in a PC simulation where the simulation state needs to be rendered on screen after a simulation step. But in my case it takes up too much time …much greater than 20 ms…so I can no longer guarantee i can send out packets through the rs232 port every 20 ms.
What are my options here if I want to send out packets and visualize data at a reasonable frame rate - packets within 20 ms is more imp of course.
baud rate is about 115 kbps…yes I can do multithreading…maybe have a separate thread for the visualizing part and another for just sending and receving part. Is there any standard linux library for threads with low overhead for switching ?
Thread-switching nowadays is extremely light (< 3k cycles), unlike what popular literature and belief dictates. With virtually everyone having dualcores+ , there’s even less worry .
There’s “PThreads”.
115kbps, 90 or 100 bits at 50fps: 0.78ms per send if you’re doing it synchronously. Easily doable, no?
If dualcores are not an option, the first thing I’d try is to make the TX and RX asynchronous, the specialized ICs on the motherboard can handle it. Yet, the two-threads approach looks really better nowadays. (you need FIFOs and critical-sections/xchgcmp)
Yeah…i think I ll go ahead with the 2 threads…I am planning to store the user inputs in a set of global variables by the thread containing the GLUT main loop and having it picked up from there to be sent by the rs232 thread. After sending, the same thread checks if anything is there in the local UART buffer and if so, it stores it in a different set of receive variables. The receive variables are only read by the GLUT thread for rendering and never written to.
So in either case, 1 thread is writing and the other reading…so I am hoping this wont cause any locking issues as these are the minimum variables which have to be shared.