Jump to content

Tim Zim

EstablishedMember
  • Content Count

    44
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Tim Zim

  • Rank
    Regular

Contact Methods

  • Website URL
    http://timzim.blogspot.com
  • ICQ
    0

Profile Information

  • Gender
    Male
  • Location
    Hampshire, UK
  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
×
×
  • Create New...