PIC16F84A can't get a bit out of it, any example hex?

[T3STY]

I have programmed many different C programs for PIC16F876 and PIC16F84A, and I have built 3 different prototypes for writing a simple string on an LCD display using HD44780 controller. All of them worked when simulated in ISIS, none worked when programmed on the real PIC.

I now want to test if I'm doing something wrong or if it's the programmer/PIC that's not working. To do so I'd like to use PIC16F84A with a simple binary 8-bit counter on PORTB connected to LEDs. But my programs are not working at all on the real PIC. Could someone please write a simple C program and give me C source, HEX and schematic for it?

Thank you in advance

 

[emresel]

I think you are suspect about the programming the device.
Did you tried to verify option of the programmer? Or read back the program from your device and compare your builded hex file.
That may help to understand this point.
The other point, if possible check if xtal is oscillating or not? Try different xtals or change the xtal load caps.

Hope helps

 

[betwixt]

Show us your schematic and counter code code. You must be doing something fundamentally wrong for all of those not to work.

Brian.

 

[tpetar]

I have programmed many different C programs for PIC16F876 and PIC16F84A, and I have built 3 different prototypes for writing a simple string on an LCD display using HD44780 controller. All of them worked when simulated in ISIS, none worked when programmed on the real PIC.

I now want to test if I'm doing something wrong or if it's the programmer/PIC that's not working. To do so I'd like to use PIC16F84A with a simple binary 8-bit counter on PORTB connected to LEDs. But my programs are not working at all on the real PIC. Could someone please write a simple C program and give me C source, HEX and schematic for it?

Thank you in advance

Pretty simptomatic for simulators, you see now why people uses development boards. You spent lots of time in simulator and there is no result on end. When using simulators worst of all in this that you will never know is that works or not in real environment and with real parts, or you can learn something wrongly and you believe that is correct.



http://www.bvsystems.be/pic_LM032L.php

 

[nagkiller]

Here is my full project using 4MHz Crystal Osc!!!

Check your fuses!!!

Post your project!!!
Note: CN3
01 - GND
02 - VCC
03 - VEE
04 - RS
05 - RW
06 - ENABLE
07 - GND
08 - GND
09 - GND
10 - GND
11 - DATA4
12 - DATA5
13 - DATA6
14 - DATA7
15 - VCC LED BCKG
16 - GND LED BCKG

 

[Alan69]

Just a note that it's very common for 44780 based LCD code to be buggy. In fact every piece of LCD code I've ever looked at thoroughly was incorrect in some aspect or another. Everyone just copies code from somewhere else, almost never going back to the original specs for the timing etc. And the few who do tend to misread or misunderstand some part of the original timing specs, or not get some implication etc. No surprise though, the original documents aren't very good.

Very likely your simulator's LCD works because it doesn't really mimic the timings of the real chips. It won't care if you didn't reset long enough, timing pulses are off, etc, things that the real chip can't handle..

Also note with so many variations, often the chips themselves are buggy. Some of them simply will not work with correct timings, either the chip designer read some of the timing specs wrong themselves, just made a general bug, or even changed things a bit to make it faster or slower on purpose. I've had pulled displays that worked in equipment but wouldn't do anything on my controller, and when you track it down it needed out of spec timings.

Do a simple blink LED test first, and make sure your system is programming. If so, then realize your code is probably not timing things correctly, or even the C compiler is optimizing timing loops out, etc. Get it resetting and then clearing, and then really look at your E timing etc, to make sure you're even writing data and commands to the controller correctly. There are a TON of buggy E timing routines out there, from everyone copying everyone else, and no one really got the timing and logic correct to start with. They tend to work fine on some displays, then not at all on others..

 

[T3STY]

