This one change made Arduino run at 27.5361 FPS

[@upir_upir]

Do you like the video? Please consider buying me a coffee ☕, thank you! www.buymeacoffee.com/upir

[@astersfun]

Awesome! That speed and UI is great! First time I've seen that simulator too. Might have to try that for my next project.

[@upir_upir]

Thank you, I´m glad you like it and good luck with your next project!

[@philsponsel3824]

Wow! The Quality of this Tutorial/code review is on another level, thanks! Please do more!

[@upir_upir]

Thank you, Philipp! I do acually plan to record more videos soon, stay tuned! :)

[@ShamanthS13]

This ongoing project is pretty awesome and inspired me to get going with some creativity in my own project. Thanks for the videos!

[@upir_upir]

That´s great to hear, thank you for your comment and good luck with your project! By the way, what is the project about?

[@LimitedWard]

A couple more optimizations that you can try: 1. It looks like you write nothing to the last page of vram, so you should be able to skip it entirely (i.e. change your while loop to end on page 6) 2. You can unroll your loop to avoid any if-statements and reduce costly branches. Edit: I just tested both of these optimizations out on WOKWI and got very promising results. 23 FPS MINIMUM on the simulator. I'd test it out myself for real, but I don't have the hardware. I'm assuming that would net you >30 FPS consistently on real hardware. Here's a wowki project with the optimizations applied: 330316460209472082

[@jmdeejay]

Quick tips: - Use functions. :) It does not make your code faster, but it is way cleaner, readable & maintainable (no need to change the code at 4 different places) - Use less global variables. Use locals & constants. Not everything needs to be global all the time. Here are some additional improvements I made: - I used the lookup table trick (for sin/cos calculations) also for the lines & texts. I don't know why it was only used for the pixels. - I only recalculate & redraw, if the potentiometer value has been changed. - Fixed the boundaries code so that the ticks and labels don't disappear too soon. (We need to use all 7 pages for this fix) We can now show 4 labels at the same time. I'm now running at >23 fps when rotating and >95 fps idle. :) wowki project cleaned up: 330369650565055058

[@upir_upir]

Thank you for your comment and suggestions, those are great! Definitely something to try next time.

[@JamesHBall]

@@upir_upir Made some more changes to these optimisations and it's now at 25 fps minimum on the emulator :) Mainly just getting rid of anything that is computed multiple times. Wowki project id: 330533008303981140

[@upir_upir]

@@JamesHBall You are crazy good :)

[@Damicske]

@@JamesHBall That analog read, isn't it handier that you do that at the start of the loop and maybe if the value didn't change you just skip over everything :) it's a oled screen and has a buffer of 8 pages ;)

[@jmdeejay]

@upir In order to avoid the "blurring" happening when resizing down the image 13:22, just change the interpolation to "Nearest neighbor" instead of the default value "Bilinear". You'll get a crisp resize without pixel loss this way. :)

[@upir_upir]

You are absolutely right! Thank you for your comment. I will surely use this next time :)

[@saeedrakhshani-s4x]

You made me subscribe for the first time! Respect for all your great videos 👍👌

[@upir_upir]

That´s great to hear, and thank you for your nice comment!

[@ericoesterle2427]

Great optimizations! I'm wondering if using the three-parameter call to the SPI initializer might be even faster; the version you're using may use software SPI under the hood in u8glib. Here's the 3-parameter one: U8GLIB_SSD1306_128X64(uint8_t cs, uint8_t a0, uint8_t reset = U8G_PIN_NONE)

[@upir_upir]

That´s a great suggestion and you might be right. I will try your 3-parameter initialization to see if this makes any difference in performance (i.e. if I´m really using software SPI instead of hardware SPI). I will update this comment once I try it.

[@zyeborm]

@@upir_upir I moved from software to hardware SPI in one of my projects and hit 160FPS instead of 30ish I think it was on an esp32. This is the init #define OLED_CLK D5 //sck #define OLED_MOSI D7 //sda #define OLED_RESET D2 //Res #define OLED_DC D1 //dc #define OLED_CS D0 //csU8G2_SH1106_128X64_NONAME_F_4W_HW_SPI u8g2(U8G2_R0, /*cs*/ OLED_CS, /*dc*/ OLED_DC, /*reset*/ OLED_RESET); This is the draw. u8g2.clearBuffer(); // clear the internal memory u8g2.drawStr(posx,posy,outdata); // write something to the internal memory u8g2.drawFrame(0,0,display_width,display_height); //draw this last as the string drawing also draws "black" pixels and you can get shadows in the box. u8g2.sendBuffer(); // transfer internal memory to the display Much simpler graphically than what you're doing of course. My other suggestion is set a LED/pin to on for various chunks of your code, then off after and use a scope to look at the % of time you spend in any given function so you can ensure you are spending your time optimising in the right spots.

