ADC + OLED. Indicador de aguja. [Needle indicator

[Democrito]

Hola,

Tenía ganas de hacer una demostración gráfica, y se me ocurrió usar un ADC y que la OLED representase una línea como indicador.

Vídeo de este proyecto: https://www.youtube.com/shorts/e454pzuxG7M

El vídeo dura sólo unos segundos, pero al ser un "short" de youtube lo repite indefinidamente.

El ejemplo que adjunto tiene este aspecto:

Aprovecha el ADC que tienen las Alhambras, es un ADS7924 y funciona por I2C. Que aparezca la patilla "ADC_SDA" como entrada y "ADC_SCL" como salida no te debe de preocupar, son formas de configurar los tri-estados y en este caso ha quedado así. Si alguien prueba el circuito con otra FPGA seguramente no tendrá ninguna dificultad en usar un ADC que tenga por casa y adaptarlo a este ejemplo. Antes de meter el ADC usé un contador que contase de 0 a 127 para ver si la "aguja" se movía correctamente.

La parte que controla la OLED y el I2C de la OLED es una modificación que hice de proyectos pasados. La modificación ha consistido en que sólo dibuje una línea y lo hace de la siguiente manera (omito hablar de los cálculos para crear la línea dentro de la memoria):

1.) Borra la memoria.

2.) Hace el cálculo de la línea y la guarda en la memoria.

3.) Vuelca la memoria en la pantalla OLED.

La base de la "aguja" es fija, está siempre en la posición (63,63), es decir, que en una pantalla de 128x64 pixeles, el punto fijo se sitúa abajo del todo del eje Y y a la mitad del eje X. Para crear la sensación de que la línea siempre mida el mismo largo (recorriendo una semicircunferencia) he usado una tabla de 128 elementos previamente calculados y convertidos en hexadecimal, y viene a ser esto: Y = sin(X) * 63 pero con varios ajustes, porque el eje Y de la pantalla OLED comienza en la parte superior izquierda y hay que restarle 63 posiciones. Los resultados que da la tabla tiene presente todos estos detalles.

Si alguien lo prueba, aconsejo utilizar un potenciómetro que no sea demasiado resistivo, lo ideal sería utilizar uno que estuviera entre 5K y 20K. Cuanto mayor sea la resistencia más ruidoso se vuelve y la "aguja" se vuelve más inestable. Y valores de menos de 5K también se puede usar, pero hay que cuidado de que a través del potenciómetro no pase demasiada corriente y quemarlo. La tensión con la que he alimentado el potenciómetro ha sido de 3.3V

Quizás haya gente que quiera darle otro uso, y en vez de un ADC, quiera poner un sensor de temperatura/humedad, CO2, etc!

Adjunto el mismo ejemplo que en el vídeo.

Saludos.

[charli va]

Esta genial Democrito!!! 

--
Has recibido este mensaje porque estás suscrito al grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a fpga-wars-explorando-el...@googlegroups.com.
Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/c310e017-d8a6-445a-b784-c2870188f966n%40googlegroups.com.

[Jo mo]

Ola Democrito,

Congratulations, this is beautiful !

One day, I will certainly use part of your design for displaying encoders position in a VGA screen !

i had a quick look at the design and have a little question!

i saw in you video that your design works but do not understand the formula for the semi table  y1 = sin(x1) * 63

And also i do not see the use of cos()  for the x1 calculation ! You should have take a shortcut that i am not catching :-)

i was thinking that it should be  something like this

 table 1     y1 = sin (angle) * 63  

 table 2     x1 = cos (angle) * 63

with angle = ADCvalue /max ADC * 180°

Thanks for this nice project and Have a nice day!

[Democrito]

Bonjour Joaquim,

Effectively. To create a circumference or part of it, the sine and cosine functions are used as you have indicated.

I did something very strange, applying the same thing, with this program:

Dim As Integer i, cx, cy, aux, tt
Dim As Double  x, y, pi = Atn(1)*4.0
Dim As Double  rad = pi/180.0

For i = 0 To 180
   
    x = Cos(i * rad) * 63
    y = Sin(i * rad) * 63
   
    cx = CInt((63.0+x))
    cy = CInt(y)
   
    If cx<>aux Then
       Print (63 - cy)
       tt+=1
       If tt = 64 Then sleep
    EndIf    
   
    aux = cx
Next

Sleep

End

The variable "tt" is only used to know what number of impressions there are because I only want 63.

The variables "cx" and "cy" are the integer part of the values "x" and "y".

The variable "aux" saves the previous value of "cx" to later check if it is repeated.

This: "If cx<>aux Then" is to avoid repeating numbers if it belongs to the X axis. I make the program only give me the first 63 values (I pause there to copy the values), because the ones that follow up to 127 without repetition of the X axis, are the same but in reverse. This is from the point of view of a list of numbers.

What you were trying to do is put the Y axis as a function of the X axis. That is, for each value of the X axis, the table should get the corresponding value for the Y axis.

And doing some tricks like inverting the values (the last is the first, the penultimate is the second, etc...) It is more or less achieved, but I don't like it. The resolution I get is very bad for the first and last value, it jumps too much.

Before uploading this project to GitHub, I'm going to test with values given by a Bresenham algorithm for circles. This is going to take me some time and I don't know if it can really be done or not.

What I have presented is functional, but it has the defect that I have commented on. In any case, I am very happy with this project because it works perfectly, except for this small detail that could be improved.

If I solve this part, you'll hear from me again.

Bonne nuit, un câlin!

[Jo mo]

Ola Democrito,

Bravo, ton français est très bon! ;-)

I think i  understand what you did!

As x an y are linked (only one y possible for every x in a semi-circle) you tried to simplify things doing x= angle*gain !

Ideally: "display needle angle" is proportional to ADC value and ADC value is proportional to pot angle -->   so " display needle angle" is proportional to pot angle (adding the right gain they will even be identical)

As you simplified, i think the  display needle angle" is not proportional to ADC value, so it ends with a kind  "logarithmic potentiometer action"

As  cos(angle) = sin (angle+90°) we can try using the same table for calculating x .

I do not have a spi LCD, can you please try this following mod of your circuit !

Gracias , buenos dias, e un grande abrazo :-)

[Democrito]

Bonjour Joaquim,

In your previous post you have described much better than me the behavior of the needle. It is like that, only that it does not have a logarithmic behavior. It's just that the values in the table are not correct even though it does its job.

I have tested your design and attached a video. I was very surprised that two lines come out, since it can necessarily only represent one. Apparently it does two things at the same time and since the eye is slow, it gives the sensation that there are two lines.

Don't worry, I'm almost convinced that this little problem can be solved from the table. For this type of problem, Bresenham's algorithm for circles should solve the problem. It is not necessary to apply the algorithm, just take the data and pass it to the table. The question is to see how to do it.

The most time I can dedicate to design is on weekends, because I can dedicate many hours in a row and concentrate on what I want to get out of it. In a few days I will have it resolved (I cross my fingers).

Merci beaucoup pour votre intérêt Joaquim, un autre gros câlin!
(J'utilise google translate pour pouvoir communiquer dans d'autres langues et c'est incroyable ce que l'intelligence artificielle peut réaliser !)

[Jo mo]

Hi hi,  two needle for the price of one :-)

it seams that for one needle x is always 0   and for the other y is always 0.

it is true that , the way i modified it, the reading of the x and y values in the table take two clock cycles instead of one in your initial design! 

So i probably introduced more then one timing problems !

Maybe if we add a buffer for the x1[7:0] and y1[7:0] values (just after the demux i added), it will be better !

It will ensure that when the "start" signal arrives at the  "Draw line" module input the right x and y values will be available too!

In the following  mod v2 , to make it simpler(even if less memory efficient) i removed the table multiplexing circuit and just doubled the exact same table!

for testing/playing/improving in the week-end with calm, if you want! :-)  

But one day i have to get myself a spi display !

Your projects are always interesting Democrito so it is a pleasure to jump in and try understanding them ;-)

Have a good night !

[Democrito]

In the end I have understood that I have confused the bacon with the speed. I have to create two tables...

It's a semicircle at very low resolution, so it's clear that both the X and Y axis have repeating values.

[Democrito]

I'm sorry Joaquim, I hadn't noticed your last post when I put mine. I just read it now.

I have tried its second version and attached the video. I am clear that the solution is two tables, or take advantage of one and play where the other points.

If you buy an OLED, remember that it is not an LCD, the latter is another very old technology. And note that it is I2C, not SPI, at the moment there is no SPI driver for the OLED, it is something that I still need to do. The OLED is monochrome and I recommend white. The OLED is made up of micro-LEDs, each micro-LED is a pixel. It has a resolution of 128x64. The one I show in my videos is the biggest! (you can check how small it is), however there is another even smaller one.

Example: https://es.aliexpress.com/item/32839718675.html

It's the same one I'm using. And since the order of the pins is: VCC - GND - SCL - SDA you can connect it directly to the Alhambra.

The truth is that playing with these things is very addictive!

[Democrito]

The attached video that I forgot...

[Jo mo]

Ola Democrito,

Yes, using two different tables is the easiest way!

in the mod v2, i still had a problem, using the same table, the X1 values were mirrored for the angles above 90°(see you last video).

