Agreed but the OP has only just started to show that his hardware is 'capable' of running and my suggestion to use the debug mode was simply to ensure the code was actually executing. Also it would have the advantage you were talking about of introducing a (big) delay after power on and perhaps show up a timing issue.In my opinion, MikroC debugging is next to useless. I doubt it will prove anything.
I put on decoupling cap between VDD and VSS with 100nF and still nothing
// LCD module connections
sbit LCD_RS at RB1_bit;
sbit LCD_EN at RB2_bit;
sbit LCD_D4 at RB5_bit;
sbit LCD_D5 at RB4_bit;
sbit LCD_D6 at RB3_bit;
sbit LCD_D7 at RB2_bit;
Sadly you guess wrong. mikroE compilers effectively put an infinite loop at end of your program whether you remember to provide your own loop or not.I had a quick look at your C code file (lcd4.c) and it is missing a key feature of any embedded program: the 'while' loop.
An embedded program is expected to run forever and the 'main' function should never return. After all, there is no'operating system' for the program to return to when it finishes.
I don't know about the mikroC computer but other compilers I have used create small runtime initialisation code that sets up things such as the initialised global variables, stack pointers etc and then calls the 'main' function. If the 'main' function does ever return, the compilers that I've used have that runtime code perform a reset that restarts the device all over again.
What *might* be happening is that the LCD initialisation code takes a littler bit of time to run and shows a blank LCD display while it does. Your code then writes a line to the display but then immediately the main exits and the device resets, causing the LCD initialisation code to blank out the display again. If this happens fast enough, then your eye will not see the LCD output and so the device will appear to be not working.
Just a guess.....
Susan
'goto $+0' at the end of the main function means "loop self" and prevents exit to (non-existent) operating system. It does NOT mean goto address zero.I checked out the 'lcd4.lst' file in the .rar file in post #27. At the end of the 'main' function there is a 'goto $+0' (address 0x0121). Address 0x0000 has a 'goto 257' instruction. Address 0x0101 has the label '_main:' above it and what looks like setup code that falls into the user-written code at address 0x011a.
The first instruction there is the call to 'Lcd_Init'.
Therefore the problem I mention of continuous initialisation of the LCD will be occurring - however it would appear that the duration the display is showing the characters is long enough to be seen.
Susan
Long time since I did assembler and it was for a completely different architecture - I stand corrected.'goto $+0' at the end of the main function means "loop self" and prevents exit to (non-existent) operating system. It does NOT mean goto address zero.
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?