'Clipping' refers to the suppression of graphic data that falls outside the display area, i.e. being able to draw off screen without causing problems. If you write to screen memory or to a back buffer, if the screen is double buffered, and part or all of the data you are writing is outside the bounds of the buffer/screen display, the hardware needs to be able to ignore that part which is not in the screen buffer or video RAM without it causing problems, for example overwriting other parts of RAM that are adjacent to video RAM or the back buffer. Back buffers or double buffering is a method of producing flicker free, smooth graphics on a display. The idea is that you have a second RAM area in which you write all your display data to, i.e. text and/or graphics, then copy the freshly re-drawn image to video RAM. In many video systems you are simply required to write to a single hardware register which swaps the front buffer with the back buffer.
The Clip Range test is likely ensuring that drawing off the edges of the display works properly and doesn't bog down the processing. It's fairly common in games programming to do a similar rendering test because drawing off edges wastes time.
I think you need to check the library to see if you can specify the screen resolution of your display. It looks like the library is using more pixels than you've actually got.
Try using an RTOS like Zephyr. One task can create frame buffers, paint them, and hand off to another task to show them. The task that shows them need only send to the OLED the differences -- reducing the I/O substantially. You can also crank up the SPI baud rate higher and higher until things break down, and then back off. For example, 2Mbps would be a good goal. The display can handle up to 6Mbps probably. I would use 8 frame buffers or so. Animations that don't have a lot of complexity are easier to do fast. For example PONG, or text telemetry. Rotations requires sin/cos floating point or a very fast fixed-point library. Also, for a good physics model, you need Quaternion math to avoid gimbal lock.
+HillOrStream Have a look for 161883302798 on eBay - it's probably not from the same seller, but it is the same type, you need to solder the header pins on yourself.
hi there, its a very good video. I need to use the same display as a tiny light source in a project. you mentioned that every pixel is addressable, how is that done, and how can we display only a single column of the green line and leave the rest as black.your response will be much appreciated.
Perhaps You can help me , I would like to have several tasks to run , here as an example. I had made a IR remote that uses several channels, so if i push button 1 as an example (source) My TV goes into Source mode but i also want to see it displayed on the 0.96" I2C IIC 128X64 LED OLED: How can this be achieved
Just curious, can you record at 60 frames a second with your camera? Changing it from 30 frames to 60 frames a second may help with the refresh rate when trying to capture video on a screen like this and other you may do in the future and reduce the flicker? RUclips does support 60 frames per second videos when uploaded. But then RUclips does re-encode it to variable frame rate also, so you may need a constant moving object next to the LCD in the camera frame shot to compensate for that so it appears more like a constant frame rate. Just some ideas that might help with recording future displays. Also an updated Arduino board using the 2560 chip might help with period icing faster frame rates on the LCD/OLED displays, they are fairly cheap these days but I don't remember what the 2560 board is called.
It would be nice to use a DSP to feed the oled ntsc or pal live video so we could make nice diy goggles. Nice vid, I think the type cut off with 3d box may be clipping path overlay border?
I bought a similar display a while ago,and could never get it working..Maybe I'll dig it out,and give it another shot,after I (re-)watch this video. It's odd that the pins have I2C-like labels(SCL,SDA),when it's an SPI interface.
+TheDutyPaid You'd have to decode the composite signal into RGB first. Then squirt the data very quickly over SPI - the flat colour boxes were being drawn at 30fps so it should be fast enough. I guess it could be done. But 96x64 pixels is pretty low resolution telly!
+TheDutyPaid An Arduino wouldn't be able to handle the data fast enough. You'd need a much faster ADC than what is built in, plus significantly faster processing to RGB. The 30fps was only for square boxes not arbitrary graphics.
+gamerpaddy What's wrong with the CH340? I have sort of gone off FTDI after how they are handling the clone chip issue, but have yet to have any issues with CH340 UARTS - they seem to just work without any hiccups or issues, and are a great price.
nothing is wrong with them, but the 16u2 is an microcontroller, and sometimes i just need to use it as an HID device (Joystick for example) the ch340 cant do. a 32u4 (micro pro micro and leonardo) would do the job too, but its also more expensive. just a few bucks, but that makes the difference between having one or not.
Good point there... was wondering if that was your application :) On the topic of HID, have you had a look at vusb for doing USB emulation on attiny85s and atmeta328? Or is that too processor intensive/restrictive?
Those screens will be hard to capture on video LCD is much nicer in that respect :) Library does not seems to be fast not sure what was the speed of the SPI and the microcontroller. The LCD I use has about 12x higher resolution but I run the SPI at 20MHz and the microcontroller is more powerful and also running at 40MHz. I still can not imagine this library to be that optimized and is probably using all the resources of the micro while running and that will not be the case if you want to build a real up that will do way more than run the display. I'm sure the colors look great since it is a organic LED.
I just got a similar display. The rotating cube you show looks quite disappointing. I know that the correct way to do a faster frame rate is to use double-buffering (or even more), and have a VSYNC interrupt send the next frame on a fixed clock interval. Probably with Arduino sandbox this would be difficult to implement unless you implement the interrupt handler to do all the frame buffer copying. Another thing you could try is the Zephyr RTOS, which supports multi-threading.
I don't think VSYNC is necessary. You can have one task showing ONLY the differences between frames, reducing I/O. For 30FPS, for example, a 33.33msec sleep is needed between frames. But if it takes 5msec say to work on showing the frame, then you sleep for 28.333msec. You can calculate this easily be grabbing time at various places to determine how much to sleep. Yah, I would avoid Arduino sanbox and go to an RTOS, like Zephyr.
Has anybody seen a datasheet on this type of Arduino Uno boards? I am wondering for years what the KEY_H and KEY_L buttons are for - even probing them didn't lead to any results.
+Andre Klärner I Think you have to use their jumpers that are right next to them. They are labled Key_H and Key_L so they might be a pull up and a pull down switch each.
But would that cause a noticeable flicker in the *drawing* of the display? I would think it is the sheer amount of data the little 8 bit micro has to process, and the SPI speed that is the issue there. If Julian were to use a Arduino Due or a cheap STM32, it would probably be a lot smoother. Is the Arduino Mega going to make much different here... it's main benefits would be more memory (SRAM & Flash), not sure if the clock speed is much higher?
Julian, Thanks for the very prompt reply. I've checked the web and can't find any reference to this problem - could be me but I don't think so, I'll check again. The examples appear at the bottom of the list in a folder marked "INCOMPATIBLE" and the library is nowhere to be found. I used the library manager so I will download an earlier version and see if that works. Regards Alan
Most likely the code, sorry sketch was written for a larger screen, as is the most common fault of coders who do not provide alternative scaling sketches or allow some globals for manipulation in the header.
+Parker „Moviemaster“ Belcher It's because Intel can't bring us CPUs with enough power to convert 1080p video fast enough. REALLY DISSAPPOINTED!!! And don't tell me, that with GPU encoding it's much faster. It is, but it does not use all H264 featues of the codec standard and the quality is comparable with MPEG4 ASP (DivX, XviD, etc.) or even MPEG2. Just forget to encode low bitrate video in good quality via GPUs!
If you put a little drop of water in the screen it magnifies and you can see the pixels
'Clipping' refers to the suppression of graphic data that falls outside the display area, i.e. being able to draw off screen without causing problems. If you write to screen memory or to a back buffer, if the screen is double buffered, and part or all of the data you are writing is outside the bounds of the buffer/screen display, the hardware needs to be able to ignore that part which is not in the screen buffer or video RAM without it causing problems, for example overwriting other parts of RAM that are adjacent to video RAM or the back buffer. Back buffers or double buffering is a method of producing flicker free, smooth graphics on a display. The idea is that you have a second RAM area in which you write all your display data to, i.e. text and/or graphics, then copy the freshly re-drawn image to video RAM. In many video systems you are simply required to write to a single hardware register which swaps the front buffer with the back buffer.
The Clip Range test is likely ensuring that drawing off the edges of the display works properly and doesn't bog down the processing. It's fairly common in games programming to do a similar rendering test because drawing off edges wastes time.
I think you need to check the library to see if you can specify the screen resolution of your display. It looks like the library is using more pixels than you've actually got.
Clear, Concise, Detailed, Informative and Entertaining. Thank you.
I love your vids, brother but you GOTTA find a screen capture program.... haha
+mnelson10000 He he. I'm more of a camera in front of screen, microphone in front of speakers kind of guy.
Agreed! Camstudio is free and you can still narrate with your mic.
+Julian Ilett It's the best screen capturing program. Free, doesn't eat up the CPU, doesn't lag. Beware of the Sun :D
+MrOpenGL OBS is actually better. 60 FPS without problems, directly to mp4 H264.
it's funny how excited we are about such old technology
Try using an RTOS like Zephyr. One task can create frame buffers, paint them, and hand off to another task to show them. The task that shows them need only send to the OLED the differences -- reducing the I/O substantially. You can also crank up the SPI baud rate higher and higher until things break down, and then back off. For example, 2Mbps would be a good goal. The display can handle up to 6Mbps probably. I would use 8 frame buffers or so. Animations that don't have a lot of complexity are easier to do fast. For example PONG, or text telemetry. Rotations requires sin/cos floating point or a very fast fixed-point library. Also, for a good physics model, you need Quaternion math to avoid gimbal lock.
Reminds me of the pixel layout on colour television displays. They couldn't had used a PenTile Matrix layout?
+douro20 Only Samsung cheats this way to save 1/3 LEDs in the display.
Pentile is similar to the 1/2 pixel per scanline offset.
What is that Arduino clone you are using? The male headers look like a a very useful feature.
+Samuel Doye Was wondering the same. Both pins and sockets! Want one!
+HillOrStream Have a look for 161883302798 on eBay - it's probably not from the same seller, but it is the same type, you need to solder the header pins on yourself.
hi there, its a very good video. I need to use the same display as a tiny light source in a project. you mentioned that every pixel is addressable, how is that done, and how can we display only a single column of the green line and leave the rest as black.your response will be much appreciated.
Perhaps You can help me , I would like to have several tasks to run , here as an example.
I had made a IR remote that uses several channels, so if i push button 1 as an example (source) My TV goes into Source mode but i also want to see it displayed on the 0.96" I2C IIC 128X64 LED OLED:
How can this be achieved
Just curious, can you record at 60 frames a second with your camera? Changing it from 30 frames to 60 frames a second may help with the refresh rate when trying to capture video on a screen like this and other you may do in the future and reduce the flicker? RUclips does support 60 frames per second videos when uploaded. But then RUclips does re-encode it to variable frame rate also, so you may need a constant moving object next to the LCD in the camera frame shot to compensate for that so it appears more like a constant frame rate. Just some ideas that might help with recording future displays. Also an updated Arduino board using the 2560 chip might help with period icing faster frame rates on the LCD/OLED displays, they are fairly cheap these days but I don't remember what the 2560 board is called.
It would be nice to use a DSP to feed the oled ntsc or pal live video so we could make nice diy goggles. Nice vid, I think the type cut off with 3d box may be clipping path overlay border?
What if you remove that 50ms delay on the 3D cube loop?
Is is me or the 1080p video seems to be a bit blurry/pixelated? The bitrate seems to be lower than usual
+Nicnl It's a new feature in RUclips. Pretending to be 1080p in the settings but it actually is 720p. That's why marketing should be forbidden by law.
I bought a similar display a while ago,and could never get it working..Maybe I'll dig it out,and give it another shot,after I (re-)watch this video.
It's odd that the pins have I2C-like labels(SCL,SDA),when it's an SPI interface.
+PhattyMo And,It's working! :)
+PhattyMo yay, result :)
The physical layer of I2C and SPI (and many others) is exactly the same.
Could you use this to show composite signal from a PS1?
+TheDutyPaid You'd have to decode the composite signal into RGB first. Then squirt the data very quickly over SPI - the flat colour boxes were being drawn at 30fps so it should be fast enough. I guess it could be done. But 96x64 pixels is pretty low resolution telly!
+Julian Ilett would it be better to start with a component cable?
+TheDutyPaid An Arduino wouldn't be able to handle the data fast enough. You'd need a much faster ADC than what is built in, plus significantly faster processing to RGB. The 30fps was only for square boxes not arbitrary graphics.
useful video. btw where did u buy this Arduino uno board with icsp connector ( aka idc 10 )? can u share link, please
He couldn't had made the library to use the existing SPI lines on the Uno R3?
Try using a more powerful Arduino for this. I want to see this screen's full potential
Is this useful header design board available with 32u4 chip? or 328 with 16u2 usb-serial chip? im not happy with ftdi or ch340.
+gamerpaddy What's wrong with the CH340? I have sort of gone off FTDI after how they are handling the clone chip issue, but have yet to have any issues with CH340 UARTS - they seem to just work without any hiccups or issues, and are a great price.
nothing is wrong with them, but the 16u2 is an microcontroller, and sometimes i just need to use it as an HID device (Joystick for example) the ch340 cant do. a 32u4 (micro pro micro and leonardo) would do the job too, but its also more expensive. just a few bucks, but that makes the difference between having one or not.
Good point there... was wondering if that was your application :) On the topic of HID, have you had a look at vusb for doing USB emulation on attiny85s and atmeta328? Or is that too processor intensive/restrictive?
+Peter Feerick i havent used vusb yet. mostly im doing the HID descriptors by myself, depending on what i need.
Those screens will be hard to capture on video LCD is much nicer in that respect :)
Library does not seems to be fast not sure what was the speed of the SPI and the microcontroller. The LCD I use has about 12x higher resolution but I run the SPI at 20MHz and the microcontroller is more powerful and also running at 40MHz.
I still can not imagine this library to be that optimized and is probably using all the resources of the micro while running and that will not be the case if you want to build a real up that will do way more than run the display.
I'm sure the colors look great since it is a organic LED.
I just got a similar display. The rotating cube you show looks quite disappointing. I know that the correct way to do a faster frame rate is to use double-buffering (or even more), and have a VSYNC interrupt send the next frame on a fixed clock interval. Probably with Arduino sandbox this would be difficult to implement unless you implement the interrupt handler to do all the frame buffer copying. Another thing you could try is the Zephyr RTOS, which supports multi-threading.
I don't think VSYNC is necessary. You can have one task showing ONLY the differences between frames, reducing I/O. For 30FPS, for example, a 33.33msec sleep is needed between frames. But if it takes 5msec say to work on showing the frame, then you sleep for 28.333msec. You can calculate this easily be grabbing time at various places to determine how much to sleep. Yah, I would avoid Arduino sanbox and go to an RTOS, like Zephyr.
What's it's power consumption? Might get one
Has anybody seen a datasheet on this type of Arduino Uno boards? I am wondering for years what the KEY_H and KEY_L buttons are for - even probing them didn't lead to any results.
+Andre Klärner I Think you have to use their jumpers that are right next to them. They are labled Key_H and Key_L so they might be a pull up and a pull down switch each.
Thats what 8 thought - but I cannot find what they are connected to - neither ground nor VCC are getting connected when I press them.
The image quality of your camera is awesome. (Even if the focusing behavior isn't perfect.)
Any links to the code? and, what board are you using? doesn't look like my UNO boards.
with your complain about the rotating cube. you did notice the delay(50) statement in the code?
But would that cause a noticeable flicker in the *drawing* of the display? I would think it is the sheer amount of data the little 8 bit micro has to process, and the SPI speed that is the issue there. If Julian were to use a Arduino Due or a cheap STM32, it would probably be a lot smoother. Is the Arduino Mega going to make much different here... it's main benefits would be more memory (SRAM & Flash), not sure if the clock speed is much higher?
Hey Jullian i wonder how it will work with pictures from a SD CARD?
+joseph chrzempiec (josephchrzempiec) I'm sure it could be done, but the display is ultra-low resolution, not really suitable for stills or movies.
Awesome thank you.
Where to buy it ? No link ?
Good work as usual bud.
How to camera?
what is the price? and the exact name? or Amazon/ebay/aliexpress link?
+Noxmiles Full details in this video: ruclips.net/video/YNPtMR0e6I4/видео.html
+Julian Ilett thank you
Does this work with the esp32?
The only thing is that it doesn't have the buffer which makes it better
Interesting - Just installed the UCGlib and it appears incompatible with Arduino 1.8.1
Oh wonderful (said sarcastically). That's what I like about analogue electronics - none of this compatibility nonsense :)
Julian,
Thanks for the very prompt reply. I've checked the web and can't find any reference to this problem - could be me but I don't think so, I'll check again. The examples appear at the bottom of the list in a folder marked "INCOMPATIBLE" and the library is nowhere to be found. I used the library manager so I will download an earlier version and see if that works.
Regards
Alan
It wouldn't surprise me if Oli Kraus fixes his libraries pretty soon - he's always been very responsive.
Most likely the code, sorry sketch was written for a larger screen, as is the most common fault of coders who do not provide alternative scaling sketches or allow some globals for manipulation in the header.
Thank you very much, it really helped me alot.
Disappointing the UcgLib doesn't have a frame buffer.
I wish I could buy this kit
Awesome.
that was awesome
I use a mobile cameras internal lense to see pixels...
Arduino IDE 1.6.8 is pretty flawed indeed. I'm still at 1.6.4 waiting for a better update (like a lot of people).
Thank you so much. The adafruit one, is not that complete.. thanks!!
:) cool :)
"S-R-C Directory" it stands for source and is also pronunced source XD
+fredlllll Do you really think that Julian doesn't know this :)
no hd... damn it
+IscleGaming | ZefaCraft Please watch it again in a little while, when RUclips has finished rendering the video into full HD.
Julian Ilett i've already watched it hahaha but i can't see the screen details... will have a look a few hours later :) BTW, good video!!
Omg that display is 20$, its ridiculous!
Looks like standard RGB-Subpixel layout. None of this fucking Samscum-Pen-Tile cheapo rubbish.
good old 360p
+Parker “Moviemaster” Belcher Now in full HD
+Parker „Moviemaster“ Belcher It's because Intel can't bring us CPUs with enough power to convert 1080p video fast enough. REALLY DISSAPPOINTED!!! And don't tell me, that with GPU encoding it's much faster. It is, but it does not use all H264 featues of the codec standard and the quality is comparable with MPEG4 ASP (DivX, XviD, etc.) or even MPEG2. Just forget to encode low bitrate video in good quality via GPUs!
HEY,REPLY TO ME!
no
Not first . Bugger
100th
me first