That is why when you keep turning right the potentiometer above 90°, the needle comes back to the left ( instead of continuing to the right) !

- another thing that i just noticed is that in the table you made, there is a semicircle function (as stated in the table name) and not a sin(X1) as you commented next to the table!

Now, i fully understand, why your initial design was fully working (apart from the non linear/proportional rotation behavior)

so here i made a "display adapted" sin (ang) to replace the "semi-circle" table (for the Y1 values):

and here is a second table for the X1 values :

and i inserted both tables in a mod v3 ice file!  let us cross the fingers :-)

Remark: if needed , due to the symmetries in those tables, the design could be optimized in term of memory usage ( division by 4 max).

A bit like you did when you made your "Example_serial_Sin_table_q1_10.ice" in february2022

Of course, it will cost of a bit more of LC/LUTs and some more of our precious neurons :-). So maybe we can just spare some neurons this time ;-p

Know, for the OLED display that you suggest, remains the most difficult part! I have to choose which (a white or a blue) i will buy !  :-)

Thanks again and have a nice day/week.

[Democrito]

Joaquim, now it works perfectly. I do not put video because it does exactly what is expected. It does not jump at the beginning or the end and has a completely natural path. Thank you very much for the work you have done, I will put you in the author credits.

About the color of the screen, I recommend white because it is the most visible, it is blue it looks duller in comparison, but don't listen to me, if you like blue, make it blue!

Thank you for getting involved in this project, a big hug!

[Jo mo]

Great Democrito,

So, i ordered the white Oled Display.

Thanks a lot and keep up the good work !

Big hug

[Democrito]

He subido el proyecto (corregido gracias a Joaquim) aquí: https://github.com/Democrito/repositorios/tree/master/Sensors/I2C/OLED/needle_indicator

Luego he hecho un PR+Merge en Icecrystal pero parece que ha habido algún problema.

Adjunto el ejemplo funcionando perfectamente bien por si alguien no sabe descargar con GitHub-

Saludos

[charli va]

Súbelo sin falta!! ando liado con cosas del core de ICestudio que quiero sacar en breve y no estoy pudiendo enredar con todo esto pero en cuanto pueda probaré todo lo que estais mandando.

--

Has recibido este mensaje porque estás suscrito al grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a fpga-wars-explorando-el...@googlegroups.com.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/c8584080-3a07-4ac1-b014-14b2fdbe1234n%40googlegroups.com.

[Democrito]

Ya está, parece ser que había que confirmar y di por hecho que ya lo estaba.

Enlace: https://github.com/cavearr/icecrystal/tree/master/examples/I2C/OLED/needles_indicator

Este fin de semana moveré una cosa que subí hace tiempo a Icecrystal, no está en la carpeta que le corresponde , me he dado cuenta hace un rato.

Otros arreglos que quiero hacer es sobre la colección IceArith, que se supone que es sólo para números enteros (al menos así está definido en la colección), y la trigonometría y las divisiones con decimales y raíces cuadradas (con decimales) no deberían de estar ahí. Os sugiero que dentro de las colecciones de Icestudio añadáis "IceMaths", entonces lo subiría ahí todo (trigonometría, logaritmos, raices, y divisiones con decimales). Los logaritmos todavía no lo he subido por el motivo que estoy contando.

Si creáis "IceMaths" aparte de subir todo lo que comento, también corregiré (eliminando lo que añadí hasta ahora que no sea aritmética entera) la colección IceArith dejándola tal como está definida. Esto me llevará tiempo, pero poco a poco lo puedo ir haciendo.

Saludos!

[Democrito]

He hecho otro, pero esta vez con "skin" de fondo.

Parece que es azul, pero en realidad es blanco.

Vídeo: https://www.youtube.com/shorts/f5yaUYAxqYs

He sustituido una parte del circuito, en el que en vez de borrar la pantalla, carga un "skin". El "skin" actúa como un CLS, pero cargando una imagen, y luego se calcula la línea que hace de "aguja" y se mete en la misma memoria, y para no chafar la imagen del "skin", una OR de 8 bits se encarga de súper poner ambas imágenes. Una vez hecho todo esto, se vuelca la memoria (1KB) en la OLED.

Adjunto ICE.

Saludos.

[Jo mo]

Ola Democrito,

hope you had a great week-end!

Nice idea to include a background skin! Remark: In your joined file, i could not see the skin!

 it will be nice to add a scale with numbers, this can be done with a skin as you just did.

or maybe (a bit more complex) using a character rom like  https://www.atariarchives.org/cgp/Ch02_Sec04.php

for that maybe the size of the needle may need to be reduced ( maybe 50 pixels long instead of 63)

it will end a bit like this (but maybe with the numbers written horizontally, it is simpler )

have a nice day

[Democrito]

Hello, Joaquim,

I put your paragraphs and I comment below.

<<

Nice idea to include a background skin! Remark: In your joined file, i could not see the skin!

>>

A skin gives a lot of play because, in addition to embellishing the project, you can put useful information. It's a potential, I've only shown an extremely simple demo here.

The skin data is inside ICE itself, there is no separate ".list" file. I assume you mean this.

If you go to the internal modules, one of them is the same as what you see above, the red box is the memory box that holds the skin data.

The green box above ("Memory Manager") doesn't need it, but I plugged it in there so the skin would come out from the start. The bottom green box is the ROM (it's RAM acting like ROM) that contains the skin and reloads it into memory every cycle.

"In each cycle" means that the "skin" erases what was there before (placing the image with nothing else, there is no needle) and then the module that makes the line (the needle) comes into play, which in this case does not eliminate nothing, an 8-bit OR gate allows the line to be embedded in the background image (whatever is in that byte + whether or not the line is precisely there). There's a pin on the "memory manager" called "skin" that allows you to do this at will (squash what's there, or embed it inside what's there). And none of this can be seen because it is only when these two cycles have been completed that the memory is dumped into the OLED.

<<

it will be nice to add a scale with numbers, this can be done with a skin as you just did.
or maybe (a bit more complex) using a character rom like  https://www.atariarchives.org/cgp/Ch02_Sec04.php

>>

It would be ideal, the problem is that I lack knowledge of image editing, I only know the "paint" that comes by default in Windows...
I did try though, I tried to make an arc with demarcation stripes and numbering, but at 128x64 pixels... it's more complicated than it looks. It can be done, but you have to know how to handle an editing program well. By programming I would remove it, but it would take me a long time and the important thing is to see the possibilities of this circuit.

<<

for that maybe the size of the needle may need to be reduced ( maybe 50 pixels long instead of 63)

>>

I agree, but this is according to taste. For example, in what I have presented, yes, the needle is better if it is shorter. However, if there is an arch with dividers, it is better if the needle overlaps and even goes over the background image (of the arch with its dividers).

<<

it will end a bit like this (but maybe with the numbers written horizontally, it is simpler )

>>

A person who knows about image editing could put a line of numbers in a row and turn it into an arc. The problem is knowing how to do it. The most complicated of all this is the resolution, which is very very low.

Thank you for always being there, a big hug!

[Jo mo]

Ola Democrito,

Yes i was searching for a ram block but i missed it in the Drawline/drawmanager block!  So now, i see it!  thanks!

For the design of the background we can use a "pixel art oriented " drawing tool

Here i installed paint.net (windows only) . With it, we can make layers and show/hide any of them (very useful for making "construction" lines that will not appear in the final design)

and made the following background!

tips: For the text/numbers, i installed "Minecraftia" fonttype  and use the size 6  ( In the text tool bar of paint.net, we have to disable anti-aliasing )

Other possible fonts to install and use for those Oled displays:

in size 5 :   Pixel    
in size 6 :   Minecraftia    PC Senior     Pixel     pixelFj8pt1   

Then paint.net can  "save as"  (for example) a png image.

Then we have to convert that image to hexadecimal values ready for storing in our FPGA Ram block !

 i just found these two website that may help for that task!

https://www.youtube.com/watch?v=MOI9qBAAClo

https://jborza.com/hardware/2020/10/16/hardware-adventures-6-12864.html

I will try to play a bit  with this when i get my screen from china !

If needed , you can download the paint.net software and the Minecraftia fonttype i used!

and i am joining the png image and my paint.net created "source" file (*.pdn),

Thanks Democrito and a big hug

[charli va]

Hi guys! tomorrow afternoon i'm joinning to your party! 😂

What do you think if we make a plugin for Icestudio to load an image and convert into an icestudio memory block? I think in it long time ago and could be a very good moment to continue with it, tell me if you think could be useful.

--

Has recibido este mensaje porque estás suscrito al grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a fpga-wars-explorando-el...@googlegroups.com.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/6a961953-6a31-4547-abe0-0a2700df61e2n%40googlegroups.com.

[Democrito]

Carlos, that would be a great idea!

Joaquim, here you can see your creation: https://www.youtube.com/shorts/lNdy9-4W3Tc

I really liked the information you have given.

Today I have been playing with the 360 degrees: https://twitter.com/Democri74875408/status/1580248790539198528/video/1

Needs adjustment, there are places where the needle jumps too quickly from one place to another, but these are mathematical adjustments. On the other hand, we have to divide 360 degrees by 256 (1.40625)

A big hug to both!

[Democrito]

I forgot to attach the used example (ICE) from the youtube video...

[charli va]

