C++ un mikrokontrolieri

[Jurkins]

Skaidrs, ka visiem prātā krāna nojaukšana un karš Ukrainā, bet nu, īstenībā jau dzīve neapstājas.

Kā zināms 🤣, man laiku pa laikam uznāk paitona saasinājums, pa laikam c++ saasinājums, pa laikam pastiprinātāju saasinājums, u.t.t.

Uznāca c++ saasinājums 🤣. Noskatījos pāris lekcijas par "value based" pārākumu par "type based" metodi (vai kā to nosaukt). Nu un sarakstīju variantu avr, konkrēti populārās atmega 328 - arduino uno, arduino pro nano, laikam vēl kaut kādi I/O portu padarīšanai.

 

Var rakstīt kaut kā tā. 

#include <avr/io.h>
#include "main.h"
#include "atmega_328.h"


using lcd_7 = pb6;
using lcd_6 = pb5;
using lcd_5 = pd0;
using lcd_4 = pd1;
using lcd_3 = pc5;
using lcd_2 = pb1;
using lcd_1 = pb3;
using lcd_0 = pc6;

using LCD = IOport<lcd_7, lcd_6, lcd_5, lcd_4, lcd_3, lcd_2, lcd_1, lcd_0 >;
int main(void)
{
	LCD::AsOutput();
	LCD::Write(0b1111'1111);
  	LCD::AsInput();
  	uint8_t v = LCD::Read();
  
    while (1) 
    {
    }
}

Assemblers gandrīz ideāls.

Nav problēmu noportēt uz stm32. Viss strādā.

Jautājums... visām funkcijām ar portu kods ir divi varianti - rakstīt vai lasīt kaut ko.

template<class Tport, class ... Tports>
	static inline void dir_as_input_imp(type_pack<Tport, Tports ... >)
	{
		dir_as_input_imp(type_pack<Tport>{});
		dir_as_input_imp(type_pack<Tports...>{});
	}
	template<class Tport>
	static inline void dir_as_input_imp(type_pack<Tport>)
	{
		constexpr auto port_lines = port_line_pack(just_type<Tport>{}, pin_pack);
		if constexpr(Tport::port_length == size_of_pack(port_lines))
			Tport::AsInput();
		else
		{
			constexpr auto port_mask = mask_of_pinpack(port_lines);
			Tport::AsInput(port_mask);
		}
	}

Atšķirība ir tikai izsaucamā funkcija - šajā gadījumā Tport::AsInput(). Tupīju vēl tajos templeitos. Vai var kaut kādā veidā šo funkciju padot kā parametru?

main.h atmega_328.h type_traits.h

[AndrisBB]

Neko nezinu par tēmu un kāds ir jautājums, bet ...

 

Realitāte ir tāda ka tāds kods ir pārāk sarežģīts, tapēc visdrīzāk tiktu izmests un netiktu apstiprināts. Nu vismaz es neapstiprinātu, it īpaši uz mikrokontrolieliem vai kautvai kautkur sistēmas līmenī.

Laiks ir nauda, ja kādam jātērē laiks, lai tam izburtos cauri, vai nedod dievs vajag debuggot, kad kautkas neiet.

 

Nu akadēmisku iemeslu pēc jau var kautko čakarēties, bet ne reālajā dzīvē.

Edited Friday at 09:27 PM by AndrisBB

[Jurkins]

Pirms 9 minūtēm , AndrisBB teica:

nedod dievs vajag debuggot, kad kautkas neiet.

kāpēc neiet? Viss iet. Un vienmēr. Tas kods ir jāuzraksta tikai vienreiz. Pēc tam nevajag rakstīt vairs.

Jautājums - vai var kā parametru funkcijas šablonam padot klases šablona funkciju?

 

Pirms 15 minūtēm , AndrisBB teica:

bet ne reālajā dzīvē.

Nu jā, tas nav mans maizes darbs.

[AndrisBB]

Pirms 3 minūtēm , Jurkins teica:

kāpēc neiet? Viss iet. Un vienmēr.

Nav tāda koda kas vienmēr ietu  vienmēr kautkas neiet, it īpaši ja mazliet vairāk par divām funkcijām.

[AndrisBB]

Iedomājies tev jādebuggo kautkādu problēma, kas notiek vienreiz pilnmēnesī, tu atver kodu ko nekad neesi redzējis un tur kādas 50k rindas ar kautko tādu.

 

 

Ne velti ir tāds KISS princips.

[Jurkins]

@AndrisBB, ja paskatās uz arduino vai tā paša stm standarta rsisinājumiem, tad mani kā neprofesionālu programmētāju pārņem izmisums 🤣.

Tāpēc jau tagad ir tā, ka parasta aplikācija ir ap 1GB 😁

Bija te variants. Cilvēks uz C# uzraksta kaltēm aplikāciju. Viss it kā darbojas, bet ir gadījumi, kad uzkaras... nu nevar saprast kas tur īsti par lietu, reizēm gļuko, bet ja to koda gabalu ieliek iekš "try... except", tad iet. ĀĀĀĀĀ! Skaidrs, ka iet....

Pirms 2 minūtēm , AndrisBB teica:

kautkādu problēma, kas notiek vienreiz pilnmēnesī,

Bet kāpēc tādā vienkāršā kodā kaut kam jānotiek reizi pilnmēnesī? Ja šis ir sarežģīts kods, tad...

Pirms 4 minūtēm , AndrisBB teica:

50k rindas

Tāpēc jau jautāju... nezinu, vai pareizi formulēju... bet vai var klases šablona funkciju padot kā parametru funkcijas šablonam?

[AndrisBB]

Kodam ir tieksme mainīties nepārtraukti, kautkas jāpieliek, kautkas jāpamaina, nav tā ka vienreiz uzraksti un tad iet mūžiem.

Pat ja tas konkrētais kods iet bez problēmām, tad tas nenozīmē ka pēc gada, kad kautko vajadzēs pamainīt, tu pats atcerēsies ka vispār rakstiji to kodu un čortosies, kurš tādus murgus sarakstījis.

Ja nu tomēr kautkas neiet, tad tu jau nezini, niet tur vai kautkur citur. Bet ja kāds cits pēc mēneša mēģina debuggot, tad viņam būs jāpavada ilgs laiks lai vispār saprastu kas tur domāts.

Nav jau arī tā ka ja tas kods kompilējas ar gcc 8, tad viņs kompilēsies un darbosies korekti pēc mēneša ar gcc 9, vai vispār citu kompilieri uz kādas citas sistēmas.

Visā tajā C++ maģijā, ir miljoniem lietu kas var aiziet greizi.

Vispār jau Templeiti uz Mikrokontroliera pa lielam ir liels 'no no' jebkurā gadījumā.

[Jurkins]

Kāda starpība uz mikrokontroliera vai kur citur? Tā ir vienkārši metaprogrammēšana - kods, kurš izveido kodu. Kas mk I/O var mainīties?

Tad jau praktiski gan std gan stl var norakstīt.

 

Ja ir iznācis uz gcc c++20 un kāds leito gcc ar cc++03, tad... . Visur tak jābūt attīstībai 😁.

Edited Friday at 10:13 PM by Jurkins

[AndrisBB]

Pirms 16 minūtēm , Jurkins teica:

bet vai var klases šablona funkciju padot kā parametru funkcijas šablonam?

Ganjau ka var, kapēc lai nevarētu? Atbildi gan nezinu, no templeitiem parasti izvairos, lietoju tik ja nu galīgi baigi vajag.

Pirms 2 minūtēm , Jurkins teica:

Tad jau praktiski gan std gan stl var norakstīt.

Uz MCU jau parasti arī visādus vektorus utt diezko neizmanto. Pārāk bīstami.

[Jurkins]

Just now, AndrisBB teica:

no templeitiem parasti izvairos, lietoju tik ja nu galīgi baigi vajag.

Nu ja, es neesmu programmētājs un tas nav mans maizes darbs, bet patīk gan.

[AndrisBB]

Tevis paša pieminētajos STM standartrisinājumos. Esi redzējis kaut vienu std, stl utt?

[Jurkins]

Neesmu. Stm standartrisinājumi ir kaut kas šausmīgs. Īstenībā, domāju, ka tas ir marokāņu 😁programmistu nopelns. Bet dīvaini. Mani parasti šeit lamā par stagnātu😁.  Savukārt es esmu pilnīgi atvērts c++23😁... nu jā, zinu gan jau 1% no c++20.

[Jurkins]

Pirms 9 minūtēm , AndrisBB teica:

Pārāk bīstami

Var par šo konkrētāk? Kāpēc bīstami? Protams, jautājums, vai tas ir vajadzīgs. Bet kāpēc bīstami?

[AndrisBB]

Pa lielam jau tās HAL bibliotēkas netiek rakstītas tikai lai programmētāji varētu manuāli rakstīt kodu un lietot viņas. Tapēc reizēm varbūt tas kods var likties dīvains.

Realitāte ir tāda ka tas kkods tiek rakstīts, lai varētu izmantot uz 1000 un 1 dažāda MCU, lai varētu automātiski ģenerēt no vosādiem tūļiem, izmantot visādas testu bibliotēkas, viegli integrēt kautkādos OS. Kas ir īstenībā būtiski, jo nav jēgas no HAL bibliotēkas ja viņu viegli nevar ieintegrēt kādā RTOS.

[Jurkins]

Nu jā, neesmu sevi piespiedis apgūt kādu RTOS.

Kā neprofesionālis izjūtu nepatiku pret OS mikrokontrolierī.

Edited Friday at 10:33 PM by Jurkins

[AndrisBB]

Pirms 8 minūtēm , Jurkins teica:

Var par šo konkrētāk? Kāpēc bīstami?

Viss jau atkarīgs no konkrētās applikācijas. STL izmanto heapu un dinamosko atmiņas izdalīšanu. Esi pārliecināts ka agrāk vai vēlāk neiebrauksi kautkādās divainās atmiņas fragmentācijas problēmās?

 

Pirms 4 minūtēm , Jurkins teica:

Nu jā, neesmu sevi piespiedis apgūt kādu RTOS.

Zephyr nav ne vainas.

https://www.zephyrproject.org/

[Jurkins]

Just now, AndrisBB teica:

atmiņas fragmentācijas problēmās?

Mož tupiju... ne jau visas std/stl funkcijas izmanto Tevis minētās lietas. Kāda starpība bīstamībai, vai tas notiek uz avr, arm vai x86-64. Tad jau tajās problēmās var iebraukt uz jebkuras arhitektūras.

 

[AndrisBB]

Nu ja tu paņem kautkādu ARM Cortex ar teiksim 100kb brīvu atmiņu iedalītu heapam. Tad randomā malloco un atbrīvo kautkādus objektus izmēros teiksim 200b līdz 2kb. Cik daudz laika vajadzēs, līdz tu vairs nevarēsi izveidot jaunus 2kb objektus, jo nebūs vairs 'spraugas', kur viņu iespraust? Kautgan lielākā daļa atmiņas ir itkā brīva.

x86 un resnākiem ARM pavisam cits stāsts, tur ir bezgalīga virtuālā atmiņa un MMU.

Edited Friday at 10:49 PM by AndrisBB

[Jurkins]

Mana savārstījuma 😁 gadījumā vispār nekādi objekti netiek veidoti. Pat speciāli no tā notiek intensīva atkratīšanās.

[AndrisBB]

https://cpp4arduino.com/2018/11/06/what-is-heap-fragmentation.html

Pirms 1 minūtes , Jurkins teica:

Mana savārstījuma 😁 gadījumā vispār nekādi objekti netiek veidoti.

Tas vairāk bij domāts par STL kopumā.

[Jurkins]

Nu tas laikam šoreiz nebūs. Reāli kods nekur tālāk par reģistriem neiet. Nekādi malloc un new vispār nav paredzēti. Doma tāda, ka maksimāli viss iespējamais notike compile time.

 

p.s. arduino ir šausmīgs savā būtībā 😁

Edited Friday at 11:02 PM by Jurkins