ST7735 128x128 LCDs #1014
Replies: 21 comments
-
Posted at 2015-06-19 by @gfwilliams Wow, that's pretty close! Looks like the width is right, but the start address and 'view window' is off. I'd look at copying these two:
The first one is already there, but just uses different values, and for the second one you'll need to change the code in There's also this code - it looks like the Adafruit lib supports a few different types of screen by sending different initialisation code. It wouldn't surprise me if their 'default' setup doesn't work for you either. |
Beta Was this translation helpful? Give feedback.
-
Posted at 2015-06-19 by Jorgen I just figured out on my train drive, that I need But good idea to add this later on to one LCD-display driver library. |
Beta Was this translation helpful? Give feedback.
-
Posted at 2015-06-19 by @gfwilliams Interestingly, Espruino already has a similar 'do anything' implementation for parallel-interface LCDs, that's used on the 'HY' boards: https://github.com/espruino/Espruino/blob/master/libs/graphics/lcd_fsmc.c#L403 With the two-way comms on those it can actually read out the controller ID and then execute the correct code. It's a hard balance with modules though - you don't want loads of modules from the point of view of maintenance, but at the same time you don't want to be using up precious RAM with code that you're never using. I guess one option is to actually generate multiple files using some kind of preprocessor. In fact with minification and the closure compiler it'd be possible to do it just with IF statements... |
Beta Was this translation helpful? Give feedback.
-
Posted at 2015-06-19 by @gfwilliams Also, pretty sure you won't need the Magical Unicorn Dust. I'm pretty sure that's for setting the Gamma ramp, but the colour doesn't seem to be a problem on your screen at the moment. |
Beta Was this translation helpful? Give feedback.
-
Posted at 2015-06-19 by Jorgen Now it is much better, but still not as expected...
|
Beta Was this translation helpful? Give feedback.
-
Posted at 2015-06-19 by @gfwilliams What's it look like now? |
Beta Was this translation helpful? Give feedback.
-
Posted at 2015-06-20 by Jorgen |
Beta Was this translation helpful? Give feedback.
-
Posted at 2015-06-20 by Jorgen Ok, don't know why, but when I modify the flip by add 2px to the X and 3px to the Y it works...
|
Beta Was this translation helpful? Give feedback.
-
Posted at 2015-06-20 by Jorgen here is my file to play with. I just add it to my local webserver and load it with require.
|
Beta Was this translation helpful? Give feedback.
-
Posted at 2015-06-22 by @gfwilliams Thanks! I'll update the docs with it - it looks like you've changed enough that it's better as a separate module. Mind if I use your photo of it working on the page? |
Beta Was this translation helpful? Give feedback.
-
Posted at 2015-06-22 by Jorgen @gordon I Just try to use your original source and only change the part of rewrite flip
And voilà it works also :D |
Beta Was this translation helpful? Give feedback.
-
Posted at 2015-06-22 by @gfwilliams Actually it'd be great if you could do just the display on a white background, but don't worry if not. Ok, great! interesting about the offset - I'll try and fit that into the existing module. |
Beta Was this translation helpful? Give feedback.
-
Posted at 2018-12-20 by stephaneAG Hi there ! I stumbled upon this thread ( 3 years old -> cute ^^) while looking for fixes to drive the following screen correctly: The breakout uses an ST7735 driver, as @jorgen's & as within the Espruino tutorial The issues:
Many tries, but I couldn't get the above fixed without further modding the ILI9163 library ( fiddling with g.setRotation didn't fix the offset no the italic text :/ .. )
From the above fixes, I don't know if a 'offset: { x: , y:}' could be added to an option object that could be passed while connecting to the screen ? This being said, I have few questions on the graphics module ( & I'd be glad to format & add the answers fetched to the graphics page ;) ): Q1: on screen colors & update speed for a "little bigger" chip, I was wondering If I could expect a nearly instant refresh for paletted ( & non paletted as well ? ) modes on this screen & the STM32F407VGT6 ( 1024kB flash, 192kB ram). 12812816bpp = 32768 bytes = 33kB -> ~159kB are ram left ? ( I bet this assumption is pretty naïve, since the amount of ram available to Espruino may not match the total amount of ram available or something of the same kind I'm not aware of ? .. ) Q2: would a mode with 'non palettes zones' & other stuff 'palettes' be of any interest ? Q3: would a mod of the 'clear()' & 'flip()' methods accepting a rectangle x1,y1,x2,y2 be of any help ( to either clear or update only part of the screen ) ? ( then we could also have 'canvases' & do stuff like g.cnvs[0].clear(), .draw.. & maybe have x&y coords shifted by the top-left of such canvases - that may be rotated as well ? ;) ) Q4: could 'dynamic italic text' be come a feature ? ( I'll add visuals from my tests to better illustrate this 'glitch-not-yet-a-feature' ;p ) Q5: could an alternative behavior for the 'palettes' mode be handy ? ( if color is outa bounds, fallback to either black or white depending on a param passed or settings ) Q6: best way to get 'instant drawing' for a (colored or not but likely ) logo ? I tried using setPixel() & timing the time taken to draw the entire screen with sort of a gradient ( see hacks in code below ), then just using fillPoly() & while the latter seems way more promising than loading setting every pixel, getting it into the right colors quickly drawn from an array is I think possible, yet I'm not sure yet how to achieve that ( by using E.mapInPlace() & Cie ? - I also wonder how loading an image is done - and I failed but 'll retry to getting the Espruino logo example loading as an image ;) ) I currently have two possible scenarios of how to get that colored logo draw quickly ( 'll presumably happen on device boot or reboot - and may be used as a "background" while a loading bar is updated at the bottom - not sure how of much time a 'clearToBackground()' fcn would take ;p .. ) A:
B:
drawing to screen directly being slower than to memory then in-one-row to screen, I'm wondering how drawing from obj ( from an already painted in ArrayBuffer saved in flash ? ) to screen would preform ( I guess it'll take more time for more colors ) & how to minimize the ram used to do so ( if I get correctly the current paletted code, it send rows by rows what I'd like to load & send row-by-row ( to lessen ram used ), but I'm not sure how 'fillPoly()' is implemented & whether or not I may be able to just draw its points & then use 'ce.set' once all are drawn I'll try some stuff out & then post an update ;) here some hacks for the adventurous readers ;p
|
Beta Was this translation helpful? Give feedback.
-
Posted at 2018-12-21 by stephaneAG a quick update on the subject: I tried for a while getting the following to work but yet without success ( it seems I get the beginning right, but then my code happily produces 'instant pixel artifacts garbage' instead of sending part of the buffer for spi refresh ) The idea behind the 'flipP' ( fliPartial() ) & 'clearP()' ( clearPartial() ) is to be able to later build upon those in order to provide saving & restoring an ArrayBuffer ( g.buffer ) smaller than the entire screen as well as providing a way to quickly update or clear only part of the screen ( in normal & paletted mode ) If anyone's skilled & brave enough to defeat the troubles that lies below, I guess I'm not the only one who'd benefit for such kindness ;p the non-working-quite-right versions ( rest of the code is as above )
test code ( better tried with something already drawn on screen, like some polygons or a logo ..
I achieved 'horizontal color stripes' on the 1st item with 3 redrawns before messing with the code & not being able to fix my mess back to that moment I wished I saved it :/ ( gotta upload picture of this & other cases as well .. ) this being said, I'm onto a little break .. |
Beta Was this translation helpful? Give feedback.
-
Posted at 2018-12-21 by @gfwilliams Thanks for posting this up -I'll have to diff and see what init values actually changed. Looks like we need some kind of options object to let this stuff be specified - although the module itself is quite small so I wonder whether we shouldn't just have another module for this slightly different type of display? The row/col offsets could hopefully be added during initialisation as well - calculating offsets for each pixel write would really slow things down.
I think you're still going to be limited by SPI transfer speed. Until Espruino supports DMA you're not going to be able to push the data that fast.
I'm not sure I understand... But if the other mode is unusable on all official Espruino boards because of the memory usage then I doubt it'd be that useful to people?
There is actually Graphics.getModified http://www.espruino.com/Reference#l_Graphics_getModified as Graphics keeps track of what has changed. If you could make
I know what you mean, but I'm not convinced! You could write a function a bit like there is for doubling font size though? http://forum.espruino.com/conversations/327333
Wouldn't that make everything really slow? And I'm not sure how it could be out of bounds - if you have a 4 bit image with 16 colours then they can't be out of bounds by definition??
Just copy the contents of Or if you want to save memory you could use heatshrink compress/decompress on it: http://www.espruino.com/Reference#l_heatshrink_compress |
Beta Was this translation helpful? Give feedback.
-
Posted at 2018-12-23 by stephaneAG Hi there ! A whole module seems a little overkill for stuff that could be set via options ( or it seems to me, at least ? ), also I have a little 64x48 old screen for which I can't fix the display ( I didn't mod the SSD1306 module right during my tests, reason for the horizontal white lines I'm getting :/ .. ) I totally agree on putting the rows/cols offsets in the init cmds & I tired to do so, but I still don't have enough hints on the params of column & page address ( I could successfully fiddle with those to fix the "italic" text, but couldn't get the same fix working with tweaks on init .. ) -> if you have any docs on those, I'll be very glad to read about it :)
Understood for the DMA stuff ( I 'll have to continue my beginner tries on how to use DMA before jumping to Espruino code that would relate to the subject .. but not skilled enough to help you there :/ ) For the "other mode", I was thinking of something that would actually work on the official Espruino boards as well & use some "partial clear & flip()" to minimize the ram & memory needed :) Thanks for the link on ".getModified()", it'd be pretty nice to clear the last stuff drawn :) For your proposal on 'flip()' you'd wish something that clears only the last area drawn or every areas drawn ? (in other words, if I do the following, do I get a "cumulative" modified area ? )
If the above is actually what's returned, I'll be happy modding the flip() fcn in order to only send the modified rows ( shall we include a bool to "force" re-sending unmodified stuff as well ? ) :) For the "italic" text, it was actually a glitch from setting the 1st or 3rd params in the 0x2A/0x2B calls, but thanks for the hint on the font doubling ;) For the "alternative behavior" of the "paletted mode", I was getting weird colors mainly because of having a not big enough palette I guess ( it seemed to went away when having a palette of 16 items, clearer after reading the source again .. ;) ) For the "instant logo drawing", I studied your platform game code ( & tested it -> it seemed I had some fixes to do be done with the player "flying" and going down otherwise, but this may have come from the way I set my btns ;) ) The goal being to save memory & get a colored logo drawn at once in whatever paletted/normal mode, I guess a possible solution would be to 1st save it to .boot0 & cie & then have the code that draws it on power up & reboot ? -> I'll try the said stuff in few mins & give an update that as well ( .. ) Last but not least, I digged within jswrap_graphics.h/.c & graphics.h.c to better understand stuff .. and there's a lot to grasp :) ! For the "partial clear" part, what about the following ?
For the 'flip()' update, maybe something like the following to be able to either try a flip or a partial flip if something was modified, and "force" it for whatever reason if needed - but I guess the "force" bool wouldn't be used .. ?
This being said, I'm onto some fun with g.buffer ;) I hope the above 'll work as is ( I still have to make my 1st own Espruino build before trying further modding the src ;) |
Beta Was this translation helpful? Give feedback.
-
Posted at 2018-12-23 by @gfwilliams Surely a partial clear is just a fillRect with the background colour? I'm not sure I see the need for a whole extra function there? And yes, pass |
Beta Was this translation helpful? Give feedback.
-
Posted at 2019-02-01 by stephaneAG hi there ! I clearly see your point for the non-need of a whole extra fcn ( I guess maybe update clear() & allows args & same for flip() ? ) -> anyway, it seems the above code helped others than me, so maybe I'll have to put it somewhere else .. |
Beta Was this translation helpful? Give feedback.
-
Posted at 2019-02-04 by stephaneAG Hi there ! I had a quick take on getting that partial flip thing to work, but for a reason I can't figure out ( I'm either too dumb, tired, or both ;p ) I can't make it work for only a vertical portion of the screen ( smaller than LCD_WIDTH ) any quick hint on this ?
Also, I've been able to figure out that my screen seems to accept either RBG or BRG, not RGB, and thanks to the following link /code, here's a quick & handy remapper for those in need ;)
-> I hope I'll be able to draw things faster in "unicolor" that way ;p ( one of the goals is to be able to draw in 2 colors, one black & the other dynamically changing ) |
Beta Was this translation helpful? Give feedback.
-
Posted at 2019-02-06 by stephaneAG hi there !
Also, as a side subject, any idea of a hack to allow stuff already on screen of color other than black ( for ex ) to be all set to a particular color ? this being said, here's the code for partial flip :D
|
Beta Was this translation helpful? Give feedback.
-
Posted at 2019-02-06 by @gfwilliams
I'm not 100% sure I understand this, but I guess you have two options:
|
Beta Was this translation helpful? Give feedback.
-
Posted at 2015-06-18 by Jorgen
I try to port another driver library for this inexpensive 1.44" display
It uses the ST7735 driver - which is used by most of these cheap displays.
Currently I try to use first the new ILI9163 library from Gordon (Forum post)
Here is what I get as initial state:
Try this as inline to play with commands...

This is what comes out of the box with the ILI9163 driver:
As you can see, the coordinates are not right now. Everything seems to be shifted...
I will start working on this tomorrow - my son is getting his third tooth, so everything is grumpy today :/
Thanks to @gordon, I'll try add these commands tomorrow
Beta Was this translation helpful? Give feedback.
All reactions