Hi Democrito! tha's great! your twitter link doesn't work.

El mié, 12 oct 2022 a las 22:12, Democrito (<spo...@gmail.com>) escribió:

I forgot to attach the used example (ICE) from the youtube video...

--

Has recibido este mensaje porque estás suscrito al grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a fpga-wars-explorando-el...@googlegroups.com.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/fd45f5de-b93b-4331-bbf4-a732fec03df5n%40googlegroups.com.

[Democrito]

I don't know what can happen, Carlos. I don't understand social networks, I joined today because I know that many of you also have an account and I wanted to join you. I put that I follow you, Obijuan, CarlosGS and others. I get a message that only my circle can see the video and I get lost there... I don't know how to be more public, I don't see the option.

[Democrito]

I attach the video of the tweet I posted in case there are problems seeing it on twitter.

[charli va]

Hello Democritus! I'm watching your video now, but not on the link you post. I think you took the link in an intermediate step.

You posted your video as a response to Obijuan's message:

https://twitter.com/Democri74875408/status/1580244889714843648

Twitter is very interesting for FPGA stuff, welcome!

El jue, 13 oct 2022 a las 3:52, Democrito (<spo...@gmail.com>) escribió:

I attach the video of the tweet I posted in case there are problems seeing it on twitter.

--

Has recibido este mensaje porque estás suscrito al grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a fpga-wars-explorando-el...@googlegroups.com.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/28aaf52c-78be-4a6e-9866-a28afc8b2e89n%40googlegroups.com.

[Jo mo]

Ola Democrito e Charli,

Thanks Democrito for the test of my background, so which technique did you used to extract the hex values from a png file?

Remark: your icestudio design is very powerful, we can now very easily make an analog display for any sensors eg: with this next backgroung (duplication and modification of the text layer of the pdn file took 2 minutes) you have a simple  Alhambra analog voltmeter!

For you plugin idea Charli it is a good one!

We have to define what are the input and ouputs of this peace of software!

As inputs: maybe we can start by a monochome image (format to be defined(png,..)) + dimensions (width and height in pixel ) (maybe the plugin can autodetect those from the input image)

ouput: the ram ready hex values;

Maybe later, if it is doable, it will be nice if the plugin can show the monochrome image in is GUI, and maybe we can show a movable "cropping box" with the dimentions of our Oled screen(128x64 pix) . To allow the selection of the part ( of a bigger image) that we want to display on our Oled screen. ....

For twitter, i also decided to start using it, about two weeks ago! Mainly to follow what is beeing done in the FPGA comunity!

But i have now to refrain myself to waste to much time looking at what others people do and doing nothing myself :-)   Social networks are evil !! ;-)

Have a nice day guys!

[Democrito]

Hi Joaquim,

I attach the ICE with the new background (voltmeter) and a video. It is going very well, I have checked with the separate voltmeter if what it indicated was real and it is.

To convert it to hexadecimal I use a program called "LCDAssistant". This program only accepts files of type ".BMP", but the "Paint" that comes by default in "Windows" can convert ".PNG" to ".BMP" and maintains the dimensions as if it were a ".BMP"

LCDAssistant takes the ".BMP" and converts it to a HEX file in type C language. I leave instructions on how I proceed:

https://groups.google.com/g/fpga-wars-explorando-el-lado-libre/c/lea8VkKIhV4/m/ZAkMsoKLBgAJ

(I have put the post that explains the procedure I do, but surely you have to upload a bit.)

Since you send me the ".PNG" at 128x64 there are no steps necessary, I just have to save it in BMP format.

Thank you very much for everything you are contributing.

Have a nice night!

[Democrito]

There is a moment, in the post that I put, in which I talk about adding some hexadecimal numbers. Nothing to add today. Once you have the HEX with 1024 values, that's what you have to copy and paste into the little "skin" box inside the ICE.

[Democrito]

All I'm doing is experimenting, the line creation module is not definitive. All the projects that I have presented so far in this thread, you can only create a single line.

The final module will work like this:

1.) A background will be recorded in memory.
2.) You can draw one or several lines, as many as you want. All this will remain in memory.
3.) When the previous two steps are complete, the memory in the OLED will be dumped.

It will function as a counting machine, with its "start", "next", "exec", "busy, "stop"" and "done" pins.

It will be very easy to handle. Anyone who knows how to operate a counting machine will understand the dynamics of operation from the start. This way of working is the most convenient in digital electronics.

[Jo mo]

Ola Democrito,

paint.net can also save as bmp. so next time i will spare you one operation ;-)

I will have a close look at your post from 2019, i looks very interesting!  i missed it (i joined the community in 2020 i think)

Continue experimenting, we like that ;-) 

And if i can do something to help you, just let me know!

Remark 1: i am specially interested in this work because at some point, i will have to make a kind of simple graphic driver for a VGA screen ( drawlines, draw curves and write text, on top of a fixed background image) ! And what works for 128x68 pixel, should work for 640x480 (or 1024x768). On the ecp5 fpgas the ram is enough to hold a monochrome image at those sizes !

Remark2: for simple but big monochome images/graphics (even photos, but without dithering) to spare some ram usage, it could be interesting to have a simple compression/decompression circuit! (eg: storing only the numbers of pixels between two black/white commutations (RLE compression) ).  I may have a look at thid one day too! ;-p

Have a great weekend!

[Jo mo]

Ola Charli,

For the plugin, i just found that a guy (or a girl ) did a python script open version of lcd assistant !

For inspiration, there is also this one which look to have a bit more features ( colors, RLE Compression,...)

Have a nice evening!

[charli va]

A great reference Jo! a lot of thanks!

--
Has recibido este mensaje porque estás suscrito al grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a fpga-wars-explorando-el...@googlegroups.com.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/3fda873c-55db-4023-bbd7-03735d77aa03n%40googlegroups.com.

[Democrito]

Adjunto un vídeo y el "ICE" de un pequeño proyecto donde una aguja da vueltas como un radar. Se trata de que la aguja rote los 360º.

A la frecuencia I2C le hice "overclocking" de 1 Mhz, en vez de los 400 KHz, para que fuese un poco más rápido (el doble de rápido). He probado con varias OLEDs, y no todas se dejan manejar a frecuencias muy elevadas. Lo máximo que he conseguido es de 1.5 MHz.

Saludos.

[Jo mo]

Ola Democrito,

Gracias for that 360 degrees design,

i received two days ago my Oled screen.

So i tried your designs (by adding a PLL block (made by benitos) to convert the 25mhz of my colorligth i5 board to 12mhz)

but i got this "partially good" result (there is sign of the moving radar in the horizontal black strip)

i am joining a video too!

when the screen turns black it is because i am disconnect thee screen VDD.

and at repowering the black strip can move its position!

Any idea what is going on here guys ?

remark: i measured the systemclock frequency entering in the circuit and i have 11.999 Mhz!

Thanks and have a nice day

[Democrito]

Joaquim, I don't know what must be happening, but it doesn't look good.

I thought I'd buy a board like yours to see what can happen to circuits on other boards.

I'll order an FPGA board like yours and maybe Santa will bring it to me.

That some circuits work on a board and not others, is something that worries me.

[Democrito]

* Santa Claus

[Jo mo]

Maybe it is this new screen which is faulty!

 i will try it with an arduino project!

Le mercredi 26 octobre 2022 à 11:11:08 UTC+2, Democrito a écrit :

* Santa Claus

[Democrito]

I don't think that's the problem... In time we will find a solution.

[Jo mo]

Ola Democrito

You are rigth! the screen is good i could test it with my arduino uno.

But i found that in fact my screen should be an SH1106 and not a SSD1136

- Firstly, when  trying with arduino thinking thaht it was an ssd1136 it was not working!

- then i changed the i2c address to 0x3c instead of 0x3d and it started working but with a similar behaviour has i am having with my FPGA board ?

- then following thaht link   i changed the libraries to SH1106 with the example given and the display started working like a charm!

So maybe, one think you can do, is include in you .ice file a text block mentioning the OLED display  (SSD1136 or SH1106) targeted by your design.

and maybe also mentioning what is the i2C address that you are using for that target display!

Thanks a lot and have a nice evening !

[Democrito]

That's right, I've hidden too many important variables. I'll change all that later.

What I am going to comment on next is not entirely certain.

The OLED I2C standard is the SSD1306. I'm not sure, but the last two numbers give me the feeling that it refers to the size of the screen. On the other hand SH1106 and SSD1136 I am convinced that they are fully compatible. "SH(...)" and "SSD(...)", I have a feeling it makes a difference if it's SPI (the former) or I2C (the latter). If it is SPI it can also be I2C compatible.

The correct I2C address is the one you mention and it is also carried by the circuit: 'h3C in 7 bits, and if we add the LSB bit called RW (8 bits) to it, then it would be 'h78 (write only) . In fact, most likely if the I2C or SPI address was wrong you would have gotten a black screen, nothing would have appeared.

I have a feeling your display is actually SPI, but it would be weird if your display only had 4 pins. SPI has more pins. And if not, then my design has something that your screen doesn't accept. I would like to know the exact place where you bought it so I can buy it too, to know what is going on. And I hope it's not a board problem... because that would be much more complicated to solve.

Thank you very much for the tests and comments,  have a nice evening!

[Jo mo]

