Go to main section
Qt for MCUs. Instru­ment Cluster for Golf cart. A developer’s per­spect­ive.

Qt for MCUs. Instru­ment Cluster for Golf cart. A developer’s per­spect­ive.

Kamil Hajdukiewicz, HMI Centre of Competence member Kamil Hajdukiewicz, HMI Centre of Competence member

Our Golf Cart instru­ment cluster is an intern­al pro­ject in which developers from Codelab’s HMI Centre of Com­pet­ence cre­ate an instru­ment cluster for an elec­tric golf vehicle. We chose the Qt for MCUs tech­no­logy and an STM micro­con­trol­ler with an integ­rated screen to cre­ate a pro­to­type and then the com­plete soft­ware. Qt for MCUs is a new graph­ics frame­work and toolkit which deliv­ers everything what is neces­sary to design, devel­op and deploy GUIs on micro­con­trol­lers. The dif­fer­ence between nor­mal Qt and Qt for MCUs is that Qt for MCUs uses the new QML ren­der­ing engine — Qt Quick Ultral­ite (QUL) which allows applic­a­tions to run on bare met­al or on a real-time oper­at­ing sys­tem. The frame­work was shared to developers last year.

Main goal of the pro­ject is to increase the employee’s com­pet­en­cies in cre­at­ing HMI sys­tems and expand know­ledge about the new frame­work. The cluster for an elec­tric golf cart shall ful­fill the fol­low­ing func­tion­al­it­ies:

  • Present the cur­rent speed of the vehicle, bat­tery level and cur­rent power
  • Inform about lights on, turn sig­nals and vari­ous types of fail­ures
  • Enable the oper­a­tion of mul­ti­me­dia devices
  • Dis­play nav­ig­a­tion and cur­rent pos­i­tion of the vehicle on the map
  • Present the vehicle char­ging status
  • Dis­play cur­rent weath­er

After col­lect­ing the require­ments, pre­par­ing the design and set­ting up the envir­on­ment we went straight to the imple­ment­a­tion of the sys­tem. Almost every part of the pro­ject is writ­ten using QML lan­guage. CMake is used for build man­age­ment which made our com­pil­a­tion pro­cess fully auto­mated.

The main tar­get of the applic­a­tion is STM board but the pro­gram can also run on Win­dows. This facil­it­ates the imple­ment­a­tion and test­ing pro­cess because STM board is not always avail­able for every developer. We cre­ated the inter­face which makes it pos­sible to send the spe­cif­ic events to the applic­a­tion on but­tons click. It allows us to test the beha­vi­or of the applic­a­tion on vari­ous events.

Usu­ally when you learn some­thing new you have to deal with some prob­lems. In our case it was a prob­lem related to the lim­ited per­form­ance of the STM board. Applic­a­tion had too little frames per second so its per­form­ance was not smooth at times. We had to find a cause. In order to do that we had to ana­lyze in which way resources are loaded to the pro­gram. We also checked the impact of the anim­a­tions in the pro­gram on the sys­tem per­form­ance. We found out what we could do bet­ter. After mak­ing the changes our pro­gram runs much smooth­er. The pro­ject allowed us to learn not only about a new frame­work but also about optim­iz­a­tion meth­ods.

The pro­ject is still in pro­gress. The applic­a­tion is con­stantly evolving with new func­tion­al­it­ies. The graph­ic­al inter­face is chan­ging to be more user-friendly. I hope that someday the pro­ject will see the light of day and we as developers will be able to boast about it.

Sticky news

| Jan Tecker Siegel

Auto­mot­ive SPICE — a lux­ury or neces­sity?

Auto­mot­ive SPICE — a lux­ury or neces­sity?

The auto­mot­ive industry is get­ting more and more com­plex every day. All com­pan­ies, nev­er­the­less if OEMs or Tier­’s, are oper­at­ing in VUCA (Volat­ile, Uncer­tain, Com­plex and Ambigu­ous) world. The sys­tems that we build...

| Robert Rychcicki, Sebastian Wieczorek and Bartosz Hajdaś

Design Think­ing in R&D

Design Think­ing in R&D

When cre­at­ing new products or ser­vices, it is worth doing it based on a deep under­stand­ing of the prob­lems and needs of users. That’s the time where “Design Think­ing” should be used. In Codelab, we have used this approach while work­ing...