Jump to content

Tim Zim

EstablishedMember
  • Content Count

    44
  • Joined

  • Last visited

Everything posted by Tim Zim

  1. Hi Reynard Excellent. Thanks for the clear instructions. All working well now. Onwards & upwards... Cheers Tim
  2. Hi Reynard Thanks for that - can you give me a little more information on what I need to do, as I can't seem to make sense of the issue here. Is it the case that my Sourceboost is not setup right? Regards Tim
  3. Hi I wonder if anyone can help. I've bought a few PIC18F26J50's and have just upgraded to the latest version of SourceBooost (7.20), but cannot seem to get this particular PIC to work with a simple startup example (tried both the PIC's I have in case). I've had no problem with any of the previous types of PIC's I've been using. When I write to the PIC with my PICKIT2, the LED's I'm trying to flash light up briefly, as I would expect on writing the hex, showing me the hardware is likely ok. The loaded program just does not work. Code: #include <system.h> //#include <PIC18F26J50.h> #pragma config PLLDIV = 1 // No prescale (4 MHz oscillator input drives PLL directly) #pragma config XINST = OFF // Disabled #pragma config WDTEN = OFF // Disabled - Controlled by SWDTEN bit #pragma config STVREN = OFF // Disabled #pragma config CPUDIV = OSC1 // No CPU system clock divide #pragma config OSC = INTOSC // INTOSC #pragma config CP0 = OFF // Program memory is not code-protected #pragma config T1DIG = OFF // Secondary Oscillator clock source may not be selected #pragma config LPT1OSC = OFF // High-power operation #pragma config FCMEN = OFF // Disabled #pragma config IESO = OFF // Disabled #pragma config WDTPS = 1 // 1 #pragma config DSWDTOSC = INTOSCREF // DSWDT uses INTRC #pragma config RTCOSC = INTOSCREF // RTCC uses INTRC #pragma config DSBOREN = OFF // Disabled #pragma config DSWDTEN = OFF // Disabled #pragma config DSWDTPS = 2 // 1:2,097,152 (36 minutes) #pragma config IOL1WAY = OFF #pragma config MSSP7B_EN = MSK7 // MSSP address mask #pragma config WPFP = PAGE_0 // Write/Erase protect #pragma config WPEND = PAGE_0 // Write/Erase protect #pragma config WPCFG = OFF #pragma config WPDIS = OFF #pragma CLOCK_FREQ 8000000 #define LED1 portc.0 #define LED2 portc.1 void setup(void){ // Setup internal oscillater at 8Mhz osccon =0b01110000; // // setup ports to all digital output trisa=0; porta=0; trisb=0; portb=0; trisc=0; portc=0; // no a/d ancon0=0b11111111; // Digital ports ancon1=0b00011111; // Also digital ports adcon0=0b00000000; // No A/D adcon1=0b00000000; // No reference voltages wdtcon=0; // No watchdog timer // setup interrupts intcon =0b00000000; // Turn off Global, peripheral and timer 0 interrupts intcon2=0b00000000; // Nothing for us here intcon3=0b00000000; // Nothing for us here either pir1=0b00000000; // Actual interrupt registers - all cleared pir2=0b00000000; // Actual interrupt registers 2 - all cleared pir3=0b00000000; // Actual interrupt registers 3 - all cleared pie1=0b00000000; // No A/D conversion interrupt pie2=0b00000000; // Nothing for us here pie3=0b00000000; // Nothing for us here rcon=0b00000000; // We don't care about priorities here } void interrupt(void){ } void interrupt_low(void){ } void main(void){ setup(); while(1){ LED1=1; LED2=1; delay_s(1); LED1=0; LED2=0; delay_s(1); } } I've been at this a while now, off and on, but with the latest SourceBoost upgrade still cant get anything working. Any help would be greatly appreciated...
  4. Hi Chuck Don't forget, you don't HAVE to use interrupts, you can simply check the status of the interrupt flags in your main loop. This may actually prove quicker in some circumstances.... Tim
  5. Hi davidb I agree that depending on the requirement, there are different ways of doing things, no problem there. I see so many code snippets posted which seem unnecessarily complex, or bloated, that from time to time I feel compelled to put in my 10p worth. In all cases writing robust, easy to comprehend, code provides the basis for reliable operation. Cheers Tim
  6. Just because you own a pair of snow shoes doesn't mean you have to wear them to work every day of the year. In the same respect, just because the PIC has interrupts does not mean they have to be coded or used. The sample code corrected by davidb could be cleaned up to: void interrupt(void) { // Timer0 Interrupt tmr0=tmr0_offset; clear_bit( intcon, T0IF ); // Clear T0IF every time } The other interrupts can be turned off in INTCON or whatever, as they are not being used. Also, seeing as I'm off on one here, why check to see if an interrupt is enabled as well as checking if it's interrupt flag is set? In addition, an if...else in priority order is better in an interrupt routine, as only one interrupt is processed at a time. Interrupts are useful things, but easily overused for no good reason. The interrupt flags generally get set without the need to also use the interrupt routine, so it is often practical to check for an interrupt flag in the main code loop, rather than have to juggle interrupts. If the timing of interrupts are not crucial, and all you do is set a status in the interrupt routine anyway, why bother? For example, if timing for timer0 is not crucial, the above code could be handled as follows, without even bothering the PIC with interruptions. This results in better overall performance: while(1) { ... ... doing processing ... // Timer0 Interrupt if(test_bit(intcon,INT0IF)){ // just as good as setting a flag in the interrupt routine for say switches etc. tmr0=tmr0_offset; clear_bit( intcon, T0IF ); // Clear T0IF } ... .... doing processing ... } I know this all seems picky, so please accept this post as helpful criticism, but my experience has always been that writing good, clean, code even for apparently simple apps pays dividends when things get more complex and performance becomes an issue.
  7. Hi Ian Great - I have a few of these MRF24J40MA's winging their way to me and am planning on using PIC18F13K50's to drive them. Fancy collaborating on this? Regards Tim
  8. Hi all Has anyone done any interfacing between PICs and the MRF24J40MA, also from Microchip, using SourceBoost? I'm thinking of using the ZigBee protocol, probably starting with the stack from Microchip. I've seen a few enquiries on this in the past, but have not seen any replies.
  9. Hi Raghunathan In my view, using USB for serial comms is a little like using a Ferrari as a tractor. Send me a separate message with your email address, and I'll email you some PIC USB code I have been working on which will address these issues. Tim
  10. Raghunathan - you don't need anything between Vusb and D+. The configuration will do the job of setting the USB speed for you. That may wll be your problem. Regards Tim
  11. I use a slight variant on that for my generic EEProm writes, which I often use for simple/quick debugging: void WriteEEP(unsigned char address, unsigned char data){ eecon1=0b00000100; // Initial eecon1 state - enables write while( test_bit(eecon1, WR) ){ } eeadr=address; eedata=data; eecon2=0x55; eecon2=0xaa; set_bit(eecon1, WR); eecon1=0; // disable write (does not affect WR) } Here, the checking to see if the write is complete is at the top of the code - so avoiding a wait for the write to complete if there is no need to. Also, as interrupts are not used, the GIE flag does not have to be set/cleared. This may be inappropriate for other code in use anyway.
  12. Keni I used the i2c_test example code in C:\Program Files\SourceBoost\Samples\C\BoostC Set the i2c software args etc. for the 18F88 as: //////////////////////////////////////////////////////////////////////////// // i2c software implementation template arguments //////////////////////////////////////////////////////////////////////////// // SCL = PORTB.3 // SDA = PORTB.4 #define i2c_ARGS 3, PORTB, TRISB, 4, PORTB, TRISB, e_SSPCON1, e_SSPCON2, \ e_SSPSTAT, e_SSPBUF, e_SSPIF_BIT, e_SSPIF_PIR, \ e_BCLIF_BIT, e_BCLIF_PIR, 7, e_SSPADD, (i2c_reset_wdt | i2c_SMP) // RAM used by the software i2c driver to emulate the equivalent i2c hardware registers unsigned short swi2c_SSPCON1@0x40; // define location for the emulated SSPCON1 unsigned short swi2c_SSPCON2@0x41; // define location for the emulated SSPCON2 unsigned short swi2c_SSPSTAT@0x42; // define location for the emulated SSPSTAT unsigned short swi2c_SSPBUF@0x43; // define location for the emulated SSPBUF unsigned short swi2c_SSPIF_PIR@0x44;// define location for the emulated SSPIF_PIR unsigned short swi2c_BCLIF_PIR@0x45;// define location for the emulated BCLIF_PIR unsigned short swi2c_SSPADD@0x46; // define location for the emulated SSPADD This worked perfectly. Truth is I didn't use the hardware setting as I did not understand the I2C_divisor setting (do now), or what the addresses of the various registers should be (also do now, though for a PIC18F2550). I hope this helps.
  13. Mike Looks like it may be worth you looking at the PWM module - this may save you some effort.
  14. Hi Raghunathan I had to add the 18F2550 to the analog_inputs_off() def in picutils.h and it compiles and runs just fine. With the serial debug turned on, at a slower baud rate than Ian's, the code did not work. I turned the debug code off and it all runs perfectly. I hope that helps Regards Tim
  15. I'm with Benj on this USB is the way to interface with PC's and the like, so I don't doubt the benefit to all if SourceBoost was to support it.
  16. Hi Benj It works!!!! Thanks for your help and suggestions. I left the #pragmas as they were - the 16Mhz setting was what was in the original code, so I thought it best to keep it at it was. The thing that made the difference was not debugging to the serial port. I suspect I had set the baud rate too low, as the Pickkit2 UART is not that fast, for the rest of the USB code to stay in time. So I tried setting the USB_EPx_xxx_ADDR settings to 460 onwards. On connecting to the usb I got the message unknown USB device under USB controllers in device manager, which I could not connect to, though windows reports it as working properly! Changing the setting back makes the USB perform properly again. I don't know it that helps?
  17. Hi Benj FYI, the config settings for a 20Mhz crystal (PIC18F2550) were as follows when it was not working: #pragma DATA _CONFIG1L, _PLLDIV_5_1L & _CPUDIV_OSC4_PLL6_1L & _USBDIV_2_1L #pragma DATA _CONFIG1H, _FOSC_HSPLL_HS_1H & _FCMEN_OFF_1H & _IESO_OFF_1H #pragma DATA _CONFIG2L, _PWRT_ON_2L & _BOR_OFF_2L & _VREGEN_ON_2L #pragma DATA _CONFIG2H, _WDT_OFF_2H & _WDTPS_128_2H #pragma DATA _CONFIG3H, _CCP2MX_OFF_3H & _LPT1OSC_OFF_3H & _PBADEN_OFF_3H & _MCLRE_OFF_3H #pragma DATA _CONFIG4L, _STVREN_ON_4L & _LVP_OFF_4L & _DEBUG_OFF_4L & _XINST_OFF_4L #pragma DATA _CONFIG5L, _CP0_OFF_5L & _CP1_OFF_5L & _CP2_OFF_5L & _CP3_OFF_5L #pragma DATA _CONFIG5H, _CPB_OFF_5H & _CPD_OFF_5H #pragma DATA _CONFIG6L, _WRT0_OFF_6L & _WRT1_OFF_6L & _WRT2_OFF_6L & _WRT3_OFF_6L #pragma DATA _CONFIG6H, _WRTC_OFF_6H & _WRTB_OFF_6H & _WRTD_OFF_6H #pragma DATA _CONFIG7L, _EBTR0_OFF_7L & _EBTR1_OFF_7L & _EBTR2_OFF_7L & _EBTR3_OFF_7L #pragma DATA _CONFIG7H, _EBTRB_OFF_7H I had this together on a breadboard & will try again a little later today... regards Tim
  18. Hi Benj Thanks. Looking at the spec sheet for the 2550 though, the USB memory starts at 400h for the Buffer descriptors. As it happens, the PIC pack code uses endpoint out address at 500h anyway so I must have some other problem that needs ironing out. I used the code with only very few changes, so it should have worked. Scratches head...
  19. I tried using USB and the PIC Pack 2.0 code on a PIC 18F2550 and only ever got gobledygook on the serial debug - I gave up in the end, meaning to come back to it when I had more time/patience. I'm very interested to see a result here....
  20. I know the choice of PIC is very much one of horses for courses for most people. I've always thought big projects=big PIC's. I've come around to thinking that it's best to stick to one general purpose PIC for all my various projects, even if it contains functions, and pins, I'm not going to use on any particular project. To date, after using various other PIC16s, I've pretty much settled on the PIC16F88. I've had no luck with USB, so have not had any particular motivation to switch to the PIC18 range. Ideally I'd like a range of PICs with the same spec but increasing numbers of I/O pins, so have been eyeing the PIC16F88x range. Great for those projects which gobble I/O pins. Recently, by chance, I looked at a PIC18F13K50/14K50 (supported by Sourceboost). This set me to thinking why not adopt this one for the future? It's bigger and has more functionality on board, yet is 2/3rds the price of a PIC16F88 and 2/5ths the price of the PIC18F2550 or PIC18F4550. In turn, this also has me wondering what do other people prefer, and why?
  21. Hi Dave Thanks for that. I looked up differential amplifiers & found this: Op-Amp - Amplified Difference Looking at the diagrams there, it all makes perfect sense now. A big help for something I've been mulling over for days now. I presume resistances of 25K (R1) and 5K (R2), to make up to the 5V Vpp, would be right here? Also, would this end up having the effect of reducing the voltage difference across the shunt, so making the measurement less accurate?
  22. I'm in the process of building a combined ammeter/voltmeter using a PIC16F88 and an LCD display. It's to measure the volts/amps produced by a 24V wind generator, so I'm only interested in the +ve amps. I have the voltmeter working great, using a voltage divider and A/D. This is powered using the 24V system's power through a voltage regulator (5V). I, separately, have the ammeter working great, using a shunt, opamp and resistors to multiply up the voltage and A/D. This is done without the voltmeter circuit connected and a separate (4.5V) power supply. The issue I have is how to make them both work in the same circuit, using the system voltage via a voltage regulator (5V), to drive the whole lot. To my mind, the voltage either side of the shunt cannot simply be connected to the -ve supply, as it can be when implemented stand alone, but if I put a big resistor (say 30K) between the opamp non inverting side and rest of the circuit's -ve, the amp readings will be wrong. My initial idea is to use two transistors to switch the voltmeter and ammeter circuits on/off as appropriate to do the A/D conversion and live with the fact I have to use a separate power supply. Any better ideas on how to achieve this?
  23. Does anyone have experience with driving a VGA screen directly from a PIC16? The hd44780 LCD screens always seem frustratingly small..
×
×
  • Create New...