Ola Democrito,

the sh1106  driver (ic included in these oled PCBs) has two differences with the ssd1306 :

(1)  SSD1306 display buffer = 132x64 (this is mapped to 128x64 of the oleddisplay). (ssd1306 buffer is 132x64 )
(2) only supports page addressing mode (ssd1306 provides various modes)
so 1 byte writes all the rows in a page (8) and then the cursor moves  on to the next column. column increments automatically.
 however   when reached the end of page, need to set the next page manually

The picture is from the ssd1306 datasheet but it is almost similar paging system for the SH1106 (only each of the 8 line of each page is 132 bits length instead of 128 bits for SSD1306)

In fact it seams that  in my case only one page is "almost" correct an the others are looking like noise!

see In that page the issue is quite well explained (but for the micro-controller world (python))

There, a guy got, on his screen, a wrong pattern similar the one i am getting with my FPGA oled combo!

So, to summarize, the memory paging should be different for sh1106 (maybe a kind of offset of two pixels on left and on the right of the screen is sufficient ), maybe we need to write to multiple pages (one by one) instead of a single buffer in one go,... )

I bought my 4pin II2C white Oled screen there !

Democrito, this is not a urgent matter, personally for now i do not need to use thaht Oled screen.

And when i will need it i can play myself with your design to convert it to my display!

So do not worry with that ;-)

Thanks and have a nice day!

[Democrito]

Thanks for the information Joaquin. I've been looking at more information and I think the problem is in the configuration, there are sections that need other values. When I have a screen like yours, I'll try things and let you know.

Have sweet dreams.

[Jo mo]

Ola Democrito,

As the subject is fresh in my head, i did one more think.

With my logic analyzer, i add a look at the i2s signals generated by my FPGA and by my arduino uno for driving these oled screens!

A) For the fpga (with your designs) we have one dump of a full screen in 12 [ms] (with SCL 862Khz) :

- 2 first bytes:  78 40

- followed by ~1024 bytes  (128[bytes/page] x 8 [pages])

So here the "Horizontal addressing mode" is used  (ssd1306 datasheet p.35)

its is good for SSD1306 but the problem is the Sh1106 do not recognize that mode !

B) For my arduino (with SH1106_128x64_i2c_QTPY  sketch loaded) we have one dump of a full screen in 38 [ms] (with SCL 390Khz) :

-  78  40    00 00 00 00

-  78  00    B0 10  02           <-- command for switching to page 0 of the buffer

-  78  40    xxxxx (32 bytes for 1/4 data of page 0 )

-  78  40    xxxxx (32 bytes for 2/4 data of page 0 )

-  78  40    xxxxx (32 bytes for 3/4 data of page 0 )

-  78  40    xxxxx (32 bytes for 4/4 data of page 0 )

-  78  40    00 00 00 00

-  78  00    B1 10  02          <-- command for switching to page 1 of the buffer

-  78  40    xxxxx (32 bytes for 1/4 data of page 1 )

-  78  40    xxxxx (32 bytes for 2/4 data of page 1 )

-  78  40    xxxxx (32 bytes for 3/4 data of page 1 )

-  78  40    xxxxx (32 bytes for 4/4 data of page 1 )

-  .....

- idem for pages 2,3,4,5,6

- ....

-  78  40    00 00 00 00

-  78  00    B7 10  02         <-- command for switching to page 7 of the buffer

-  78  40    xxxxx (32 bytes for 1/4 data of page 7 )

-  78  40    xxxxx (32 bytes for 2/4 data of page 7 )

-  78  40    xxxxx (32 bytes for 3/4 data of page 7 )

-  78  40    xxxxx (32 bytes for 4/4 data of page 7 )

So here the " page addressing mode" is used  (ssd1306 dataheet p.34)

Remark: this mode exist and is compatible between both ic

C) Conclusion if we want an icestudio block that work for both oled (SSD1306 and SH1106) we nee to used the ""page addressing" mode .

So as you wrote, some initial config datas need to be trimmed !

like in the sub/sub/sub block "init config"   :

    line   04      20 // Modo de escritura horizontal;

        becomes

    line   04      22 // Modo de escritura pagina;

and then we need (at least) to add the  78  00    Bi 10  02   before sending the i page datas ( for i=0 to 7  (pages 0 to 7) )

if you need to see the details of the i2C signals, i am joining the files that can be opened with kingvs software (it runs also without the hardware connected)

Sorry for the long post ;-)

Have a nice week end !

[Democrito]

Good morning Joaquin,

Thanks again for the information provided. I remember (December 2019), at that time I also looked at the I2C signals with an Arduino and could see that the information was fragmented. I took the option to send everything at once because it was the easiest and, in my opinion, the most optimal. I think (don't remember) that there are three ways to send the 1024 bytes and I took the simplest one.

I am waiting for the "SH" screen to arrive and as soon as it arrives I will start looking at the available options. In addition to that screen, I have bought another one that has another chip, and it is much bigger. There is much work to be done in this regard. You should also make all of these displays work with SPI, which would be great for motion graphics.

What seems more complicated to me is to create a module and that most people can use/adapt it to their own project without difficulty, and that problem is what worries me the most, I've been dragging it for a long time.

I will be there for about 4 weeks, a bit limited in time, but even so I will let you know what I can see, on the other hand little by little I will add documentation to Carlos's GitHub (there I still have to document how to send information to the "SSD" chip).

Thank you very much again for your contributions and information Joaquim.

[Jo mo]

Ola Democrito,

yeah, for you choice in 2019, i would probably had made the same if i had the ssd1363.

As you know; i like ressources efficiency :-)

Concerning ressources: I am a bit sad, since few month, because my icestudio installation doesn't show me any more the FPGA ressources.

They are (not any more generatedby yosis/nextpnr, in the command output, when building the design!)

@ Obijuan: was our yosis or nextpnr command changed at some point (maybe we touched an option which removed all that usefull info)

@ democrito, that big LCD (not OLED) screen looks nice too, i may buy one too !

yeah: making a generic block/module which work for all may be difficult ! 

I think the important is:

- to try to clearly indicate in the block name or in the top level the main conditions to have it working ! to avoid people not understanding why the design is not working for them !

- to (if it is possible) have the graphic functions (not included in the oled block) to make them generic (working for any oled block of a certain ( eg 128x68))....

Thank you too Democrito for your work!

Have a sunny saturday!

[Democrito]

Ayer recibí una pantalla OLED I2C de 2.42 pulgadas, totalmente compatible con los circuitos que estamos manejando. Me ha encantado. Se puede ver los pixels con unas gafas de ver cerca y si tienes buena vista, a ojo desnudo.

Lleva el chip SSD1309 y como dije arriba es totalmente compatible con la dirección I2C, comandos y formas de envío. La pantalla se puede extraer y poner otra, está pensada para poder cambiar de color de los pequeños leds que hacen de píxeles. La mía es verde y me la pedí así para darle un toque retro. Existe azul, blanca, verde y anaranjado. El verde y anaranjado me recuerdan a las primeras pantallas CRT de fósforo verde o naranjas, pero la tecnología OLED es mucho más nítida y se puede ver perfectamente en cualquier ángulo.

En esta foto se puede comparar el tamaño de una OLED blanca, la más pequeña que tengo, frente a la nueva de 2.42". Además, no se aprecia a la vista ningún parpadeo, da la sensación de que la luminosidad es constante. En la pantalla pequeña se aprecia unos cortes negros, no es un glicht, es que al hacer la foto, la parte que sale negra le cogió en el momento de uno de esos parpadeos.

A la hora de poner texto, se ve perfectamente las letras.

Esta nueva pantalla no es barata, pero si vas a trabajar en diseño electrónico usando una OLED, se agradece mucho que sea así de grande.

Adjunto un vídeo para ver en vivo una animación donde salen dos agujas. El circuito tiene dos contadores en cascada que cuentan de 0 a 127. El comienzo (punto 0) es (para que nos entendamos) a las 3:15h. No es un reloj, pero se podría adaptar para que lo fuese. No adjunto el circuito porque estoy corrigiendo partes internas.

Saludos. 

[charli va]

Hola Demócrito! me encanta tu nuevo juguete! ando preparando bastantes cosas y por eso estoy participando poco en las conversaciones, voy con poco tiempo y tengo que optimizar, pero como siempre gracias por todo tu trabajo!

Voy a empezar a participar poco a poco en este hilo, ya que va a confluir con varias cosas en las que ando trabajando y está llegando el momento de poder aportar.

Por el momento te mando un vídeo y una imagen.

En la imagen es la pantalla de 128x64,  te la mando por si te ha pasado o es algo que tengas identificado y así ahorrarme el testeo.

Como ves en la imagen "faltan pixels" en el círculo, no sé si es que está rota (no lo descargo me ha hecho cosas raras de inicio aunque de repente se ha estabilizado, por lo que no descarto que tenga alguna soldadura floja) o es por algun problema de la resolución y el algoritmo de pintado que justo en esos puntos no lo haga bien (como te digo te pregunto SÓLO por si te ha pasado y lo tienes identificado). He quitado el overclocking por si pudiera ser pero no ,pasa lo mismo.

Tengo que revisar porque lo estoy haciendo funcionar sobre una hat que estoy diseñando para la Alhambra II y este es el primer prototipo, hecho todo manual por lo que no descarto que haya también algún error de soldadura o similar.