[@retronexusio]

oh my god this channel is fantastic!!! i cannot wait for more content!

[@upir_upir]

Thank you, I´m glad you like it! If you have a request for any specific topic for my future videos, please let me know.

[@Leif_YT]

Thank you for sharing. I just discovered your channel and it's super helpful and gives nice inspiration. For someone like me, who never "learned" programming in a traditional way and just learns it by trial and error and the growing experience from each hobby project I do it was also a great example on using arrays. 👍

[@upir_upir]

Thank you for such a nice comment. Truth be told, I have never learned pogramming the proper way either. I´m still learning as I work on new projects, and by "learning", I of course mean copying snippets of code from others. I hope it´s not that visible :)

[@toddroles3234]

Congrats on your project making it on the official arduino company weekly newsletter. This is the first time I can say I built something before it came out in the newsletter

[@upir_upir]

Thank you, Todd! Truth be told, I wasn’t expecting that so many people would be interested in this project, it was a big surprise.

[@VoeViking]

Learn something today, happy. Very nice.

[@upir_upir]

That´s great to hear, thank you!

[@jankomuzykant1844]

Works very nice, like it, respect :o)

[@upir_upir]

Thank you, Janko!

[@davelordy]

Looks really nice ! The bigger knob works great too (no indicator helps).

[@upir_upir]

Thank you. I agree with the knob, it´s just much harder to find a knob without the mark... but this one is great.

[@g_rr_tt]

Hey, I just want to say thank for sharing this knowledge for free. I'm a mechanical engineering student with an interest in electronics; needless to say, I don't have enough time to organically learn this stuff through traditionally "read a book, then learn from your mistakes." Without people like yourself, I would have never of bought my first microcontroller and programmed my first OLED. Once again, Thank you.

[@g_rr_tt]

Also, I'm using 128 x 32 I2C display and with these changes I'm managing to get around 33 FPS

[@upir_upir]

Thank you very much for your nice comment, I really appreciate it! Good luck with your projects and please feel free to share your creations, I would love to see where this goes.

[@davidkempton2894]

Awesome! Thanks for sharing!!👍

[@upir_upir]

You are welcome, David! I´m glad you like it.

[@НикиГенов-ь1ф]

Great optimization, thanks for the video!

[@upir_upir]

You are welcome, thank you for your comment!

[@BooBar2521]

Stunning. I will keep your project in mind if I need a nub in my project with display 🔥🔥🇩🇪

[@upir_upir]

That´s great to hear, and hope you will find a good use for the knob in your future project :) Greetings to Germany!

[@miege90]

Nice Project, I really like the look of it. I'd recommend to buffer the displayed value and only update it / rerender when the measured value deviates by a value of more than 0.1 or 0.2. This way you should be able to get rid of the jitter.

[@miege90]

Also your code would probably run much faster if you use a data structure which makes use of the pages. if you know which dots/lines/text to draw in which page beforehand you do not have to have multiple loops inside a loop so the execution time would roughly drop from quadratic to linear. Also, don't loop over all tickmarks, calculate their angle and determine wether they are inside the screen. You already know the potentiometer value, so you can do it the other way round. Calculate the first tickmark on the screen, for example if the potentiometer is 50% you know you only need to draw 35 to 65, no need to do all the calculations for the other tickmarks. This also saves you branches inside a loop, which can be painfully slow...

[@upir_upir]

Thank you for your comment and proposed changes. Right now, I´m happy with the (almost) 30FPS, but I will consider your ideas for next projects when I struggle with performance (which is pretty much always :)

[@temyraverdana6421]

Thanks, an incredible lesson!

[@upir_upir]

Thank you, I´m glad you like it!

[@Mike98006]

I'd pick a rotary encoder over a potentiometer - this would eliminate the jitter on the display

[@upir_upir]

Agreed, it would make more sense, but I wanted to make it as simple as possible.

[@pzellerphoto]

Great job,very well done and explained

[@upir_upir]

Thank you for your comment, I´m glad you like it!

[@Diamonddrake]

