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

One line more then expected #22

Open
thErZAgH opened this issue Jun 14, 2018 · 15 comments
Open

One line more then expected #22

thErZAgH opened this issue Jun 14, 2018 · 15 comments

Comments

@thErZAgH
Copy link

thErZAgH commented Jun 14, 2018

Hi.

I looked into the code. But I don't know where the place for y (start)position is. Sometimes the white bar creates a new line at the upper screen. The 16th line of the bar, maybe.

https://www.forum64.de/index.php?thread/81832-neue-laufwerksemulation-pi1541/&postID=1272547#post1272547

Seems like the screen don't starts at y=0. It starts at 1 instead?

@pi1541
Copy link
Owner

pi1541 commented Jun 14, 2018

I can't reproduce it on my screen.

@penfold42
Copy link
Contributor

I did see it previously- possibly before I moved the i2c pins.

What i2c pins are you using ?
If using 27/28 Have you added pull-up resistors ?

@thErZAgH
Copy link
Author

thErZAgH commented Jun 14, 2018

27/28 /wout pull-up.

Other guys have this phaenomena, too. Problem is: I cannot see a rule when this happens. It happes, yes. I tried a few times. But could not see why this happens...

Hmmmm....

@penfold42
Copy link
Contributor

I2c corruption due to insufficient pull up resistors.

The cheap Ebay displays don’t have them and the pi doesnt on 27/28.
The Pi does have them on the other i2c bus.

@thErZAgH
Copy link
Author

Uhm. Ok, 4,7kO, or does two 10kO the job, too? I have only one 4,7kO.

@penfold42
Copy link
Contributor

I used 4k7 resistors on each SDA and SCL.

Use your 4k7 for one of them and put 2x10k in parallel for the other

@penfold42
Copy link
Contributor

I just noticed mine is doing this. I’m using the i2c on pins 3/5 and I have pull-up resistors.

If I slowly navigate with single keyboard presses it’s fine.
If I HOLD the down key to scroll continuously down, I see this issue

@penfold42
Copy link
Contributor

And now mine isn’t doing this.

It’s an intermittent issue.

On reset, sometime the display is corrupt. If it is, I always get the extra line.
If it’s not corrupt at start, then it’s fine.

I notice the ssd1306 data sheet has a software init flow diagram for which registers need setting up and in what order - I’ll check this against the code.
Another possibility is the display needs some delays during init.

@thErZAgH
Copy link
Author

thErZAgH commented Jun 16, 2018

Yup. Same here.
Some times at the startup it looks like TV has no tansmission (white noise).
Some time the text on the screen is garbled.

I don't know if this could help:
https://github.com/adafruit/Adafruit_SSD1306

@thErZAgH
Copy link
Author

thErZAgH commented Jun 23, 2018

Could this be one of the init problems of the SSD1306?

This line

SendCommand(SSD1306_CMD_ENTIRE_DISPLAY_ON);

is not a the end of init routine in

[]https://github.com/pi1541/Pi1541/blob/master/src/SSD1306.cpp

Could this be a problem?

EDIT: Tihs. This is not the problem. But: If the C64 is off the display shows garbled text some time!? If the C64 is on, the rate of the garbled text is less... I don't know why this happens...

EDIT²: If the text is garbled (C64 == off) and I switch on C64, the text resets to non garbled text!?!?

Yes. I have the two 4k7 R between +5V and the two data lines now...

M Y S T E R Y

@penfold42
Copy link
Contributor

It is a mystery - I’ve noticed the pi1541 splash screen always looks ok.

My guess is some of the other hardware init code could be causing spurious junk to be sent

@penfold42
Copy link
Contributor

#38 includes a workaround for this.

I need to find time with the logic analyser but for now I reissue the oled init commands again after all the other init stuff has happened but before the browse list pops up

@penfold42
Copy link
Contributor

i jus noticed this in IEC::BUS Initialise

// Clear all outputs to 0
write32(ARM_GPIO_GPCLR0, 0xFFFFFFFF);

I wonder if this is glitching the I2C bus...

@pi1541
Copy link
Owner

pi1541 commented Aug 12, 2018

Perhaps, try calling RPI_I2CInit before any write32(ARM_GPIO_GPCLR0, 0xFFFFFFFF); is called.

@penfold42
Copy link
Contributor

Tried that, also tried changing mask to fffff0

The problem I’ve now got is trying to reproduce it reliably - even removing my workaround re inits

pi1541 added a commit that referenced this issue Dec 30, 2018
Stopped both cores sending I2C data at the same time.
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