Pure Basic supports independent program threads, but is beyond my level of programming to be of any use to you. Suggest you look at their forum for better information.
http://purebasic.myforums.net/
You mentioned that you receive ~16 bytes of data per event. What kind of calculations do you do on the incoming data? Whatever you do with the incoming stream, just put that portion of the program in a 1,000,000 iteration loop and calculate the average time that Blitz spends to process the incoming data stream. Then you'll at least know how many processes Blitz can handle per second. After attaining the processing time, you will need to ascertain the time Blitz takes to process each graphic area in a similar fashion. This is the only way that I know of getting real time results, afterall if you are using Windows, then you cannot acheive true real time processing, only *near* real time processing (unless you can program your own vxd's).
Looking at it from another perspective however, you should have in excess of 100 million machine cycles per second for each process, or 100,000 machine cycles per millisecond per process. With 100,000 machine cycles per millisecond, you may with to consider polling the ports instead of generating an interrupt. This should allow you quite a bit of flexibility in what you can accomplish towards real time programming. Even with an engine that screams at 12,000 RPM the engine only turns 7.2 degrees in one millisecond.
http://purebasic.myforums.net/
You mentioned that you receive ~16 bytes of data per event. What kind of calculations do you do on the incoming data? Whatever you do with the incoming stream, just put that portion of the program in a 1,000,000 iteration loop and calculate the average time that Blitz spends to process the incoming data stream. Then you'll at least know how many processes Blitz can handle per second. After attaining the processing time, you will need to ascertain the time Blitz takes to process each graphic area in a similar fashion. This is the only way that I know of getting real time results, afterall if you are using Windows, then you cannot acheive true real time processing, only *near* real time processing (unless you can program your own vxd's).
Looking at it from another perspective however, you should have in excess of 100 million machine cycles per second for each process, or 100,000 machine cycles per millisecond per process. With 100,000 machine cycles per millisecond, you may with to consider polling the ports instead of generating an interrupt. This should allow you quite a bit of flexibility in what you can accomplish towards real time programming. Even with an engine that screams at 12,000 RPM the engine only turns 7.2 degrees in one millisecond.