I love this effect, would look sweet on a high end stereo! These little oleds burn in hard though if you leave them on all the time. I used them for thermometer displays and they all turned into garbled messed after a year

[@upir_upir]

Thank you for your comment. I was actually curious how long would it take for the OLED to burn in the pixels. One year sounds like quite short time...

[@nikthefix8918]

@@upir_upir Yes and PMOLED is different from AMOLED in that regard but in that case you might be comparing monochrome with colour so the wear effect is different too.

[@upir_upir]

@@nikthefix8918 I thought that original comment talked about the monochrome PMOLED. That said, I have a new PC with AMOLED, and I worry about burned pixels a lot...we will see

[@nikthefix8918]

@@upir_upir I think is is still an issue that blue pixels degrade faster than red, green so the 'burn-in' is largely due to a lack of blue when there is an illuminated region - yellow ghosts when displaying white for example. Manufacturers are claiming that this is getting solved so I shouldn't worry about it and I would guess the TV's will have a usage related compensation algorithm. Hope so, as they know exactly what will happen over time with a particular model. So we shouldn't call it burn in but degradation leaving certain pixels dominant. If the manufacturers apply appropriate wear levelling then I imagine that the display would simply get dimmer over time. The long term reviews of AMOLED equipped laptops are very encouraging but I'm sure it will will considered an intermediate technology in the near future. PMOLED for Arduino is a different matter of course. Especially as many experimenters run 3.3V limited devices with 5V Uno/Nano. Screen saver (blank screen is a good idea for sleep).

[@rraftek]

@upir - fantastic tutorial! You’ve inspire me to create universal modbus - transmitter simulator (:

[@upir_upir]

That´s great to hear! Feel free to share links to your creation, I would love to see it

[@StephenHoldaway]

The repeated drawing for each page is a compromise to save RAM, but the entire buffer is only 1KB, so if you don't need that RAM for anything else you can change the number of pages and only draw once (or twice to reduce RAM use to 512B). It also looks like you're using `int` a lot, which is 16-bit on AVR. For any values that can be 0-255 or -127-128 you'll halve the number of instructions for any operations on those by using an 8-bit type (uint8_t or int8_t), since the CPU can only work on 8 bits at once. Using floats on AVR is also a big slow down, but trickier to substitute here in a beginner friendly way

[@upir_upir]

Undestand about the RAM usage, it makes perfect sense. Also, good point about using 8-bit integers when not needed to use 16-bits. I have used "byte" type for the lookup arrays, but I guess I could use it in more places as well. Thank you for your comment!

[@r3martinez]

Skvělej projekt!

[@upir_upir]

Díky díky! :)

[@miriamramstudio3982]

Great video. Thanks

[@upir_upir]

Glad you liked it!

[@electronics-by-practice]

Nice project , you can mount the knob on a stepper motor and use it as encoder , the result will be a remote controlled volume knob.

[@upir_upir]

Thank you. Good idea with the stepper motor. I might try it next time.

[@DeLewrh]

Do you speed up your videos? The speed is fine but somewhat uncomfortable, tried setting it to x0.75 here on KZbin but it wasn't close to natural. If you've sped up a video, please stick to multiples of .34 so that x0.75 can be used to revert it.

[@upir_upir]

Not really, but I talk quite fast and I cut out the awkward pauses and breathing. I need to find a way how to not sound uncomfortable while making some pauses. Hope it will be better next time!

[@DeLewrh]

@@upir_upir that's fine! I figured it might've just been fast talking with cuts. It really is fine but I just found it hard to follow at times.

[@RomainPetitAsTokazio]

Really nice rendering! In old video games the costly sin/cos computations were cached in an array to optimize it, maybe another optim to try

[@upir_upir]

Thank you! As for your suggestion, the code is already using lookup tables for sin/cos calculations, although not all of them. You might probably get one or two extra FPS if you use lookup tables for all calculations.

[@nikthefix8918]

Indeed, and using lookup tables of legal quadrature sequences to debounce the encoder is great rather than multiple conditional branches. Even logical XOR and STATUS,Z in ASM is worth doing if things are critical. I always used to use hardware debouncing using filters and schmitt triggers but software always seems superior if tuned correctly, plus, the spurious data which the hardware approach aims to filter out contains useful cues for fast scrolling and interpolating for that 'accelerometer' style of encoder navigation.

[@mungewell]

You may be can pre-compute, an array for the dots, an array for the lines and OR them together. Reflect around the center axis to reduce memory required.

[@mehdik348]

Super duper new useful idea tnx...

