TOF10120 Laser Range Sensor Module

stan74

Senior Member
Things are getting more clear with every post of your help, thanks.o_O

To put all info sofar in perspective(please correct me if I'm wrong)...
* Didn't now the diversity of SSD1306 displays! I thought that sda+scl always means I2C in their communications. So I will order a new 4pins display.
* But still SSD1306 displays are essentional parts that I (and a lot of people) can use in many existing and future (low power, compact and lightweight) projects.
* Even to replace project displays for instance, about 5 years ago, where I used a red 4 digits LED DOT matrix for heating temperature in °C and very short error messages with running text.:ROFLMAO:
* So while designing new projects and upgrading old ones with a SSD1306 display it could sometimes be easier to just add another PIC(axe) or AVR as a display driver. I did that with a previous project where I used the picaxe 20X2 driver by @marks to drive a 4x20 LCD, and works great. Less rerouting of the old pcb by just adding instead of replacing with a bigger chip.
* Therefore for me the R&D of the 08M2, 28X2 or non-picaxe chips to drive the SSD1306 display is desirable. (And this thread can help others)
* Even with the 08M2 I at least like to see what is accomplished.
* With new projects though @stan74 has a point saying...

* Also, besides the slow grahics, the refresh rate of characters is slower with a picaxe.
* But how much faster does a graphic or text needs to be depends on the project where often the PICAXE is fast enough.
* Because of the PICAXE catching BASIC instead of C+, I love to use it as overall master controller.
* External cheaper and faster alternative (display or other) drivers with an Microchip or AVR (with LIB) eventually is also desirable on other forums. The video @stan74 "SSD1306 analogue voltmeter" is impressive!
* Running all (controller and driver code) within one chip (28X2 or non-picaxe) is an good option that I'm trying. (but also where to maybe waste many unused I/O's).

Took me some time to structural write my philosophy on this, but glad to have cleared my mind.🤕
the video code uses sin and cos like picaxe. it don't do pi or floating point math only long vars like picaxe doesn't.
I got trig working better since this.
;analogue 5V voltmeter and DVM - OK 13-7-17
#chip mega328p, 16
#option explicit
#include <glcd.h>
#INCLUDE <TRIG2PLACES.H>
;
#define HI2C_BAUD_RATE 400
#define HI2C_DATA
HI2CMode Master
#define GLCD_TYPE GLCD_TYPE_SSD1306
#define GLCD_I2C_Address 0x78
GLCDfntDefaultsize=1
#define ADSpeed LowSpeed
dir portc.0 in
dim radius,xcentre,ycentre,xend,old_xend,yend,old_yend as byte
dim angle,old_angle,adcval as word
dim volts as string * 4
xcentre=63
ycentre=58
;draw dial
GLCDCLS
box 0,0,127,63
for radius=144 to 141
dial
next radius
GLCDDrawChar (5,40,asc("0")):GLCDDrawChar (115,40,asc("5"))
radius=120
angle=1 ;ReadAD(an0)/2
anglecheck
;main
do
old_angle=angle
;--- DVM
adcval=ReadAD(an0)
angle=adcval/2
;
adcval=adcval*100
adcval=adcval/51
volts=str(adcval)
if adcval<10 then
volts="0.0"+left(volts,1,1)
goto volt_format_done
end if
if adcval<100 then
volts="0."+mid(volts,1,2)
else
volts=left(volts,1,1)+"."+mid(volts,2,2)
end if
volt_format_done:
;---
anglecheck
old_xend = xcentre + radius * sin (old_angle)/255
old_yend = ycentre - radius * cos (old_angle)/255
xend = xcentre + radius * sin (angle)/255
yend = ycentre - radius * cos (angle)/255
if old_angle<>angle then ;-- update screen if volts has changed
; erase old needle
line (xcentre,ycentre,old_xend,old_yend,0)
; draw V
line (55,22,63,38):line (63,38,71,22)
; print new voltage
GLCDPrint (50,10,volts,1) ;new-print Voltage
; draw new needle
line (xcentre,ycentre,xend,yend,1)
; wait 20 ms
end if
loop
;end main
sub plotdial
xend = 63 + radius * sin (angle)/255
yend = 58 - radius * cos (angle)/255
pset (xend,yend,1)
end sub
;
sub dial
for angle= 296 to 359
plotdial
next angle
;
for angle= 0 to 63
plotdial
next angle
end sub
;
sub anglecheck
if angle>127 then
angle =angle-127
else
angle =296+angle
end if
end sub
 