Mi intención es aprovechar este hilo y las pruebas con las pantallas etc para depurar la hat.

Por otro lado os adjunto un vídeo (se ve muy oscuro pero mi móvil no era capaz de grabar la oled si subía la luz ambiente) de otra OLED, esta ha llegado por equivocación, había pedido dos y me ha llegado la de la foto y luego esta que es más grande y tiene una franja arriba de color amarillo.

En el fondo aunque haya sido una equivocación del envío me he alegrado porque le veo posibilidades a tener dos colores disponibles, aunque sea por áreas.

Lo que no he investigado aún es la resolución que tiene pero se ve mucho mejor que la pequeña, de echo la resolución me ha parecido muy chula (se ve mucho mejor que otras oled que había vistocreo que el alto es mayor de 64 (el ancho estoy casi seguro que es 128) porque no me cuadra todo el espacio que queda debajo del círculo de tu circuito.  Bueno ahora haré pruebas y ya lo acotaré, he buscado por aliexpress pero no he encontrado el modelo, pero bueno te lo mandaba para que vieras que tu circuito ha funcionado a la perfección.

Una de las cosas que estoy alineando es generalizar estos circuitos para diferentes tipos de pantallas dentro de lo que se pueda.

Por otro lado estoy cerrando lo que comentamos de un conversor de imágenes a bloques de memoria y alguna otra herramienta para integrar en icestudio y trabajar con pantallas y gráficos.

Lo dicho muchas gracias por todo lo que andas haciendo!!

¡Un abrazo!

--
Has recibido este mensaje porque estás suscrito al grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a fpga-wars-explorando-el...@googlegroups.com.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/d4f5f4ae-70e7-44b9-bbef-3dd814ea1e8en%40googlegroups.com.

[Democrito]

Hola Carlos!

Estoy casi convencido de que el problema no es del diseño, al menos lo que he visto de tu foto. He ido probando en las diferentes OLEDs que tengo y no me sale ese problema. La OLED que estaba usando, de 1.3", tuvo un accidente mientras trataba de matar a un mosquito. Saltó por los aires y se melló en una esquina. Te pongo una foto para que la veas.

Cuando la volví a colocar ya no funcionaba bien, y pensé que el problema era del diseño, pero la cambié por otra y todo funcionaba bien de nuevo, así que comprendí que el problema era de la pantalla debido al golpe. Te adjunto un vídeo para que veas que "el síntoma" de esta pantalla (la de la foto) es muy parecido a lo que le sucede a la tuya.

Tu pantalla bi-color también es una pantalla de 128x64, sólo que la parte de arriba tiene una anchura de 16 pixels de alto de color naranja y el resto de otro color (los micro-leds que forman los píxels siempre tienen el mismo color, pero los de arriba son naranja y el resto azul o blanco).

Luego, entre un color y el otro, hay un sólo pixel de alto de separación donde no hay micro-leds y es por eso que se ve con una línea negra entre un color y el otro.

Mi conclusión es que tu "HAT" funciona bien y que el problema está en la pantalla. En tu vídeo, al usar la pantalla bi-color, todo se ve bien.

Tener varias pantallas es bueno, así podemos descartar este tipo de problemas cuando diseñamos cosas para la OLED.

No te preocupes, ni te agobies, cuando tengas más tiempo libre sé que tú le darás un buen meneo a todo esto. Yo estoy atascado completamente, a tal punto que quizás tomo la decisión de comenzar desde el principio (el crear múltiples líneas), pero aprovechando y validando partes que ya existen. He visto problemas en mi diseño. Hay una parte, la que calcula qué bits se han de encender y transferirlo a la memoria, me di cuenta que no cumple con las reglas del diseño síncrono. A velocidades de puerto serie no hay problema, pero cuando es en tiempo real, aparecen los problemas (para una sola línea no hay problemas, es cuando tratas de dibujar más de una). Cuando corregí ese fallo vi que seguía habiendo otros y estoy en ello. Los vídeos que he puesto donde aparecen dos agujas los hago funcionar por fuerza bruta, por eso no he querido adjuntar el ICE.

Estoy esperando que me llegue una pantalla que en vez de ser "SSD"  es "SH", que en teoría son compatibles. Espero que cambiando algunos comandos se resuelva el problema de compatibilidad. Por otra parte, cuando consiga resolver que dibuje múltiples líneas al mismo tiempo y lo haga bien, el siguiente paso que tengo pensado dar es crear un módulo SPI para las OLEDs que funcionan con ese protocolo. Por otra parte, en el GitHub de Icecristal me queda pendiente documentar el funcionamiento de la OLED (que además es terriblemente sencillo).

Creo que no se me olvida nada más por comentar. Mira el vídeo que adjunto, se parece mucho a lo que le sucede a la OLED que pusiste en la foto.

Un abrazo!

[charli va]

Buenas Demócrito! pues efectivamente yo creo que es el mismo problema! la puse recién desembalada así que imagino que no debió pasar bien los test de calidad de la fábrica XD

La dejaré para pruebas arriesgadas XD

Gracias por las pruebas y el mail como siempre, tengo que mirarme bien tu circuito, hace tiempo estuve usando tu  controlador inicial que subiste a icecrystal para algunos experimentos y modularicé alrededor de él en un modo más estándar para trabajar con gráficos, mi idea es estas semanas ir rescatando todo eso para que me ayude a terminar de desarrollar y probar funcionalidades que estoy haciendo en icestudio y así con un mismo foco atacar varios frentes simultáneos.

Seguimos!

--
Has recibido este mensaje porque estás suscrito al grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a fpga-wars-explorando-el...@googlegroups.com.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/497d74a4-0a3b-4a12-8b7c-bd7ac2c46c0en%40googlegroups.com.

[Democrito]

Para todo el mundo:

Todas las pantallas que he utilizado hasta ahora las alimento con 3.3V. Según el datasheet, puede funcionar de 1.65 hasta 3.3V y consume muy poca corriente. Internamente eleva la tensión hasta los 14V; entiendo que hace iluminar a los micro-led por tensión elevada pero con una corriente pequeñísima.

Si en la serigrafía pone "VDD" se alimenta con 3.3V, y si pone "VCC" entiendo que en la placa lleva un regulador de tensión para pasar de los 5V a 3.3. Sin embargo, aunque ponga "VCC" y alimentas con 3.3V. como dije, funcionará igual de bien.

[Democrito]

Carlos,

te adjunto un vídeo para que veas en funcionamiento tu controlador desde mi OLED de 2.42", es el segundo ejemplo de este proyecto:

https://github.com/Obijuan/nand2tetris-icestudio/tree/master/examples/05-Computer-arch/00-OLED-screen128x64

hace poco estuve corrigiendo esos 5 ejemplos, tenían el problema de las entradas al aire.

[charli va]

Fantástico Demócrito! la verdad que la pantalla mola un montón, voy a ver si pillo una.

--

Has recibido este mensaje porque estás suscrito al grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a fpga-wars-explorando-el...@googlegroups.com.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/0792251b-8991-453d-9bc1-0ba119a99abbn%40googlegroups.com.

[Democrito]

Si alguien la compra asegurarse de lo siguiente:

- Que sea I2C (en aliexpress se encuentra como "IIC"), sólo ha de tener 4 ó 5 pines (si tiene 5, el 5º es "reset"), si tiene más pines es que es SPI.

- El chip ha de ser el SSD1309

- Para ese chip hay dos tamaños, uno de 1.5" y la otra es de 2.42", elige la de 2.42".

- El color (incluido el blanco) es arbitrario, sin embargo para el ojo humano el color azul es el menos visible. Quien haya tenido láseres de colores lo sabrá bien (el verde y naranja son los colores que mejor aprecia el ojo humano, aparte del blanco, que también).

Pongo como ejemplo este enlace, y recuerda tener presente lo que menciono arriba para no equivocarse, porque a veces salen muchas opciones y nos podemos confundir al elegir:

https://aliexpress.com/item/1005003950796751.html

[Democrito]

La que yo me compré, lo hice en este lugar, y no lo puse antes porque es un poco más cara:

https://aliexpress.com/item/1005003787866468.html

[Jo mo]

ola guys,

To avoid the corners breaks (and his " half of the lines not working" symptom) some people added some glue below the corners!

@ democrito: This "old times  green color" is beautiful ! It remind me some of the first cathodique equipment (scopes, FFT analysers, ibm computers) that i used at school (around 1994) :-)

[charli va]

Jajaja, i love this hack! i'll try it and tell you! thanks Jom!

--

Has recibido este mensaje porque estás suscrito al grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a fpga-wars-explorando-el...@googlegroups.com.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/68768608-a3a3-4fe9-8565-54b4e521b718n%40googlegroups.com.

[Democrito]

Hahaha! I'm going to contact the guy to fix the screen for us!

[charli va]

Oops!, my screen is broken in the bottom right corner! incredible! I have tried to press with my fingers but the screen does not fix. I think this screen is for experiments....

El mié, 2 nov 2022 a las 21:36, Democrito (<spo...@gmail.com>) escribió:

Hahaha! I'm going to contact the guy to fix the screen for us!

--