[@upir_upir]

Thank you, Mehdi! I´m glad you like it.

[@hatkidchan_]

You also could create structures for pixels, lines and text blocks instead of messing with indices

[@upir_upir]

That´s actually great idea. I will surely use structures in next project to make it more readable. Thank you for your suggestion

[@AntonioNoack]

I would imagine the text modifying operations like sprintf and divisions to take quite a bit of performance as well, so it might be helpful to only execute them once per frame (or once per change) as well.

[@upir_upir]

Agreed. Divisions and floating point operations are slow, and there are some places where integer math would be sufficient. I did stop with the optimizations when I have reached 30 FPS, but I´m sure you can speed it up even more.

[@szaszm_]

Just a tiny detail: I was wondering why you're using 2D arrays instead of 1D arrays of structs. This would allow naming of the points and coordinates instead of having to remember the meaning of the second index, and I think it would generate the same assembly code.

[@upir_upir]

That´s a very good point. I´m actually using structs in my current projects for the mentioned reasons. It´s much easier to understand inside the code. That said, thank you for the suggestion!

[@marc_frank]

great work :)

[@upir_upir]

Thank you, Marc!

[@usefulelectronics]

Nice tutorial I absolutely like your work !! I think if you had an ADC with better resolution, you be having more stable system.

[@upir_upir]

Thank you for your comment, I´m glad you like it! I agree, the readings are still wiggling a little bit, a more stable readings would probably look better..

[@zyeborm]

Finer resolution isn't the problem. Less noise is the problem, that can be somewhat accounted for in software by smoothing. Using a pot is inherently a noisy proposition however without great care and expense in selection (and even then).

[@upir_upir]

@@zyebormAgreed. I´ve pretty much only used potentiometer for a simplicity, but it would probably make more sense to just replace it with a rotary encoder.

[@tomaszszczepaniak2101]

@@upir_upir just make average of last 4 measurment it still will be damn fast but you will not see this wierd jumps when not touching knoob, Sory for my eng hope you understand ;p

[@ah.l]

impressive design.

[@upir_upir]

Thank you!

[@stefanguiton]

Great video!

[@upir_upir]

Thank you, Stefan!

tohle je tak skvělý

[@upir_upir]

Díky, to mě samozřejmě těší!

[@MarinusMakesStuff]

I wonder if it would be feasible to change the board to an ESP32 or STM32 to also help speed up the framerate? On top of that, I noticed that common Uno's have gotten more expensive than the STM32. I see some people around me change to the STM32. It does take a little getting used to, but once they changed, they said they didn't want to go back. There are some nice development boards available and these are also usually smaller than the Uno's.

[@upir_upir]

Definitely. Replacing the UNO with anything more powerful would surely increase the FPS a lot - like STM32, ESP32, Arduino Mega, Teensy, etc.

[@duckyblenderold]

@@upir_upir i'm gonna try this without the optimizations on the raspberry pi pico (in micropython) shortly, I'm gonna keep you updated :)

[@quantumfluctuations1]

very cool

[@upir_upir]

Thank you!

[@S98dragon98S]

looks nice

[@upir_upir]

Thank you!

[@lmtythis]

looks like it could use some filtering, so the values don't wander around so much. cool project

[@upir_upir]

Thank you! Yep, filtering would surely help. Any ideas or links for something that might be helpful related to that topic?

[@lmtythis]

I would just create a simple condition to prevent refreshing if the value is within a threshold interval. Update the display only If new_value < old_value -tolerance or new value > old value + tolerance

[@lmtythis]

Or averaging some readings

[@DanielMelendrezPhD]

@@upir_upir What about using the RunnigAverage library from Rob Tilliart?

[@upir_upir]

Good idea, thank you for your recommendation, I might try that.

[@90sboy22]

Hey! Do you do commissioned Arduino projects?

[@upir_upir]

Hi, sure, please send me an email. My contact information is in the about section of the KZbin channel. Thank you!

[@chrisliddiard725]

"This one change.... " LOL Still its useful to see how the page swapping works on these Oled screens. I was thinking the arrays could be calculated at setup(). or calculated outside the prog before hand for each page and then held in a static array. Also the pixel / lines screen changes could be limited to say 5 screens based on the decernable pixel difference. eg if above 5 screens you can't see any pixel changes why plot for 7 or 8 screens. [I couldnt tell if you were allowing for the rate of change when you turn the knob] The only thing which changes with a greater resolution is the position of the numbers. There i would have an array to rememeber the old number positions and plan the new number position. Then draw over the old numbers in black, and rewrite the new position in white. [ If your code allows, you might reserve two screens exclusively for the numbers and then swap between these when you write and overwrite, eg to avoid flicker].

