Open UsrnameTaken opened 6 years ago
Confirmed/me too.
Hi,
I'm been able to get the display working! However not in a way i understand, i suspect a compiler issue.
Checked code of display.[ch], and did not find any issue.
While debugging, I discoverd
Changing in function:
void display_refresh(void)
display_word(digit | display_data[i]);
to display_word(digit | display_data[0]);
Shows all active 4 digits (instead only the last one). This prooves the display/shiftregister logic itself works.
So there must something wrong with display_data[1..3] Again checked the code, and all looks good.
While debugging further i came with a workarond which i cannot explain othere then beeing a compiler issue.
In function: display_show pending_display_data[3] = display_char(ch1, dot1); pending_display_data[2] = display_char(ch2, dot2); pending_display_data[1] = display_char(ch3, dot3); pending_display_data[0] = display_char(ch4, dot4);
if ( pending_display_data[0] == pending_display_data[1] == pending_display_data[2] == pending_display_data[3]) {
uart_write_str("ERROR\n\r");
}
pending_update = 1;
Added code basically touching the fresh data, the uart_write_str("ERROR\n\r)"; isn't actually triggered (checked), but this workaround makes all digit's working including dot.
Removing the uart_writestr() causes the the single digit issue to be back. but a __asm_\("nop\n"); instead uart_write works just as good (to prevent empty loop optimizations)
I expect this is a compiler issue $ sdcc -v SDCC : mcs51/z80/z180/r2k/r3ka/gbz80/tlcs90/ds390/TININative/ds400/hc08/s08/stm8 3.5.0 #9253 (Mar 24 2016) (Linux) published under GNU General Public License (GPL)
running on "Ubuntu 16.04.3 LTS" (64bit)
note the workarond produces a warning: $ make DEP display.c CC display.c display.c:107: warning 185: comparison of 'signed char' with 'unsigned char' requires promotion to int display.c:107: warning 185: comparison of 'signed char' with 'unsigned char' requires promotion to int LINK b3603.ihx Code fits the flash, it is 7863
Anyway, there is a workaround for the single digit issue, suspecting it is related to sdcc.
Regards,
Arjan
Hi,
looking into the possible compiler issue, I created 3 situations.
1) the non-working situation (bug* files) 2) the working version (workaround files) 3) the non working version code just (display.c) recompiled with --no-peep (nopeephole_ files)
to my surprise 3) works as well!! Definitly pointing to compiler optimazation issues
Added --no-peep to Makefile: CFLAGS= -lstm8 -mstm8 --opt-code-size --std-c99 --fverbose-asm --no-peep and recompiled alal the stuff, but onfortunately, the b3603.ihx becomes to big: Code is too large, it is 8502 bytes
created a 4th test case, by using the latest build of sdcc and --no-peep http://sdcc.sourceforge.net/snap.php With still --no-peep in Makefile results in: Code is too large, it is 8388 bytes Smaller that 3.5.0 version I had used before, but stil too large to load.
A 5th case by using the latest build of sdcc without --no-peep results in: Code fits the flash, it is 7662 small enough to load, and and display works as expected now!
To my opinion the this open issue may be closed as compiler issue, and sdcc snapshot of today sdcc-snapshot-amd64-unknown-linux2.5-20171203-10186.tar.bz2 solved it.
While using the latest snapshot I noticed a few warnings : main.c:451: warning 158: overflow in implicit constant conversion eeprom.c:43: warning 158: overflow in implicit constant conversion
At the specific lines i did not notice anything special.
Attached the first 3 debug cases for those interested finding out which specific compiler bug was triggered. Regards
Sorry for the late response, I haven't been using my b3603 units much and so don't have an easy setup to test this on and verify. I hope I can get to it sometime soon.
When I plug in power source, only first display from the right shows numbers. Those I think are random, but it is to investigate.