Matrix user forums

I'm trying to make such a project with a PIC16F84A and MPLAB and a fully updated PICStart PLUS - readout on 4 LED Digits, a switch is used for choosing COUNTING or RPM. If counting there is a FREEZE button to freeze the display. Clearing/reset is just done by MCLR. I can get the counter to work and I can get the RPM to work as TWO projects and have big troubles in joining them into ONE project

BUT

can FlowCode REALY do this for me if I can draw the flocharts in a proper way and can it make the code quick enough for RPMs up to 9999 ?

And can I still use my PICStarter for "burning" the code into the PIC ?

I pick up pulses from a gear wheel with 80 teeth and this wheel should be able to go up to (in teory) 9999 RPM - is that posible with FlowCode ?

I do NOT know C-code but have worked a lot with other languages - and a "beginner" in ASM.

Hello ksor

Most of the Matrix team are away at a show this week but I will help as much as I can.

Flowcode should be more than adequate to make a program quick enough to reach 9999 in a minute.

You can use Flowcode to build your .hex file that will be sent via your PICstart programmer.

Having made such a project in the past the key is to realise that you only need to sample the rotation speed for say a second or two and then the programme can happily go away and spend it time giving output and ignore any further RPM data input.

If this is not self evident, then consider how fast you can read a display or what you would do with a rapidly changing display result (assuming rpm changes). The answer is probably not much. If you want dynamic acceleration data then outputting to a visual display is probably not the way to go anyway.

If I have missed the point then sorry, but it does seem that the two programmes need not work simultaneously, merely sequentially (in a big loop).

You'r just right - I only need to change the display every 1 second but I think I have to refresh it, say 75-80 times pr sekund.

I think I'll have to try much more in the FlowCode demo version to see the point in implementing my "Freeze display" because I for a shot moment change an output port to an input port to se IF the freeze button is pressed.

In theory my big wheel with 80 teeth could generate 80*9999 pulses pr. minut - can the code "catch" them all without no problems ?

KSor, Denmark

80 * 9999 is about 800,000 and a pic can run at say 20MHz, with an instruction cycle of about 4MHz, which gives 5 instructions inbetween cycles. This looks like just enough time, but barely so, and not long enough for a RB0 interrupt counting routine.

An alternative route is to use Timer 1, where you can have a pulse counter 'independent' of code execution, here you could count up to 65,000 pulses (so do it for 1/20 second and use up 4000 pulses) without costing a single line of concurrent code. This may even enable you to refresh the display.

I am looking forward to Flowcode 3 to see if this feature is properly supported.

Happy coding.

Hi Mark,

Sorry but I don't think there's a Timer1 in a 16F84

The 16F84 doesnt have a 16 bit timer1 but it does have an 8 bit timer0 so letting it timeout 255 times would add up to the same amount of dely. If this was implemented as an interrupt function then the PIC is free to carry on counting pulses.

Hi Ksor,

Yes, sorry I forgot the caveat in your first message on the 16F84. I am used to swapping between PIC devices to obtain whatever functionality I require.

One big benefit for Flowcode is that you can do this at will without recoding (some setup change can be required).

Since the cost difference between a 16F84 and a 16F876 is relatively small (your time trying to use the 16F84 is presumably worth something) then consider the change.

I'd consider the 16F88 chip - this is pin-for-pin compatible with the 84, but has a load of extra features. And because it is a more recent device, it is actually cheaper than the 16F88!