[@upir_upir]

Thank you for your long comment. I agree with all your changes, and I think that all of them would allow for even better performance. I have basically stoped when I was close to 30 FPS, as I was feeling that any additional change would mean a lot of new code for only a slight performance improvement, and also because 30FPS is usually considered as "smooth".

[@mhe123321]

Maybe implementing a simple first order IIR lp filter for the angle would smooth out the measurement

[@upir_upir]

Would you perhaps have some links where I can find more info about the proposed solutions? Thank you!

[@mhe123321]

To simplify a lot: You only want to add a fraction of the difference between the current value and the newly measured value - in code this can be written as: curr_val = curr_val + (meas - curr_val) / 16 i chose " / 16 " as this i very easy to impl. in µcontrollers as it can be represented simply as a bitshift by 4 to the right such that the above code becomes: curr_val = curr_val + ((meas - curr_val) >> 4) if you want to see the resulting response from a step response google: "first order low pass filter step response" Hope this helps!

[@gtxsatria2010]

selalu yang terbaik yang anda lakukan. you are the best

[@upir_upir]

Thank you! But I had to use google translate :)

[@gtxsatria2010]

@@upir_upir yes i am sorry . salam i from Indonesia

[@upir_upir]

@@gtxsatria2010 No need to apologize, I always enjoy translating from different languages, especially when the translation makes sense :)

[@mymagicsigns]

So...out of all the changes you made, which is the one that made the Arduino run at 27.5361 FPS?

[@upir_upir]

That one change was rewriting the code, and of course, it consisted of multiple sub-changes :)

[@deathtothebeardless2959]

Try to add a while(true) around everything inside void loop(). Void loop() just calls while(true), and that call takes some ticks to do.

[@upir_upir]

Interesting idea. I will try it with the next project.

[@dip8]

hmmm... In parallel communication you send all the bits simultaneously, in serial you send all the bits through one cable. Is there anything in between?

[@upir_upir]

Actualy there is. You can have dual, quad, octa SPI communication, which is serial, but is using multiple data lines.

[@bensmirmusic]

Can it transmit midi CC? Is there a knob with tactile feedback with each increment?(with a tick)

[@upir_upir]

Yes, you can send MIDI, for example by using the control-surface library. Rotary encoder has a small tick with each increment, is that what you think?

[@LanceThumping]

Have you considered taking lookup tables to the next level? It should be possible to generate all the different images created at different positions. It's very likely that there is shockingly few when you take into account how the ticks effectively go through a cycle that repeats every 10 degrees. If storing all that in the program takes a lot of space you can add in how its effectively mirrored in that the second half of one screen will be the same as the first half of its complement reflected (something like 61 and 69). Also the blank space could probably be compressed with counts of the runs of zeros. All the text positions can be similarly precalculated as they will also have origins that are cyclical. You can likely remove all the trig functions this way. If you want it to still be easily customizable you could likely create code to generate these values via preprocessor instructions that will evaluate at compile time and never actually need to run on the device.

[@upir_upir]

I was thinking about something similar. The "image" of all the tickmarks repeats quite a lot, so you are right, if you would count all the possible options, it would most likely be some small number, and you can store those images in a memory, not having to calculate anything, drawing lines etc. That said, I have stopped with the optimizations once I was close to 30 FPS. I need to continue on other projects, since I have like 10 running all at the same time..

[@drgusman]

Are you sure about how the pages work? According to the documentation of the library the pages are totally unrelated to the display's memory pages, the library creates a local half buffer to use less ram and does only two passes and each pass is called a "page". Check the documentation about the graphic loop in the wiki at theirs github.

[@upir_upir]

I believe the documentation is not up to date, or perhaps it only shows two pages becase maybe some displays only use two pages? In this case, I´m quite sure that there are 8 pages, as the internal variable that I have defined goes from 0-7.

[@michaelmuller8877]

Bigger knobs, even better to interface with.

[@upir_upir]

Well... ehm... Let´s just forget about it :)

[@drdyna]

I have a Minidsp shd studio that has a small oled screen on it like this, I wish I could hack it to use this style of readout, it's a lot cooler :P

[@upir_upir]

Perhaps someone from the dev team would see the video and change it in the next version :) Anyway, thank you for your comment, I´m glad you like it!

