Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by Hobknob

  1. It is correct, but you must also enable the global interrupt enable enable_interrupt (INTE); // enable the external interrupt enable_interrupt (GIE); // turn interrupts on Regards Dave
  2. The RA4 pin has a different output circuit to the other pins on port A. The other pins have a sink/source capability, while RA4 can only sink current. To turn you led on on RA4, connect it between 5V and the pin, then set the pin output to 0 to turn the LED on, and 1 to turn the LED off. Regards Dave
  3. You can tell that the processor has been watchdog reset by checking bit 4 (TO bit) in the STATUS register. If the processor has been watchdog reset this bit is 0. I guess you are talking about using timer TMR0, for you interrupt driven serial comms. One bit being transmitted every interrupt. The limitation with TMR0 and watchdog, is that they have only one prescaler between them. It can be switched to be used either by TMR0 or watchdog, but not both at the same time. The watchdog will still work if TMR0 is using the prescaler, but has a much shorter timeout period. Hope this helps Regards Dave
  4. The simulator currently simulates: Instruction decoding, ALU, W REG, STATUS register, Program counter, FSR register, RAM File Registers, Stack, TMR0 and EEPROM. Interrupt generation from port b is not currently supported, but will be implemented very soon. Regards Dave
  5. The simulator currently simulates: Instruction decoding, ALU, W REG, STATUS register, Program counter, FSR register, RAM File Registers, Stack, TMR0 and EEPROM. So you will see no activity from timer 2 in the simulator. Regards Dave
  6. What is the status of the watchdog, if the watchdog keeps reseting the processor before the timedelay complete, the LED's will never go off because the code will never get that far. Try disabling the watchdog. Regards Dave
  7. The delay_x functions work by creating a software delay loop. Consider how long the pulse will be with the LED's off - it will be about 4 microseconds with a repetition rate of 1000,000 microseconds (1 second), so you are looking for something that will be hard to trigger on with your scope. Please try the modified code, I sure it will resolve your problem. Regards Dave
  8. The problem is you have a delay after switching on your LED's, but not after you switch them off. This means that are off for such a short time you won't see it. I've added an additional delay in the code below to make it work. //Timing settings #pragma CLOCK_FREQ 4000000 void main(void) { //Hardware Initialization disable_interrupt( GIE ); set_bit( STATUS, RP0 ); set_tris_a( 2 ); set_tris_b( 0 ); clear_bit( STATUS, RP0 ); output_port_a( 0 ); output_port_b( 0 ); while(1) { output_port_b(0xff); delay_s(1); // delay to keep leds on for one second output_port_b(0x00); delay_s(1); // delay to keeps led off for one second } } Regards Dave
  9. Becareful. The circuit you are talking about will almost certaininly not being meeting the RS232 specification, although it may work on one PC. The RS232 spec requires a minimum of +/-3V at the receiver, so if you want your PC to receive data from you PIC you need to provide voltages at least around these levels. If you just want your pic to recieve data from you PC, then a couple of resistors and clamping diodes should work pretty well, but the interace does not meet the RS232 spec. Something like a max232 does a nice solution to providing at interface that meets the RS232 spec. Another thing to bear in mind is that different PC manufactures RS232 ports vary. So an out of specification designed that works with one PC may not work with another. If you are really interested there are pages on the web (sorry cant remember where) about designing micro-power circuits that interface to the RS232 port and get all their power from there two (a normal mouse does this), but these designs have to be very clever to work with all PC's. Have Fun Regards Dave
  10. Consider performing more testing using putch(); eg while( 1 ) { for ( int i = 65; i < 82; i++ ) putch( i ); } Make sure that you get a to z, just testing with single character could work with some port parameters wrong. Regards Dave
  11. I think the rules for posting maybe unclear. At first a questioned is asked as particular behaviour may be a bug or just a users miss-understanding. I would be confused by this. Regards Dave Hobknob
  12. How does one know if a problem is a bug, or a characteristic, or a mis-understanding of how to use the tool? Regards Hobknob
  13. Please be more specific as to what the issues you beleive to exist. Regards Hobknob
  14. Whoops I meant #pragma TRUE_RS232 1 to #pragma TRUE_RS232 0
  15. What components are being used in the electrical interface to your PC ? - Some kind of voltage level convertor is required. Sometimes this kind of interface circuit invertors the signal, sometimes it does not. Consider the RS232 polarity - change #pragma TRUE_RS232 1 to #pragma TRUE_RS232 2 to reverse.
  16. Your interrupt routine has to look at the interrupt flag for all the sources of interrupt you have enabled (through the interrupt enable flags) to see what the source was. The the routine can decide what to do next. Regards Hobknob
  17. I think you should post a code sample to show the problem, otherwise its very difficult to help.
  18. My guess here is that the array you have created is not Null terminated, the the code tries to access memory beyond the end of your string. So change the string definition to: const char lcd[4]= {'T','e', 's', 't', 0 }; // note zero on end or const char* lcd = "test"; which naturally terminates the string with a null. Hope this helps
  19. I believe macro functionality is limited. You can't have a macro with an argument list. So the brakets cause an error.
  20. What about the script optimization ? if ((INTCON & _T0IF) != 0) 00AD: MOVF INTCON,W 00AE: ANDLW 04 00AF: XORLW 00 00B0: BTFSC STATUS.2 00B1: GOTO 0B4 with 8 patterns, for all the single bit values ( 1, 2, 4, 8, 16, 32, 64, 128 )values could be tested for and optimised to BTFSC INTCON, BITX GOTO ??? couldn't they ?
  21. More information is required! What is a DS1621? Is the DS1621 a I2C slave device or master device ? Are you expecting your 16F84A to be slave or master? ???
  22. I would recommend not setting the INTCON register. Leave it to its power on reset value. You haven't defined an interrupt handler, you don't need one for what you are doing, but you are enabling some interrupts. Not sure what device your using, and hence what sources of interrupts are available. If an interrupt is generated, it jumps the control to address 0004, if this doesn't jump to an interrupt handler it may be restarting you program continously. So if the code enters the delay loop it doesn't stay there for long ! Hope this work for ya.
  23. You haven't explained what is happening, other than it doesn't work so this makes it real hard to help. Also you have only supplied a tiny fragment of code, break you code down to just a simple main routine and supply the complete code explaining what is happening. A classic fault here is leaving the watchdog timer enabled, so the processor keeps getting reset so the results are what are expected Hope this helps.
  24. Pascal is back!!!!!!!!!!!! PLC's following the IEC1131 standard support a programming language call structured text, this is very much like PASCAL. This is really quite new stuff in the PLC areana. What is a PLC you may ask, its an embeded computer that is often programmed in Ladder Logic and used to control industrial machines. ::
  • Create New...