M_J Septembris 8, 2018 Share Septembris 8, 2018 Esmu mācījies pie Platača no viņa grāmatas un pie cita pasniedzēja lineāro ķēžu teoriju. Tas tomēr ir ļoti ērti priekš studentiem, ja pats pasniedzējs ir sarakstījis grāmatu. Kaut vai tāpēc, ka nav tās putrošanās ar apzīmējumiem, par ko jau rakstīji. Piekrītu - latviešu valodā neko labāku par šīm tēmām nezinu. Man šīs grāmatas nevajag, pašam mājās ir abas, turklāt pa laikam tajās ieskatos, bet vienalga man būtu žēl ja Tu savējās tā vienkārši izmestu. Apmēram pirms gada, risinot vienu problēmu ar jaudīgu trīzfāzu sinhrono ģeneratoru, biju pārsteigts cik slikti cilvēki Latvijā zina teoriju. Zvanīju pazīstamiem ļaužiem, kas strādā lielajos HESos, kas strādā pie kurzemes loka projekta. Domāju - viņi savā ikdienas darbā ar to noteikti būs saskārušies un uzreiz pateiks risinājumu. Viņi nevarēja palīdzēt, jo vairs nenodarbojas ar lietām kur vajadzīgas teorētiskās zināšanas, bet precīzi izpilda angļu/franču/vācu valodā rakstītas instrukcijas tipa: "čukča pabaro sunīšus, tikai podziņas neaiztiec". Risinājumu atradu vienā no vecajām grāmatām (ne no šīm). Link to comment Share on other sites More sharing options...
rnxx Septembris 8, 2018 Share Septembris 8, 2018 pirms 17 stundām , AndrisBB teica: inžinierim pa dienu jāmaksā kautkādi 600 - 700 Eur. Daudzi LV domā ka tā summa jāmaksā mēnesī. pirms 15 stundām , M_J teica: Tik tā starpība, ka tad, lai kaut ko pamainītu shēmā, bija jāņem rokā lodāmurs, tagad tās izmaiņas var veikt uz datora ekrāna. Assemblerī realizēt lielāko daļu šo darbību ir dažu rindiņu jautājums. Assemblerī ir cool, bet vai visur tika lietots vienāds devaiss? Tā personālatlase jau arī ir tādi filtri, ka nav ko cerēt uz labu atlasi. Jauni, smuki, smuki CV un aiziet. Par kondensatora efektu ekranētos vados arī var iedot testā iekšā. M_J, kas par pročiem, kuriem tik viegli ar asm paprogrammēt? Vienam vajadzējis darboties ar Assembler priekš projekta, ta viņam bija jālasa dokumentācijas čupa + datasheeti par devaisu. Vecis programmē 25 gadus, vienalga bija jāpēta. Link to comment Share on other sites More sharing options...
AndrisBB Septembris 8, 2018 Share Septembris 8, 2018 Pirms 2 minūtēm , rnxx teica: Daudzi LV domā ka tā summa jāmaksā mēnesī. Nu tas ja "outsourcingo" inženieri kautkādam projektam. Mēs piemeram nodarbojamies vairāk ar BSP, custom draiveriem, Linux kerneļa pieslīpēšanu utt, bet kad vajag kautko darīt ar pašu hārdwāri, tad nākas maksāt to summu firmām kas piedāvā elektronikas inžinierus. Tā arī mēs apmēram iekasējam no saviem klientiem, no amerikāņiem vairāk :D, pašiem programmētājiem jau tikdaudz netiek, tuvāk kautkam starp 1/2 un 2/3. Link to comment Share on other sites More sharing options...
rnxx Septembris 8, 2018 Share Septembris 8, 2018 Ne tikai outsourcingam vien. Mums te tik daudz kapeik****, labās vietās atkal smuka konkurence uz darbavietām. ASM paprogrammēt tīri čilīgi var arī ne elektroniķis, ja devaiss vienāds, interese par lietu ir, tad pamācies kārtīgi un programmē. Par vadu mudžekļa efektu devaisā arī var uzzināt var katrs kam interesē. Ir taču pilnas malas info, kāpēc izstrādā kabeļu un vadu novietojuma kartes pat 3D formātā. Ņem taču vērā ne tikai kondensatora efektu, indukcijas un siltuma, potenciālo vibrāciju efektus. Problēma manuprāt vairāk ar to devaisu maiņu, ja viņi jāprogrammē. Kad ir viens devaiss, tur visas sastāvdaļas nemainās, tad var gadiem mierīgi programmēt to devaisu xxxx numur xxx ?. Link to comment Share on other sites More sharing options...
M_J Septembris 8, 2018 Share Septembris 8, 2018 Assembleri sāku lietot krievu laikos ar PDP11, tie bija tā saucamajās krievu "Bekās" un ДВК. Kad nopirku pirmo PC, šķiet, ar 386. procesoru, tad arī uz tā uztaisīju tieši assemblerī dažas programmiņas, bet tas bija īslaicīgi. Pēc tam bija PIC 8 bitu mikrokontrolieru periods, tad pārgāju uz Atmel AVR mikrokontrolieriem. Gribu pāriet STM32. Tur gan ir izdarīts viss, lai negribētos programmēt assemblerī, bet ir cilvēki, kas tomēr to dara. Taisot alternatīvos variantus "klucīšu" kontrolieriem, nevienu brīdi nav bijusi doma izmantot un pārprogrammēt jau esošo dzelzi ar esošo procesoru. Lai tā darītos, nāktos, vispirms stipri noņemties ar reverso inženieriju, lai no fiziskās ierīces pārzīmētu shēmu. Gatavas ierīču shēmas nemēdz būt brīvi pieejamas, bet izsekot visiem celiņiem daudzslāņu montāžas gadījumā ir murgs. Otrkārt - kad kādu brīdi ir sanācis ņemties ar kādu "klucīšmašīnu", jau ir izveidojies viedoklis, par lietām, ko gribu taisīt savādāk. Tāpēc ņemu mikrokontrolieri, kuru pazīstu un uztaisu shēmu no nulles. Kad tā lieta nāk gatava, tad var salīdzināt, ko varu izdarīt ar "klucīšmašīnu" un ko ar savu kontrolieri. Tad arī rodas tie secinājumi. Assemblerī migrēšana starp dažādas arhitektūras devaisiem, protams, ir sarežģītāka, kā lietojot augsta līmeņa valodas bet starp dažādiem devaisiem vienas arhitektūras robežās - nekādu problēmu. 1 Link to comment Share on other sites More sharing options...
AndrisBB Septembris 8, 2018 Share Septembris 8, 2018 (labots) Pirms 20 minūtēm , M_J teica: Gribu pāriet STM32. STM32 primāri izmantoju jau ntos gadus, nezinu ko īsti būtu jādara, lai būtu jēga programmēt Assablerī, jo compilators lielākajā daļā gadījumu darbu izdarīs labāk. Cita lieta ir vietām optimizēt kautkādus algoritmus, izmantojot piemēram SIMD operācijas utt. Pietam ST piedāvā vairāku līmeņu HAL abstrakcijas, gan "resnas", kur lai ieslēgtu GPIO nākas iet caur 4 līmeņu funkcijām, gan daudz "plānākas" kā LL, kas būtībā ir vienkārši C inline wrapperi, lai piekļutu reģistriem. Bet piemēram uzrakstīt RTOS vai TCP/IP staku Assamblerī būtu interesanti, jāpagoogle vai maz tādi eksistē. Labots Septembris 8, 2018 - AndrisBB Link to comment Share on other sites More sharing options...
M_J Septembris 8, 2018 Share Septembris 8, 2018 Pirms 12 minūtēm , AndrisBB teica: STM32 primāri izmantoju jau ntos gadus, nezinu ko īsti būtu jādara, lai būtu jēga programmēt Assablerī, jo compilators lielākajā daļā gadījumu darbu izdarīs labāk. Viņš to izdarīs labāk pēc savas izpratnes, bet tas var atšķirties no manām vajadzībām. Manuprāt daudz kas ir atkarīgs no tā, kādus uzdevumus risina. Es pie programmēšanas nonācu no elektronikas un risinu tos uzdevumus, ko līdz tam risināju, lodējot loģiskās shēmas, trigerus un tādā garā. Un tagad viens piemērs, kādus risinu, izmantojot assembleru: Gribu iegūt impulsu ģeneratoru, kurš ģenerē impulsus ar brīvi maināmu garumu un periodu. Procesora takts frekvence ir 20MHz. Impulsu garums sākot no 0.05 us, (kas atbilst laikam, kādā procesors izpilda vienu komandu) impulsa garuma izmaiņas solis tāpat. Periods sākot no 1us, perioda izmaiņas solis tās pašas 0.05us. Nav pieļaujama situācija, kad visu impulsu starpā kāds impulss "izlec" un ir par vienu soli garāks vai īsāks par pārējiem. Tāpat nav pieļaujama situācija, kad impulss kaut par 0.05us atpaliek, vai pienāk pirms paredzētā laika. Un tagad iedomāsimies, ka kontrolierim jāstrādā kā šādu impulsu divkanālu ģeneratoram, kur katrā kanālā ir mazliet atšķirīgs periods. Mums ir jāiegūst divas impulsu virknes, kas brīvi "peld" viena pret otru. Visinteresantākais ir tas moments, kad divi impulsi "peld" viens pāri otram. Nezinu, kā kaut ko tādu izdarīt ne Assemblerī. Link to comment Share on other sites More sharing options...
AndrisBB Septembris 8, 2018 Share Septembris 8, 2018 Tava ideja skaidra, bet tad tev vajag diezgan primitīvu mikrokontrolieri. Kā arī gluži tavu ģeneratoru nenausaukšu īsti par programmēšanu. Pirms 10 minūtēm , M_J teica: kas atbilst laikam, kādā procesors izpilda vienu komandu Es domāju ka moderniem STM32 tu nevari garantēt cik ilgi aizņems viena instrukcija. Droši vien ka var instrukcijas ielādēt Ramā un tad vairāk vai mazāk būs droši. Pirms 13 minūtēm , M_J teica: kontrolierim jāstrādā kā šādu impulsu divkanālu ģeneratoram, kur katrā kanālā ir mazliet atšķirīgs periods Man izklausās ka te varētu atrasties pielietojums PWM/Timerim, kurš izpilda patternus, kas tiek ielādēt pa taisno no atmiņas caur DMA. Skaidrs ka ar 20MHz tur nav ko iesākt, bet moderni STM32 iet ar 80 - 120 un pat ātrāk. Ja tā implulsu ģenerēšana ir vienīgais ko tas kontrolieris dara, un nav nekādi citas lietas ko apstrādāt, tad jau tava doma ir OK. Link to comment Share on other sites More sharing options...
rnxx Septembris 8, 2018 Share Septembris 8, 2018 1 stundu atpakaļ, M_J teica: Assembleri sāku lietot krievu laikos ar PDP11, tie bija tā saucamajās krievu "Bekās" un ДВК. Kad nopirku pirmo PC, šķiet, ar 386. procesoru, tad arī uz tā uztaisīju tieši assemblerī dažas programmiņas. Forši, skatos ka liela pieredze. 1 stundu atpakaļ, M_J teica: Lai tā darītos, nāktos, vispirms stipri noņemties ar reverso inženieriju, lai no fiziskās ierīces pārzīmētu shēmu. Gatavas ierīču shēmas nemēdz būt brīvi pieejamas, bet izsekot visiem celiņiem daudzslāņu montāžas gadījumā ir murgs. Precīzi. Par to, ka vienai arhitektūrai daudz kas ir vienādi, pilnīga taisnība. Atceros, vienreiz pie diezgan nikna priekšnieka čaļi uztaisīja daļu optimizācijas serverim ar ASM, pieslīpējot tieši konkrētam AMD procim. Kad tur nomainīja dzelžus, sistēma palika lēna. Droši vien ne vienmēr viss ir tik vienādi. Divi impulsi, taču tomēr katrs pa savu kanālu? Skatoties, ka daudz kur ir 4*4 kanāli un vēl jāmēra intensitāte, tiešām ASM ir jauks. Laika kritiskām sistēmām jau izmanto visu laiku. Zenītraķetes viens piemērs. Link to comment Share on other sites More sharing options...
M_J Septembris 8, 2018 Share Septembris 8, 2018 Pirms 18 minūtēm , rnxx teica: Divi impulsi, taču tomēr katrs pa savu kanālu? Konkrētais piemērs tika taisīts, lai pārbaudītu pieslīpētu fāzu detektora darbību vienā PLL sistēmā. Protams, kontrolierim vēl bija vajadzīga saite ar "ārpasauli", konkrētajā gadījumā tas tika realizēts caur SPI portu. Visa darīšanās ar impulsiem tika realizēta taimera pārtraukumos un, kaut arī procesors salīdzinoši lielu laika daļu atradās pārtraukumos, galvenajā cilpā viņam vienalga nebija īsti ko darīt, izņemot saziņu pa SPI portu un tur varētu viņam uzticēt lērumu citu lietu, bet konkrētajā gadījumā nebija jau īsti ko viņam likt vēl darīt. Cits, salīdzinoši nesen realizēts piemērs ir trīsfāzu sinhronā ģeneratora ierosmes tiristoru/diožu tilta vadība ieskaitot sprieguma un fāzes kontroli ierosmes statora tinumā, strāvas kontroli rotora tinumā + sprieguma un tā fāzes kontrole ģeneratora un tīkla katrā fāzē + iekšdedzes motora apgriezienu piestūrēšana lai sinhronizētu ģeneratoru ar tīklu + jaudas slēdža vadība ģeneratora saslēgšanai ar tīklu + strāvas kontrole katrā fāzē, aktīvās un reaktīvās jaudas mērīšana motora piestūrēšana lai iegūtu prasīto jaudu un ierosmes regulēšana, lai nodrošinātu vajadzīgo cos (fi), kad ģenerators ir saslēgts ar tīklu + visas aizsardzības un tādi sīkumi kā motorstundu un saražoto aktīvo un reaktīvo kilovatstundu skaitīšana + saziņa ar apkārtējo pasauli caur Modbus RTU. Tas ir gadījums, kad vienam procesoram tika uzkrauti diezgan daudz, bet salīdzinoši lēni procesi. ATMEGA8 ar to tiek galā. 1 1 Link to comment Share on other sites More sharing options...
AndrisBB Septembris 8, 2018 Share Septembris 8, 2018 Šī diskusija par signāliem liek atcerēties vienu projektu, kur bij mūžigā strīdēšanās ar elektroniķiem. Ideja apmēram tāda ka bij pamatprocesors uz kura darbojas Linux, interfeiss, webservers utt un vairāki mikrokontrolieri, kuri monitorē sensorus. Mikrokontrolieri parastas "state" mašinas ar pāris stāvokļiem, bet elektroniķi nez kapēc bij izdomājuši ka steitu reportēs uz pamatprocesoru caur vienu pinu un izmantos periodisku signālu, kur signāla garums atbilst stāvoklim (Patīk nezkapēc viņiem tie signāli). Viņu argumentācija jau skaidra, vienkāršāks PCB (tik viens celiņš no katra kontroliera) un mazāk programmēšana. Tik tas ka Linux driverī pēctam čakars nepajokam, kad jāmēra signāla garumus no 16 sensoriem viņus neinteresē. Driverim draudzīgāka ideja ka to signāla celiņu izmantot kā interruptu un tad stāvokli nolasīt caur i2c vai citu busu tika noraidīta. Beigās kad sensoru skaits pieauga līdz 32 tad nāca saldā uzvara pār elektroniķiem un viņi tika spiesti ieviest I2C busu Link to comment Share on other sites More sharing options...
M_J Septembris 8, 2018 Share Septembris 8, 2018 Tad beigās visi tie 32 sensori sēdēja uz viena I2C busa? Link to comment Share on other sites More sharing options...
AndrisBB Septembris 8, 2018 Share Septembris 8, 2018 Jā, reāli tā bij daudz vienkāršāk un ātrāk nolasīt viņus tādā secībā kādā tika reģistrēti interrupti (reti kad relatīvi vienlaicīgi notika izmaiņas vairāk kā 2 sensoros) nekā nepārtraukti monitorēt 32 signālus un skatīties vai nav izmaiņas. Link to comment Share on other sites More sharing options...
rnxx Septembris 8, 2018 Share Septembris 8, 2018 M_J Tas ir kā, piemēram, koğenerācijas staciju saslēgšanai ar tīklu? Kur ārā izdotā kvalitāte un sinhronizācija ar tīklu ir svarīga, bet lielas ēkas un inženieru uz vietas nav? AndrisBB Ieinteresēja, kā informāciju salīdzina, piemēram, robotikā vai zenītraķetēs. Piemērs. Sensors ir ar nosacītu gradādiju 1 - 100, piemērs 0,1,2,...99...100 Grupā trīs nosacītie sensori, katram signāla gradācija pa 1,0 no 0 līdz 100. Sensors sadalīts 7 sektoros, katrā sanāk pa 300 variantiem, jo grupā 3 nosacītie sensori. Rezultātā ir vismaz 2100 ievades varianti, reāli daudz vairāk. Kā ātri apstrādāt šādu info un sistēmai pieņemt lēmumu? Tādu kodēt ASM vai tomēr kur citur? Piemērs ir kombinēts UV un divspektru IK (infrasarkanais ) detektora galviņa. Link to comment Share on other sites More sharing options...
M_J Septembris 8, 2018 Share Septembris 8, 2018 Pirms 3 minūtēm , rnxx teica: Tas ir kā, piemēram, koğenerācijas staciju saslēgšanai ar tīklu? Tā arī ir koģenerācijas stacijas saslēgšana ar tīklu. 1 Link to comment Share on other sites More sharing options...
AndrisBB Septembris 8, 2018 Share Septembris 8, 2018 Pirms 3 minūtēm , rnxx teica: Kā ātri apstrādāt šādu info un sistēmai pieņemt lēmumu? Domāju ka FPGA vai ASIC būs atbilde Link to comment Share on other sites More sharing options...
ggg97 Septembris 8, 2018 Share Septembris 8, 2018 pirms 10 stundām , M_J teica: Zvanīju pazīstamiem ļaužiem, kas strādā lielajos HESos, kas strādā pie kurzemes loka projekta. Domāju - viņi savā ikdienas darbā ar to noteikti būs saskārušies un uzreiz pateiks risinājumu. Te ir tāpat, kā ar ķirurgiem, vieni operē sirdis, citi - smadzenes, citi atkal dibenus. Vispārējās līnijās visi par visu zina, bet par konkrētu problēmu savā jomā zina tikai savas jomas ķirurgs. Link to comment Share on other sites More sharing options...
AndrisBB Septembris 8, 2018 Share Septembris 8, 2018 Runājot par raķetēm, tad man tepat 5 minūšu gājienā no mājas atrodas MBDA iestāde, kas nodarbojas ar raķešu sistēmām un visādu citu aprīkojumu. Vienu dienu skatos tur notiek "atvērto durvju dienas", domāju aiziešu paskatīšos kas interesants, tik tas ka ar latviešu pasi mani neieielaida iekšā pat aprunāties. Tas laikam tuvākais cik esu bijis raķetēm Link to comment Share on other sites More sharing options...
ggg97 Septembris 8, 2018 Share Septembris 8, 2018 (labots) Pirms 15 minūtēm , M_J teica: Tā arī ir koģenerācijas stacijas saslēgšana ar tīklu. Vot pie viņiem arī bija jāinteresējas, nevis jāmeklē jauns ritenis pie svešiem. Ir relejnieki un ir primāti - primāro ķēžu inženieri. Ir jābūt kādam, kurš šitos prot saganīt, sasaistīt vienā projektā. Labots Septembris 8, 2018 - ggg97 Link to comment Share on other sites More sharing options...
rnxx Septembris 8, 2018 Share Septembris 8, 2018 AndrisBB Tiem jau nav tipa Stinger vai Verba. Kam it kā esot tie <7cm diametra galviņas ar multispektra analīzi. Par 20 gadus vecu variantu cirkulē info, ka 7 cores ar ap 33 MHz takti esot jūzotas. Cik precīza info, nav ne jausmas. Tad vēl programmas maiņa, nomainot vienu čipu ( 90 ajos ). Link to comment Share on other sites More sharing options...
M_J Septembris 8, 2018 Share Septembris 8, 2018 Pirms 1 minūtes , ggg97 teica: Vot pie viņiem arī bija jāinteresējas, nevis jāmeklē jauns ritenis pie svešiem. Kā es pie viņiem interesēšos, ja tieši viņi man palūdza to problēmu risināt. Nu neaizraujas tajās koģenerācijas stacijās neviens ar teoriju. Visi labprātāk "sunīšus baro" nevis "podziņas spaida". Link to comment Share on other sites More sharing options...
ggg97 Septembris 8, 2018 Share Septembris 8, 2018 (labots) Nu tad sorry, karogs Tev rokā! p.s. ar koģenerāciju ir jāņem vērā, izvēloties vadus un kabeļus, ka tā manta ilgstoši griezīsies uz maksimālo jaudu, nodrošinot saimniekam maksimālo peļņu. Atšķirībā no, piemēram, dzīvokļu elektroapgādes, kur ne visi griezīs plītis un veļmašīnas vienlaicīgi, attiecīgi ir pielietojams vienlaicības koeficents. Labots Septembris 8, 2018 - ggg97 Link to comment Share on other sites More sharing options...
abi Septembris 8, 2018 Share Septembris 8, 2018 izp tos OIK kodeģenerātus ?️? Link to comment Share on other sites More sharing options...
Ronalds Septembris 9, 2018 Share Septembris 9, 2018 Runājot par asambleru. Skatos te ir vismaz viens, kurš viņā mauc. Bet mūsdienās tendence ir tāda, ka viss notiekas arvien augstāka līmeņa valodās, jo tā ir vienkāršāk! Un lētāk! Ja nevelk, lētāk ir paņemt jaudīgāku dzelzi. Nevis meklēt un maksāt asm specem. Bez tam softa izstrādes laiks asm būs lielāks. Kods sanāk krietni grūtāk lasāms. Ja koda autors aiziet no darba, tad citam (pat specam) pārņemt projektu būs ļoti grūti. Par raķetēm gan neko nezinu. Tur gan jau ka citi spēles noteikumi! Bet tā pati ģeneratora sinhronizācija ar tīklu - tur nu nekādu asambleru 100% nevajag. Link to comment Share on other sites More sharing options...
Inspektors Caps Septembris 9, 2018 Share Septembris 9, 2018 pirms 13 stundām , M_J teica: Gribu pāriet STM32. Tur gan ir izdarīts viss, lai negribētos programmēt assemblerī Nekā tamlīdzīga. Pat gatavais startup fails ir asamblerī un pat tas ir triviāls. Tas satur konstantu pārtraukumu vektoru tabulu un kodu, kas inicializē data un bss sekcijas, izsauc C standartbibliotēkas inicializāciju un Tavu main() funkciju. Izdzēs nevajadzīgo no tā un raksti main() un pārējo asamblerā. Cita lieta, ka tas no darba viedokļa ir neefektīvi. Mūsdienu C kompilatori ar attiecīgu optimizāciju ģenerē ļoti labu kodu un tādēļ 98% koda top C. Asamblerā raksta tikai arhitektūras specifiskas un atsevišķas īpaši svarīgas funkcijas. Daži pat raksta C++. Tur gan, ja izmanto C++ "krutās" fīčas, tad kods vairs nav "caurspīdīgs", bet, ja neizmanto, tad no tā nav jēgas, jo tas pats C vien sanāk. Lai vai kā, asamblers, C un C++ ļoti labi sadzīvo un var izmantot kaut visus trīs vienā projektā. pirms 13 stundām , AndrisBB teica: piemēram uzrakstīt RTOS vai TCP/IP staku Assamblerī būtu interesanti Nu, interesanti ir daudz kas, bet vai lietderīgi? C rakstīts IP steks ir uzreiz izmantojams uz daudz platformām, bet asamblerā rakstīts būs ierobežots vienai. Ar RTOS tas pats, tikai ar piezīmi, ka tur platformas specifiskās daļas jau tāpat ir un būs rakstītas asamblerī. Manuprāt, ja iegulda lielu darbu, tad ir tikai loģiski to izmantot pēc iespējas vairāk sistēmās. pirms 12 stundām , M_J teica: Nezinu, kā kaut ko tādu izdarīt ne Assemblerī. AVR un PIC ir vienkāršas CPU arhitektūras ar 2 posmu konveijeru, un tādēļ arī relatīvi lēnas. Palielinoties CPU ātrumam, ir jāpalielina konveijera posmu skaits, kas savukārt velk līdzi vēl citus pribambasus. Cortex-M0+ arī ir 2 posmu konveijers, bet Cortex-M3/M4 jau 3 posmu un ar branch prediction. Cortex-M7 ir vēl krietni savādāks zvērs ar 6 posmu konveijeru, branch predicion, tas ir superskalārs (var izpildīt divas instrukcijas vienā taktī) un parasti tiek komplektēts ar kešatmiņu. Papildus vēl arī flash atmiņa nestrādā tik ātri, cik CPU, un tādēļ arī tai ir buferis un aizture vairākas taktis. Arī pārtraukumiem ir 12 taktu aizture. Tas nav specifiski STM32, bet gan procesora arhitektūrai, kas tiem ir ARM. Un arī ARM te nav unikāls, jo tā ir visām arhitektūrām priekš attiecīga ātruma. Jaudīgie STM32F7 strādā līdz 216 MHz un STM32H7 vispār 400 MHz, un, tā kā tie ir Cortex-M7, tad vēl izpilda divas instrukcijas vienā taktī. Pilnai jautrībai, otrajam visa perifērija, tai skaitā GPIO un taimeri, nemaz nevar strādāt ar CPU frekvenci, bet gan līdz 200 MHz. Tā visa dēļ, jo ātrāks CPU, jo grūtāk ir uzrakstīt kodu, kas vienmēr izpildās konkrētā taktu skaitā. Bet lielo MCU pasaulē tā ir problēmas risināšana fundamentāli nepareizā veidā un, kā jau AndrisBB teica, tas minētais uzdevums ir priekš hardware taimeriem un, ja vajag DMA, bet CPU tikai konfigurē un vada tos. Tiem, kuri nāk no maziem MCU, lai būtu priekšstats par STM32 taimeriem, iesaku iziet cauri šai prezentācijai. pirms 3 stundām , Ronalds teica: mūsdienās tendence ir tāda, ka viss notiekas arvien augstāka līmeņa valodās Ja nevelk, lētāk ir paņemt jaudīgāku dzelzi. Šie ir meli mežaveču un usveru stilā, kuri nespēj domāt tālāk par savu kases aparātu ikdienu. Pirmajā maldi ir vārdā "arvien". Jā, mikrokontrolieru programmatūras izstrāde galvenokārt notiek augstāka līmeņa valodās par asambleru - pārsvarā C un dažkārt C++, bet nekādu "arvien augstāk" nav. Mikrokontrolieros Java, .NET, Python un tamlīdzīgus brīnumus darbina tikai visādi amatieri saviem puķupoda temperatūras mērīšanas "projektiem". Realitāte ir tāda, ka programmēt dzelžus ar C ir ne tikai efektīvāk, bet pat arī vieglāk, bet lameriem to nesaprast. Otrajā maldi ir tajā, ka vienmēr var paņemt jaudīgāku. Ja ir low-power ierīce, kas darbojas no akumulatora vai pat monētas tipa baterijas, tad Tu nevari paņemt jaudīgāku dzelzi un notriekt enerģiju bezjēdzīgai bloatware koda darbināšanai. Un arī daudz citos gadījumos, kad ražo 100+ eksemplārus, to nevar dēļ gala produkta cenas. Asamblers pār C gandrīz nekādu performanci nedos, bet, ja ir runa par vēl krietni augstāka līmeņa valodām, tad Tavs produkts vienkārši nebūs konkurētspējīgs ar manu C rakstīto. 3 Link to comment Share on other sites More sharing options...
rnxx Septembris 9, 2018 Share Septembris 9, 2018 Ir tendence veidot valodas un vides ar maksimāli īsu izstrādes laiku. Biznesmeņi jau uzskata, ka Java ir par ilgu izstrādes laiks. Algas grib ietaupīt pirmkārt, visi ir skopi kā velni. Par programmēšanas popularitātes burbulis āfrikā būs, tad izstrāde būs lētāka. Outsourcēt varēs uz Nigēriju, Angolu. Tagad bēdīgi, tikai Ķīna, Indija, Vjetnama, Pakistāna, Ķīna un Bangladeša. pirms 4 stundām , Ronalds teica: Runājot par asambleru. Ja koda autors aiziet no darba, tad citam (pat specam) pārņemt projektu būs ļoti grūti. Tas ir tieši tas vislabākais variants, lielākas izredzes uz normālu algu un attieksmi. Citādi visi grib lai raksta tā, ka cilvēkus viegli aizvietot. Jo sliktāk saprotams kods un vairāk problēmu jo ilgāk būs darbs. 2 Link to comment Share on other sites More sharing options...
Inspektors Caps Septembris 9, 2018 Share Septembris 9, 2018 (labots) Pirms 48 minūtēm , rnxx teica: Ir tendence veidot valodas un vides ar maksimāli īsu izstrādes laiku. Biznesmeņi jau uzskata, ka Java ir par ilgu izstrādes laiks. Te taču ir runa par mikrokontrolieriem, nevis par kaut kādām IT sistēmām. Parādiet reālus produktus, kur mikrokontrolieri darbina Java vai ko tādu, nevis tikai dzenājiet datorzinātņu profesoreļu teoriju! Pirms 48 minūtēm , rnxx teica: Outsourcēt varēs uz Nigēriju, Angolu. Tieši minētajam ražotājam ST koda izstrāde jau notiek tieši tur. Rezultātā kods ir milzīgs, lēns, kļūdains, nekorekts un vienkārši lameriskā studentu līmenī. Sanāk, ka it kā viņi kaut ko programmē, bet jēga no tā de facto ir gandrīz nulle, jo, kad vajag radīt nopietnu produktu, gandrīz viss ir jāraksta pašam. Tai pat laikā tādi balto cilvēku izstrādāti pat atvērti bezmaksas projekti kā FreeRTOS un lwIP kvalitātes un lietojamības ziņā, salīdzinot ar multimiljonu multinacionālas kompānijas algotu nigēriešu kodu, ir tālu kosmosā. Labots Septembris 9, 2018 - Inspektors Caps 1 Link to comment Share on other sites More sharing options...
M_J Septembris 9, 2018 Share Septembris 9, 2018 Pirms 57 minūtēm , Inspektors Caps teica: Tā visa dēļ, jo ātrāks CPU, jo grūtāk ir uzrakstīt kodu, kas vienmēr izpildās konkrētā taktu skaitā. Bet lielo MCU pasaulē tā ir problēmas risināšana fundamentāli nepareizā veidā un, kā jau AndrisBB teica, tas minētais uzdevums ir priekš hardware taimeriem un, ja vajag DMA, bet CPU tikai konfigurē un vada tos. Tas jau arī iemesls, kas atsit apetīti ar šitiem zvēriem kaut ko darīties ASMā. Pirms 44 minūtēm , rnxx teica: Jo sliktāk saprotams kods un vairāk problēmu jo ilgāk būs darbs. Šitais atgādina vienu anekdoti: Dēls pārņem tēva advokāta kantori. Pirmajā dienā atnāk no darba un priecīgs stāsta tēvam: - Šodien es atrisināju to sarežģīto lietu, ar kuru Tu netiki galā 30 gadus. - Un no kā Tu muļķi turpmāk dzīvosi? 1 Link to comment Share on other sites More sharing options...
Inspektors Caps Septembris 9, 2018 Share Septembris 9, 2018 (labots) pirms 1 stundas , M_J teica: Tas jau arī iemesls, kas atsit apetīti ar šitiem zvēriem kaut ko darīties ASMā. Bet kādēļ spītēties un darīt lietas nepiemērotā veidā? Asamblers un CPU izpratne kā tādi jau nekur nepazūd. Arī ar tiem CPU varēsi lieliski programmēt asamblerā to, ko reāli vajag vai ir izdevīgi tā rakstīt. Es te nestrīdos, bet mēģinu parādīt ceļu uz efektīvu risinājumu. Izej cauri tai manis iepriekš dotajai prezentācijai par STM32 taimeriem un redzēsi, cik lielisks instruments tas ir priekš Tevis aprakstītajiem uzdevumiem. Tur var ne tikai ar vienu taimeri ģenerēt un capturēt 4 kanālu PWM, bet arī iegūt citas signāla formas, savienot vairākus taimerus sinhroni, ielikt dead-time, mainīt signāla parametrus ar DMA palīdzību no masīva atmiņā un vēl visu ko. Labots Septembris 9, 2018 - Inspektors Caps 1 Link to comment Share on other sites More sharing options...
M_J Septembris 9, 2018 Share Septembris 9, 2018 Pirms 2 minūtēm , Inspektors Caps teica: Bet kādēļ spītēties un darīt lietas nepiemērotā veidā? Negribu spītēties un darīt lietas nepiemērotā veidā. Tāpēc jau arī gribu ķerties pie STM32. Ar AVR man tas nesanāk sevi salauzt un pāriet uz C. Pārāk mīļš un pierasts tas ASMs. Vairākkārtīgi esmu to mēģinājis un atkritis atpakaļ uz ASMu. Pārejot uz C tāda sajūta, kā uzvelkot rokā dūraiņus un tad mēģināt lodēt uz plates smalkas SMD detaļas. Sajūta tāda, ka pazaudēju kontroli pār notiekošo. Kad vēl paskatos kompilatora saģenerēto ASM kodu, neizturu un krītu atpakaļ. Ar STM32, kur tāda bezmaz vai fiziska notiekošā procesa izjūta nav izveidojusies ceru izrauties no šī apburtā loka. 1 Link to comment Share on other sites More sharing options...
rnxx Septembris 9, 2018 Share Septembris 9, 2018 (labots) Īsti nesaprati, tā nav profesoru teorija, bet gan prakse. Nevis mikrokontrolieriem, bet atziņa, ka Java lūk esot par ilgu izstrādes laiks biznesa sistēmām. Atziņas rezultāts ir Scala, Clojure, Kotlin. Izstrādes laiks īsāks. Erlang ekosistēma dažos gadījumos ir lingua franca. Par daudz jāmaksā izstrādātājiem? Top Elixir, kurā kaut ko uztaisīt var ātrāk. Skopums valda pār pasauli. Ideālā pasaule būtu kaut kāds Prolog mikslis ar citām ļoti augsta līmeņa valodām. Nigērijā un Angolā uzkodēs un miers. C jau arī ir augsta līmeņa valoda, ja salīdzina ar ASM. Viņi jau skopi kā velni, katru $, kas jāmaksā cilvēkam vērtē dārgāk nekā devaisu izmaksas dolāru. Mobilie vien, 1 kodola un 128 MB RAM vietā tagad 4 - 8 kodoli un 1 - 3 GB RAM. Būs mobilie ar 6 GB RAMu, 16 kodoliem un visu sagremos. Telefoni ir jāražo, kad ražosim ēdelīgas programmas, tad cilvēki pirks dārgus telefonus bieži. Tas palielina peļņu ražotājiem un tirgotājiem. To pašu Vistu kā palaida, jaudīgāku kompju pirkšana taču pieauga. Labots Septembris 9, 2018 - rnxx 2 Link to comment Share on other sites More sharing options...
Inspektors Caps Septembris 9, 2018 Share Septembris 9, 2018 Pirms 6 minūtēm , M_J teica: Pārejot uz C tāda sajūta, kā uzvelkot rokā dūraiņus un tad mēģināt lodēt uz plates smalkas SMD detaļas. Sajūta tāda, ka pazaudēju kontroli pār notiekošo. Ar C kontrole nezūd, jo tas neveido apakšā nekādas advancētas konstrukcijas. Sarežģītākās abstrakcijas tur ir masīvu un struktūru elementu adrešu un pointeru aritmētika, bet tās ir skaidri dokumentētas triviālas lietas. Viss! Kontrole sāk zust ar C++, jo tur parādās konstruktori, destruktori, visāda veida metodes, templeiti, operatoru overloading un citas jau tiešām augstas abstrakcijas. Tiesa, ja pats ievēro stingru disciplīnu, tad pat C++ var kontrolēt situāciju, bet tad, kā jau teicu, zūd jēga no paša C++ un tas pārvēršas par gandrīz to pašu C. Tā kā ir svarīgi kārtīgi iepazīties ar C un nejaukt to ar C++, kas ir ļoti izplatīti. Pirms 16 minūtēm , M_J teica: Kad vēl paskatos kompilatora saģenerēto ASM kodu, neizturu un krītu atpakaļ. Kompilatoram ir dažādi optimizācijas līmeņi un mērķi. Pie O0 tiešām ir "liekas" instrukcijas, bet tas ir, lai varētu ērti debugot C kodu ar breakpointiem un visu citu. Savukārt pie O2 un O3, tas ģenerē tādu kodu, kādu, lai ar rokām uzrakstītu, pie tā būtu jāsēž tiešām ilgi. Tās ir optimizācijas for speed, bet vēl ir Os (for size), kas ģenerē kodu, kas ir pēc iespējas mazāks. Kad vajag, tā vienkārši ar vienu opciju varam uzģenerēt pavisam citādi optimizētu kodu. Pie tam izmēra samazinājums dēļ šī vien būs nevis daži %, bet gan kādi 10-30 %. 1 stundu atpakaļ, rnxx teica: Mobilie vien, 1 kodola un 128 MB RAM vietā tagad 4 - 8 kodoli un 1 - 3 Gab RAM. Pats fakts, ka tagad ir tik jaudīgi mobilo ierīču procesori, ir super. Esmu tikai par attīstību! Bet programmatūra atpaliek vienkārši drausmīgi. Android ir absolūti fundamentāli nepareiza bloatware. Apple iOS vēl kaut cik pareizā virzienā, bet arī ne ideāla. Savā ziņā vismaz konceptuāli Symbian bija pareizais balanss priekš mobilām ierīcēm. Pirms 25 minūtēm , rnxx teica: Ideālā pasaule Ideālā pasaule ir komunisms, bet tā ir tikai teorētisks fantazjoru koncepts un praksē nestrādā, jo ir pretrunā ar evolūciju. Bet par tēmu, tas, ko saki, ir taisnība, bet tas nav par mikrokontrolieru pasauli. Tas ir par IT, smartfoniem un citām jomām, kur nav vajadzīga ne top līmeņa performance, ne kvalitāte, ne izmaksas, ne kas cits tamlīdzīgs. Tur kur kaut kādā ziņā vajag top līmeni, tur ir citi noteikumi. Visi tie high-level risinājumi ir tikai aisberga redzamā daļa parastajam cilvēkam. Bet to, ka viņa automašīnā, sadzīves tehnikā un citur ir jau pilns mikrokontrolieriem, kuri darbina ASM/C/C++ rakstītas programmas, kas ir maksimāli optimizētas tam vai citam aspektam, parastais cilvēks neredz. Un tas pats ir ar teorētiķiem profesoriem un citiem sausiņiem. Tā ir arī lielākā Latvijas augstskolu kļūda, ka tur ir gandrīz tikai akli teorētiķi, kuri rada IT sistēmu un weblapu cepējus. Līdz ar to elektroniku, mikrokontrolierus un to programmēšanu šeit gandrīz neviens nesajēdz, bet mūsdienu pasaulē bez tā visa nopietna tehnikas ražošana vienkārši nav iespējama. Šis aklums piemīt gan tautai, gan valdībai un, kamēr tā būs, nopietna attīstība mūsdienu tehnoloģiskajā pasaulē šai valstij "nedraud". 2 Link to comment Share on other sites More sharing options...
rnxx Septembris 9, 2018 Share Septembris 9, 2018 Ideālā pasaule bija domāta no naudasmaisu viedokļa. Maksimāli samazināts izstrādes laiks cilvēkstundās. Izstrādātāja stundas tarifu maksimāli zemu. Tāpēc ir āfrikas, kur aktīvi promotē programmēšanas bumu, visādās Bangladeša, Indonēzija. Programmēšana kā biļete aizbēgt no nabadzības. Indija ar savu augstskolu bumu. Pakistāna arī tagad sāk Indijas ceļu. Protams, visu tā neizstrādāt, bet skopums spīd cauri visur. Latvijā jau arī, kaut klients tāpat atrodas Londonā, Rēzeknē, D-pilī vai Jēkabpilī algu par to pašu darbu mazāku kā Rīgā. Argumenti, tip depresīvas vietas, dzīve esot lēta ( paika veikalā ņifiga nav lētāka ). Uzmanās ka tik darbinieks nevarētu kaut ko sakrāt. Tā taču naudasmaisam nelaime. Tāpat jau ļoti var ietaupīt uz NĪ cenu vai nomu. Nepietiek, arī algas jāsola mazas. Skopums. 2 Link to comment Share on other sites More sharing options...
AndrisBB Septembris 9, 2018 Share Septembris 9, 2018 pirms 3 stundām , M_J teica: Tāpēc jau arī gribu ķerties pie STM32 Šī ir diezgan laba grāmata iesākumam https://leanpub.com/mastering-stm32 Vēl jau ir STM8, kas gan ir pavisam cits zvērs, bet vismaz ekosistēma tāpati. Iesākumam draudzīgākie manliekas ir Silicon Labs EMF32, ja svarīgs ir enerģijas patēriņš, tad viņiem ir vairāk visādas power saving modes un iespējas kā STM32. Visi tie PIC un AVR patīk parasti elektroniķiem, bet no programmēšanas viedokļa ir diezgan lielas pārcenotas kakas, kautvai vienkarši salīdzinot pašu vienkāršāko STM32F0 ar līdzīgas cenas AVR, var iegūt pavisam citas takts frekvences, hardwāres funkcijas, daudz vairāk flash/ram utt. Kautkad senāk jau teicu un linku uz dokumentu devu, bet diezgan laba alternatīva C/C++ ir Rust. Viens no labākajiem salīdzinājumiem ko esu atradis ir te https://brage.bibsys.no/xmlui/bitstream/handle/11250/2352353/12925_FULLTEXT.pdf. Mazliet pats kautko padariju un varu teikt ka strādā labi un kautkādā ziņā ir pat programmēt ērtāk un patīkamāk nekā C, tik mazliet "augstākā" līmenī, bet bez C++ bezjēdzībām. Protams aizņem laiku, lai iebrauktu Rust ideoloģijā. Miksēt C un Rust nav problēmu, pats rakstiju firmwari iekš Rust un salinkoju ar FreeRTOS un LWIP bez problēmām. Lielākā problēma laikam ir tā ka C parasti izmanto daudz direktīvas un #denine, kuri nav pieejami pa taisno no Rust un tapēc nākas vainu definēt par jaunu, vai arī taisīt C wrapperus. Šis ir ļoti sāpīgi kad vajag izmantot mikrokontroliera definīciju failus (peripheriālu addresses, visādi makrosi utt). Neesu gan izmēģinājis, bet manuprāt diezgan labi varētu darboties STM32 LL Hal bibliotēka, kuru vienkārši varētu ielinktot Rust applikācijā. Doma arī bij paskatīties kā varētu izmantot CubeMX ģenerētos projektu failus, lai uzbuildotu Rust kodu priekš mikrokontroliera initializācijas. 1 Link to comment Share on other sites More sharing options...
Inspektors Caps Septembris 9, 2018 Share Septembris 9, 2018 (labots) pirms 1 stundas , AndrisBB teica: Visi tie PIC un AVR patīk parasti elektroniķiem, bet no programmēšanas viedokļa ir diezgan lielas pārcenotas kakas Man gan neceļas rokas tos tā lamāt, jo jāņem vērā, ka PIC ir 1975. gada arhitektūra un AVR ir 1996. gada. Tādā ziņā visu cieņu - savam laikam labas mantas. Vienkārši šodien to un vispār 8-bit CPU laiks plašam patēriņam pa lielam ir pagājis un tie paliek tikai šauras nišas produkti kaut kam superspecifiskam. Ar 16-bit CPU notiek gandrīz tas pats. 32-bit CPU gan būs apkārt vēl ilgi vai pat "vienmēr", jo uzdevumi, ko ar tiem var paveikt, ir ļoti lieli. Tā kā tie dzīvos paralēli ar 64-bit procesoriem citās jomās. pirms 1 stundas , AndrisBB teica: diezgan laba alternatīva C/C++ ir Rust Jautājums sportiskas intereses pēc - kā Rust ir ar kaut kādām standarta bibliotēkām? pirms 1 stundas , AndrisBB teica: izmantot CubeMX ģenerētos projektu failus, lai uzbuildotu Rust kodu priekš mikrokontroliera initializācijas Mani secinājumi par CubeMX ģenerēto kodu no nopietnu projektu skatu punkta: Tas uzspiež savu koda struktūru, kas krietni ierobežo manu kodu. Un, tā kā to struktūru veido melni Nigērijas "indusi", tad tā ir nelietojama. Tas nav modulārs. Perifērijas funkcijas un aplikācijas loģika tiek sagāzti kopā vienos failos - nav augstāka līmeņa perifērijas komponenšu koncepta un attiecīga API slāņa. Nu, piemēram, kā Tavā sensoru piemērā, kur komponente "sensor hub" iekšā izmantotu attiecīgos GPIO/EXTI, I2C, DMA un visu citu, kas attiecas uz tiem sensoriem. Un viens no lielākajiem feiliem ir tas, ka nav iespējas normāli veidot projektu, ko var kompilēt priekš dažādām platēm un konfigurācijām. FreeRTOS tiek lietots caur CMSIS-RTOS API wrapperi. Šeit kā reizi ir lieks abstrakcijas slānis. lwIP integrācija ir ne tikai ar nopietniem gadiem veciem bugiem, ko neviens pat netaisās labot, bet vispārīgi lameru līmenī. Es pa trīs vakariem uzrakstīju gan savu Ethernet draiveri, gan lwIP integrāciju ar zero-copy buferiem, ko viņi nespēs laikam nekad. Pat fiziskā savienojuma (link status) pārbaude viņiem ir implementēta ar papildus OS pavedienu, kas ir pilnīgs idiotisms, jo to var izdarīt ar gaidīšanas funkcijas timeout tur pat jau esošajā pakešu saņemšanas kodā. Kods ir liels, lēns, kļūdains, nekorekts un pilns ar neoptimālām konstrukcijām, kas nodod to, ka tās ir rakstījis lameris. Vārdu sakot, tas ir sliktas kvalitātes visos aspektos. Tas īsti neko nedod, jo uzģenerē tikai pinu un perifērijas konfigurācijas, bet tā ir mikroskopiska daļa no projekta, kas nav pat 5%. Pie tam pinu konfigurācija pēc plates izgatavošanas gandrīz nekad nemainās, bet, ja tā ir jāmaina darbības laikā, tad ģenerētais kods tieši ir šķērslis, ko jāapiet. Un perifērijas konfigurācijai nomainīt kādus parametrus kodā ir tieši tik pat viegli, cik GUI izvēlnēs. Rezultātā uzskatu, ka laiks, ko notērē cīņā ar CubeMX neskaitāmajiem bagiem un labojot, papildinot, apejot tā ģenerēto kodu, ir iztriekts veltīgi un to labāk veltīt laba sava koda uzrakstīšanai. Vispār CubeMX es izmantoju, bet tikai kā pinu un clocku konfigurēšanas instrumentu elektronikas izstrādē. Labots Septembris 9, 2018 - Inspektors Caps Link to comment Share on other sites More sharing options...
AndrisBB Septembris 9, 2018 Share Septembris 9, 2018 Pirms 17 minūtēm , Inspektors Caps teica: Vienkārši šodien to un vispār 8-bit CPU laiks plašam patēriņam pa lielam ir pagājis un tie paliek tikai šauras nišas produkti kaut kam superspecifiskam. Te ir relatīvi interesants salīdzinājums https://jaycarlson.net/microcontrollers/ Vēl interesantāka diskusija, kur viesos ir tas pats autors un viņš daudz labāk un detalizētāk argumentē savus secinājumus https://www.embedded.fm/episodes/226 Pirms 19 minūtēm , Inspektors Caps teica: Jautājums sportiskas intereses pēc - kā Rust ir ar kaut kādām standarta bibliotēkām? Droši vien ka jāsāk ar to ka standarta bibliotēka nav lietojama uz mikrokontroliera, jo balstās uz Posix un citām lietām. Bet ir Core bibliotēka (uz kuras balstās arī standarta biblioteka), kuru vajag obligāti, tur ietilps datu tipi, pointeri, dažādas pointeru manipulāciju metodes, 'primitīvi' stringi utt, te var redzēt sīkāk kādi moduļi tur ietilpst https://doc.rust-lang.org/core/. To nav problēmu crosscompilēt un tad ielinkot. Būtībā tādam tīram firmwares projektam neko vairāk arī nevajag. Ja gribas izmantot jau 'gudrākus' Stringus, vectorus utt, tad vajag atmiņas allocatoru. Pa defaulto Rust nāk ar 2 vai 3 allocatoriem starp kuriem var izvēlēties, bet neviens no viņiem neder mikrokontrolierim un nākas rakstīt pašam savu. Ir itkā pieejami vairāki varianti (noteikti ka tagad vairāk) iekš https://crates.io/ (tāda centralizēta biblioteku krātuve, kas trūkst priekš C), bet mans pagaidu risinājums bij vienkārši pārsūtīt visus Rust mallocus uz C mallocu. Ja tas viss strādā, tad neredzu iemeslu, lai citas bibliotēkas, kuras ir jēgpilnas priekš mikrokontrolliera nedarbotos. Iekš Crates.io bibliotēkas ir pieejamas gandrīz katrai lietai. Es nezinu vai es sāktu rakstīt nopietnu projektu iekš Rust, bet tādiem hobijprojektiem ir OK, kā arī kad atrisina tās fundamentālās problēmas, tad viss ir vienkāršāk. Sūdīgi ka nav pieejams tāds mikrokontrolierim draudzīgs TCP/IP staks un nākas rakstīt wrapperi ap LWIP. Tas pats attiecas uz RTOS. Pirms 53 minūtēm , Inspektors Caps teica: Rezultātā uzskatu, ka laiks, ko notērē cīņā ar CubeMX neskaitāmajiem bagiem un labojot, papildinot, apejot tā ģenerēto kodu Es viņu pārsvarā izmantoju lai setupotu kautkādus GPIO/timerus etc, pēctam copy/paste uz vajadzīgo projektu. Līdz kautkādam līmenim, tos templeitus ko izmanto CubeMX var palabot, viņi izmanto Apache FreeMarker .ftl template failus. Link to comment Share on other sites More sharing options...
AndrisBB Septembris 9, 2018 Share Septembris 9, 2018 Piemēram reku tāds pavisam vienkāršs un naivs kods (bez error chekiem utt), kur es uzrakstiju wrapperi ap lwip un Freertos #![no_std] #![feature(lang_items)] #![allow(dead_code)] use super::lwip; use super::rtos; use super::lora; use super::core::ptr; use super::core::mem; const payload:&'static str = "{\"stat\":{\"time\":\"2017-10-22T14:33:00+00:00\",\"lati\":46.24000,\"long\":3.25230,\"alti\":145,\"rxnb\":2,\"rxok\":2,\"rxfw\":2,\"ackr\":100.0,\"dwnb\":2,\"txnb\":2}}"; #[no_mangle] pub extern "C" fn task_upstream(args: *const u32) { let conn; let server_ip; let token = 1; let message = lora::PushDataPkt { protocol_version: 0x01, token: token, identifier: 0x00, eui: [1,1,1,1,1,1,1,1] }; server_ip = lwip::Ipaddr::new(192, 168, 2, 228); conn = lwip::Netconn::new(0x20); if conn.connect(&server_ip, 45678) != 0 { conn.delete(); } while true { let buf = lwip::Netbuf::new(); let ptr: &u8 = unsafe {mem::transmute_copy(&&message)}; if buf.reference(ptr, 12) == 0 { conn.send(&buf); } if buf.reference(payload.as_ptr(), payload.len()) == 0 { conn.send(&buf); } buf.delete(); rtos::task_delay(2000); } } extern "C" { fn _Error_Handler(file: *const u8, line: u32); } Link to comment Share on other sites More sharing options...
rnxx Septembris 9, 2018 Share Septembris 9, 2018 pirms 1 stundas , Inspektors Caps teica: Un, tā kā to struktūru veido Nigērijas ", tad tā ir nelietojama. Kods ir liels, lēns, kļūdains, nekorekts un pilns ar neoptimālām konstrukcijām, kas nodod to, ka tās ir rakstījis lameris. Vārdu sakot, tas ir sliktas kvalitātes visos aspektos. To koderu priekšnieki bieži ir ar uzskaitveža domāšanu. Nekādi datoriķi, drīzāk naudas skaitītāji. Par koda daudzuma mākslīgu palielināšanu, man liekas, daudzviet tur developeri vērtē pēc sarakstīto rindiņu daudzuma stundā. Indikatori tam ir vairāki piemēri. Čalim iedod lielas firmas kontraktor- firmā taisītu gabalu priekš moduļa. 135000 rindiņas koda, tajā gabalā kaut kāda funkcionalitāte realizēta ar 55000 rindiņām. 20000 rindiņas izslēgtas no spēles, bet sorcē atrodas, tad 60000 rindiņu izslēgtas ar log ielāpu. Salīdzinājumam students to funkcionalitāti realizēja ar 30000 rindiņām. 30000 v.s 135000. Link to comment Share on other sites More sharing options...
rnxx Septembris 9, 2018 Share Septembris 9, 2018 pirms 3 stundām , AndrisBB teica: Viens no labākajiem salīdzinājumiem ko esu atradis ir te https://brage.bibsys.no/xmlui/bitstream/handle/11250/2352353/12925_FULLTEXT.pdf. Paldies par šo, palasīju, būs jāpapēta ko var uztaisīt ar Rust. Kas attiecas uz elektroniķi mīl ASM, tas visdrīzāk augstskolas dēļ. Cik nu pakomunicēts ar tiem, kas ASV mācījušies el inženieriju, elektroniku, el tehn datorvadību, tiem studējot likts kārtot kursu par ASM. Tur padaudz kredītstundu, salīdzinot ar CompSci un SwE programmām. Viņiem tur, piemēram, 5 - 6 punktu kurss par Asamblerīšiem un opcionāli 2-4 punktu par C&C++. CompSci programmās drīzāk otrādi; C/C++ studiju kursi lielāki un mandatory, Asamblerīšus piedāvā kā izvēles kursu. Kur obligāti, stundu tāpat mazāk kā EE programmās. Link to comment Share on other sites More sharing options...
138 Septembris 9, 2018 Share Septembris 9, 2018 pirms 6 stundām , Inspektors Caps teica: Android ir absolūti fundamentāli nepareiza bloatware. Apple iOS vēl kaut cik pareizā virzienā Uz diviem pirkstiem, lūdzu - kāda ir tā fundamentālā pareizība/nepareizība? Pirms 55 minūtēm , rnxx teica: 135000 rindiņas koda, tajā gabalā kaut kāda funkcionalitāte realizēta ar 55000 rindiņām. 20000 rindiņas izslēgtas no spēles, bet sorcē atrodas, tad 60000 rindiņu izslēgtas ar log ielāpu. Link to comment Share on other sites More sharing options...
Recommended Posts
Izveido kontu, vai pieraksties esošajā, lai komentētu
Jums ir jābūt šī foruma biedram, lai varētu komentēt tēmas
Izveidot jaunu kontu
Piereģistrējies un izveido jaunu kontu, tas būs viegli!
Reģistrēt jaunu kontuPierakstīties
Jums jau ir konts? Pierakstieties tajā šeit!
Pierakstīties tagad!