Jump to content

Edward Mulder

EstablishedMember
  • Content Count

    8
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Edward Mulder

  • Rank
    Newbrie

Contact Methods

  • Website URL
    http://www.artexgroupllc.com/aboutus.html

Profile Information

  • Gender
    Male
  • Location
    Buenos Aires
  1. Hi Jorge, I checked with a small program in MPLAB, and that simulation works. Building the hardware, and connecting some LED's confirms that RA.6 and RA.7 are normal outputs. When simulating in SourceBoost, using the LCD-plugin on PortA/PortB works fine (except for RA.6/7). Using PortC is a different story however. Seems that I have to report a bug on this combination. Edward
  2. Hi Jorge, This is what I did to disable the analog inputs and activate the internal oscillator: #include <stdlib.h> #include <string.h> #include <ctype.h> #include <system.h> #pragma DATA _CONFIG1H, _OSC_INTIO67_1H // internal oscillator, RA.6 and RA.7 as IO #pragma DATA _CONFIG2L, _PWRT_ON_2L & _BOREN_OFF_2L #pragma DATA _CONFIG2H, _WDT_OFF_2H #pragma DATA _CONFIG3H, _MCLRE_ON_3H & _PBADEN_OFF_3H void main(void) { // 4MHz internal oscillator osccon = IRCF2 & IRCF1 & SCS1; // all digital inputs adcon1 = 0x0F; // all pins as outputs trisa = 0x00; trisb = 0x00; trisc = 0x00; // all outputs off porta = 0x00; portb = 0x00; portc = 0x00; porta = 0x01; porta = 0x02; porta = 0x04; porta = 0x08; porta = 0x10; porta = 0x20; porta = 0x40; porta = 0x80; while(1) ; } The 18F2520 data sheet mentions a difference in the QFN versus PDIP package (RA.6 / RA.7 bidirectional or input or output), but I have no way to choose this behaviour in SourceBoost. Thanks, Edward
  3. Hello all, I just tried to port my routines for an LCD from a PIC16 to an 18F2520 (DIP-28). When I use RC.0-3 for the data and RA.4 and 5 for the E/RS lines, everything works fine. When I try to run the plug-in, using RA.6 and RA.7, I canĀ“t see any activation of the output pins. Oscillator mode is _OSC_INTIO67_1H, so these pins should be available for I/O. Running a small check like this confirms the behaviour: porta = 0x10; porta = 0x20; porta = 0x40; //no activation porta = 0x80; //no activation Anbody knows what I am missing? I have not built the circuit yet, I first wanted to run the program on the plug-in simulator. Edward
  4. Try this one: http://www.decadenet.com/bob/bob.html
  5. Hi all, When I use whatever PIC (16f88, 16f873 etc.) and try to simulate an input (button block), not one input responds. I used v6.89 and 6.91. When I change the OS from Windows Vista Home Edition to Windows-XP everything runs fine. Any clues ? Edward
  6. @Pavel: That's it. Adding -d DEBUG to the compiler options does exactly what I want. Thanks very much. Edward
  7. @Pavel: I did as you said, but what do I have to look for? All I see is a line that contains only comment in the .pp file, it does not make any difference when I use #define DEBUG 1 or 0. What should the output look like? @richard: Using a global.h file surely helps, but the problem is that I should declare it always, even if I don't want to use the DEBUG. When I don't declare the global.h file, the compiler generates an error. Any suggestions? Thanks to both of you. Edward
  8. Hi all, I want to use a define when debugging my program. I have a UART routine that waits for an interrupt. When debugging, I want to skip that line. The structure of my program is like this: main.c #define DEBUG #include "serial.h" void main() { } serial.c void ser_printf(char value) { #ifdef DEBUG return; #endif while ((txsta & 1 << TRMT) == 0) ; txreg = value; } In the project part I have incuded the serial.c file, but now the problem: the reference to DEBUG in the serial.c file does not "see" the DEBUG declaration in the main.c file What can I do to control the ser_printf function from the main file? I do not want to make changes to the serial.c file every time I want to debug. Thanks, Edward
×
×
  • Create New...