Has recibido este mensaje porque estás suscrito al grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a fpga-wars-explorando-el...@googlegroups.com.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/628a8487-671f-4864-ac8a-170cac13a0a1n%40googlegroups.com.

[Jo mo]

Unfortunately that fix is only a preventive one !  Once the fragile corners (because of a thin glass part) are damaged, the display is half dead forever !

So i just protected my screen!

Look side views

before fix

after fix

That it is beautiful job, i am already proud of my starting day :-))

Remark: if the glue is only below the thin part (and not the thick one),the corners may break even easier ( if a pressure is applied in the middle of the screen)

have a nice day guys

[Democrito]

It seems that during the journey from China to home they suffer a lot of stress: Blows, pressure from other packages, and other things that we cannot even imagine.

[Democrito]

Hola de nuevo,

Todo lo que he publicado en este hilo anteriormente sólo sirve para hacer una sola línea y contienen pequeños fallos que no son visibles a la vista. Al intentar crear múltiples líneas y con un "skin" de fondo fue cuando me di cuenta.

He estado trabajando en uno que funcione perfecto y creo que lo he conseguido. Os dejo tres vídeos.

Este primero ya lo conocéis, pero ahora ya va bien y sin problemas: https://www.youtube.com/shorts/46PbbhHPH-E

Este segundo es una demostración de movimiento de líneas a diferentes velocidades:  https://www.youtube.com/shorts/bZtKYe26jTQ

Y este tercero emula una rueda rodando: https://www.youtube.com/shorts/pZOFqYocVHE

En los tres vídeos sale un pixel encendido en las 4 esquinas de la OLED. Está puesto en el "skin" a propósito para verificar que pone la imagen en el lugar correcto. En las versiones antiguas las imágenes salían con un pixel desplazado a la derecha, pero no se podía percibir porque era un error imperceptible a la vista. En este nuevo diseño eso ya no sucede.

Adjunto los tres ICEs que he utilizado en los vídeos.

La documentación sobre cómo funciona la publicaré durante estos días que vienen.

Saludos.

[charli va]

Gran avance! en cuanto pueda lo probaré.  Mañana me llegarán algunos "cacharros" que he pedido y entre ellas una pantalla lcd horizontal que se supone debería ser compatible, ya te contaré si va todo bien.

Un abrazo!

--

Has recibido este mensaje porque estás suscrito al grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a fpga-wars-explorando-el...@googlegroups.com.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/71e5d1db-4c66-4765-a270-e6ce5153625bn%40googlegroups.com.

[Democrito]

En el vídeo donde da la apariencia de una rueda con 7 radios que giran a la vez, en la parte de arriba tiene un movimiento extraño cuando pasa por ahí uno de los radios. Esto es debido a los ajustes que hice en las tablas (seno y coseno) cuando publiqué los "Needles indicators" y que sólo se movía la línea 180º. Forcé la última posición (127, creo que en la tabla del seno) a un valor máximo para que quedase completamente en horizontal al llegar al final. Para los indicadores de 180º está bien, pero si gira los 360º la posición 127 y 0 tienen el mismo valor, y por eso da la sensación de que se atasca un ciclo. Ese pequeño error (totalmente corregible) es heredado. Si se hace bien daría la perfecta sensación de ver una rueda girando.

Y hay otros detalles mejorables, pero lo que quería era hacer varias demostraciones sencillas y ver posibilidades para otro tipo de proyectos. Si alguien quiere jugar con este proyecto, puede cambiar las operaciones que hay en el cuadro de código, o la frecuencia del contador, etc.

Otro abrazo Carlos!

[Democrito]

Joaquim,

Today the postman-woman brought me the "SH" screen (just like yours) and the same thing happened to me as to you. I have spent a long time trying to change the configuration following the technical sheet, but I have not achieved anything. This weekend I will take an Arduino and Pulseview and see what configuration it takes and apply the same. If we're lucky (if there are no unknown issues) we'll release a driver for that display type.

Cheers!

[Jo mo]

Ola Democrito,

Congratulations, for your last upgrades of those lcd designs ! Multiples lines drawing is great!

For the Sh lcd, if you want to quickly have the curves (without the need of setting up an arduino) you can just load the kdat files  with the kingvst software (see my first post of the 29.10)

Have a nice day!

[Democrito]

Oops! Certain! I had forgotten... I will take this information into account.

Thank you!

[Democrito]

Good morning Joaquim,

I have made a very useful circuit for debugging I2C peripherals through the serial port. I would like you to try it.

The configuration of the SH is done by the circuit itself, all you have to do is tell it which page you want to record on (0..7) and then "paint" on the screen. It is simpler than it seems, let's give a practical example.

The screen at startup will be "dirty" with random pixels. That does not matter, because we will see the changes we make.

The commands to control which page you're going to write to are as you said. Suppose we want to write to page 3, type the following into the terminal (or copy and paste, and if you're using Icestudio's serial terminal, when you go to "paste" do it with your mouse, right click and all that)

78 00 B3 10 02  and hit enter.  ("B3" is page 3)

78 is the address and 00 is the command and means that what follows are commands for the screen. I know that you know this, but I am commenting it in case someone else wants to try it too.

Now we are going to "paint". We will erase everything in its path. You write for example:

78 40 00000000000000000000000000000000000000000000000000000000000000 and hit enter.

Hexadecimal codes don't actually need spaces or commas, but you can if you want. The important thing is that when you finish typing you press enter.

"78 40" means that everything after that is to "paint" (8 vertical bits), successive bytes.

In the case of the SH screen, up to 132 bytes per page can be painted.

From my serial terminal it would look like this:

And what would appear on the screen is this rectangular bite:

Now you can repeat on another page and with other codes.

The codes you gave me, one of them is:

78 40 00 00 00 00

This is because 128 to 132 are missing 4 bytes and to be compatible both screens put that "remedy".

The circuit that makes all this possible works for any other peripheral. In the configuration box you enter the configuration data and then through the keyboard (in hexadecimal) you can see how the peripheral responds.

I will do the operation of this circuit in the future... (I have a lot of accumulated work and I am in a difficult few months to invest a lot of time).

I attach the circuit.

Have a nice day.

Note:

In the same circuit I have put the SSD boxes (with their configuration) and "ncfg" which is the total number of bytes inside that box. You just have to replace it with the ones below and you can try it with an SSD screen.

In the configuration of the SSD it is not by pages, therefore you do not have to enter that command. It is configured to send you 1024 bytes at a time.

You can write directly for example:

78 40 AA55AA55AA55AA55AA55AA55...etc

[Jo mo]

Ola Democrito!

First Thanks for that detailed explanation and you work on the startup config of the SH1106!

Sorry for the delay of my reply but it took me some time to test all this for the following reasons:

1- Since few days my programmers (Ft2232+blaster) were not working any-more, i had to reinstall a fully fresh icestudio to make my programmers communicating.

2- My icestudio serial monitor is sending the data after each key press or paste click (and not only when i press enter).

question :Do you know of any setting to avoid these automatic send of datas after each key press?

i tried with putty (same problem)! And finally with the arduino serial monitor. and this one works as wanted (send after the "enter" key press)! this allow the editing of the data before sending it! useful for changing just the part we want! Arduino serial monitor also records the previous inputs and we can recall them with the up and down keys (a bit like for a shell where you can quickly recall the previous commands).

I will try to have a look at the icestudio serial monitor code! see if it is easy to sort out something!

3- To make your design work with my ecp5 fpga, i quickly understood (reading the building error message) that i needed to change the tristate blocks from ice40 primitives to ECP5 primitives.

But stupidly, it took me, this time, maybe half an our to understand that i need also to update my frequency from 25Mhz to 12Mhz :-)

4- i also took a lot of time to realize that my USBb to Serial interface was sending the input characters inversely (0->1 @ 1->0) for now i can't correct it on the Win10 driver config side so i just added a not gate at the input of Rx serial block of your design

AND Finally, i am getting a good i2c communication going out of the FPGA.

As you can see in the following picture, i can write to the screen following you commands!  but i have a slightly different result with my SH1106 display!

Above i send to page 3 then to page 5 then two page 7 and i got those 3" successive rectangles!

7800B31002

784000000000000000000000000000000000000000000000000000000000000000

7800B51002

784000000000000000000000000000000000000000000000000000000000000000

7800B71002

784000000000000000000000000000000000000000000000000000000000000000

Little remark:

- The i2c frequency is  lower than the 400khz set inside your block!

 333khz (using only i2c  10k  pullups resistors soldered on those LCD pannels )

 375 khz (with lower i2c pullups resistors,  adding 1.8k resistors in parallel with each of those two 10k resistors ) (see https://hackaday.io/project/171509-t-rex-duino/log/184884-support-for-

 375 khz should be ok for the i2c protocol and for this oled-display (even, maybe, the 333khz could be sufficient) !

So now , i will use your serial to I2C block and play a bit with the "startup configuration" block of the SH1106 and see if i can get it working 100% !

Thanks a lot for all this and have a nice week-end

Big hug

[Jo mo]

For my inverted Uart signals problem (point 4 in my last post),

I made a noob mistake, In fact, the new converter that I am using is a "usb to RS232" and not a "usb to uart" converter!
Hopefully the fpga inputs are strong and i should not have fried them with the +5V :-)

