Close

ESP32 Mockup Completed

A project log for Terminal-BASIC programmable calculator

A poket-to-laptop size microcomputer/programmable calculator, based on Terminal-BASIC

ptravptrav 01/15/2020 at 02:223 Comments

Finally got the working mockup running. Currently the hardware includes:

The LCD part can be easily removed from the primary board - it is held attached by a header.



Power consumption in this configuration:

I have also compared this to the power consumption of Arduino Mega 2560 with a TFT 480x320 color screen and an SD card (see the video in the Project Log 01). Two different Mega we used: "Classic" and "OSEPP" (in brackets).

I could not find an elegant way of disconnecting/managing the TFT power and the TFT backlight as it is mounted on a shield.

Obviously, Mega with a BW LCD would make a decent calculator with about 30-50 mA consumption, which equates to one month of a continuous running! Unfortunately, this system has only 4-byte arithmetic, no real-time clock, no WiFi, etc.


The calculator connects to the PC in three ways:

The Terminal BASIC on ESP32 is working... kind of. I have replaced the capitalized keywords with a lower-case. 

The SD card code is not compiling properly as the ESP32 and the Arduino libraries are different - still working on it. The hardware is fully operational, and I am able to run independent tests:

The Terminal BASIC is seemingly having a hard time working with double-precision numbers on ESP32. This program calculates a factorial in integers:

Now replacing r% with r - for 4-byte floats:

Finally, we replace "r" with "r!" ("!" stands for long reals) results in busted stack!

Next: debugging Terminal BASIC on ESP32!

Discussions

Andrey Skvortsov wrote 01/30/2020 at 00:34 point

As I wrote before, I was unable to see the long reals (doubles) problem on ESP32. But the same issue comes out on Arduino DUE. It appears from unaligned access to 8-byte values I think. Now I'm working on the fix, using slower, but more reliable approach of sequential byte read/write instead of reinterpreting unaligned areas of BASIC memory to numeric types.

It's a big disappointment, that compilers do not work around alignment problems. What sense of using C/C++ if the standard features (unions, pointers cast, variable length structures) doesn't work on some platforms and do work on others?

  Are you sure? yes | no

Andrey Skvortsov wrote 01/21/2020 at 22:03 point

It's weird, but I still can't reproduce this error. I didn't use autocapitalize feature during my tests. Also another configuration parameters need to be compared.

Here my test log:

=~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2020.01.22 00:46:49 =~=~=~=~=~=~=~=~=~=~=~= ets Jun  8 2016 00:22:57  
rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT) configsip: 0, SPIWP:0xee clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 mode:DIO, clock div:1 load:0x3fff0018,len:4 load:0x3fff001c,len:1044 load:0x40078000,len:8896 load:0x40080400,len:5816 entry 0x400806ac TERMINAL BASIC  
VERSION 2.1.1-1277  
65535 BYTES AVAILABLE  
READY  
A = 1 READY  
A%  =    = 1 READY  
A! = TRUE READY  
A! = 1 READY  
PRINT A!  1  
READY  
PRINT A! / 2  .5  
READY  
PRINT A!@  / 2.3  .4347826177  
READY  
CLS READY  
10 PRINT "GIVE ME A         Give me a" 20 INPUT A! % 30 r R! = 1 40 FOR I%=2 to a%     TO A% 50 R! = R! * I% 60 NEXT I% 70 PRINT R! 80 END

LIST

10 PRINT "Give me a"  
20 INPUT A%  
30 R! =  1  
40 FOR I% =  2 TO A%  
50   R! = R! * I%  
60 NEXT I%  
70 PRINT R!  
80 END  
READY  
RUN Give me a ?7  5040  
READY  
RUN Give me a ?8  40320  
READY  
RUN Give me a ?9  362880  
READY  
RUN Give me a ?10  3628800  
READY  
RUN Give me a ?11  39916800  
READY  
RUN Give me a ?12  479001600  
READY  
RUN Give me a ?13  6227020800  
READY  
RUN Give me a ?14  8.71782912E+10  
READY  

  Are you sure? yes | no

Andrey Skvortsov wrote 01/15/2020 at 09:25 point

Absolutely great job! I will look at TB code for the possible double floats problem.

  Are you sure? yes | no