stan74

Senior Member
the video code uses sin and cos like picaxe. it don't do pi or floating point math only long vars like picaxe doesn't.
I got trig working better since this.
;analogue 5V voltmeter and DVM - OK 13-7-17
#chip mega328p, 16
#option explicit
#include <glcd.h>
#INCLUDE <TRIG2PLACES.H>
;
#define HI2C_BAUD_RATE 400
#define HI2C_DATA
HI2CMode Master
#define GLCD_TYPE GLCD_TYPE_SSD1306
#define GLCD_I2C_Address 0x78
GLCDfntDefaultsize=1
#define ADSpeed LowSpeed
dir portc.0 in
dim radius,xcentre,ycentre,xend,old_xend,yend,old_yend as byte
dim angle,old_angle,adcval as word
dim volts as string * 4
xcentre=63
ycentre=58
;draw dial
GLCDCLS
box 0,0,127,63
for radius=144 to 141
dial
next radius
GLCDDrawChar (5,40,asc("0")):GLCDDrawChar (115,40,asc("5"))
radius=120
angle=1 ;ReadAD(an0)/2
anglecheck
;main
do
old_angle=angle
;--- DVM
adcval=ReadAD(an0)
angle=adcval/2
;
adcval=adcval*100
adcval=adcval/51
volts=str(adcval)
if adcval<10 then
volts="0.0"+left(volts,1,1)
goto volt_format_done
end if
if adcval<100 then
volts="0."+mid(volts,1,2)
else
volts=left(volts,1,1)+"."+mid(volts,2,2)
end if
volt_format_done:
;---
anglecheck
old_xend = xcentre + radius * sin (old_angle)/255
old_yend = ycentre - radius * cos (old_angle)/255
xend = xcentre + radius * sin (angle)/255
yend = ycentre - radius * cos (angle)/255
if old_angle<>angle then ;-- update screen if volts has changed
; erase old needle
line (xcentre,ycentre,old_xend,old_yend,0)
; draw V
line (55,22,63,38):line (63,38,71,22)
; print new voltage
GLCDPrint (50,10,volts,1) ;new-print Voltage
; draw new needle
line (xcentre,ycentre,xend,yend,1)
; wait 20 ms
end if
loop
;end main
sub plotdial
xend = 63 + radius * sin (angle)/255
yend = 58 - radius * cos (angle)/255
pset (xend,yend,1)
end sub
;
sub dial
for angle= 296 to 359
plotdial
next angle
;
for angle= 0 to 63
plotdial
next angle
end sub
;
sub anglecheck
if angle>127 then
angle =angle-127
else
angle =296+angle
end if
end sub
more not picaxe but when I was really into picaxe stuff like this was gold.
there's similarities in the trig stuff.
I got trig start from zero working now and can draw arcs and stuff. Er...groovy

I know it's old because I used goto and I'm not supposed to use goto and think it's maligned and does have a use
that do loop with conditions don't cover.
I can think of many times when goto would be an elegant solution ... but alas, it is so uncool
 
Last edited:

stan74

Senior Member
I posted the idea of a glcd slave display and got
@Anobium
"You dont need a 1k buffer for SSD1306, The minimum buffer is 16 byte buffer but you they will need to implement transactions and that would be very very hard in PICAXE."
me - Someone sorted it for char set but what about graphics? buffer needed?!?
@Anobium
"It will be very very simple in GCB to create a serial interface for a GLCD."
"Not a PIC but a LGT328p. Fast and lots memory. And, cheap. So, a LGT328p UNO shield with an ILI9341."
"
https://www.ebay.co.uk/itm/LGT8F328P-Arduino-Uno-Compatible-Board-32Mhz-READ-DESCRIPTION/184384807098?hash=item2aee30e0ba:g:yowAAOSwOBpfJV3l

https://www.aliexpress.com/item/4000322450131.html?spm=a2g0o.productlist.0.0.74205b04nfq4Ev&algo_pvid=f3991749-4a34-479a-ad5a-6b9175bf10c6&algo_expid=f3991749-4a34-479a-ad5a-6b9175bf10c6-40&btsid=2100bdd516074989504528217e3c54&ws_ab_test=searchweb0_0,searchweb201602_,searchweb201603_

