I want circular motion with progress bar.
But there is only one direction motion.
From left to right or from bottom to top.
Can be achieved via pictures and user code. Considered implemented.
I am now reviewing all of the Feature Requests, this will take some time, patience please.
Circular progress bar - previously requested - carried forward
An example of picking and choosing what to send
Obviously, if old pixel is the same color value of new pixel - there is no need to update - it is already that color, but I am certain that you could probably get away with +/- 2 color values in each Red and Blue channels and +/- 3 color values in the Green channel - so if new pixel color is "close enough" you can skip sending its update and save some time and bandwidth. So just need to write the functions
Well for MCUs I prefer the Intel Edison - no lack of resources, but I will also be trying it out on Iteads ESP-8285 chip PSF-A85 (wifi) and the STM32F103
I have a OV7670 640x480 coming, so I will let you know how it works out. But in fairness I am doing mine on a 3.2" 400x240, so the 3.2" will be 4x faster than the 7.0" as it only has 25% of the amount pixels to be concerned with.
Which microcontroller? Rasperry pi, arduino mega, smt32?
Perhaps instead of trying to use a full screen, you use a smaller portion of the screen to achieve a faster rate. Perhaps instead of high resolution, you use 1/3 and stretch each pixel 3x3. So an example that might fit on a 7.0" Nextion ...
Leave an 80px strip left for touch functions, use 720x480 for cam picture
Crop and Reduce cam image to 240x160
convert 240x160 colors from RGB to 565
Then for each pixel send command to draw the square 3x3 with pixels color
draw 80,0,3,3,63443 (this is sent 240x160 times)
So you will actually achieve a "zoomed" portion of the picture from the cam in view.
To achieve what you want, you will have to decide how much of cam is in view
You would have to decide, how much stretching can be done that you find acceptable
You will probably have to pick and chose segments to update this round (like an MPEG does)
But technically, you can get a representation on the screen.
:) Thanks for your replies.
115,200 baud will accomplish some, though I haven't tested what frame rate. Graphic programming will always require smart usage. So like an MPEG movie, you make choices what is being updated, but certainly not the whole screen, just what is suppose to be in user's focus. Just a historical point - graphics were introduced to the Internet around 1992 and average modem speed was 2400 baud. Top of the line modem in 1992 was a 14400 and maybe the 19200 was coming out. So 115200 was unheard of unless you were hard wired into the backbone over a T1 line. And even then the T1 line was divided into 57600 segments, so you needed an adapter (I think it was an ISDN) to combine two lines to get up to 115200.
You're certainly not going to get 30 fps.
Here is something for you to think on.
A non Nextion HMI display requires you send the picture to the display
- this is 1 data wire in over Rx/Tx ... so similar to an SPI display but slower data rate.
Therefore, you do have the capabilities with Nextion, but Nextion has more abilities so that not as much has to go over the wire (stored pictures) but these extras do not prevent you from sending a picture and setting the pixels yourself.
A bigger question might be whose responsibility to program your project. In an SPI display, there is no HMI Editor - responsibility is all up to the user to have their program use the display as they see fit. The fact that the Nextion display has an HMI editor has never prevented you from using it like an SPI display and allows you to still use it as generic display as well as HMI functions. So Nextion you have both.
For example 115200kbps speed is it enough?
Respectfully, the shortcoming is from ... ? Perhaps you have to dig deeper.
- a cam could technically be done as well. But what are the technical specs of the cam?
- jpeg output at 640x480?
Cam captures a picture
- picture probably requires resizing and cropping
- picture format must be converted to be compatible with the display
- picture must be sent over the wire to the display
This is a shortcoming.
And camera in does not work.
Maybe support 7" screen in the near future? Cam and progress?
@Blue, how do you mean?
- everyone can look up the specs of the STM32F030C8T6 that is on the back of the Nextion.
Imagine for a moment you could finally achieve transparent pictures, but you had to choose to get rid of half your other command - what would you ditch. You have to think about it. 8K is shared RAM for both the firmware and your project - so when the firmware gets bigger, there is less for your project, or something old and not wanted has to go.