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.
'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.
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.
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? RU-vid does support 60 frames per second videos when uploaded. But then RU-vid 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.
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.
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
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.
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?
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.
+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.
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.
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.
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.
+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?
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
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.
+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!