so 3 solutions :
1- i buy this  to invert and adapt the 5V to 3.3 V levels !
2- i buy this , and trow away my usb to rs232 converter :-)

3- or I solder this  !

solution 3 is faster than 1 and 2 (one month of delivery times proposed ) :-)

And the solution 4 will be to use my teensy board (or arduino) as usb to uart converter (i was using that solution for the past year)

Sorry for that quite off topic post !

have a nice week-end guys!

[charli va]

Jajaja! we could do a "Fried FPGA museum" 😂

Good work Joaquim!

--
Has recibido este mensaje porque estás suscrito al grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a fpga-wars-explorando-el...@googlegroups.com.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/d4faf3db-dff9-4aba-8dac-8c12afb9a7bfn%40googlegroups.com.

[Democrito]

Hello Joaquim, I am very happy to read you again!

Mamma mía! What an adventure you had to make it work! However, everything you have commented will help me when I start with those FPGA boards, I knew the PLL ones, but the tri-state one, although it is something that can be guessed, I was completely unaware of it. I mean when we go from one FPGA to another, which are details that must be taken into account.

I think you've done everything right, the problem is that there are things that I haven't explained to you, because I've taken them for granted.

But first I show you some images of how I see it and then I explain why it doesn't work for you. It's just to check.

There are two things to keep in mind. The first is that an LF (ASCII 10) is necessary when you want to change lines. This depends on the program we use and also on the operating system. The I2C module that I designed (I have several, but I'm talking about this case) the first byte gives the I2C "start" signal and only when it receives an "LF" (ASCII 10) does the I2C protocol give the "stop" signal from the I2C protocol. This is very important, otherwise it won't work. It only listens for the "LF" signal to close the data packet. Another important thing is that "LF" only has to occur once, if it receives two or more "LF" they will stop working. I will fix this part when I do the official circuit.

On the other hand, do not copy the codes and paste everything in block (several lines at a time), but line by line and press enter from the keyboard. You may have done it that way, but I'll let you know in case it hadn't.  It doesn't matter which serial terminal you choose (Icestudio's is particular in that it sends everything you type without waiting for you to hit enter, but it works great). The important thing is that the "LF" exists when you hit enter. The only problem with Icestudio's serial terminal is that you can't correct what's already written.

There are programs and operating systems that use only "CR" (ASCII 13, carriage return) or only "LF" (ASCII 10, end of line) or even both at the same time (CR, LF). We need it to always contain "LF" as the end of the line, and it doesn't matter if it's CR, LF, because the circuit will only listen for LF.

So make sure that the serial terminal, when you press enter, gives the "LF" signal, regardless of whether it also contains "CR". And it only has to happen once.

I have repeated myself when explaining it because it is important. When we send "LF" we close the I2C data packet. Otherwise, what it would do would be to concatenate the rest of the data that you send it, as if it were the same data packet.

About the frequency, I will measure it tomorrow. The I2C I used in this project is different than the ones I used as "read only", and is much more aware of the I2C protocol. In this case it is write/read, but set to write only.

If you see that you are still having problems, please let me know as soon as possible. I don't want anyone to get frustrated and waste hours unnecessarily. You tell me what happens and we go step by step.

Another big hug!

[charli va]

Hi Democrito! try the last wip, the serial communicator have a CR or CR+LF selector ;)

--
Has recibido este mensaje porque estás suscrito al grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a fpga-wars-explorando-el...@googlegroups.com.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/3a7aa0e1-8e82-40d9-b296-c65dba3bbf4an%40googlegroups.com.

[Democrito]

Carlos, I know and I love it! In a month and a half I will write you an email with things that I am seeing.

[charli va]

Whenever you want Democritus, your feedback is always welcome!

In the next few weeks I will post a lot of new things that I am finishing now, I will need all your help to stabilize and test it.

Thanks again for everything my friend!

El vie, 25 nov 2022 a las 23:09, Democrito (<spo...@gmail.com>) escribió:

Carlos, I know and I love it! In a month and a half I will write you an email with things that I am seeing.

--

Has recibido este mensaje porque estás suscrito al grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a fpga-wars-explorando-el...@googlegroups.com.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/06450c55-d5e9-48d6-8224-0f7a622a46b9n%40googlegroups.com.

[Democrito]

I'll be there, you know, a hug!

[Democrito]

I use these level converters (the red ones, 4 and 8 bit) and have never had any problems and they are bidirectional:

https://es.aliexpress.com/item/33011912713.html

There are USB to Serial (RS232) converters that you can choose the voltage, 3.3 or 5V:

https://es.aliexpress.com/item/1005002919716645.html

In this type of thing I do not defend anything, I only comment on what I use.

[Jo mo]

Ola Democritop e Charli,

Finally i connected the second (unused) port of my FT2232 programmer !

I was strongly inspired by the Alhambra 2 design! i even added the two LED (for RX,TX)!  My desk will look a bit more like an illuminated Christmas tree :-)

So now on the sa

But as a backup, i will order a level converter for my usb to RS232 interface (it can not arm in my drawers :-))!  Thanks for the links!

About the tristate outputs on the ECP5 fpgas, maybe you know, we already have the corresponding blocks also in the IceIO library !

Yes, it will be great, to have an automatic update of the used the blocks ( for those who contains specific fpga primitives)  when we  convert a design from one board  to another one.

This Sunday, hopefully i will have a bit of time to play with this Oled communication following your previous instruction!*

I will let you know my progress !

Have a good night and Sunday guys!

[Democrito]

Hello Joaquim,

I am attaching an improved "debugger", although it is not final yet. In this new design it accepts CR, LF and CR-LF codes as carriage returns and it doesn't matter how many times they are repeated (there will be no problem with that).

So the only important thing in this regard is that when you type a command (7800...) or paint on the screen (7840...) you end up hitting enter on your keyboard once you've typed the whole packet. When enter is pressed, the circuit interprets that you want to close the I2C data packet, so it's important to do this, otherwise it will concatenate everything you write to it.

I also attached a file (motto.txt). Copy everything (control+a, control+c) and paste it into the serial terminal that has Icestudio (right click and choose "paste") and paste it there. A Latin phrase will appear on the screen that says: "Per aspera ad astra", which means: "Through the difficult path, towards the stars", with some little stars.

I have done small tests to check the actual speed of the I2C and I get 333KHz too, but if I increase the sample resolution (in logic analyzer) it goes to approx. 375Khz. I think this is because to create a frequency, it does it by dividing with powers of 2, so you can never get exact frequencies. I will look at this calmly later, for now what can be done is increase the frequency in the corresponding box, and even overclock (each screen has its limit).

A hug!

[Democrito]

I forgot to mention that with this latest design there is no need to put pull up resistors. In this case, the entries will never be floats.

[Jo mo]

Ola Democrito,

Ok, with your last design it is is much easier to command my SH1106 oled display (even with the icestudio serial monitor).
What a pity that the Arduino serial monitor is not open source, to help us improve our serial monitor!

Here is your picture sent from the icestudio serial monitor !  it is the FIRST 100% good image displayed by that baby ;-)

Thanks a lot for all the time you took to explain me all this!  

As you said it is a bit the hard way!!   But never mind, for the crazy people around here :-))

@Charli : With the serial monitor, when we have  CR for the "on enter sends:" option,  the enter key send a line fead (LF)  (and not a cariage return(CR)) .
If i am right, maybe we need just to change the two "CR" texts by LF in the listbox !

On the code side:  at line 295  of  \resources\plugins\serial-term\index.html

[charli va]

Hi Jom!! good work!!! Why don't you do a pull request with this new "carriage return" setting?

This weekend I've been closing some tasks in the icestudio core that I had pending and I haven't been able to play with the colored light but soon I'll be bothering you a lot 😂

--

Has recibido este mensaje porque estás suscrito al grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a fpga-wars-explorando-el...@googlegroups.com.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/3e8511f8-c01f-467f-b2ee-2cb9ab1b6df5n%40googlegroups.com.

[Jo mo]

Pull request done Charly (+ a bit more ;-)

To not cannibalize Democritos Oled thread, i made a new one for the serial monitor updates

[Democrito]

Hello Joaquim,

When you feel like it and you have time, I'll leave you a zip with several examples to try on the SH1106 screen. I don't have time to explain how it works right now because I have to rush to work, but the module to create lines works exactly the same as the SSD and I explained in previous posts.

Regards!

[Jo mo]

Ola Democrito,

Sorry for my late reply!

Thanks a lot for these new designs!

These days, i am strongly focused on the rework of the serial monitor, to make the inputs really editable!

i hope to finish by the end of this week!

Then i will test your designs.

Have a nice day guys!

[Democrito]

Adjunto los nuevos diseños oficiales y ejemplos para crear una o múltiples líneas con un fondo de pantalla para las pantallas SSDs y SH1106 a través de I2C. En los próximos días voy a intentar crear lo mismo pero con el protocolo SPI.

Futuras mejoras y ampliaciones las estoy metiendo aquí: https://github.com/cavearr/icecrystal/tree/master/examples/I2C/OLED/New_designs

@Joaquim, if at any time you do the tests, you better use the improved examples that I attached to this post.

Good evening!

[Democrito]

Añado dos ejemplos más, un triangulo y un cuadrado en rotación horaria. Dentro del zip se ven 4, pero son 2 para las SSD y los otros 2 para el SH1106.

