From: Jean-Paul <tch...@fr...> - 2011-11-07 09:00:35
|
You're right. I didn't read all the code. I just took "lcd_command" for a "command" function, but it actually is a general "write" function. Ten milliseconds still make a long E pulse. It's not the problem. Maybe I have not read all the code, but I don't see where (when) the address is written after "Foobar !", before "Hello". Jason, you could try: REG_SEL=0; lcd_command(0x80); // SET DD RAM ADDRESS (or send again the init instructions) in order to set "DDRAM Address" back to the beginning of the first line (0) before calling puts_lcd("~Hello") and see what happens. Le Monday 07 November 2011, KHMan a écrit : > > I think you are completely missing the point. None of the above is > an issue. Jason knows what he's doing, and it's not a 0.1s delay. > IIRC, Jason got single char calls working, but the loop output > does not work. I can't see anything wrong with the rest of the > code. Might need to check the assembly version of puts_lcd(). -- Never jump into a loop! |
From: KHMan <kei...@gm...> - 2011-11-07 09:18:37
|
On 11/7/2011 5:00 PM, Jean-Paul wrote: > [snip] > Maybe I have not read all the code, but I don't see where (when) the address > is written after "Foobar !", before "Hello". > > Jason, you could try: > > REG_SEL=0; > lcd_command(0x80); // SET DD RAM ADDRESS > > (or send again the init instructions) > in order to set "DDRAM Address" back to the beginning of the first line (0) > > before calling > puts_lcd("~Hello") Well, he said puts_lcd() only outputs the first character. Now, assume "Foobar !" works and we are seeing '~' only and the final LED blinking works. LCD is still auto-incrementing. I don't think setting the DDRAM is useful, for now. Try degrading the function. Loop a char variable to output ASCII 65-70 ("ABCDE") and verify that simple looping works. If looping works, then it may be a pointer thingy... -- Cheers, Kein-Hong Man (esq.) Kuala Lumpur, Malaysia |
From: Jean-Paul <tch...@fr...> - 2011-11-07 09:43:11
|
Le Monday 07 November 2011, KHMan a écrit : > Well, he said puts_lcd() only outputs the first character. > Now, assume "Foobar !" works and we are seeing '~' only and the > final LED blinking works. LCD is still auto-incrementing. I don't > think setting the DDRAM is useful, for now. Don't you think it would be useful to start puts_lcd() in a definite and known state of the display? Just to confirm that the problem is not the address? And then try the ABCDE loop, keeping in mind the auto-incrementing and being prepared to write in the 40 characters RAM, whatever the number of characters physically displayed, and to see only the 1st and 41st characters appear on the first location in the display line? I would do it with a number of characters which 40 would not a multiple of. -- Never jump into a loop! |
From: KHMan <kei...@gm...> - 2011-11-07 11:19:40
|
On 11/7/2011 5:43 PM, Jean-Paul wrote: > Le Monday 07 November 2011, KHMan a écrit : >> Well, he said puts_lcd() only outputs the first character. >> Now, assume "Foobar !" works and we are seeing '~' only and the >> final LED blinking works. LCD is still auto-incrementing. I don't >> think setting the DDRAM is useful, for now. > > Don't you think it would be useful to start puts_lcd() in a definite and known > state of the display? Just to confirm that the problem is not the address? > And then try the ABCDE loop, keeping in mind the auto-incrementing and being > prepared to write in the 40 characters RAM, whatever the number of characters > physically displayed, and to see only the 1st and 41st characters appear on > the first location in the display line? > I would do it with a number of characters which 40 would not a multiple of. I'm not going to quibble over such matters. One can start to troubleshoot in any number of locations, the important thing is that it is done incrementally where one can determine what is working and what isn't. I guess now it's up to Jason. -- Cheers, Kein-Hong Man (esq.) Kuala Lumpur, Malaysia |
From: Gál Z. <tra...@fr...> - 2011-11-07 10:41:47
|
Hello Jason an KHMan, I would like to ask You, which version of SDCC are used to translate this program and please send the command line used for compiling it. Zsolt |
From: Gál Z. <tra...@fr...> - 2011-11-07 11:21:38
|
I examined the compiled code, and I found a big problem in it. That is caused by the assembly parts of the wait function. Here we are: clrwdt movlw 0x42 movwf 0 decfsz 0, f goto 0x102 nop If you are using pointers the compiler will use the FSR register for it. In your code you are using the 0x00 reg which is the INDF reg. The FSR is pointed of the last used register which should be actually the (*s). That register will be used trough INDF in your delay routine. So that cause the problem. It is unusual to make cblock into inline assembly. You have to make a global variable for using this type of delay routine. You have to use BANKSEL also. For example: unsigned char d1; void wait(long time) { for(i=0;i<time;i++) { __asm clrwdt movlw 0x42 BANKSEL _d1 movwf _d1 decfsz _d1, f goto $-1 nop __endasm; } } Inline assembly could cause lot of problem. Zsolt 2011/11/7 Gál Zsolt <tra...@fr...>: > Hello Jason an KHMan, > > I would like to ask You, which version of SDCC are used to translate > this program and please send the command line used for compiling it. > > Zsolt > -- ~~~~~~~~~~~~~~~~ http://galzsolt.zzl.org |
From: KHMan <kei...@gm...> - 2011-11-07 11:58:34
|
On 11/7/2011 7:21 PM, Gál Zsolt wrote: > I examined the compiled code, and I found a big problem in it. That is > caused by the assembly parts of the wait function. > Here we are: > > clrwdt > movlw 0x42 > movwf 0 > decfsz 0, f > goto 0x102 > nop > > If you are using pointers the compiler will use the FSR register for > it. In your code you are using the 0x00 reg which is the INDF reg. The > FSR is pointed of the last used register which should be actually the > (*s). That register will be used trough INDF in your delay routine. So > that cause the problem. Good catch. U da man :-) > It is unusual to make cblock into inline assembly. You have to make a > global variable for using this type of delay routine. You have to use > BANKSEL also. >[snip snip] -- Cheers, Kein-Hong Man (esq.) Kuala Lumpur, Malaysia |
From: Jason W. <whi...@gm...> - 2011-11-07 16:20:20
|
The code fix didn't work, it still stops after the first character. How should I proceed ? Compiler Version: SDCC : mcs51/gbz80/z80/avr/ds390/ pic16/pic14/TININative/xa51/ds400/hc08 2.9.0 #5416 (Feb 3 2010) (UNIX) the compiler I have is not exactly a new version ... -- Jason White |
From: Gál Z. <tra...@fr...> - 2011-11-07 19:41:51
|
Jason! Try this option at compiling: --nooverlay It is worth to use these option also: --nogcse --nolabelopt --noinvariant --noinduction --nojtbound --noloopreverse |
From: Jason W. <whi...@gm...> - 2011-11-07 21:22:53
|
I've done some more experimenting and the problem is purely just a problem of passing the pointer to the function. If I use a global variable to pass the data or paste the contents of the function into the main code then it works. any further suggestions ? @Gál Zsolt --nooverlay caused the while loop at the end not to be executed and the rest of the options had no noticeable effect on the program -- Jason White |
From: Gál Z. <tra...@fr...> - 2011-11-07 22:14:23
|
Why don't you try a fresher version of SDCC? There are lot of improvement since the 2.9.0 version. |
From: Jason W. <whi...@gm...> - 2011-11-08 00:01:19
|
That fixes everything, Thanks -- Jason White |