baruch / b3603

Alternative firmware for the B3603
GNU General Public License v3.0
64 stars 35 forks source link

Only one 7-segment display working #16

Open UsrnameTaken opened 6 years ago

UsrnameTaken commented 6 years ago

When I plug in power source, only first display from the right shows numbers. Those I think are random, but it is to investigate.

iafilius commented 6 years ago

Confirmed/me too.

iafilius commented 6 years ago

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 img_6165

iafilius commented 6 years ago

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

Arjan b3606_compiler_issue_debug.zip

baruch commented 6 years ago

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.