Programmēšana un programmēšana

Šoreiz par vienu it kā vienkāršu tēmu - kas ir programmēšana un ko ar to kurš saprot. Kāpēc šāda tēma radās? Vienā no forumiem chip tūneris ierakstīja, ka viņš rakstot programmas Tricore. Pāris izstrādes inženieros un developeros šis apgalvojums izraisīja smieklu vētru. Līdzīgu reakciju pēc brīža izpelnījās arī viens cits  foruma dalībnieks (pamatdarbā: datortīkla administrators), apgalvojot, ka ar Tool32 viņš veicot ''low-level vadību'' un ar EDIABAS - ''softa analīzi''.

Latviski ir iezadzies neliels ''bardaks'' terminoloģijā, arī angliski ''program/programming; coding; flashing'' - katrs var iztulkot, kā vien vēlas.

Centīšos maksimāli vienkārši, lai ''cilvēkam no malas'' top skaidrāks.

MCU sistēma (katrs no moderna auto blokiem ir specializēta MCU sistēma) sastāv no sirds: MCU (mikrokontrolieris) un periferiālajām ierīcēm (ADC; DAC; izpildmehānismu vadība, utml.). MCU ''kopš dzimšanas'' ir ''pliks dzelzis'' - tas neko ''nemāk''. Precīzāk - tas māk tikai saskaitīt, atņemt, dalīt, reizināt un veikt vēl virkni primitīvu darbību. Taču tam nav ne mazākās ''nojēgas'', kas būs jādara - jāpārsūta dati, vai jāvada sprauslas, vai, piemēram, jāattēlo multimedia attēls, utjpr. Funkcionalitāti izstrādā ražotājs vai tā subkontraktors. Mūsu gadījumā: funkcionalitāti nosaka BMW AG, bet realizē Siemens; Bosch; Hella, u.t.t. Šo izstrādes posmu tā arī sauc: izstrāde (development); kodēšana (coding). Reizēm lieto arī terminu programmēšana (programming). Gan ar coding, gan programming var rasties (un rodas) pārpratumi, jo tos lieto arī citās nozīmēs.

Izstrādes inženieri un programmētāji ar kodēšanu/programmēšanu saprot programmatūras RADĪŠANU. Šī radīšana notiek katram MCU paredzētā development vidē. RT (real time) sistēmu MCU programatūra tipiski tiek radīta pielāgotā C, ja nepieciešams, ar ASM bloku ietveršanu. Ja prasības nav tik kritiskas, tiek izmantotas augstāka līmeņa programmēšanas valodas/vides.  Būtiskākais ir tieši šis radīšanas aspekts.

Ražotājs katram no šiem MCU blokiem tipiski paredz iespēju programmatūru atjaunot. Lai tas būtu iespējams, ražotājs dīlerservisu tīklu (un arī entuziastus) nodrošina ar visu nepieciešamo rīku kompleksu, lai šo programmatūras atjaunošanu varētu veikt. BMW gadījumā tas ir DCAN savienotājvads vai iCOM (hardware) un ISTA un WinKFP E sērijai vai eSys F sērijai (software). Ja ISTA viss notiek maksimāli vienkārši (''dažu pogu nospiešana''), tad piem., WinKFP ir drusku sarežģītāk - ir iespēja izvēlēties vajadzīgo failu (kas satur atjaunināto programmatūru) un caur ''savienotājvadu'' to ielādēt izvēlētajā blokā. Angliski parasti lieto terminu ''flash'', jo ''program'' īsti neatbilst darbības jēgai. Tajā par laikā, BMW šo programmatūras maiņu/atjaunināšanu sauc tieši par programmēšanu (programming). No šejienes rodas pirmais pārpratums - cilvēki, kuri nezina, ko nozīmē ''īstā'' programmēšana, apgalvo, ka viņi programmē BMW blokus, kaut patiesībā viņi tikai ielādē ražotāja izstrādātu programmu, izmantojot ražotāja izstrādātus rīkus. 

