Best PIC for Project?

[PJ Adams]

Hello,

I have a project I am working on. I was hoping someone could look over my notes & tell me if this is possiple & which chip would be best.

If that chip is available as an 'easy to use' development board - great. If not - then I'll 'bread-board' it & experiment.

If possiple - I would prefer the PIC chip to use direct USB communications - as that makes things easy for power & comms.


I am trying to build a homemade dyno. The two inputs are engine RPM & Dyno drum rpm. These can be conditioned so that each 'event' is represented as 0 or 5+ volt signals. I have these signals working.

For engine RPM - absolute min is 2 events per second (4 cycle engine, 1 event per cycle = 480 RPM). Absolute max is 500 events per second (2 cycle 'screamer' racing engine = 30,000 RPM).

For dyno RPM - absolute min is 0. Absolute max is 83.33 events per second (single event per rpm - max 5,000 rpm).

I wish to time when these events occur as accurately as possible (within reason). I was hoping to run a timer to 1 million of a second. Faster would be better if available.

Here's how I imagined it might work...

1) Start the timer at 1Mhz
2) Every time there is an engine event - it triggers the PIC to send the timer count to the PC - with an identifier for engine rpm - like the value E200000
3) Every time there is a dyno drum event - it triggers the PIC to send the timer count to the PC - with an identifier for dyno drum rpm - like D300000
4) When the timer hits it's upper limit - reset it to 0 & send a message to the PC saying 0. That way - it would know when the timer is reset each time & it gives me a 0 reference relevant to the other readings.

Does this sound realistic to achive with a PIC chip?


Thanks

Paul

 

[BOBKA]

It is not trivial to use the USB on PIC.

Also consider that you might need to write drivers for your device, unless you are using build-in staff.

Try to implement it using USART if you can, this way you don't need to worry about the USB staff.

Or, you can also use the Microchip application notes to implement the rs-232 over USB.

 

[3v0]

Does this sound realistic to achive with a PIC chip?

Very much so if you can program.
As noted earlier the USB part is not trivial.
For the most part you are just looking at building a pair of tachs.

I am curious about the hardware?

 

[gramo]

You can use the TMR1 as a counter, and there’s even an application note on how to make a 50Mhz Frequency Meter, but the error rate rises as the frequency does.

Your Program would be very easy with the use of the PORTB Change Interrupt.

Basically, this interrupt occurs when the state of PORTB.4/PORTB.5/PORTB.6/PORTB.7 changes. Your program will instantly leave what ever it is doing, and goto an interrupt handle. Here you simply check what pin has changed, and "poll" the state to compare against the last value to check which Pin has changed.

[B]Interrupt [/B]PORTB_Change(2)
    [B]Save[/B](0)                                   // Save the system variables
    [B]If [/B]RBIF = 1 [B]Then                          [/B]// Check if the interrupt was a PORTB change
	RBIF = 0
        WREG = PORTB                          // Be sure to read the contents of PORTB to clear the mismatch (hardware requirement)
	[B]If [/B]RPM.Pin <> RPM.LastPin [B]Then        [/B]// Check if the RPM has changed
		RPM.Counter = RPM.Counter + 1
		RPM.LastPin = RPM.Pin
	[B]EndIf
	If [/B]DYNO.Pin <> DYNO.LastPin [B]Then      [/B]// Check if the DYNO signal has changed
		DYNO.Counter = DYNO.Counter + 1
		DYNO.LastPin = DYNO.Pin
	[B]EndIf[/B]
    E[B]ndIf[/B]
    [b]Restore[/B]                                   // Restore system variables
[B]End Interrupt[/B]

These are just simple examples - you would have to change things as necessary

And of course you would have a seperate Interrupt (with a higher priority) for the Timer.

[B]Interrupt [/B]TMR2_Interrupt(1)
    [B]Save[/B](0)                             // Back up system variables
    [B]If [/B]TMR2IF = 1 [B]Then                  [/B]// Check if the interrupt was from TMR2
        TMR2IF = 0                      // Clear the TMR2 interrupt flag
        [B]Inc[/B](mS)                         // Increment the mS counter
        [B]If [/B]mS = 1000 [B]Then[/B]               // Check if one second has occured
                [B]Disable[/B](PORTB_Change)   // If so, then turn off the interrupts
                [B]Disable[/B](TMR2_Interrupt) //
                Done = True             // and set the Done flag
        [B]EndIf[/B]
    [B]EndIf                     [/B]//
    R[B]estore                             [/B]// Restore system variables
[B]End Interrupt[/B]

I'm sure you can see where that is heading, and I suppose I can leave the rest to your imagination. 18F PIC's allow you to use priority based interrupts. All the examples here are written with Swordfish

