Loop problem: CPU usage

[dude_1967]

I mean, when I started developping the comms I wanted to use non-overlapping I/O so I could keep control over what was happening. The problem was that using non-overlapping my Tx thread would block until an Rx event occured. I couldn't get to the bottom of this so I switched to overlapped which works now... but the additional complexity worries me.

I've just tested the Rx and Tx at 60 per second and both the µC and the PC seem to be able to keep up so that's quite encouraging.

Wait a minute Ben. The PC side is extremely powerful. There should not be a problem here no matter what baud rate you are using.

You just need to design the right kind of driver using the Win32 API for your particular requirements. For your simple communication needs, I don't think that you need any kind of overlapped design. Nor do I think that you need send events or receive events on the PC side. You predominantly use interrupt supported polling on the microcontroller side. And you can probably very well get away with a simple polling thread on the PC side combined with a sensible use of the Sleep(...) function. Maybe you can handle send as well as receive within a single worker thread.

Can you try to re-think your design and get it as simple as possible? Also do make sure that you have full command of the RS232 in the Win32-API so that you are not struggling with two issues at once.

I have been really busy lately so I can't get all over this---maybe next week if you still need assistance at that time.

Sincerely, Chris.

[shoppinit]

Thanks for that.

The RS-232 comms seem to be working OK. I need my PC Rx to be event driven but not the Tx. It seems that with non overlapping I can't Tx while the Rx is waiting for an event. It doesn't matter, the overlapped IO seems to be working for me.

I have 2 serial ports on the PC and micro, so if things get out of control I'll use one for Rx and the other for Tx.

It's a real pleasure knowing that if you ask the micro to do something at x ms it'll do it :-)

Thanks for all your help so far.

Ben.

[dude_1967]

Hi Ben,

I have 2 serial ports on the PC and micro, so if things get out of control I'll use one for Rx and the other for Tx.

You should really try to develop your microcontroller serial driver with both Rx and Tx using one port. You can even write the majority of the code (except for the register stuff) using the same code for both channels. Did you have a chance to study the sample driver which I had attatched a few weeks ago?

It's a real pleasure knowing that if you ask the micro to do something at x ms it'll do it :-)

Yes, it is almost strange in this day and age when a computer actually does something that it was programmed to do.

Mixing microcontrollers, which offer reaction times in hard real-time, with the comfort of a PC interface can be a very powerful technique.

It sounds like you are coming along pretty well with your project.

Keep going!

Sincerely, Chris.

[shoppinit]

Hi Chris,

I looked at your halser.c and it helped with developping the micro side of things. Thanks. That part works really well, I'm quite happy with my serial driver for the micro.

My only concern was the PC side which seems to be working OK now (fingers crossed). I'll keep testing and let you know :-)

Off hand, do you know if the following is feasible:

Create a thread (possibly with higher than normal priority) which waits for an event generated by the micro every 1 ms. The aim being to generate a "realtime" tick in the PC. Not sure what I'd use if for yet, but it's been in the back of my mind.

Have a good weekend!

Ben.

[dude_1967]

Off hand, do you know if the following is feasible:

Create a thread (possibly with higher than normal priority) which waits for an event generated by the micro every 1 ms. The aim being to generate a "realtime" tick in the PC. Not sure what I'd use if for yet, but it's been in the back of my mind.

Ben,

Unfortunately this is not possible with the PC running any kind of Windows. As you may recall at the beginning of this thread, we had a lot of discussion pertaining to the feasibility of generating an internal semi-realtime tick within the Windows environment. And we argued that it was not possible. Sadly the semi-realtime response to an external tick is also not possible within the Windows environment.

A high priority or critical priority thread will not provide for semi-realtime performance. Other processes will simply interrupt this thread.

You can, however, access a real-time tick within the PC. Assuming you have some generation of Pentium, there is support for the pentium time stamp counter, accessed with the rdtsc assembler operation (google and search here for rdtsc). Also Windows supports QueryPerformanceFrequency(...) as well as QueryPerformanceCounter(...). There is a lot of information at CodeGuru about all of these fast counters. All of these fast counters will give you the exact tick (with some sort of tick units) at the time of the call. However, the timing resolution of the call is governed by the limitations of Windows.

Sincerely, Chris.

[*io*]

Chris (dude_1967),

Is the above post equally applicable to a linux environment not compiled with real-time support?

Kind Regards
Chris

[dude_1967]

Chris (dude_1967),
Is the above post equally applicable to a linux environment not compiled with real-time support?

I do not know enough abuot linux systems to be able to fully comment on their real-time characteristics. However, I do suspect that standard linux configurations in normal user-mode are just as incapable of real-time performance as windows in normal-user mode.

The real-time performance tick, accessed through the rdtsc assembler command, is present for all pentiums and their clones. The reading of the rdtsc can be programmed in the linux environment using inline assembler and the language of gas (Gnu assembler) in the GCC. No problem here...

Sincerely, Chris.

[shoppinit]

Does any one know if Vista have any advantages in terms of realtime apps?

Chris, I'm liking the microcontrollers. I might forego the PC altogether! If only... Thanks to all those who oriented me towards the micro route.

Ben.