Thank you all for your fast replies guys!
@emresel:
Yes, I wrote the HEX on the PIC, then read back and verified - says always all OK. I even erased the PIC and then I wrote the program, still all OK.
I use a 4MHz crystal, already tested and working on other circuits; not working in mine...
@tpetar: Thanks for the link! I'll try it tomorrow (it's a bit late right now - 4AM... ). About simulators, I couldn't use real HW until now so i had to trust ISIS. I guess ISIS made me make wrong assumptions of how to do these things and now I'm suffering the consequences. My bad, still, I want to learn the good way. I obviously put too much trust in ISIS and I guess I won't use it anymore from now on, if not with very simple circuits.
@nagkiller: Thanks for your support, I'll for sure try your program!
@Alan69: That's the point, I can't get to work not even a simple LED test. When I test the crystal with an oscilloscope I get flat 0, which means either the crystal is not working (impossible, I've changed 3 crystals, all of them working fine in other circuits, about 3.9-4.0 MHz frequency on oscilloscope), or the PIC does not make it work properly (configuration bits wrong?).
@betwixt: I am attaching a C program, the compiled HEX (compiled with MPLAB + HiTech PIC C Compiler), the schematic and PCB images (sources for ExpressPCB and ExpressSCH available too). This is working just fine in ISIS, and it's way too basic for it to not work on a real PIC. Although I can't get it to work. Please tell me if you see any error in the program or in the schematic/PCB... anything I'm doing wrong, and if you can test it on a real PIC please tell me if it's working for you.

 

[betwixt]

I have checked the hex file and it does contain the config fuses. I have imported the hex file into MPLAB and simulated it and it does work as expected. This is a classic example of a simulator and real life doing completely different things!

The problems are:
1. in hardware - you must add series resistor in each LED to limit the current they draw frm the PIC. If these are standard LEDs, add a 330 Ohm in series with each. Drawing too much current may damage the PIC and may cause it to reset itself.

2. in software - it isn't a good idea to directly do math on the port register. This is mentioned in the data sheet because it can cause what is known as RMW (Read Modify write) problems. Basically, to add one to the value it has to read the present port voltages, do the math and write it back in one operation. You can see the problem with using the voltages on the port pins when they are loaded down by the LED current!

The fix is very simple - first add the resistors. Then change the code to count and output a variable instead:

#define _XTAL_FREQ 4000000
#include <htc.h>

/* XTAL Oscillator
 * Watchdog timer OFF
 * Power up timer OFF
 * Code protection OFF
 */
__CONFIG(FOSC_XT & WDTE_OFF & PWRTE_OFF & CP_OFF);

char MyCounter;

void main(void){
    // Intializing ports as outputs, and port value 0
    TRISA=0x00;
    TRISB=0x00;
    PORTA=0x00;
    PORTB=0x00;
    
    // Counting on PORTB, forever
    while (1){
        //output the counter on the port pins
        PORTB = MyCounter++;
        
        // I'll give it 250ms delay so I can
        // watch changes on the output LEDs
        __delay_ms(250);
    }
}

Now all it does it write new values to PORTB, it never tries to read it back. I haven't got HTC to try it but it should compile OK.

Brian.

 

[nagkiller]

T3STY !!!
Your code works fine into my real pcb!!!
See schematic into PORTB.zip!!!

 

[T3STY]

Hey Brian, as I read on many forums (and on the datasheet, if I'm not wrong) the PIC has direct LED driver so there's no need of resistors. Anyway, I'll add them just to make sure things are made correctly. And the counter variable, it gets compiled right

I'll now test it, I hope it'll work.

 

[betwixt]

Direct LED drive means it can supply enough current to drive an LED without using a transistor, it doesn't mean an LED can be connected without a resistor! Typically a PIC can supply 20 - 25mA from one of it's port pins, at least on the smaller types but an LED with 5V across it will try to draw far more than that.

Brian.

 

[elecbaba]

Pretty symptomatic for simulators

Every approach has its limitations. I have completed many code projects, otherwise imposible debugging for me, only using simulators. But if you have very basic fault in your hardware, simulators can't be blamed.

 

[T3STY]

Finally, I got it working! I mean, the led test.

I found that the programmer I was using had a hidden setting for overriding oscillator type, WDT and other fuses. As soon as I correctly set settings, the LED test worked!
I wasn't that lucky with the LCD display. I am using the LCD driver I made following the timings on the HD44780 datasheet, and I actually used even longer times in some instances, but the LCD won't work anyway. I guess the driver timing is not enough, maybe there's something I left out in the driver?

I'm now going to use an LCD driver I found on the internet (written in C) to see if it's working, and if I can adapt my driver to other one. But I'd be very happy if you could take a look a look at it and tell me if I'm doing something wrong. The HD44780 specifics I followed can be found in this datasheet:
**broken link removed**
The LCD driver is the one I made some time ago following the exact timing directives from the datasheet (even longer in a few cases). The driver can be found on my blog, but I have modified it a bit because initialization on 4-bit was different than in 8-bit. I'll attach the driver here.

 

[betwixt]

Looking at it (but not actually trying it) I can't see anything wrong but there are two things to be careful of:

1. make sure you set "LCD_DL" properly. Set it to zero if you are using 4 bit interfacing and set it to 1 for 8 bit interfacing
2. the routine "LCD_GoTo" will only work with some display types, you need to use different offsets (the 0x80) for two or four line displays.

Brian.

 

[T3STY]

I have tried both 4-bit and 8-bit (properly connecting wires too) and it doesn't work anyway.
I'm not really interested in the LCD_GoTo routine, it works fine on all displays using HD44780 controller because the 0x80 code only means the goto instruction for the HD44780 controller, that's not an index (check the 'set DDRAM address' specifications in the datasheet).

I will now build again a test circuit for the display and I'll post it here (later). Meanwhile, thanks for your support!

 

[jayanth.devarayanadurga]

Why don't you post your code?

 

[T3STY]

Simple answer: because there's none!
I mean, I only have LCD_Initialize and LCD_WriteString in the main function... but if you're looking for it, here it is:
main.c

#define _XTAL_FREQ 4000000
#include <htc.h>

// The LCD driver
#include "HD44780.h"
#include "HD44780.c"

/* XTAL Oscillator
 * Watchdog timer OFF
 * Power up timer OFF
 * Code protection OFF
 */
__CONFIG(FOSC_XT & WDTE_OFF & PWRTE_OFF & CP_OFF);

void main(void){
	// Intializing ports as outputs, and port value 0
	TRISA=0x00;
	TRISB=0x00;
	PORTA=0x00;
	PORTB=0x00;
	
	// Initializing LCD
	LCD_Initialize();
	
	// Writing the string as follows (\n will jump to line 2)
	// 0123456789ABCDEF
	// FEDCBA9876543210
	LCD_WriteString("0123456789ABCDEF\nFEDCBA9876543210");
}

The driver is the one I posted before, I won't post it again. With this code I tried both 4bit and 8bit data transmission mode (check HD44780.h for LCD settings), but none worked. Actually, pretty strange, the LCD kept showing rectangles as when it's not Initialized at all. The same LCD works just fine on another circuit using the same type of LCD display.

 

[jayanth.devarayanadurga]

Maybe the problem is with LCD Contrast adjustment.

 

[T3STY]

Nope, that's not. I have used both a potentiometer on V0 and grounded it (maximum contrast) but it keeps showing the squares on the display like when it's not initialized at all (at first instruction display clears).
I'll make a few more tests by increasing timings in the initialization routine and the EN delay time, it'll be slower but I hope it works.

 

[jayanth.devarayanadurga]

Yes. Delays are the main problem. Use 1 ms delay where ever us delay is used.