UART would be a much eaiser option (and low cost), to send something to your PC;

[B]Include [/B]"USART.bas"
[B]Include [/B]"Convert.bas"

[B]USART.Write[/B](RPM   = ", [B]Convert.DecToStr[/B](RPM.Counter))
[B]USART.Write[/B](DYNO  = ", [B]Convert.DecToStr[/B](DYNO.Counter))

 

[Sceadwian]

The simplest way to get USB functionality on a micro controller is to use one of FTDI's line of serial/parallel to USB interface chips. I have one on order from Futurelec (USBMOD2) if I ever get it. Mouser carries a module called the VDIP1 which looks a bit more sophisticated as it allows it to be connected as a USB storage class device, though it's probably more complicated to setup. The USBMOD2 chip I got is a straight forward high speed parallel interface to a virtual serial port on the PC.

 

[gramo]

Man, that chip (USBMOD2) costs US$29.20 ! And the one at Mouser costs $26.80

With the above program, and an 18F4550 for $6.42, you have USB with your PC/another device. Here's how you would wire it up;

**broken link removed**

 

[Sceadwian]

Microchip supplies royalty free license free drivers to let the PIC communicate to the PC as a virtual com port? Between labor and parts you're looking at 20-30 dollars in effort/bits to create even a basic PIC USB implementation.

 

[Nigel Goodwin]

Microchip supplies royalty free license free drivers to let the PIC communicate to the PC as a virtual com port?

They certainly provide example source code for the PC end of a USB connection, but I've never bothered to read the conditions of it.

 

[Sceadwian]

That's why I like the modules. No code required PC side, it will interface directly to any program that can access a com port. It also comes with a DLL for direct use if you want to make custom USB device ID's and distribution of the drivers is completly user customizable and free.

 

[BOBKA]

gramo: what are you using to draw your schematics?

 

[PJ Adams]

Thanks for all the responses.

Yes - I can program - VB 6 / VB .NET 1.1 & 2.0
I could tolorate C, C++, C# if I had to - but the development time would slow. I'm not clever but I am stubbon - I'll get there! ;-)

It seems similar to a pair of tachs - but I need to know the time between each event (instead of counting pulses) AND 'where' in time each separate event happens with relation to each other.


Gramo - very useful - thank you very much


Yes - I've read the newer 'USB' PIC chips make life easy with regards to connection, power & programming. I found this site & this guy makes it look very easy to wire up the PIC chip - http://www.alanmacek.com/usb/ It's essentially what Gramo posted.


Costs are all relevant to what you are used to. $7 or $30 for chips (and some tinkering time) seems dirt cheap to me when the electronics for a commercial dyno are $600 to $1000.


Paul

 

[gramo]

Microchip supplies royalty free license free drivers to let the PIC communicate to the PC as a virtual com port? Between labor and parts you're looking at 20-30 dollars in effort/bits to create even a basic PIC USB implementation.

Just wanted to add that SF has a free plug-in called EasyHID, it will create the Visual Basic/C++/Delphi code depending on the settings you required for your device. Handy.

Sample code written by EasyHID

' vendor and product IDs
Private Const VendorID = 6017
Private Const ProductID = 2000

' read and write buffers
Private Const BufferInSize = 8
Private Const BufferOutSize = 8
Dim BufferIn(0 To BufferInSize) As Byte
Dim BufferOut(0 To BufferOutSize) As Byte

' ****************************************************************
' when the form loads, connect to the HID controller - pass
' the form window handle so that you can receive notification
' events...
'*****************************************************************
Private Sub Form_Load()
   ' do not remove!
   ConnectToHID (Me.hwnd)
End Sub

'*****************************************************************
' disconnect from the HID controller...
'*****************************************************************
Private Sub Form_Unload(Cancel As Integer)
   DisconnectFromHID
End Sub

'*****************************************************************
' a HID device has been plugged in...
'*****************************************************************
Public Sub OnPlugged(ByVal pHandle As Long)
   If hidGetVendorID(pHandle) = VendorID And hidGetProductID(pHandle) = ProductID Then
      ' ** YOUR CODE HERE **
   End If
End Sub

'*****************************************************************
' a HID device has been unplugged...
'*****************************************************************
Public Sub OnUnplugged(ByVal pHandle As Long)
   If hidGetVendorID(pHandle) = VendorID And hidGetProductID(pHandle) = ProductID Then
      ' ** YOUR CODE HERE **
   End If
End Sub

'*****************************************************************
' controller changed notification - called
' after ALL HID devices are plugged or unplugged
'*****************************************************************
Public Sub OnChanged()
   Dim DeviceHandle As Long
   
   ' get the handle of the device we are interested in, then set
   ' its read notify flag to true - this ensures you get a read
   ' notification message when there is some data to read...
   DeviceHandle = hidGetHandle(VendorID, ProductID)
   hidSetReadNotify DeviceHandle, True
End Sub

'*****************************************************************
' on read event...
'*****************************************************************
Public Sub OnRead(ByVal pHandle As Long)
   
   ' read the data (don't forget, pass the whole array)...
   If hidRead(pHandle, BufferIn(0)) Then
      ' ** YOUR CODE HERE **
      ' first byte is the report ID, e.g. BufferIn(0)
      ' the other bytes are the data from the microcontrolller...
   End If
End Sub

'*****************************************************************
' this is how you write some data...
'*****************************************************************
Public Sub WriteSomeData()
   BufferOut(0) = 0   ' first by is always the report ID
   BufferOut(1) = 10  ' first data item, etc etc

   ' write the data (don't forget, pass the whole array)...
   hidWriteEx VendorID, ProductID, BufferOut(0)