So, you get serial IO via USB or Serial via the standard USART ports.

I would simply replicate the Nextion command set. No point in reinventing the wheel. Then, you can use the Nextion library to drive the unit."
 

Haroen

Member
@stan74, thanks for all "other basic" code and info that I really appriciate!
* This because about a year ago while surfing china webshops I found the nextion display types too and more but did not dare to try!
Instead I went for another(white 20pins) large 20x4 display then my previous(blue 16pins) medium 20x4 display mentioned in one of my threads.
The large display is for projects where at a distance(1,2m) it should be readable.
Recent days I've been testing how to drive it also with @marks PICAXE 20X2 driver code without succes and made this new thread.
* I can't explore "other basic" code for not owning an arduino yet and in the past days I'm researching(with my criteria wish-list) which to buy and contact on the gcb-forum as user "Haroen".
I like to take that R&D of this forum to gcb where especially complicated bigger (touch) "graphic" displays(picaxe then to slow) will be my focus with excisting working gcb code (maybe as driver only).
I would simply replicate the Nextion command set. No point in reinventing the wheel. Then, you can use the Nextion library to drive the unit."
* Thus achieving better archiving of threads and forums without breaking picaxe rules.
 

Haroen

Member
@AllyCat
Yes, I understand and agree with nearly all that you say in your philiosophy. ;)
You surprise me! Thought I made no sense.

But perhaps I should quote from my introduction to my ASCII / SSD1306 / 08M2 thread:
" The program was intended as a "core" or "preamble" for further development, ...... The code size is about 1400 bytes, so there is space for around another 500 bytes, even with an 08M2; or some/most of the code might be removed in a final application. ".
I slightly regret posting it in the "Finished / Video Projects" because it was really intended as a "Code Snippet" (where I usually post my programs) rather like a "Library" function with Arduino. The user still needs to understand what the "Library" function does and write their own "Sketch" program.
Perhaps for the SSD1306 a driver can be made like the 20X2 LCD driver code from @marks where the user(also kids) can quickly implement a small display and start from scratch programming only the master controller over serial and/or I2C.

PICaxe doesn't normally need or use "Include" files (Hooray !), so Library and Sketch are all together, but for that SSD1306 thread the "Sketch" is basically:
Code:
; WRITE FONT TO OLED:
    for index = 32 to 127
        char = index
        call tree
        hi2cout addr,(0)        ; Inter-character gap
    next
which shows how the "tree" function can be used. Of course a few more lines are needed to initialise the system, etc. and more "Library" functions are available (for example "Clear Memory" and "Double-Height").
Maybe the code also could be added as a complete (long) attachment too, instead of minimizing it so it could fit in the thread "</>code" window.
Then the user doesn't have to merge several codes anymore. Also I don't understand the position for implementation of the code for the "Double-Height" option?

But it does seem that you need to be very careful about the specification of those OLED displays. Not only are there different I2C and SPI versions, but some use different control Integrated Circuits (i.e. NOT SSD1306); some are "compatible" but not all !
Just to be sure...
Is this the right SSD1306 I2C 128x32 display for your picaxe code?
I read that your code doesn't support 128x64 displays, but 128x32 should be enough for the I2Cscanner (and TOF10120 stand-alone visualization display).
 
Last edited:

stan74

Senior Member
@stan74, thanks for all "other basic" code and info that I really appriciate!

* I can't explore "other basic" code for not owning an arduino yet and in the past days I'm researching(with my criteria wish-list) which to buy and contact on the gcb-forum as user "Haroen".
I like to take that R&D of this forum to gcb where especially complicated bigger (touch) "graphic" displays(picaxe then to slow) will be my focus with excisting working gcb code (maybe as driver only).

* Thus achieving better archiving of threads and forums without breaking picaxe rules.
I hope to discuss things with you on the gcb forum where talking about picaxe or arduino code is Not a problem.
I have not seen you on the forum yet. You have to sign in like picaxe.
From experience a 328 uno or nano from fleabay would be your best choice,
unless you own a pickit 2 or 3 or other pic programmer then any 8bit pic could be used.
arduino and clones are just plug a usb lead in and it is the power and serial in/out.
It's like picaxe where same code runs on all devices, you just got to tell it what device you're using.
These are looking interesting https://www.ebay.co.uk/itm/LGT8F328P-LQFP32-32MHz-miniEVB-replaces-Arduino-nano-V3-0-HT42B534-chip-/402349266470