[@Nordicx86]

Hmmm... But why you need update screen so many times when Changes of values a discrets? Why not change screen only when values changes?

[@upir_upir]

You are right, you can as well update the screen only when the value changes. I kept it running and drawing all the time since the Arduino is only driving the screen and not doing any other calculations.

[@motionsick]

How do I change the order of the numbers from 0 to 100. To work like a normal speed or volume dial the pot needs to be turning in the opposite direction when increasing amplitude, clockwise. I got the pot working correctly by mapping 1023, 0 instead of 0, 1023 but how do I reverse the graphics to follow the dial?

[@upir_upir]

From top of my head, I think you can do this when you are drawing the numbers, just map thsoe to a different range. This way, it´s not affecting other parts of code.

[@motionsick]

@@upir_upir thank you I was watching to tutorial last night so I will try again soon.

[@upir_upir]

Sounds good, good luck with your project!

[@pixelfrenzy]

This is great! I've been struggling with what I thought was a slow OLED the last couple of days, and your analysis of the u8glib library really helps a lot. One question: Did you try using the u8g2 library instead, from the same guy, which is much newer? Does it have better optimisations? I couldn't get it to work with my display (using SPI, but with SH1106 controller).

[@upir_upir]

Thank you, I´m glad it was helpful! I have quickly tried u8g2 library, and it was working just fine. I don´t believe you can get any better performance with UNO, since you have to use the same "page" method. However, with microcontrollers with bigger flash, you can use "fullscreen" and that should be faster. I will explore those soon and surely record another video.

[@YO2LDK]

very nice project ! if I want to start from 50 to 150 (instead 0-100), where I need to modify ? tnx in advance !

[@upir_upir]

Thank you! There is a line on the bottom of the sketch for reading the potentiometer value and mapping it from 0-1000. Just change the numbers to 500 and 1500 and you should be good to go. If not, let me know.

[@luizdanielsantos]

