Quoting Ernst Bachmann <[EMAIL PROTECTED]>:
>
>
> Ok, so the hardware works.
> Could you try without stackmodel=large?
I have tried all sorts of pragmas, without stack model large etc... None of the
options made any difference.
> Otherwise, could you post an minimal program to reproduce your problems?
> Maybe
> just blink a LED or something?
>
Here is a minimal program that illustrates the problem:
/*******************************************************************************
* hello.c: A "hello world" program
******************************************************************************/
#define __pic18f2550
#include <pic18fregs.h>
#include <sdcc-lib.h>
#include <delay.h>
#define OUT LATCbits.LATC7
typedef unsigned int config;
code char at __CONFIG3H _config4 = 0x00; //0b00000000
void init(void)
{
OSCCON=0xf7; //0b11110111
TRISA=0xff; //0b00000000
TRISB=0xff; //0b11111111
TRISC=0x00; //0b11111110
}
void blinkarg(unsigned char blinks)
{
int i;
//blinks=5;
blinks=+2;
for(i=0;i<blinks;i++) {
OUT=1;
delay1ktcy(1);
OUT=0;
delay1ktcy(1);
}
blinks=0;
}
void main(void)
{
init();
while(1) {
blinkarg(3); // blink (arg) times
delay100ktcy(1);
}
}
******
What happens is that the function is called with the argument "3", the function
should add 2, and thus the "led" (=the oscilloscope) should show 5 blinks, but
it only blinks twice.
If I comment blinks=+2; and uncomment blinks=5; it does blink five times.
Quoting "John J. McDonough" <[EMAIL PROTECTED]>:
> Take a closer look at your LCDputc() routine. You appear to raise LCD
> Enable -before- you put the data on the lines. You want to put the data on
> the lines, raise LCD Enable, wait 450ns, then drop LCD Enable. Then move on
> to the next nybble. If you raise LCD Enable before putting the data on the
> lines the result will be more or less random.
>
The datasheet of the LCD (displaytech 162) says to first raise EN, then load the
data. Anyway, this version works, as does your suggestion, when I use a 16f90
and the PICC Lite compiler.
>
> Also, I'm not sure what delay1ktcy() exactly results in, but you need a
> substantial wait after sending the byte. I don't recall exactly what it
> needs to be but it seems like it is on the order of 2ms ... in any case way
> more than the 450ns needed to strobe the data into the LCD.
>
> --McD
delay1ktcy(1) delays for 1000 cycles, which is about 0,5 ms (an eternity).
PS. Sorry for double posting this question, I was unsuccessful in deleting the
first one.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Sdcc-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sdcc-user
