Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Categories

Welcome to the new platform of Programmer's Heaven! We apologize for the inconvenience caused, if you visited us from a broken link of the previous version. The main reason to move to a new platform is to provide more effective and collaborative experience to you all. Please feel free to experience the new platform and use its exciting features. Contact us for any issue that you need to get clarified. We are more than happy to help you.

Similar thread issues

coyoteboycoyoteboy Posts: 45Member
I'm having issues.lol.
I have a UI, and a second, comms, thread that will be simply looping and sending and recieving data to RS232 as frequently as possible.
I'm struggling to figure the best way to have the data shared between the threads so the user can enter new co-ordinates in the UI and it will process the change and alter the data that the comms thread reads, in a fashion that gives the required acceleration and speed of movement of the item.

I'm wondering if it would be better to use some sort of a stack of co-ords (co-ords are actually in a 23 byte string) written in one go by the UI thread, and picked off one at a time by the comms thread (down to the final position at which it will continue sending that position)instead of an intensive UI thread, bearing in mind that the other end of the RS232 is sat expecting constant data feed with no more than 250ms between new co-ords.

I'm guessing I'm using CS's too which dont appear to be a prob on the surface. I'm hoping not anyway!

My backgroud = new to programming so go easy :)

James

Comments

  • BriballBriball Posts: 265Member
    That actually is a very good idea...except one thing. Since this is a time critical operation (need info every 250s) then you need to inhibit the thread that sends the data as little as possible. This is all a design issue I think.

    When the UI locks the cs (yes, you'll need it with the queue idea) then the other thread can't run until the UI unlocks it. This could put you over 250 limit. Messages might be even worse (they use the queue structure as well).

    My only idea is to do some tests. Run several scenarios (sorry to make you code more than one) and put in some timers. Normal windows timers have on average a percision of 50, less than your 250. If the thing goes over the limit alert yourself. The one that alerts the fewest is the winner.

Sign In or Register to comment.