Write a mixed C/ASM for the Atmega and you`ll see a huge improvement. Standard library functions are sometimes slower than custom. Instead of divisions, try to use multiply and register shift. Look for Q1.15 integer fixed Point operations. Float Point os Very, Very, Very slow.

[@upir_upir]

Thank you for your comment. I´m pretty sure that having some inline ASM would help, but that´s currently outside the scope of what I can do. For now. I would like to learn as much as possible, but it´s slow.

[@Diamonddrake]

The atmega328p used in the Arduino uno doesn’t have hardware support for floating point, so fixed point would see a huge I improvement. If anyone reading doesn’t know fixed point is when you encode decimal numbers as whole numbers then do fast math and convert them back at the end. To do this you have to decide how many decimal digits you’ll use, hence “fixed point” precision. Modern hardware encodes numbers using a “floating point” precision and used completely different hardware to do math on it. Fixed point is easy to do but can be confusing to anyone who doesn’t understand how it works. (Though you don’t really need to know why it works, just that it does and the very simple rules to using it)

[@duality4y]

either you are running i2c or spi but the video overlay is wrong if it is spi because spi doesnt have sda and scl that is i2c then it should be mosi miso

[@upir_upir]

The WOKWI project uses I2C display while my "real" project uses SPI display. The code has initializations for both displays, so you can just uncomment the one that you are using. Does that make sense?

[@linciyuan598]

Is there an u8g2 version of this project

[@upir_upir]

There is not, but it should not be hard to adapt it to use u8g2.

[@xoxerxes]

Hi Upir. Did you consider eliminating any floating point arithmetics in your code? From what I have seen, most of the time spent in arduino libraries is spent on those. Like reading a giro sensor value can take something in the millisecond range using an arduino library while the actual interfacing with the sensor only take something in the microsecond range. calculating those values between 1 and 0 cost so much processing time.

[@upir_upir]

That´s a good point. I´m sure there are places where floating point math is not really needed and could be done with fixed point math instead. I will try it next time when I will optimize the code.

[@xoxerxes]

I would actually argue that floating point is necessary hardly anywhere in small to medium size embedded systems. The benefit of floating point math is primarily the huge range which can be covered by one variable however only with a certain degree of accuracy. secondarily I think its mostly for comfortable human interaction. In the end basically every sensor is providing the values in fixed point via twos-complement across certain static ranges. This can be reflected through the whole system to get rid of floating point. Having divisions truncated can easily be solved by upscaling a number for calculations to reduce forwarding errors (*10 or *100) and then downscaling to the necessary resolution. If you would use 1/1000 instead of 1/100 as number scaling, then there is even no need for numbers between 1 and 0 at all. Also it is great to see that you use wokwi. I think its a great platform!

[@toddroles3234]

I mentioned that yellow blue screen effect

[@upir_upir]

That’s right, you were the one! Thanks again 👍

[@Dsschuh]

Looks like an interesting video. However the technician speaks so fast it doesn't seem yo take a breath I have trouble following it.

[@upir_upir]

Thank you for your comment. I need to find a balance between a boring video with a lot of pauses and the one where I get comments like this. I´m still learning. In the meantime, please use the playback controls and play it at slower speed.

[@andrewferguson6901]

Yoooo what is this dial it looks great

[@upir_upir]

It´s just a dial. It´s ul to you how you use it :)

[@andrewferguson6901]

@@upir_upir yeah man but where do i get a nice dial like that. they don't carry that at your typical hardware store do they?

[@upir_upir]

The link is in the description for the video, it’s from AliExpress that ships worldwide. You can try some local hardware store as well, but it would most likely be more expensive, if available at all. I would think that you might have better luck by salvaging the knob from some old unused audio device.

[@UndercoverFerret404]

It seems like the value is not stable?

[@upir_upir]

Yep, it´s a combination of cheap potentiometer, unstable input voltage, and the wrong alignment of stars. I mean, it could use some filtering for sure.

[@browaruspierogus2182]

use round lcd / oled for better effect

[@upir_upir]

Good idea, but it would be even better to have a round display with a hole in it... but I´m struggling to find such display.

[@ArtyomGalstyan]

Now you can overclock arduino to make even more FPS.

[@upir_upir]

Do you have any link how to do that? Thank you.

[@ShinyQuagsire]

Oh I've actually worked with a display similar to this (though it was using an ARM uC and the 8080 bus, bit banged, with a much higher resolution). I ended up getting about 20fps by setting it into an upload command and using DMA to constantly stream RAM from my microcontroller to SPI. While it sent the last frame, I could begin drawing the next one.

[@upir_upir]

That´s very interesting! Are there perhaps some screenshots of your work that you could share? I would love to see it!

[@ShinyQuagsire]

@@upir_upir ok actually I mixed up two projects I did, but the solution was the same: kzbin.info/www/bejne/gHzJoqWKlrCKe8k kzbin.info/www/bejne/npiud4amjb6ep5o Bigger bit banged display used to be so bad you could watch it draw, and similar for the smaller SPI one. DMA is hard to beat though because you can get data out cycle-perfect, basically. The bit banged one required weird DMA microcode that wrote to two registers (data+rd/wr), but SPI controllers almost always have plain "here's memory and a length" DMA. The Uno might be too limited though--but I think the ATMegas and STM32s all have DMA which works nicely for stuff like this.

[@AgainPsychoX]

From my experience u8g library is just sad performance waste. It comes with great compatibly and features, but sadly the way its written doesn't work most optimal way for every display. I once had project with LC7981 240x128 display, and it was working slow and had high memory usage (buffered). Ended up writing my own library, which by default was like 3 times faster (in my specific case) and used only fraction of the memory u8g used. Of course, it requires more time and effort, but in some cases its mega worth.

[@upir_upir]

Well, I guess the performance is a price you have to pay for the great compatibility and features. Personaly, I´m quite happy with the speed for this project, and I really like the simplicity of using the u8g library.

[@unit_4001]

I don't know what's happening but it looks cool

[@upir_upir]

That still counts :)

[@aleksitjvladica.]

? What? That number is invalid! You can not have four digits after the dot!

[@upir_upir]

:)

[@aleksitjvladica.]

Yeah. The USA does different.

[@nikthefix8918]

ESP32 and Teensy users are unlikely to feel the need to optimize when using these peripherals which is a shame as this is such a good education. I occasionally force myself to use an Uno or Nano just so I can see where the bottlenecks might appear later if it develops to an ESP project.

[@upir_upir]

Agreed about the ESP32 and Teensy. That said, if you make it work with Uno, it will work with anything (well, not the attiny... )

[@nikthefix8918]

@@upir_upir Agreed although paradoxically, faster cpu's if not accounted for can play havoc with switch bounce as there's so much more time to get it wrong :)

[@hybridinnovate]

Size firmware??

[@upir_upir]

You mean the program size?

[@hybridinnovate]

@@upir_upir yes

[@upir_upir]

I will check tomorrow, but I’m nowhere close the limit of Arduino uno

[@hybridinnovate]

@@upir_upir my small project, used fully memory atmega8, and only used small code from uart, connected word))

[@upir_upir]

@@hybridinnovate you mean ATTINY85? That might be a challenge, since the memory is much more limited compared to UNO. I´m not quite sure that my program would fit, it would probably also make sense to use other library than u8g for that device.

[@rm709]

Why are your videos sped up during editing? I want to watch but it’s so distracting to me sorry

[@upir_upir]

It´s not sped up. That´s the speed I talk, but you are welcome to slow it down using the playback controls...

[@KeithOlson]

FWIW, it is *VERY* important that, if you are using pages, you change the zero position of Y to be the top of the relevant page(s). You can see that the meter needs to be moved down 1 or 2 pixels because it isn't fully within the page range. Other than that, bloddy impressive, mate!

[@upir_upir]

Thank you, Keith! Could you please clarify a little bit more how you change the zero position of Y to be on the top of the relevant page? From the screenshot in Photopea, it looks like the meter is aligned properly. Do you mean the pixels, or the top part? Thanks.

[@KeithOlson]

@@upir_upir 1. As each page is 20 pixels high, to ensure that an object lies within a page, you would just need not make sure that the top of that object lies at or below a multiple of 20. 2. Looking closer at the image at 14:39, I realized that the arc of the meter looks flat at the top because it *IS* flat at the top because of the low resolution of the screen. It doesn't need to be moved down because the top is sitting at a page boundary already. Oops. My bad.

[@sebbes333]

0:29 "I'm using the UHG library, as you can see by the number of VIRUS on my screen" :D ;P

[@upir_upir]

Sometimes the automatic subtitles are not so great :)

[@sebbes333]

@@upir_upir :D

[@ThomasBrasser1]

You should combine forces with kzbin.info/www/bejne/n6GZZWSNor5npqM (The smartknob view)! Having an extra screen like yours in his design should look really good.

[@upir_upir]

Yes, that video is gold. It´s so great that I have cancelled my plans to put a display inside the knob, I´m not quite sure if I can make it any better than this.

[@ThomasBrasser1]

@@upir_upir I think your approach wins greatly on implementation complexity, and apart from the haptic feedback, it's pretty comparable feature-wise. Would love to see a line of home/iot control panels (esphome for example) based on both projects.

[@jackcameroon8423]

Thanks for spelling Aluminium correctly. Sorry that's all I'm pointing out but I can't even tell how many times I've just became mildly agitated at listening to Aluminum.

[@upir_upir]

Actually it seems that both are correct, at least according to this page - www.merriam-webster.com/words-at-play/aluminum-vs-aluminium That said, I still prefer Aluminium :)

[@jackcameroon8423]

@@upir_upir I know I'm a bit of a Vocab N@zi. I just find it better and more uniform when compared to other elements in the periodic table. For example: Rhenium not Rhenum, Titanium not Titanum, Uranium not Uranum Noah Webster, in his 1828 An American Dictionary of the English Language, defined aluminum as "The name given to the supposed metallic base of alumina." - from you link, very helpful, thanks

[@upir_upir]

@@jackcameroon8423 Fully agree with being consistent with the periodic table.

[@motionsick]

Imperial is superior to metric

[@jackcameroon8423]

@@motionsick 1feet = 12 inches 1 mile = 5280 feet 1 mile = 1760 yards 1 pound = 16 ounces 1 imperial tonne = 2,240 pounds Also, mass and weight in the imperial system mean the same thing? Y U DO DIS? It's an unnecessary pain in the arse we all can do without. Else, people will keep calculating how many hamburgers long their washing machines are.

[@citruscampbell]

Aaaahhhh to fast feelslikeyouaretalkinglikethisthewholetimeanditisveryconfusing

[@upir_upir]

Yep, I need to slow down a little I guess...

[@A3Kr0n]

Your title sounds like Fox News clickbait.

[@upir_upir]

I know.. but I also wonder if you would click on this video if it would have some boring title?

[@reallyboringindividual]

You should ditch float math. This atmega does not have an FPU - you're doing all float math in software.

[@upir_upir]

You are correct, that might help for sure.

[@Marloniiv]

727

[@upir_upir]

?

[@duckyblenderold]

nice

[@duckyblenderold]

@@upir_upir 727 is a joke in the osu community

[@negvorsa]

...you don't know what you are doing !!

[@upir_upir]

What?