End Sub

 

[PJ Adams]

Thanks Gramo - EasyHID is interesting.

I've just looked at your site. I see you've experimented with a hall effect sensor for RPM - that's exactly the route I used for the dyno drum.

And the reasons you list about inaccuracy of counting pulses is the reason I decided to run a fast timer / counter & count the time between pluses.

Paul

 

[gramo]

Thanks Gramo - EasyHID is interesting.

I've just looked at your site. I see you've experimented with a hall effect sensor for RPM - that's exactly the route I used for the dyno drum.

And the reasons you list about inaccuracy of counting pulses is the reason I decided to run a fast timer / counter & count the time between pluses.

Paul

Aye, its a great program, and fast tracks you into USB programming on the PC side.

Your idea is great; I only leant toward the "Count for X milliseconds, and then scale up" as a simple to understand "suit any job" type application.

But you’re right, if your signal is clean, there is no reason why you can't count between pulses. Be sure to use PORTC as the input source, as it has built in Schmitt triggers that will make your pulse sampling much more accurate, and less susceptible to noise. eg,
**broken link removed**

 

[Nigel Goodwin]

But you’re right, if your signal is clean, there is no reason why you can't count between pulses.

It would be crazy to do anything else, you're only talking very low frequencies, pulse counting is MUCH too slow and inaccurate - for low frequencies the time between pulses is commonly used, and a little simple maths.

 

[gramo]

It would be crazy to do anything else, you're only talking very low frequencies, pulse counting is MUCH too slow and inaccurate - for low frequencies the time between pulses is commonly used, and a little simple maths.

Yeah, I hear ya, definitely time between pulses for slow signals, but I have found the Averaging feature of counting for a known period of time to be more useful for fast signals, as it compensates for dodge (noisy/bumpy) signals here and there (as too does the 50Mhz frequency meter Application Note by Microchip)

 

[gramo]

On a side note, do you think that picture made much sense about using PORTC (with built in Schmitt triggers) for inputs?

Thinking about re-doing a more professional version for my site

 

[Nigel Goodwin]

Yeah, I hear ya, definitely time between pulses for slow signals, but I have found the Averaging feature of counting for a known period of time to be more useful for fast signals, as it compensates for dodge (noisy/bumpy) signals here and there (as too does the 50Mhz frequency meter Application Note by Microchip)

For higher frequencies obviously counting is by FAR the best, but it's unsuitable for low frequencies - which is why the MicroChip application note auto switches between the two.

Using a schmitt trigger input makes good sense, and your diagram looks fine.

 

[PJ Adams]

Gramo - your diagram makes perfect sense - and it's exactly what I wanted - infact, I was planning to add separate, external Schmitt triggers - now I don't have to bother.


Newbie question - PORT B & PORT C

On the diagram of a 18F4550 chip (in an ealier posting) - I assume the PORT B type inputs are pins 33 to 40? And PORT C type inputs are 15 to 17? Correct?

Paul

 

[pacoraap]

Hi,

New to this forum but also busy with DYNO project see link.
http://www.twf8.ws/new/tech/dtss/downloads/documents/dtss_manual.htm

We are talking about a poormans project to be rebuild by any person without special tools.

We currently use USB datalogging from DATAQ but found out that RPM collection accuracy is crucial for calculating INERTIA Power to reproduce constant and reliable figures. We have to finish the tests for the USB device but it looks we have to go an other route.
if you like to read all I found out sofar for this device read this link
http://support.dataq.com/viewtopic.php?t=638

We also looked into PICS but were advised to use the parallel PC port to collect the RPM data by person of Univerity of Amsterdam.

So now next step is to work with this parallel port RPM collection.
If that works I let you know, if people are interested anyway.

With kind regards,

Paco