Vídeo del triángulo en rotación: https://www.youtube.com/watch?v=dU39G4tLVxM

Vídeo del cuadrado en rotación: https://www.youtube.com/watch?v=k746fesv4bM

Los puntos que se ven en cada esquina siempre los pongo para verificar que la imagen del skin (fondo de pantalla) la coloca correctamente.

Saludos.

[charli va]

Demócrito! mil gracias por estos aportes!! en cuanto pueda probarlos te reporto.

Un abrazo!

--

Has recibido este mensaje porque estás suscrito al grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a fpga-wars-explorando-el...@googlegroups.com.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/4b2a3763-a601-40b8-8611-3406e249e339n%40googlegroups.com.

[Democrito]

Nada que agradecer Carlos, todo esto es para quien realmente lo necesite!  Los ejemplos que pongo es para ver las posibilidades de lo que se puede hacer con simples líneas y el juego que puede dar tener un fondo de pantalla fijo.

Yo voy a seguir trabajando es sacar todo lo que me sea posible con la única premisa de seguir aprendiendo y enfrentar nuevos retos, y lo que vaya consiguiendo, darle luz pública por si a alguien le es útil. No hace falta agradecer nada, porque es una forma de que veáis que el esfuerzo que hacéis vosotros tiene sus frutos. Yo os estoy infinitamente agradecido por esta herramienta y tutoriales y que me da tanta vida!

Un fuerte abrazo!

[charli va]

Para eso somos comunidad! yo estoy deseando soltaros en lo que estoy trabajando todos estos meses, está siendo duro pero va quedando ya poco! en cuanto lo suelte ya tendré más tiempo de cacharrear, tengo muchas ideas y ganas de hacer cosas con gráficos. Mucho ánimo con todo!

--

Has recibido este mensaje porque estás suscrito al grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a fpga-wars-explorando-el...@googlegroups.com.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/ac779324-4735-436e-8a93-c352ea5cc2a7n%40googlegroups.com.

[Democrito]

Hola de nuevo,

Ya he conseguido hacer funcionar una pantalla OLED monocroma (128x64) a través de SPI. Me llevé una sorpresa al abordar este proyecto. Tengo dos pantallas SPI iguales y ambas son SPI de 4 hilos (SCK, SDA, DC, CS), pero además las dos son SH1106, eso significa que sólo funciona a través de paginación. Primero estuve viendo cómo funcionaba con un Arduino, le extraje las señales (las adjunto en el zip) y las estudié. Resulta que en este caso no necesita dirección SPI. Por otra parte, a través de la patilla DC (Data/Command), si esta patilla está a 0 significa que vamos a enviar comandos, y si está a 1 significa que vamos a pintar en la pantalla. Por tanto, con este tipo de SPI (de 4 hilos) no necesita enviar byte de dirección ni tampoco de comando. Hasta hoy, no había utilizado un SPI de 4 hilos y con estas características, que son nuevas para mí.

Hice las modificaciones pertinentes sobre el anterior proyecto que hice sobre el SH1106 I2C y lo convertí a SPI. Me ha gustado mucho verlo funcionar y le he hecho pruebas de velocidad. El SPI que estoy utilizando es de 3MHZ, así que es realmente veloz en comparación con un I2C. He medido la señal SCK del SPI para comprobar la frecuencia real.

Debido a la alta frecuencia la señal no se ve cuadrada, sino que toma la forma de montañas u olas. He señalado con un recuadro en rojo (arriba a la izquierda) la frecuencia/periodo de una onda individual y como se puede apreciar es de 3 MHz reales. Luego abajo del todo de esta imagen se puede leer entre otras cosas la frecuencia general que es de 2.65 MHz. Esto se debe a que entre byte y byte emitido hay un espacio (cada 8 pulsos hay un pequeño espacio) y está teniendo en cuenta ese espacio.

La asignación de pines es esta:   GND---VDD---SCK---SDA---RES---DC---CS

GND: 0V
VDD: 3.3V ó 5V
SCK: Clock
SDA: Data out (MOSI)
RES: Reset (reverse logic)
DC: Data / Command
CS: Chip Select (reverse logic)

La patilla "RES" (reset) hay que llevarla a positivo (lógica inversa), todas las demás se conectan a la FPGA.

Os dejo 5 ejemplos (los mismos que en los post anteriores, pero para SPI) y el módulo principal en el zip que adjunto en este post.

Las actualizaciones (si las hubiera en el futuro) estarán aquí: https://github.com/cavearr/icecrystal/tree/master/examples/SPI/OLED/SH1106

He de comprar una pantalla SSDxxxx (en vez de la SH1106) que funcione por SPI. Cuando la consiga haré el diseño SPI para ese tipo de pantallas. Como las compras las hago en Aliexpress y tardan muchos días, hasta que no la reciba no puedo hacer nada, pero mientras tanto abordaré otros proyectos.

Recordad que este proyecto trata solamente del dibujo de líneas y jugar con ellas, pero que permite hacer cosas muy interesantes.

Cualquier duda o lo que sea, aquí estoy.

A última hora se me ha ocurrido grabar un vídeo corto de demostración y lo adjunto. Los puntos (un sólo pixel) que está en cada esquina me ha sido siempre fundamental para comprobar de que la imagen se transfiere bien. Os lo comento por si algún día hacéis algo parecido, para tener en cuenta esta comprobación.

Saludos.

[Democrito]

Como comenté en el post anterior, las pantallas SH1106 funcionan por paginación (no permite enviar todo de golpe, le has de indicar la página en la que quieres "pintar"). Son pantallas muy econónicas en comparación con las SSDxxxx.

Las pantallas SSD permite la paginación y también enviar todo de golpe. También permite scroll por hardware, por el contrario, las SH1106 no lo permite.

Yo prefiero las SSD porque, aunque son más caras, a la hora de diseñar es más sencillo su manejo si la configuras para que reciba datos de un golpe (1024 bytes seguidos).

De los diseños que hecho para una SSD, si la cambias por una SH1106,  sucede que trata de pintar todo en los primeros 128 bytes, y se ve caótico. En cambio, un diseño hecho para la SH1106, si cambias la pantalla a una SDD, sale "medio bien", se podrá ver lo que pinta, pero saldrá con un ligero desplazamiento a la derecha.

Aunque todavía no puedo asegurarlo, porque no tengo pantalla SSD para SPI, estoy casi seguro que si pones esa pantalla en los diseños que puse en el post anterior (son para la SH1106), se verá bien los ejemplos, pero desplazado un poco a la derecha. Si te pasa esto es porque tu pantalla es SSD. Evidentemente, el que use una pantalla SH1106 por SPI, lo verá bien.

[Democrito]

Se me olvidó comentar que la frecuencia máxima (sck) que puede trabajar en modo SPI, tanto el SSD13xx como el SH1106 es de 10 MHz. Y según parece la frecuencia de refresco de la pantalla es de 60 Hz. Éste último dato no lo puedo asegurar al 100%.

[Alfredo Carmona Mirats]

Excelente trabajo.👏👍

Lo voy a probar. 

Había muy poca información en la red sobre esas pantallas tan económicas.

Además en tu exposición has dejado muy claro el modo en que se gobiernan.

Había dejado de lado cualquier proyecto con ellas, precisamente por la falta de documentación.

Y repito...lo valoro con un sobresaliente alto.

Gracias mil... Agua de Mayo para mucha gente.

¡FELICITACIONES!🤝💯

--
Has recibido este mensaje porque estás suscrito al grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a fpga-wars-explorando-el...@googlegroups.com.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/7d7378a5-03dc-4e43-9fbc-d3f8d9153436n%40googlegroups.com.

[Democrito]

Gracias Alfredo, y un fuerte abrazo para ti por tus comentarios.

Acabo de terminar otro módulo nuevo para crear líneas, es un driver universal, es decir, que funciona tanto con las pantallas SH1106 y SSD13xx, en este caso es sólo para I2C. Lo único que hay que hacer es poner un 0 ó un 1 en una patilla que se llama "choose", y así eliges la pantalla que tengas sin necesidad de cambiar de módulo.

 

En este trozo de imagen vemos el nuevo módulo, pertece a uno de los ejemplos que puse en el anterior post, pero le he sustituido el módulo controlador de líneas por el nuevo. Todo funciona exactamente igual, pero con un nuevo pin "choose": si lo llevamos a '1' le estamos diciendo que vamos a trabajar con la pantalla OLED SSH1106, y si ese pin lo ponemos a '0', le estamos diciendo que queremos trabajar con la pantalla OLED SSD13xx.

Ha sido muy sencilla hacer esta modificación, sólo era cambiar un byte de un comando que pertenece a cuando se selecciona la página en la que se quiere escribir. En esa ristra de comandos (son 3 más otros 2 del I2C) también está la opción que acabo de comentar que es la posibilidad de cambiar de chip OLED desde el mismo módulo controlador.

El modo de funcionamiento es siempre por paginación en ambos casos. Arduino, o mejor dicho, las bibliotecas de Adafruit, también trabaja así para mantener la compatibilidad de ambos chips.

Adjunto en un zip el módulo principal y un ejemplo para ver las conexiones.

Madre mía! la de cosas que se aprende cuando uno se pone pesado con un proyecto!

Saludos.