Jump to content

emte

EstablishedMember
  • Content Count

    377
  • Joined

  • Last visited

Community Reputation

0 Neutral

About emte

  • Rank
    Super Enthusiast

Contact Methods

  • AIM
    emte linuxpeople
  • ICQ
    0

Profile Information

  • Location
    Victoria, BC, Canada
  1. Could be used either way, but yes I was thinking on the master. Out of curiosity are you using the serial port on the slave? Since RC6 is both /SS and TX... And I also do not see you setting RC6 as an input...
  2. The SSPIF interrupt will trip for any SSPIF event, you need a second flag to detect which slave you want to deal with. Something like: if ((test_bit(pir1, SSPIF))&&_slaveOne) . . else /* for all other slaves */ { clear_bit(pir1, SSPIF); /* clear for second slave */ tmp = sspbuf; /* empty buffer to avoid overflow */ } Oh and also related, some chips have multiple slave type settings, would have to check the datasheet though.
  3. emte

    Sb 6.84 Registration Problem.

    It is flakey under wine, what does wines log tell you? It could simply be waiting for the correct window type, which sometimes means you need tell wine to use an older OS othertimes its a missing font etc.
  4. We would have to see your interrupt routine, it could be as simple as not detecting which slave or just a line outside your loop.
  5. Just to elaborate a bit clearer, First you control the SlaveSelect(SS) line from the master, then the master controls the clock line. After that, data is transfered in a normal fashion, but keep in mind only one device can control the clock line at a time and only the master controls SS. Just to question something in the fog of my brain, isn't there an issue with using the bit functions in an interrupt? I've been away from PIC programming for a few months so some things are a bit rusty.
  6. Just to question the obvious, but I've done it myself, are you sure your using the right hex file or that it was generated?
  7. emte

    Rs232 Docs

    I am curious why you need more documents... Serial/RS232 libraries are arguably to help new users only, you will find far more useful information in the datasheet. I suppose I should qualify that, to initialize serial you set a handfull of flags and that is the hardest part of setting up serial. Most serial libraries(not all) utilize functions that result in extra processing time for something that takes one cycle. The classic example of this is checking the transmit flag. Anyway here is a simple init and remap you can drop in a header and use: #ifndef _SERIAL_H #define _SERIAL_H #include <system.h> volatile bit _SER_TRISIN @TRISC.7; volatile bit _SER_TRISOUT @TRISC.6; volatile bit _SER_SPBRG @SPBRG; volatile unsigned char _SER_TXREG @TXREG; volatile unsigned char _SER_RXREG @RCREG; #define _SER_RCREG _SER_RXREG /* Naming Convention Macro */ volatile bit _SER_TX9D @TXSTA.0; /* Transmit 9 Bit */ volatile bit _SER_TRMT @TXSTA.1; /* */ volatile bit _SER_BRGH @TXSTA.2; /* */ volatile bit _SER_SYNC @TXSTA.4; /* */ volatile bit _SER_TXEN @TXSTA.5; /* */ volatile bit _SER_TX9 @TXSTA.6; /* */ volatile bit _SER_CSRC @TXSTA.7; /* */ volatile bit _SER_RX9D @RCSTA.0; /* */ volatile bit _SER_OERR @RCSTA.1; /* */ volatile bit _SER_FERR @RCSTA.2; /* */ volatile bit _SER_ADDEN @RCSTA.3; /* */ volatile bit _SER_CREN @RCSTA.4; /* */ volatile bit _SER_SREN @RCSTA.5; /* */ volatile bit _SER_RX9 @RCSTA.6; /* */ volatile bit _SER_SPEN @RCSTA.7; /* */ volatile bit _SER_TXIF @PIR1.4; /* */ volatile bit _SER_RXIF @PIR1.5; /* */ #define _SER_RCIF _SER_RXIF /* Naming Convention Macro */ void _initSerial(void) { /* Specific pin setup */ _SER_TRISOUT = 0; /* Output */ _SER_TRISIN = 1; /* Input */ /* TX setup */ _SER_TX9D = 0; /* 8bit mode */ _SER_TXEN = 1; /* Enable Transmit */ _SER_SYNC = 0; /* Asynchronous */ _SER_TRMT = 0; /* Clear TSR */ _SER_BRGH = 1; /* High Speed */ /* RX setup */ _SER_SPEN = 1; /* Enable Serial */ _SER_RX9D = 0; /* 8bit mode */ _SER_CREN = 1; /* Cont. Receive */ /* 115.2 baud @ 20Mhz * BaudRate = Fosc div (16(x+1)) * 113636.3636 = 20Mhz div (16(9+1)) */ _SER_SPBRG = 10; _SER_RXIF = 0; /* Clear RX Interrupt */ } #endif /* EOF */ Hope that helps.
  8. Let me see if I understand ... The problem you are having is that your toolchain and target are getting reset everyday when you restart or power up your development system? Are you using a Source Control System? If so, did you add your workspace file?
  9. emte

    Very Slow Compile

    I've tried SB now a few times on different systems and a pattern seems to be emerging, then again I could still be delusional. But, depending on which windows you have installed or more directly how much MS has altered the MS-DOS compatability for different versions, you get vastly different performance out of the compilers. Older seems better, with that said, I am only about to try and see what happens if i try to get it to run the compiler under cygwin. ...providing i can get SDCC to behave with this 8052 code first.
  10. emte

    16 Bit Pic Micro Support ?

    Incorrect, what i said was that for most people and opensource, the limited compiler works just fine and that any license under $1k is reasonable for commercial (for profit) usage. As well, using a heavily mantained parent like GCC means there are less problems with long term support and migration. Why reinvent the wheel if you already have a round rim and the rubber?
  11. emte

    Build Or Buy That Ultimate Pic Programmer?

    It is quite trivial to do this, but the USB tranceivers can get quite expensive comparativly and they require a bit of extra firmware work.
  12. emte

    Are You Fuzzy Yet?

    I shall read as soon as if find time, which seems to be in very short supply for me. Not only do I work 70 hours a week, i am also researching how to fabricate a waveguide laser. emte Not truly on topic, not being about PICs, but you might be interested anyway. I've been around a long time in electronics, seen quite a few things come - and quickly go! The one-bit processor? The General Instruments PIC? - it's still here A favourite columnist over the years has been Bob Pease of National Semi. You might enjoy his take on fuzzy logic from back in the '90s, when it was the 'next big thing'. http://www.national.com/rap/Application/0,1570,25,00.html His stuff on audio accessories like speaker cables is fun too. Regards, John
  13. Aggressive optimization is better to be used on a function-by-function case, that way if it does something bad you know where the issue is. #pragma OPTIMIZE "a" int someFunc(short var) { blah } Use this before the function you want to optimize.
  14. Unless you remap your tags, all your pin tags etc need to be lower case, just so you know. Uppercase is very common with a lot of compilers. An easy compatability work around is: #define PORTB @portb #define TRISA @trisa
×