Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Only one 7-segment display working #16

Open
UsrnameTaken opened this issue Sep 3, 2017 · 4 comments
Open

Only one 7-segment display working #16

UsrnameTaken opened this issue Sep 3, 2017 · 4 comments

Comments

@UsrnameTaken
Copy link

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
Copy link

Confirmed/me too.

@iafilius
Copy link

iafilius commented Dec 3, 2017

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_write_str() 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
Copy link

iafilius commented Dec 3, 2017

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
Copy link
Owner

baruch commented Apr 13, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants