Blog2020-02-28T14:41:54+08:00

Our Blog

1511, 2021

The Sunday Blog: Characters and their ASCII codes – Casting or conversion?

By |November 15th, 2021|

Most developers know that a character like "A" is represented inside microprocessor systems as a simple number. That's called encoding. Everything started with teletype machines which used a 5bit encoding. The so-called Baudot-code, named after Mr Émile Baudot who invented it in 1874) allowed to encode the 26 uppercase chars of the latin alphabet, the ten numbers from 0 to 9, some interpunction and and some non-printable control characters within that limited 32 character space, using a sophisticated shifting system, comparable to our modern caps lock function. Later, when the first computers came up, with screens and printers, the Baudot code was extended from 5 to 7 bits, giving a 128 character space. Now, almost everything could be encoded without shifting and tricks (they thought): Upper and lowercase letters, numbers, special characters, interpunction, mathematical signs and more control characters. Again, everybody was amazed, until people hit the flaws of the ASCII system when they wanted to do text I/O in other languages than English. That gave birth to the 8bit code page system: In whatever code page, the first half, the characters #0 to #127 remained the same, identical to the ASCII code. In the upper half, the characters #128 to #255 were used for encoding national specifics, like for example à, é, ô, or ç in France, ä, ö, ü, ß in Germany, and so on. In order to display or to print a text correctly, you'd have to know which code page was used for encoding, so that you could use the same for decoding. The ISO standard superseded and re-ordered these code pages with the intention to reduce the national chaos, but without success. And we didn't yet talk about all the languages which use non-latin characters, mostly in Asia. The UTF standard was then created to encode everything, Latin, Cyrillic, Chinese, Japanese, Serbian, etc. plus interpunction, plus graphical block characters plus smileys, plus..., plus... A 32bit space is a great thing to encode more than 4 billions of symbols, but it's not practical because each symbol would eat up 4 precious bytes. Thus, the UTF system applies a few tricks: First of all, the numbers #0 to #127 represent still - you guess it - the ASCII character set, which is still the biggest common denominator of character encoding. Then, parts of the upper half of the first byte indicate if the current symbol is encoded in one, two, three or four bytes (step back to Baudot's shifting system). And the encoding has been selected in a way that the more common a symbol is, the less bytes are required to encode it, which saves storage space and transmission bandwidth. All that to tell you, that yes, even today in 2021, English is the predominant common language and the ASCII character set is still the gold and unambiguous standard for character encoding. That's why in this article, we'll look deeper into the relationship between a character and it's numerical representation.

811, 2021

The Sunday Blog: GPIO on Nextion vs. Arduino – Part 1 (Theory)

By |November 8th, 2021|

Did you know that your Nextion HMI of the Enhanced or Intelligent series have 8 GPIO (General Purpose In-Out) pins, either for smaller autonomous (without extra MCU) projects or to extend the available IO of a connected MCU? This can be very helpful and is a great addition if you have just a few extra physical keys, LEDs, beepers, servos, or rotary encoders to control, or if you want to acquire data from an external sensor! Today, we'll see the "how to" in Nextion code, side by side with the equivalent Arduino code to ease the understanding. From the next episode on, we'll see here small demo projects for everything in practice. 

1810, 2021

The Sunday Blog: Graphics programming (once more) – The moving window technique explained

By |October 18th, 2021|

The summary is simple: If you can't find an appropriate component in the Nextion Editor, you have to write it yourself... My last two blog projects about artificial horizons (here the introduction and here the full project) with Nextion HMI made use of it, twice, in the same way: Both displays, the dynamic sky/earth horizon and the azimuth compass aren't based on "classic" components, their space on the HMI page is just empty, everything is done by the moving window code. I got much feedback about this in the different Nextion-related groups on Facebook. People were amazed, but some didn't understand how I made this work. Thus, I decided to go more into details and do a simple animated FM radio frequency display with still more explanations. At this point, I have to say that I'm very grateful for this kind of feedback! As an old developer horse with 30+ years of experience in coding, it's sometimes difficult for me to see where my readers could struggle or have difficulties in understanding, especially if these topics appear trivial or self-explaining to me. So, let's go:

410, 2021

The Sunday Blog: Graphic programming – Introduction to artificial horizons on Nextion HMI

By |October 4th, 2021|

Reading through different Nextion HMI related forums, discussion groups, and FaceBook pages, I see more and more people using Nextion HMIs in or as dashboards for (real or simulated) cars of all sizes, bikes, boats and even small airplanes. Especially for the two latter, a so-called artificial horizon might be of interest. Thus, I decided to start a short series, showing a few programming techniques which can help with this.