[dude_1967]

Does any one know if Vista have any advantages in terms of realtime apps?

Absolutely not!

Chris, I'm liking the microcontrollers. I might forego the PC altogether! If only...

Yes, they can be of great assistance when timing or other simplicity really counts.

Thanks to all those who oriented me towards the micro route.

You are welcome, Ben. That's what the CodeGuru forums are all about.

So now I have a question for you. Could you please list the microcontroller, compiler, debug system, OS, starter-kit, etc. which you decided to use for your project?

Sincerely, Chris.

[shoppinit]

So now I have a question for you. Could you please list the microcontroller, compiler, debug system, OS, starter-kit, etc. which you decided to use for your project?

Hi Chris,

THe micro is an NXP LPC 2138 mounted on an Olimex evaluation board. I got this one first:

http://www.olimex.com/dev/lpc-mt-2138.html

and I've just ordered this one which is essentially the same but without all the toys:

http://www.olimex.com/dev/lpc-p2138.html

I like the LPC2138 - it's got loads of useful peripherals and has loads of memory. It also seems to be quick, but I have nothing to compare it to, so I could be wrong about that. Runs at 60MHz in any case.

Also from Olimex I got the parallel port JTAG debugger / programmer. Cheap and effective.

The compiler / debugger environment is Rowley Cross Studio for ARM - I'm particularly pleased with this. Worked right off the bat, is easy to use for anyone that knows Visual Studio and is very reasonable in terms of price. The compiler is based (I believe) on the open source one, so all the examples for the LPC2xxx can be compiled on there. This is one of the reasons I chose it - the availability of example code. That's how I learn best.

I also like that I can put breakpoints in my program just like VS and run step by step. Helps if you're like me and generate 2 bugs per line of code written!

The evaluation board was about $80, the JTAG about $30 and Rowley about $150. I consider that pretty cost effective to get started. I'd definitely recommend this set-up for someone considering getting started in micros for the first time.

I decided to use the FreeRTOS realtime OS for my application. There is a port for the Rowley IDE and LPC2138. It's for a Kiel evaluation board, but it's pretty straightforward to modify it for the Olimex one.

http://www.freertos.org

All the best!

Ben.

[shoppinit]

Hi Chris,

Here's a question for you, which kind of loops nicely back to where this thread started...

I've got the micro working just the way I like it (just a shame I can't do everything with it) and it's doing what it's supposed to do. Detecting objects, sending and receiving info to / from pc.

All works great... but at low speed. Once the speed goes up (ie. nb of objects to analyse per second), the PC starts missing the RS232 events. Well not miss, but react unpredictably. The micro is unshakeable.

This is not too surprising because task manager show the CPU usage at between 99 and 100% so I guess everything is struggling to keep up.

This is what I have difficulty understanding: I've timed everything and to completely analyse one object the whole process, from reception of message to finishing and sending the message back to micro takes about 25ms. So in theory, with nothing else running on the PC, at 12 objects / second I should be nowhere near 100% CPU usage. More like 30% I would have thought.

I've tried with various numbers of worker threads to carry out the analyses, but the result is always similar.

Where's my 70% of processor time gone? I need to be up to about 50 objects / second and I'm starting to look at extreme quad cores and/or multiplexing PCs!

All the best.

Ben.

[TheCPUWizard]

Ben,

Did you design performance counters into your PC application. If you did, then perfmon would help you out here. If not, then you may want to consider adding some.

David

[shoppinit]

Hi David,

I use QueryPerformanceCounter calls punctually to find bottle necks.

I use perfmon to see what's going on, but I didn't know that you can specifically use code to monitor performance. How would I go about doing that?

I've also tried LTProf in the past, I might dig that out again...

Thanks.

Ben.

[MikeAThon]

You might still be viewing the role of the PC as a real-time role. For example, if proper operation of your overall system requires the PC to get some reponse back to an inquiry from the mirco within some time interval (like within 25 ms), then the PC is still being used incorrectly in a real-time role, and the system will eventually fail.

Tell us (in words) the overall operation of your current system. For example, micro detects an object and sends RS-232 notification to PC, which then does what? And what does the micro do in the meantime? And does the micro require a response from the PC in order to continue processing the object (hopefully not).

Also, post your PC's code. Maybe you are still using a polling paradigm, which should no longer be necessary since you can now rely on WaitCommEvent() to wait for an RS-232 notification from the micro.

Mike

[shoppinit]

Hi Mike,

This is the sequence of events:

1. The micro physically detects an object and gives it a number
2. The micro sends (serial) the number to the PC
3. The PC receives a serial event and unblocks a thread to start the analysis, giving the object the number that the micro sent.
4. Once the PC is done, it sends the result of the analysis (good or bad), as well as the object number, back to the micro so that the micro can take appropriate action. There is about a 1 second window for this.

If the micro doesn't get the message from the PC in time, it takes a default action. It's basically just looping all the time to see if it's time to take an action. It loops every 1 ms.

There's definitely no polling going on in the PC. (I learned my lesson ) Everything is event driven.

My application is, however, a console app (since I don't need any GUI output)... it just occured to me that maybe this might be potentially a problem?

Thanks.

Ben.