A 328p clone running at 32mhz instead of 16mhz. !!
They do fast graphics. I bought 2
Pay a bit more for soldered pins version unless you can solder:)
Here's vids of mega328 and LGT328 using same display, Notice one is faster
 
Last edited:

AllyCat

Senior Member
Hi,
Just to save time I also want to order the 128x64 SSD1306 display too with pins for I2C.
Just to be sure... is this the correct one?
Yes, that display looks correct; my software can also drive the 64 x 128 pixels I2C display (and it should give double-Height if an external EPROM or RAM is available), but some of the numbers (e.g. the initialisation) must be changed. There are a few other threads on the forum which show the configuration for 64 x 128. That's why a "single" program is not practical; there are many "options" that must be chosen by the user/programmer, for example:

= 32 x 128 or 64 x 128 display?
= SSD1306 or SH1106 controller ?
= Character font(s) data inside the PICaxe or external in EEPROM or RAM ?
= Single-Height , Double-Height or Quadruple-Height characters ?
= Single-Width, Double-Width and with "Character Rounding" option ?
= The required number of ASCII characters, other fonts (e.g. Greek) or User-Defined characters, etc. ?

Google found THIS ANSWER (post #16) to "what is the difference between SH1106 and SSD1306 controllers". One difference is that the SH1106 is for (up to) 132 pixels, not 128, so there can be a 2-pixel difference in the display position. That's not much, but still half a character might be "lost". Other differences are:

"The SSD1306 has an expanded command set over the SH1106.
The SH1106 only supports page addressing mode
The SSD1306 added special horizontal and vertical addressing modes.
The SSD1306 also has capability for automatic scrolling.
If you (or your library) uses page addressing mode, it will work with either of the contollers (with the difference of line length, 128 vs. 132).
If you (or your library) uses horizontal or vertical addressing mode it will only work on the SSD1306."


In practice the differences might not be very significant; I believe normally the "Page" mode is used and setting up the "Automatic Scrolling" seems quite complex and might be done "manually" by the program.

Cheers, Alan.
 
Last edited:

Haroen

Member
You where right that the displays look alike but carefull inspecting the china sites for crappy datasheets pages and often not mentioning the chip type SSD1306.

If we focus on the SSD1306 and disgard the SH1106 we have one variable less.
Couldn't we make just one sourcecode SSD1306.bas where all options are available and (de-)selecting is done by (un-)comment?
And by CheckSyntax for a specific choosen picaxe we will know if it fit's in that chip.
Otherwise select a picaxe with larger RAM and/or add an EEPROM.
 

AllyCat

Senior Member
Hi,
Couldn't we make just one sourcecode SSD1306.bas where all options are available and (de-)selecting is done by (un-)comment?
.....
Otherwise select a picaxe with larger RAM and/or add an EEPROM.
That's almost exactly what I've done, although #DEFINEs (at the top of the program) are generally better. But there can be "too many" as happened for my project Post # 32 HERE. Also I "dislike" forum .BAS files, because they must be downloaded to my hard drive and then opened up in the PE.

There is only one "extra" file which could be an "Include" file, but the forum does not accept ".BASINC" files. The problem is that the data in this file will often be COMPLETELY DIFFERENT for a different language (e.g. Greek) or for Double-Height characters or if an external EEPROM / RAM is available. There are much more difficult things to do than paste in one block of text where commented in the main file. In most cases it will be necessary to understand and change the program, not simply "Select another PICaxe .. or add an EEPROM".

Cheers, Alan.
 

stan74

Senior Member
I did the picaxe ssd1306 setup years ago...and the line draw.

The rest..ie circle--use mid point not trig
boxes and triangles are lines joined. cls is write bytes to screen.
I tried to do a faster line code than gcb but couldn't beat it.

These are such small mono displays and need a 1k bufffer for graphics...why bother. Get 2.4 inch spi colour for same price.
 
Last edited:

Haroen

Member
I ordered the two (128x32, 128x64) SSD1306 displays with 4 pins for I2C.
I'll wait for it to arrive and test all presented picaxe code both chars and graph.
I will let you know in time, thanks for the great help so far...

@stan74
I will certainly try/compare it also with all presented gcb code!
 
Top