Jump to content

Heimdall

EstablishedMember
  • Content Count

    16
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Heimdall

  • Rank
    Newbrie
  1. Thanks. ADCON1 did the trick. The chip seems to be glossing over some commands (It could be the cable I'm using. It's about 2 feet long), and I have to figure out how to recieve multiple bytes, send bytes, etc. But at least it's working now.
  2. I put this code on an 18F2321: #include <system.h> #pragma CLOCK_FREQ 1000000 #pragma DATA _CONFIG1H, _OSC_INTIO2_1H #pragma DATA _CONFIG2H, _WDT_OFF_2H #pragma DATA _CONFIG3H, _MCLRE_OFF_3H & _PBADEN_DIG_3H & _LPT1OSC_OFF_3H #pragma DATA _CONFIG4L, _STVREN_ON_4L & _LVP_ON_4L #pragma DATA _CONFIG5L, _CP0_OFF_5L & _CP1_OFF_5L #pragma DATA _CONFIG5H, _CPB_OFF_5H & _CPD_OFF_5H #pragma DATA _CONFIG6L, _WRT0_OFF_6L & _WRT1_OFF_6L #pragma DATA _CONFIG6H, _WRTB_OFF_6H & _WRTD_OFF_6H #pragma DATA _CONFIG7L, _EBTR0_OFF_7L & _EBTR1_OFF_7L #pragma DATA _CONFIG7
  3. RC6 is unused, and I'm not using the serial port.
  4. Wait. I'm confused. The interrupt routine I've posted is on the slave, not the master. I'm waiting for the master to send a command. In this particular instance the slave doesn't send any data back to the master yet, I haven't gotten that far. So shouldn't it only be firing when SS is pulled low? I didn't think I'd have to check the SS line, because by the time SSBUF is filled, the SS line could already be pulled high again, right? Anyway, I've set the right slave mode with the sspcon1 = 0x04. That's slave with the SS pin enabled.
  5. The interrupt routine is the same as in the first post: void interrupt(void) { char tmp; if (test_bit(pir1, SSPIF)) { clear_bit(pir1, SSPIF); tmp = sspbuf; Bar0 = tmp; } } I haven't made any changes to it. Shouldn't the SSPIF interrupt only ever fire when SS is pulled low for this chip?
  6. On reset, aren't pins set to output by default? Anyway, I tried this: set_bit(trisa, 5); clear_bit(trisc, 5); set_bit(trisc, 3); set_bit(trisc, 4); while (!test_bit(portc,3)); sspstat = 0x40; sspcon1 = 0x04; pie1 |= 0x08; pir1 = 0; intcon.PEIE = 1; intcon.GIE = 1; sspcon1.SSPEN = 1; No change. It does the exact same thing.
  7. I've got it sort of working: set_bit(trisa, 5); set_bit(trisc, 3); set_bit(trisc, 4); while (!test_bit(portc,3)); sspstat = 0x40; sspcon1 = 0x24; pie1 |= 0x08; pir1 = 0; intcon.PEIE = 1; intcon.GIE = 1; is my new main(). The interrupt routine stays the same. I was setting PIE1 wrong. Anyway, my new problem is that the interrupt is ocurring whether or not SS for this particular little chip is pulled low. Basically, I have it set so that I push a button on the master, and it sends a signal out to this slave, which works. But I also have another button which sends something to an
  8. I'm trying to operate an 18F2321 as an SPI slave, but I'm not really sure where I'm going wrong: void main() { set_bit(trisa, 5); set_bit(trisc, 3); while (!test_bit(portc,3)); sspstat = 0x40; sspcon1 = 0x24; pie1 |= 0x80; pir1 = 0; // Enable Peripheral Interrupt Bit intcon.PEIE = 1; // Enable Global Interrupt Bit intcon.GIE = 1; StartDisplayLoop(); } void interrupt(void) { char tmp; if (test_bit(pir1, SSPIF)) { clear_bit(pir1, SSPIF); tmp = sspbuf; Bar0 = tmp; } } StartDisplayLoop() just takes the data for Bar0 and spits it out on a display. That part works. The proble
  9. Ok, good. I thought I was going crazy. Thanks! (I need to brush up on my assembly. I've got some HC12 in my brain from a Microprocessor Systems class, but that's about it.) So. Compiler bug, I guess?
  10. Here's everything that I'm running on a PIC16F882 sitting right in front of me: #include <system.h> #pragma CLOCK_FREQ 4000000 //4MHz #pragma DATA _CONFIG1, _LVP_ON & _FCMEN_OFF & _IESO_OFF & _BOR_OFF & _CPD_OFF & _CP_OFF & _MCLRE_OFF & _PWRTE_OFF & _WDT_OFF & _INTRC_OSC_NOCLKOUT #pragma DATA _CONFIG2, _WRT_OFF & _BOR40V void main() { unsigned int i; unsigned int *sh; trisa = 0; porta = 0xFF; i = 0x00E7; sh = &i; delay_s(2); if (*sh == 0x13E7) { porta.7 = 0; } while(1); } I have an LED on RA7. When i give the PIC po
  11. Also, the problem does not occur if you used a regular int*. It only happens with an unsigned int*
  12. void main() { unsigned int i; unsigned int *settingHolder; Init(); i = 200; for (i = 200; i < 1000; i++) { settingHolder = &i; if (*settingHolder == 0x13E7) { SetDisplayToNumber(0); break; } SetDisplayToNumber(i); delay_ms(250); } while (1); } Right after my display reads 230, it goes to 0. So *settingHolder is 231, or 0xE7, and the *settingHolder == 0x13E7 must be evaluating as true.
  13. Hey everyone. I have an unsigned int*, and if the value there is 0x00E7, this evaluates as true: *myThing == 0x13E7 Is there any reason why BoostC isn't bothering to compare the upper byte?
  14. Thanks guys. Turns out it was two things. The _CONFIG1 _CONFIG2 thing, and I was also forgetting to pull PGM low.
  15. I don't have any crystals lying around that the 882 can take (I have a few 20MHz, and a 25MHz, but nothing below 8) Ill try to find one, and try out that. Could it just be that it wasn't working because I set up the internal oscillator wrong?
×
×
  • Create New...