Welcome! Log In Create A New Profile


Using a timing crystal

Posted by pete_l 
Using a timing crystal
October 03, 2012 07:29PM
I've just stumbled across the BV500. The description says the device uses the internal 8MHz RC osc for timing. Is there a reason why I couldn't sacrifice the RA2,3 I-Os and reprogram the device to run off an external xtal instead?
I've been using 8-bit PICs for several years and I'm kicking around some ideas for a new project that will require the ability to get microsecond resolution of input pulses of up to 1 second duration. It seems like the BV500 should be able to do this, but I want the results to be independent of operating temperature, hence the crystal.

with thanks
Re: Using a timing crystal
October 03, 2012 07:47PM
Yes, you can add an external crystal and set the OSCCON register to use that instead of the internal one - see section 8 of the data sheet. The current configuration is as follows
#if defined ( USE_EXT_XTAL )
#   pragma config FNOSC    = PRIPLL   // Oscillator Selection: Primary oscillator (XT, HS, EC) w/ PL
#   pragma config POSCMOD  = HS       // Primary Oscillator: HS oscillator
#   pragma config FNOSC    = FRCPLL   // Oscillator Selection
#   pragma config POSCMOD  = OFF //HS //EC       // Primary Oscillator
#endif//defined ( USE_EXT_XTAL )

//#pragma config PMDL1WAY = OFF	   // multiple configurarion
//#pragma config IOL1WAT  = OFF	
//#pragma config FUSBIDIO = OFF
//#pragma config FVBUSONIO = OFF
#pragma config FPLLIDIV = DIV_2    // PLL Input Divider: Divide by 2
#pragma config FPLLMUL  = MUL_20   // PLL Multiplier: Multiply by 20
#pragma config FPLLODIV = DIV_2    // PLL Output Divider: Divide by 2
#pragma config FSOSCEN  = OFF      // Secondary Oscillator Enable: Disabled
#pragma config IESO     = OFF       // Internal/External Switch-over: Disabled
#pragma config OSCIOFNC = OFF      // CLKO Enable: Disabled
#pragma config FCKSM    = CSECMD//CSDCMD   // Clock Switching & Fail Safe Monitor: Clock Switching Disabled, Clock Monitoring Disabled
#pragma config FPBDIV   = DIV_2    // Peripheral Clock divisor: Divide by

#pragma config FWDTEN   = OFF      // Watchdog Timer: Disabled (SWDTEN Bit Controls) 
#pragma config WDTPS    = PS16384  // Watchdog Timer Postscale: 16384:1

#pragma config CP       = ON      // Code Protect:
#pragma config BWP      = ON      // Boot Flash Write Protect:
#pragma config PWP      = OFF      // Program Flash Write Protect: 

#pragma config ICESEL   = ICS_PGx2 // ICE/ICD Comm Channel Select: ICE pins shared with PGC1,PGD1
#pragma config DEBUG    = OFF      // Background Debugger Enable: OFF
#pragma config JTAGEN   = OFF
These configuraton values can be changed at run time but some of them require an unlock procedure, this is described in the Microchip guide, probably DS61112. There is just a chance that it is not possible to switch FNOSC at run time but I think it probably is.
Re: Using a timing crystal
October 03, 2012 10:24PM
That's interesting - thank you. My main concern was that the firmware may periodically reset the functions of the I-O pins, but it sounds like it doesn't do anything like that it should be OK.
The other thing I'd have to think hard about is that if I do mess up changing the osc. source at run time, I could end up bricking the BV500.
I've not used MPLAB for Pic32 devices, so I'll have to see if I can find some time to play with the simulator to get the code working before commiting to real hardware..
Re: Using a timing crystal
October 04, 2012 08:06AM
The firmware on theBV500 is protected and there is also a get out procedure for creating a continuous loop so it is very difficult to stop it working alltogether.
To program you don't need a programmer or MPLAB, just send a text file and the BV500 will do the compiling. If you want to use C, MPLAB and all of those tools then you just need to buy a PIC32MX150B without the firmware and program it with a PICKit or similar. It will be few pence cheaper than the BV500 but a lot more difficult to use.

The beauty of the BV500 is that you can conduct hardware experiments on the actual IC, setting registers and seeing the actual (not simulated) effects. Connecting other hardware to it and getting the results. All the code is in RAM and so just reset if it goes wrong. You only need to commit a function to Flash once you are happy with it and even then you can erase it later. This is a completely different (and much more fun) way of working with microcontrollers so the concept takes some getting used to.
Sorry, only registered users may post in this forum.

Click here to login