I’m working on a dashboard for a motorbike, I’m planning to use a blue pill to read the data I need from CAN-BUS and a 128×64 graphic display. Other than this basic setup I might use some LEDs and maybe a couple of buttons, nothing else.
In your opinion how many frames per second can I expect on my display with this setup?
Thanks in advance for your help!
p.s. I thought to use a LCD 128×64 LCD “dots” display because I need it to be clearly visible even in sunlight, but do you think that other (maybe bigger) displays could be better?
https://www.google.com/search?q=LCD+128×64
Performance will be determined by the graphics library and how (if) the display is buffered, the protocol used, and what else the uC must do, such as retrieving and parsing the CAN bus.
Frames needs to be put into context… if you buffer the display pixels, send only changes, use DMA if supported…. my iCrystalBall is in Apple’s repair center for a new LiON battery…
Ray
Thank you for your answer, you are right, there are many variables to consider, It’s a pity that your iCrystalBall had battery issues 
Well, instead of asking dumb questions I’ll ask something useful for the project 
Could you tell me the name of some good library to manage the display, and something more about DMA? I never used a micro with DMA, I know what it is and that STM32F103 has it, but I don’t know how it could help me. I think at my firmware this way:
I need to manage 3 things: CAN, Display and GPIO.
I’ll show RPM, speed, oil and water temperature and maybe lap times (I can get all this informations from CAN-BUS).
The most important thing is the Display, in particoular RPM and speed need to have a high refresh rate, temperatures and timings can be updated slower, like once every 2 seconds for temperatures and 3 or 4 times per lap for the timings, this will not damage to the user experience.
The packets coming from CAN-BUS are way faster than the reading speed of the end user so I can focus on obtaining high fps and I’ll need little or no buffer on CAN.
I could develop the main loop with the aim of refreshing the screen sections displaying RPM and speed as fast as possible, and triggering the GPIO if needed (i.e. turning on an LED if a certain RPM threshold is reached).
In this scenario where could I use the DMA?
Thanks again!
So you should be able to produce a fast frame rate. Just look at the minimum write cycle time for the controller.
The real question is: what does the LCD look like?
LCDs do not have a very fast response.
OLEDs have a faster response. There are examples of animations on a 128×64 OLED.
Seriously, a dashboard display does not need to be fast. It should be clear and easy to read for a human pilot.
David.
[david.prentice – Fri Feb 02, 2018 10:25 pm] –
With all the wires in the photo, it must be 8-bit parallel. Only 1024 bytes to blit per frame. SPI or parallel does not matter too much.So you should be able to produce a fast frame rate. Just look at the minimum write cycle time for the controller.
The real question is: what does the LCD look like?
LCDs do not have a very fast response.OLEDs have a faster response. There are examples of animations on a 128×64 OLED.
Seriously, a dashboard display does not need to be fast. It should be clear and easy to read for a human pilot.
David.
Of course OLEDs are better, but they are smaller and more expensive 
I need it to be big, because bigger is better….when you are racing at 200Km/h
yeah, I also forgot to mention I don’t need it for road use, I need it to be seen clearly when racing, so RPM will be taking a lot of room on the screen, then timings, then Km/h then temperatures with a bright LED alongside for safety.
These are screens taken from a commercial dashboard which uses a 128×64 display:
raw, easy but very functional indeed!
- DashStruct.png (32.28 KiB) Viewed 378 times
So you would update several times in a second. I doubt if the thousands change so often.
From a human’s point of view you want to see clear digits. You don’t want a blur of changing units.
The 60C and 234kph do not change so often.
In other words, you only change a few pixels at a time.
On a colour screen you only alter changed pixels.
On a monochrome screen like yours you can afford to redraw the whole screen.
You can limit the redraw to the changed area if you want.
Forget about the motorcycle for a minute. Just write a for() loop in software that changes the RPM value and observe the display.
How fast is comfortable? How fast is necessary.
A BluePill will be fine. A 16MHz AVR would be fine too.
I would guess that humans respond better to the sound of the engine speed and an analog needle is easier to judge than decimal numbers.
David.
At night the backlight comes on.
Personally, I don’t like the Blue transmissive LCD with White graphics.
Colour TFTs certainly look very smart in the ideal lighting conditions.
Is that you riding a motorbike in your Avatar?
It looks pretty hairy but at least you are not moving at 234 kph in 60C weather.
David.
I’m Italian, for us it’s absolutely necessary to read the water temperature while riding, so when it gets to 100°C you know it’s boiling and you can cook pasta
[david.prentice – Sat Feb 03, 2018 6:15 pm] –
Is that you riding a motorbike in your Avatar?
It looks pretty hairy but at least you are not moving at 234 kph in 60C weather.
Yes its me..223kph? 60C? No idea what you do but don’t sound that enticing.
My next step was going to be a larger tft screen and try an adjust the backlight with a light sensor on the fly..sounds good in theory.
As that disolay is parallel 8 bits, the STM32 will probably be able to send raw data to it, faster than it can receive it.
The frame rate is much more likely to be a function of the complexity of the graphics etc, you want to send to the display.
I have no knowledge of the controller chip on this display, but most have basic functions like Setpixel, and ClearPixel, and FillRect etc.
This one may only have a method to set / clear pixels.
So I don’t think anyone is likely to be able to answer your question, unless they actually have this disolay and also you have your screen design finalised.
I also appreciate your jokes but I have to be honest, it hurts that you ignored my joke about cooking pasta with engine water 
[RogerClark – Sat Feb 03, 2018 8:52 pm] –
Going back to the original question…As that disolay is parallel 8 bits, the STM32 will probably be able to send raw data to it, faster than it can receive it.
The frame rate is much more likely to be a function of the complexity of the graphics etc, you want to send to the display.
I have no knowledge of the controller chip on this display, but most have basic functions like Setpixel, and ClearPixel, and FillRect etc.
This one may only have a method to set / clear pixels.So I don’t think anyone is likely to be able to answer your question, unless they actually have this disolay and also you have your screen design finalised.
As far as I understand I’ll be able to do what I want to do without much trouble and that’s enough for me.
Just to be clear and to be useful for future readers, I also don’t like the 128×64 graphic lcd in this situation, but this project is a last minute solution with really strict time and money constraints. The only display that was cheap enough and available soon was this blue 128×64 graphic lcd.
At the moment I have to use this, maybe in the future I’ll upgrade it to something better
I think i’ll open a new thread if I’ll need help developing the firmware.
Thank you again!
Tobo
[Tobo – Sat Feb 03, 2018 10:15 pm] –
Thank you for all your answers guys, I really appreciate your help
A hearty guffaw was issued here in Yorkshire.
[david.prentice – Sat Feb 03, 2018 6:15 pm] –
<…>
Personally, I don’t like the Blue transmissive LCD with White graphics.
<…>
+1
Ray
[Tobo – Sat Feb 03, 2018 12:01 pm] –
Do you think it’s a good idea?
Just my opinion, but a numeric display of RPM on a racing bike is worse than useless. It takes too long to interpret and extra time spent thinking about some such at 200 km/hr takes away from far more important tasks. One needs to know more or less where they are relative to the power band and a color coded bar graph does this far better than a numeric display.
There’s a long tradition of arranging analog instrumentation such that the needle is vertical (sometime horizontal) at the nominal condition (e.g. peak power) for much the same reason.
[MarkB – Sun Feb 04, 2018 3:58 pm] –[Tobo – Sat Feb 03, 2018 12:01 pm] –
Do you think it’s a good idea?Just my opinion, but a numeric display of RPM on a racing bike is worse than useless. It takes too long to interpret and extra time spent thinking about some such at 200 km/hr takes away from far more important tasks. One needs to know more or less where they are relative to the power band and a color coded bar graph does this far better than a numeric display.
There’s a long tradition of arranging analog instrumentation such that the needle is vertical (sometime horizontal) at the nominal condition (e.g. peak power) for much the same reason.
Thank you for your opinion, you are absolutely right, the display is just an integration to a series of led that will work as main rpm indicator.
The driver asked for something to read the laptimes on while testing the bike, the mechanics asked to see the rpms and temperature when warming up the bike.
Actually I could make 2 differen pages, one for the driver and one for the technicians
Thank you again for your input, the project is still in the design phase (and it will be for at least another week) and every comment is welcome!
[BennehBoy – Sun Feb 04, 2018 9:38 am] –[Tobo – Sat Feb 03, 2018 10:15 pm] –
Thank you for all your answers guys, I really appreciate your helpA hearty guffaw was issued here in Yorkshire.
Thank you kind stranger
Are you getting the laptimes from the circuits timing equipment?
If so, what are you going to use to transmit it to the bike?
[Manny – Sun Feb 04, 2018 6:30 pm] –
Two questions
Are you getting the laptimes from the circuits timing equipment?
If so, what are you going to use to transmit it to the bike?
Nope, I’m getting laptimes from GPS, the GPS modules sends datas through CAN to the datalogger, so when you analyze your datas (tps, front and rear suspension position, lean angle ecc..) you can know where you were on the circuit.
