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 _CONFIG7H, _EBTRB_OFF_7H void interrupt(void) { if (test_bit(pir1,SSPIF)) { clear_bit(pir1,SSPIF); } } void main() { set_bit(trisa, 5); clear_bit(trisc, 5); set_bit(trisc, 3); set_bit(trisc, 4); sspstat = 0x40; sspcon1 = 0x04; pie1 |= 0x08; pir1 = 0; intcon.PEIE = 1; intcon.GIE = 1; sspcon1.SSPEN = 1; while (1); } And put it on a breadboard with nothing but: Power to the chip, SS pulled high, and SCK pulled low, and an LED with the anode on 5V, and the cathode on SDO. The LED is turned on, despite the fact that I'm pretty sure SDO should be floating.
  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 another slave....This 18f2321's interrupt is being thrown when that happens. Any idea why that would be happening? I've confirmed that the SS line is staying high the entire time, but the interrupt is still being thrown. It's acting like SSPCON1 is set to 0x25, disabling the need for the SS pin.
  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 problem is that when I send some data, nothing happens. I'm probably just not setting it up correctly, I've never used a PIC in SPI Slave mode before, and I'm not quite sure what's going on.
  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 power, it immediately turns on, as expected. Then, two seconds later, it shuts off. If I replace the 'unsigned int's with 'int's, then the LED simply stays on. It behaves the exact same way in the simulator.
  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...