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

display bootstrap is not reliable #1

Open
svofski opened this issue Jan 24, 2024 · 5 comments
Open

display bootstrap is not reliable #1

svofski opened this issue Jan 24, 2024 · 5 comments

Comments

@svofski
Copy link

svofski commented Jan 24, 2024

Hi!

I have built your beautiful calculator. Thank you for sharing it!

I use a slightly different display, which is also based on SSD1309, has the same resolution but slightly larger physical dimensions (2.42"). IVEE often fails to initialize it at boot time. I could even say that it's really rare when it succeeds. However, once it boots up, it works without error until fully powered off (or the sketch is reuploaded). Normal power-save cycle works reliably.

Suspecting that the display or my connections might be at fault, I tried some examples from u8g2. They work without any problem whatsoever. The display works perfectly and never fails to initialise.

Have you got any idea what could be wrong?

Also I seem to be having trouble entering a program. When I input keypresses in programming mode, they are recorded correctly and I can execute such program using f(x). However words that I pick using DICT menu are entered incorrectly. I'm not sure if there is any clearly defined relationship, they are just not the tokens that I choose. For example, if I pick ABS, the USR word is selected.

In interactive mode DICT menu work as expected.

I'm sorry for conflating two issues.

@emefff
Copy link

emefff commented Jan 24, 2024

Hello,

I had the same problem with mixed-up commands in program mode.
Therefore I inserted an additional sorting at line 2786 which reads:

prgstepins(tmp);

It should be:

prgstepins(cmdsort[tmp]);

Hope it works. Sometimes during switching on, my calc also fails to boot correctly. I found that switching it on quickly helps (maybe some kind of brown out otherwise).

Mario.

@svofski
Copy link
Author

svofski commented Jan 24, 2024

@emefff thank you, your fix for program input works!

Meanwhile I think I managed to fix the problem with display initialisation. As per circuit diagram in the sketch, DC and RESET are connected to PORTF. But the sketch code uses PORTD in pin initialisation function bootpins().

My bootpins() now looks like this. CS is also not used in this schematic so I removed it.

static void bootpins(void) { // Declare and boot port pins
  DDRB  |= _BV(SPI_MOSI_BIT) | _BV(SPI_SCK_BIT) | _BV(SPI_SS_BIT);
  PORTF &= ~(_BV(RST_BIT));
  DDRF |= _BV(RST_BIT) | _BV(DC_BIT);
}

@zooxo
Copy link
Owner

zooxo commented Jan 25, 2024

Hi!
Thanks for rebuilding IV and I'm glad that your issues had been solved.

Regarding your boot/initialization issue - I had to give my display some time when initiate.
See line 2648: delaylong(4);
To minimize the boot time I came very close to my display limits with the value 4.
Maybe you might want to give your display more time to settle?

Regards
deetee

@svofski
Copy link
Author

svofski commented Jan 25, 2024

@zooxo Delay time was my first guess too but it's not that. Pins A1 and A2 on Arduino Pro Micro are PORTF. The defines for DC_PORT and RST_PORT correctly point to PORTF. However bootpins() sets direction for PORTD, which is incorrect.

There's also initialisation of CS pin, which is permanently grounded display-side in your circuit, if I understood it correctly. So it's also superfluous and can be removed.

I'm discovering your calculator's functions. It's a very interesting design. I don't think I'll use advanced features a lot, but it's amazing to poke around.

When I input more numbers than it can take, the display takes strange forms::
image
It recovers on clear though.

@zooxo
Copy link
Owner

zooxo commented Jan 25, 2024

Wow - great job and nice done. Have fun with it.

Yes the maximum number is 1E36 (or so). An overflow will be checked when calculations exceed.
Unfortunately there is no check during keying in (more than 36) numbers.

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