Līdzīgi pārpratumi veidojas, izmantojot terminu kodēšana (coding). Programmētāju (programmatūras izstrādātāju) vidē kodēšana nozīmē programkoda rakstīšanu/radīšanu - soli-pa-solim instrukciju rakstīšanu konkrētam MCU. Savukārt, BMW ar ''coding'' apzīmē bloku programmatūras konfigurācijas izmainīšanu. Ko nozīmē konfigurācija? Katrs bloks var tikt izmantots dažādas komplektācijas auto - piem., ar 4; 6 vai 8 cilindru dzinēju; ar automātisko vai manuālo transmisiju; ar halogēnlukturiem vai ksenona apgaismojumu; ar vai bez kruīzkontroles; ar ''parasto'' kruīzu vai adaptīvo, utjpr. Mainot konfigurācijas datus, katram blokam tiek ''pateikts'', kādas komplektācijas auto tas ''apkalpo''. Jā, protams, arī par šo darbību ērtu veikšanu ir padomājis BMW. Savulaik no BMW noplūda NCS Expert konfigurācijas toolis, kuru vēlāk padarīja lietotājam ērtāku un nosauca par NCS for Dummies. Vēl soli tālāk gāja daži 3.pušu ražotāji (piem., Carly; Bimmergeeks, u.c.), kas izveidoja ērtas mobilo telefonu aplikācijas. Un arī šoreiz - ir cilvēki, kas apgalvo ''es kodēju BMW'', kaut spaida podziņas Carly aplikācijā, tajā pat laikā ''īsts'' programmētājs ar to saprot - cilvēks strādā BMW izstrādes komandā un veido bloka funkcionalitāti.

Iepriekšminētā bloku ''vadība'' paredz arī darbu ar Tool32 (vai eSys F sērijai), ar kuru palīdzību var piekļūt un modificēt reģistru un atmiņas šūnu saturu. Kādēļ tas nepieciešams? Daļa datu ir jānosaka bloka konfigurācijas ietvaros kā skaitliski parametri (nevis opcijas). Piemēram, nosakot dzinēja tipu, atbilstoši tam jānosaka maksimālais atļautais RPM; jānosaka tukšgaitas RPM; jānosaka maksimālā pieprasāmā grieze, daudzi citi parametri. Daļa citu parametru tiek uzkrāti auto darba laikā. Domāju, katrs ir dzirdējis par ''lampiņu skaitītāju'' dzēšanu LM/FRM gaismu vadības blokos. Arī šādi - kļūmju un nolietojuma skaitītāji ir modificējami ar BMW izstrādāto rīku palīdzību. Un atkal - ar bloku konfigurēšanu katrs šo operāciju sapratīs savādāk. ''Īstais'' programmētājs - ar bloka darbības optimizēšanu tā izstrādes laikā, BMW diagnosta gadījumā - BMW konfigurācijas rīka izmantošanu.

Atšķirība starp Tool32 un NCS (kaut to funkcionalitāte reizēm pārklājas) - NCS strādā ar bitiem (t.i., konfigurācijas setingiem), Tool32 - ar baitiem/mainīgajiem/parametriem.

Darbs ar šiem gatavajiem ražotāja rīkiem - ''augstākais'' (lietotājam ''prastākais'') iespējamais level. Tam nav nekas kopējs ar low-level programmēšanas/testēšanas/attīstīšanas darbu.

Piezīme: low-level programmēšanas valodas/rīki: tehniski sarežģītākie (primitīvākie, bet efektīvākie kritiskākajos apstākļos) programmēšanas rīki, piem., ASM. Low-level rīku izmantošana skaitās prestiža tieši savas sarežģītības dēļ.

Šī ieraksta kopsavilkums - runājot par it kā vienu un to pašu, patiesībā cilvēki var runāt par fundamentāli atšķirīgām lietām! Protams - programmatūras izstrāde ir nesalīdzināmi sarežģītāka kā gatavu rīku izmantošanu. Lai man piedod visi BMW ''optimizētāji'', bet idejiski šo var salīdzināt, piem., ar router vai interneta browser konfigurēšanu. Produkta izstrādātājs ir nodrošinājis pilnu hardware un software rīku komplektu, jums atliek vien saspiest ''galočkas'', pamainīt parametrus atbilstošajos ''lodziņos''. Jā, BMW gadījumā - ir virkne nianšu; informācija nav precīzi dokumentēta (it sevišķi - visādiem upgrade/downgrade/retrofitiem un nestandarta kombinācijām), taču tam (arī pēc sarežģītības) nav nekas kopējs ar programmatūras izstrādi MCU sistēmām un pašu sistēmu būvēšanu.

Tieši tāpat - nav iespējama nekāda programmatūras analīze EDIABAS. Programmatūru (tās darbību) analizēt var tikai tās izstrādātājs, izmantojot source code; development rīkus - debugerus; real time datu loggerus, simulatorus, utjpr. Nekas no šī nav pieejams cilvēkiem, kas operē ar EDIABAS bāzētiem gataviem rīkiem. Katram, protams, gribās būt augstākas klases speciālistam, kāds viņš ir, bet - nevajag pārcensties. Speciālistu vidē tas izskatās smieklīgi.