The worst programmer ever to grace this forum - ME!

[HankMcSpank]

Hi - me again!

Ok, I think I mentioned that I was going to bin my 'magnets & reed switch'...in favour of an optical pickup (I needed more 'resolution' & less debouncing) - well, I have all the pieces in place now...so why am I back?

well, I need help wrt how I can be sure to ascertain that my circuit (& program) is actually picking up all the pulses fine. And with a motor turning at between 300 & 400RPM, and 48 stripes per revolution...I lose count when doing this manually!

Here's the circuit I've implemented.... http://hans-w.com/RPM.gif (I should point out that Im not using the same PIC - I'm using a 16F690 - nor his hex code...as I need to be able to customize the program)

Re the tach pickup itself - on the edge of my turning motor is a phototransistor aimed at a round disc with 48 lines on it (essentially a pie chart knocked up in Excel, printed onto a CD label & then onto an old CD!!) ...as each one of these lines passes the phototransistor, a pulse ultimately appears at a PIC input pin.

It seems to be working reasonably well *but* I have a sneaking suspiscion, that either the electronics is not setup right (there's a preset in that schematic that needs setting optimally - I have a scope, but at 48 pulses per rev running at 400RPM, the trace is too jittery to set the levels in this manner).

What I'd like to know, is the best way to establish that *all* 48 stripes are being 'seen' by the PIC and everyrevolution (not just for one revolution, but say over 400 revolutions).

I'm figuring it'll need some form of counter, with the methodology being something along these lines (this is a labourious method!)....

Start counter
Pulse 1 arrives - output this info to screen along with counter time (I'm using the Pickit2 Uart tool to debug)
Pulse 2 arrives - output this data to screen along with counter time.

I can then cut/paste the above into Excel, do a bit of simple maths (ie subtract each 'counter time' from the previous, which will yield the time taken beteween successive pulses) & ultimately put this into a bar chart. All being well my bar chart should have bars of equal height from left to right.

Since the above method seems a bit long winded, I'm sure there must me a slicker way in real time, for example...

Start counter
Pulse 1 arrives - note the time in variable1
pulse 2 arrives - note the time in variable2
Subtract variable 1 from variable 2 (to give the time between pulses) - place into variable 3

then continue in a similar vein?

The clever bit would be to have a calculation that goes along the lines of "If the time between successive pulses is greater than say 90%, then we must have missed a pulse - output this info to screen via the Pickit Uart tool.

Does this sound plausible?

Could anyone help me out with a little bit of code to get me started please?(I've never dealt with counters previously!)

[HankMcSpank]

Ok...first sign of madness is talking to yourself - I must be totally barking.

Tonight, I knocked up an encoder wheel & used DT's interupt utility to assist the PIC in cleanly counting the 96 black stripes ...using interupts vs polling is a great success (ie I reckon all the black lines are being counted now).

But I've a new problem!

Previously, I have been using the Microchip Uart tool to output the number of encoder revs counted by the PIC onto my PC screen (essentially I just output a dedicated variable that increments after every 96 black stripes have been counted).

Up until now, everything was fine - could see my info onscreen quite fine.

My problem now is that becuase the black stripe interupts are running every 2ms (this number being based on a speed of 300RPM - which equates to 5 revs per second... therefore 200ms divided by 96 'black stripes' = 2.08ms between interupts) ...my onscreen info has become truncated/garbled. If I slow the wheel speed right down to say about 30RPM...it's fine....I can read my revs on my PC screen again.

this suggests that the interupts are interfering with the serial comms/Debug/Uart signal flow. (this is a little puzzling as I had thought the whole point of interupts was to be non disruptive in the sense they tuck everything away before heading off to do the interupt routine, & then pick up where they left off by 'restoring things as they were' after the routine?)

Does anyone have a cunning plan to allow me to get my simple onscreen Debug info back - I only need to see one small bit of info...this being the total rev count in pseudo real time onscreen. (I'm happy to consider alternatives too?!)

[Jumper]

Hi,

If you have a look at RB7 it is also called TX. This is the HARDWARE port for the serial communication. HSEROUT or HSEROUT2 will be the tool for this :-)

When you use the hardware serial port you only need to put a byte in the transmit buffer and then the PIC will send out the 10 bits for you with proper timing (start bit, 8 data, stop bit) so the interupts will not trash your data.

/me

[HankMcSpank]

Thanks for your input.

I'm struggling a little with the options available to get variable 'contents' to the outside world! Here's my understanding (though could be worng!)...

1. Hardware serial .... the traditional manner (neds a converter such as a MAX232). I'd like to keep it simple & component count low as possible, so I'm not pursuing this route.

2, PICKit2 - Uart tool....this is what I'm using at the moment, but like I say,the high number of interupts is causing havoc with the data I'm seeing onscreen..

Now this is where it gets a little 'grey' for me ....I'm using the command "Debug" to get my variable contents out and onto my PC via the Pickit2 Uart tool... I'm not calling any special .bas files - it just works! Is this using software or hardware?

Now then, I'm just reading on this page...

http://www.electro-tech-online.com/m...t-example.html

where the guy declares in one of his headers...

Device = 18F4550
Clock = 8
Config FOSC = INTOSCIO_EC

// import usart module...
Include "usart.bas"

I'm figuring that going this route might actually use the PIC uart hardware? If so, this sounds ideal....can anyone shed any light here please?

[Jumper]

Some of the new 18-series PIC has the possibility to invert the hardware usart using a register setting. Your pic does not have that option..

just remember that sometimes people take component count and simplicity too far and they end up complicated and miserable. Sometimes a MAX can help... especially if you find one that requires zero external components :-)

[HankMcSpank]

Thanks once again.

I have to hold my hand up & say I'm getting a little forgetful nowadays....

it's been a bit of a long journey & during the many twists & turns, I'd forgot that a few weeks ago, I was actually using the HSEROUT command, with my PIckit2 programmer as the 'glue' between my PIC & my PC (http://www.picbasic.co.uk/forum/showthread.php?p=73184 ...though in that thread, you'll see for that particular 'moment in time' I aborted the HSEROUT route in favour of using DEBUG...but I can't use DEBUG anymore due to the high number of interrrupts my program is having to handle - also, I never did get to the bottom of why the command hserout ["Hello World", 10,13] only line feeds intemittently!

This HSEROUT/Pickiit2 method obviously does use hardware to get data out of the PIC (as opposed to the software based DEBUG command method), so I'm hoping that revisiting that aspect tonight will yield good results with the heavy amount of encoder wheel black stripe interupts!

[ShaneMichael]

I had the same trouble when I used "Debug" and interupts, using the HSEROUT worked great. You can read about it in a thread I had
"DT Interrupt and Elapsed Time Running Slow"

http://www.picbasic.co.uk/forum/showthread.php?t=11056

hope that helps,

Shane

[HankMcSpank]

Hi Shane...thanks for the info.

Just to report that my PC onscreen text from my PIC is no longer garbled with (heaps) of interupts ...using the HSEROUT command (9600 baud) coupled with the PICKit2 Uart tool - not a MAX232 chip in sight :-)

The last thing I now need to achieve is user input!

Essentially, when my program first starts, I need to prompt the user for input (using the HSERIN or SERIN command)- the input will always be three characters long - terminated with a CR.

I've googled a fair bit on this one (HSERIN & SERIN), but surprisingly, I've not find anything that a newbie like myself can latch onto easily!

Could anyone be so kind to help out?