# Cits ... >  C array[] ciparu ierakstīšanas metodes ?

## Epis

Tagat vēljoprojām pārtaisu  to VisualC# kodu un nonācu līdz tiem datu laukuem (array) kurīsti nav skaidrs vai tajā parastajā C valodā ir kautkādas īdzīgas fičas kā tajā C# ? 
piemēram visual C# es definēju jaunu Pdata[6] lauku kad man vaidzēja sagrupēt secībā iegūtos aprēķunu datus un tad tos datus likt vēl lielākā Datu glabātuvē un tur tā operācija notika šādi:



```
Pdata= new double[] {1,Xspeed,Xpos2,Yspeed,Ypos2,Zspeed,Zpos2};
 GdataBuilder(Pdata);
Pdata = new double[] { 2, XaccelerationV, DecDistanceX, YaccelerationV, DecDistanceY, ZaccelerationV, DecDistanceZ };
GdataBuilder(Pdata);

//Vēlāk GdataBuilder funkcija
void GdataBuilder (double[] Pdata)
        {
        Array.Resize(ref Gdata, Gdata.Length + 7);

                       for (int i2=0; i2 < Pdata.Length; i2++)
                       {
                           try
                           {
                               Gdata[Gdata.Length - 7 + i2] = Convert.ToInt32(Math.Round(Pdata[i2], 0));
                           }
                           catch
                           {
                               Gdata[Gdata.Length - 7 + i2] = 0;
                           }

                       }

        }
```

  vai ir kāds cits veids kā ierakstīt tajā datu laukā vertības (īsāks pieraksta veids) pagaidām man ir tāds kods


```
Pdata[0] = 1;
                  Pdata[1] =Xspeed;
                  Pdata[2] =Xpos2;
                  Pdata[3] =Yspeed;
                  Pdata[4] =Ypos2;
                  Pdata[5] =Zspeed;
                  Pdata[6] =Zpos2;
```

 ?
Ja kāds grib gudri pateikt "Ej palasi kādu C grāmatu"tad pasakat kādu grāmātu un kurā vietā ir aprakstīta tā metode kādu man vaig.

----------


## Epis

Kautko esu izdomājis, šeit kods: 



```
GdataBuilder(1,Xspeed,Xpos2,Yspeed,Ypos2,Zspeed,Zpos2);

// vēlāk: 
        s32 Gdata[100];
        s8 Gdata_i =0;
void GdataBuilder{s32 a0,s32 a1,s32 a2,s32 a3,s32 a4,s32 a5,s32 a6)
        {
        Gdata[Gdata_i+0]=a0;
        Gdata[Gdata_i+1]=a1;
        Gdata[Gdata_i+2]=a2;
        Gdata[Gdata_i+3]=a3;
        Gdata[Gdata_i+4]=a4;
        Gdata[Gdata_i+5]=a5;
        Gdata[Gdata_i+6]=a6;
        Gdata_i=Gdata_i+7;
        }
```

 itkā kompilējās, un risinājumam nav nekāda vaina, bet varbūt ir kāda labāka alternatīva kā dabūt iekšā kādā datu laukā tās vērtības nerakstot papildus funkciju ??

----------


## Delfins

Klasiskais memcopy. Var arī padot struktūras pointeri, vai int masīvu pointeri.
tas ko tu dari - hardkore un līkumānija.

Kā jau teicu, ja nemāki vēl īsti pareizi kodēt, nelien pie dzelžiem - papraktizējies parasto softu rakstīšanai  ::

----------


## jeecha

Paaris pieziimes/ieteikumi:
1) tas ko tu dari ieksh C# un arii ieksh C izskataas ljoti pat tizli (es nestriideeshos ka tas straadaa, vienkaarshi par taadu kodu nopietnaa iestaadee tev izrautu rokas :: . Spriezhot peec taa ko tu pachkaa tajos masiivos - tur ljoti uzprasaas uz masiivu no struct vai objektiem, nevis vienkaarshi masiivu no double vai int vai uint32 vai whatever kaadiem mainiigajiem;
2) atshkjiriibaa no C# vai Java, C masiivi ir diezgan statiski objekti un izmeerus paaraak mainiit neveelas...taatad ir vairaakas iespeejas:
a) ja maksimaalais masiiva izmeers ir zinaams un konkreets tad daram apmeeram kaa tu (tikai lietojot masiivu no structiem uzskataamiibas un eertiibas labad);
b) ja masiiva maksimaalais izmeers nav zinaams tad atkal ir vairaakas iespeejas (C++ STL vector<> templeits protams buutu eertaakais bet laikam shai gadiijumaa jaaaizmirst par STL un templeitiem :: :
b1) masiiva vietaa lietot kaut vai linked listu (google: linked list) un jaunajiem masiiva biedriem atminju rezerveet dinamiski;
b2) lietot pointeri uz masiivu un ja pietruukst vietas dinamiski rezerveet atminju.

----------


## Velko

> risinājumam nav nekāda vaina


 OMFG, Epi!

Sadefinē vismaz datu struktūras normāli, lai kautko var saprast. Pēc 1/2 gada pats nojūgsies tajos masīvos. Varētu izskatīties ~ šādi:


```
struct point_dim {
    s32 speed;
    s32 pos;
    s32 accelerationV;
    s32 DecDistance;
};
struct point {
   struct point_dim X;
   struct point_dim Y;
   struct point_dim Z;
};

struct point points[100];
```

 Pēc tam varēsi piešķirt:


```
points[0].X.pos = 0;
points[1].X.DecDistance = 0;
```

 Utt.

----------


## jeecha

Jaa, aizmirsu piebilst - PALASI BEIDZOT KAADU GRAAMATU PAR C!

P.S. Paaris patiesiibas par programmeeshanu kaa taadu, tieshaa veidaa nesaistiitas ar doto subj:
1) vienkaarshs, skaists un uzskataams kods kaa likums straadaa labaak nekaa tjap ljap uzrakstiits;
2) #1 punktaa mineetajaa kodaa ir nesaliidzinaami vieglaak veikt kljuudu labojumus un uzlabojumus;
3) ar algoritmu optimizaaciju var ieguut nesaliidzinaami lielaaku veiktspeejas uzlabojumu nekaa ar koda optimizaaciju, liidz ar to "skaitiit instrukcijas" ir veerts tikai kad algoritmus uzlabot vairs nav iespeejams;
4) lai padariitu kodu liidziigu #1 punktaa mineetajam vaig censties peec iespeejas (sapraata robezhaas protams) izmantot programmeeshanas valodas iespeejas un standarta biblioteekas... ik dienu programmeetaaji izgudro tuukstoshiem "jaunu velosipeedu", kas kaa likums ir sliktaaki par tiem kaadi bija pieejami gatavi;
5) programmeeshana driizaak ir maaksla nekaa graavju rakshana - ar centiibu un chaklu podzinju klabinaashanu nekur taalu tikt nevar.

----------


## Epis

Laikam būšu beidzot tavu Velko piemēra kodu sapratis  ::  (pāris stundas pagāja (kamēr noskatījos izlaušanās seriālu  ::  ) 

tad man sanāktu kautkas tāds

struct Assdati {
 s32 ĀtrumsUzrāviens;
s32 PunktuSkaits;
};

struct PData {
s8 ID;
struct Assdati X;
struct Assdati Y;
struct Assdati Z;
};

struct PData  PosData[100];
un tālāk tad šādā stilā krāmēt iekšā tos datus ja:

PosData[0].ID=1;
PosData[0].x.Ātrumsuzrāviens = 25;
PosData[0].x.punktuSkaits = 200;
un tā tālāk kamēr PosData[0] ir pilns un tad turpināt ar nākošo ja?

----------


## Velko

Jap, apmēram tā. Protams, nav obligāti vispirms jāaizpilda PosData[0]. Aizpildīt var jebkādā secībā, kā ērtāk.

----------


## Vinchi

EPI te tev būs normāla lapa par programēšanu: http://www.liis.lv/nps/nps-0.html

Un šeit par masīviem: http://www.liis.lv/nps/nps6.html

Varbūt vienreiz izlasi visu to lapu un pašam paliks viss daudz skaidrāks.

----------


## Epis

Tajās latvijas pamācībās ir par Pascal valodu tur par embaded C nekā nav. 

Situācija ir tāda ka es padomāju un tā iepriekšējā datu pierakstīšanas forma tomēr īsti neder un ir jātaisa pavisam cita tipa datu saglabāšanas sistēma, un šeit sākās problēma tāda kad šeit ierakstāmajiem datiem nebūs tādas savējās struktūras, proti var gadīties ka tiks ierakstīti kādi 3 datu lauku un tik pat labi citā situācijā tie varētu būt kādi 12 datu lauki, proti es domāju saglabāt tos reālos motora ātrumma ciparus katrā laika perjodā, un lai nebūtu jāpiegrūž atmiņa ar vienādiem cipariem ja motors iet ar vien un to pašu ātrummu vairākus soļus (Max kādi 256) tad tai vietā lai rakstītu 256 reizes vien un to pašu atmiņā ierakstīs vienkārši:
 motors 1 ies 256 soļus ar ātrummu 25mm/s binārajā tas izskatītos ( 8bit soļu skaits,16-32bit ātrums.),
 bet parastā gadījumā kad notiks paātrinājuma fāze tad katram solim būs savs ātrums un tad būs tikai 1 cipars (16-32bit ātrums) un tākā katrai asīj ir 2 datu pierakstīšanas formāti, tad vaidzēs kādu indeksa bitu, kas norādīs uz to kā katra ass tiek prierakstīta, un kuras asis vispār tiek pierakstītas, vai šito var uzkodēt kādā pareizajā stillā ar tām struktūrām? vai arī jākodē tādā brutālā veidā ka es sākumā kodēju, Proti, definējam vienu datu masīmu: s8 Glabātuve[1000] un tad taisam tādas funkcijas, kas ģenerēs to sakodēto datu struktūru un tad rakstīs iekšā pa taisno tajā Gabātuvē[i]. 

Principā tas ir jautājums: ar kādām metodēm kodē datu arhivēšanas dzinējus ?? 

ja kas šito datu arhivēšanas ideju es jau izdomāju pirms 2.3-3 gadiem kad kodēju Atmegu128 un bīju ja kas uzrakstījis kodu Asmā, kas saglabā no kompja nākošos Step/dir signālus, bet tā lieta nestrādāja jo kompis laida ārā gļukainus signālus un līdz ar to nebīj nekādas jēgas no tādas sistēmas.

----------


## jeecha

Vo, veel viena patiesiiba par programmeeshanu (un ne tikai) - pirms veikt kaadu optimizaaciju paarliecinies ka taa ir akuuti nepiecieshama! Ja optimizaacijas meerkjis ir tikai pati optimizaacija, tad visticamaak optimizaaciju veikt nevaig.

Konkreeti shajaa gadiijumaa - vai taa atminjas taupiishana tieshaam ir nepiecieshama? Jo glabaajot datus kaadaa "pakotaa formaa" (piemeeram ja seciigi ir daudz vienaadu elementu tad pierakstiit tikai pirmo un to cik taadi pashi sekos) sarezhgjiisies gan datu pieglabaashana gan nolasiishana. Rezultaataa ja atminjas taupiishana tomeer nebija nepiecieshama tad vienkaarshi buus sarakstiits daudz lieka koda un tiks teereeti daudzi lieki kontroliera instrukciju cikli lai pakotos datus rakstiitu un lasiitu.

----------


## Vikings

Vēl aizvien, Epi es neesmu sapratis vienu - nu nafig tu glabā ātrumu nevis soļa laiku? Ātrums taču tā pat būs jāpārrēķina uz laiku lai to ar taimeri mērītu. Kādēļ to uzgrūzt nabaga procītim?
Par atmiņas taupīšanu ar iedomājos un jeechas koments to apstiprināja - Nu i kāda atšķirība ja atmiņā ir 100 atšķirīgi vai vienādi soļi? Lai taupītu datu apmaiņas ātrumu? kamēr motōrs atstrādās katru soli tu paspēsi vēl 1000 soļus ierakstīt. Mazāk aizņemta atmiņa? Un ko darīs neaizņemtā atmiņa? Palīdzēs LHC rēķināt protōnu ātrumus?

----------


## Velko

> Tajās latvijas pamācībās ir par Pascal valodu tur par embaded C nekā nav.


 Pamatprincipi Pascal, C un vēl veselai kaudzei procedurālo valodu ir tādi paši. Atšķiras tikai pieraksta sintakse. Sapratīsi kā kautko izdarīt Paskālā, sapratīsi arī kā to darīt C.

----------


## jeecha

Atcereejos veel vienu patiesiibu par sho teemu - labs programmeetaajs nav tas kursh paarzin vienu vai otru programmeeshanas valodu, labs programmeetaajs ir tas kursh paarzin algoritmus un principus un speej konkreetajai probleemai piemekleet algoritmu ar ko to veiksmiigi atrisinaat un speej sho atrisinaajumu paarveerst elegantaa un straadaajoshaa programmaa.

----------


## Epis

Situācija ir tāda ka es jau varu to kodu uzkodēt pēc savas primtīvās metodes, un kā zināms tad kodu var uzkodēt pēc vairākām metodēt,variatniem, un es gribu zināt kurš tad ir tas labākais,pārksatāmākais par ko tā gudri runā Jeecha un kautko arī pieminēja Delfīns, Velko vismaz kautkādu kodu parādīja par to arī Paldies. 
Un tajās grāmatās,pamācībās ir tikai pmati, tur nav rakstīts kādās situācijās ir labāk izmantot tādu kodēšanas metodei,vai arī kādu citu salīdzinājumā ar citām metodēm proti man vaig tādu kā analīzi kā, ar kādām metodēm labāk kodēt tos arhivātorus ??  




> Vēl aizvien, Epi es neesmu sapratis vienu - nu nafig tu glabā ātrumu nevis soļa laiku? Ātrums taču tā pat būs jāpārrēķina uz laiku lai to ar taimeri mērītu. Kādēļ to uzgrūzt nabaga procītim?


 Tas tač arī būs tas pats Soļu laiks, tikai es viņu mosaucu par ātrumu  ::  un pat ja glabātu ātrumu tad no ātrumma kautkādiem mm/s dabūt soļu laiku varētu ļoti viegli ar 1-2 operācijām tākā tas arī ir tas pats, es protams glabāšu tādas vērtības kuras var pa taisno no tā buffera likt iekšā PWM frekvences taimeros, proti tos datus varētu pa taisno barot iekš fpga un iekš fpga uztaisīt loģiku kas no šiem ģenerē step/dir (tas būtu pat ļoti viegli izdarāms), un galvenais ir protams tas ka stm32 procim (kas ir uz Plates) ir tikai 10Kbytes RAM un šito atmiņu 1 vaidzēs izmantot priekš paša koda (jo no flash atmiņas tas procis iet tikai uz kādiem 24Mhz (izlaiž 2 instrukcijas) līdz ar to būs jāpārlādē Flash proga uz RAM lai dabūtu tos 72Mhz un rezultātā Rama paliks pāri ļoti maz !! un kautkādu datu bufferi es uzskatu ka vaig. tādejādi varēs cept tādu kodu kurš piemēram tās kordinātes varēs dekodēt kautvai ar ļoti švaku ātrumu <1Khz bet signāli būs piemēram līdz 10Khz un skaidrs ka šādā gadījumā bez buffera iztikt nevar, jo situācija kad patiešām būs vaidzīgs rēķināt katram solim to ātrummu reāli ir ļoti reta (kādā smalkā apļa interpolācijā, vai liela ātrumma lielā paātrinājumā un tad vaig lai tās pāris sekundes kritiskā perjoda būtu jau iepriekš izrēķinātas, un teorētiski šādu situāciju arī varētu iepriekš prognozēt jau paša Gkoda izstrādes stadījā, proti uztaisīt VisualC# proča modeli un tos aprēķinu laika perjodus, lai varētu iepriekš pirms iekārta vispār sāk darbu uzmodelēt šo bufferu darbību, proti vai neradīsies tāda situācija ka bufferī beigsies dati! un procis nespēs tos datus īstajā laikā uzģenerēt, ja šāda buffera nav tad paši saprotat būs vaidzīga pamatīga matemātiskā jauda kuras noslogojums pamatā būs labi ja 1% un tikai tajos kritiskajos brīžos  kādi 80-90% + vēl vaig kādu rezervi, bet ar Fifo bufferi procis būs visu laiku noslogots 100% kamēr buferis nav pilns un tad pēc situācijas, un šādi proča jauda varētu būt savas 10x mazāka nekā bez Buffera, un es varētu ar to stm32 mierīgi vadīt kādas 4-6 vai pat 8asis un arī padomāt par SPline interpolātoru  ::  
Principā ja ir ļoti liels bufferis (kādi 10-100Mb) tad praktiski sanāktu tā ka prims iekārta sāk darbu bufferis tiek piepildīts ar visu kodu un tad vissus MCU resursus var veltīt tiem PID un vadībai, otra galejība bīj ka to bufferi(vai Gb Flash atmiņu) varētu pielādēt kompis, bet abos gadījumos vaig C,vai C# kodu kas ģenerētu tās kordinātes kuras tad varētu pildīt tajā bufferī, un tad jāskatās kas lētāks, maza SPI flash,EPROM priekš Gkod glabāšanas un tad kāda RAM,SRAM, vai bez SRAM, vai arī viena  Gb NorFlash karte,čips (šitie čipi vēl ir arī jānolasa un tas proccess nav nekāds vienkāršais, tur labāk izvēlēties kādu speciālo čipu ar to NandFlash interfeisu) tākā šādas ir tās Opcijas kura ir lētāka, izdevīgāka es nezinu, skaidrs tas ka cepšu abus  kodus (C no C# neko daudz neatšķirās bet savas nianses protams ka ir.).

----------


## Vikings

Man gan tas vairāk izskatās pēc fantāzijām vai pašnāvības. Čakarēties ar milzīgām atmiņām, rēķināt kaut kādu RAW kodu, glabāt atmiņā un pildīt? Nu sorry, es noteikti atkārtojos, bet...paņemt procim kaut caur COM portu ielādēt Gkodu kuru tas saglabā kaut kādā savā atmiņā un reālajā laikā rēķina SD signālus. Nu ja ļoti gribas tad tiešām daļu uzdevuma var pildīt kāda lōģika. Piem, signālu ģenerēšanu kamēr procis pilda matemātiskās funkcijas. Un izejā lai ir motōru vadībiņas katrā pa procītim, kas uztur soļa strāvu un var būt pat skatās vai solis izpildīts. Bet nu labi, katram aju sava koncepcija...

----------


## Delfins

īsti nesaprotu šitam jēgu... kāds ir reāls pielietojums?
Vēlreiz atkārtošos, kamēr nemāki normāli kodēt (un to paliecina šīs te vienkāršās "lietiņas" un izteicieni, ka grāmatās nav konkrētu piemēru [kādēļ viņiem tur ir jābūt?]) - projektēt dzelžus tādā attīstības līmenī ir ĻOTI stulbi.. nekas tev tur nesanāks un tas bij no paš sākuma skaidrs.

Piemērs: zirga (koka) ratu "developeriem" uztic F1 bolīda/šasijas izstrādi...

----------


## karloslv

> (C no C# neko daudz neatšķirās bet savas nianses protams ka ir.).


 Atiet, vecīt!  ::  Veiksmi, maldoties pa trim priedēm.

----------


## Epis

Atradu vecos piezīmju papīrus tam savam super krutajam Arhivātoram un bez papildus funkcionalitātes piedomāju arī vēl klāt vēlvienu datu formāta bloku kurā saturēsies info par visādiem relejiem,slēdžiem, lai varētu kādu ierīci ieslēgt izslēgt pēc konkrētas komandas (kopā vieta ap 64 devaisiem  ::  ), viss grūtāk jau būs uzrakstīt to arhivātoru, jo dešivrātors to visu varēs ļoti ātri atkost ar if,else statmentiem. (fpga loģika tādu kodu ar pāris MUX+statemachine varētu nolasīt un datus pa kanāliem izsvaidīt.
un tāpat tā informācija ir kautkur jāglabā, lai mājā būtu kārtība, nevis bardaks.

A ko domājet ka Leišu Robotam Līnijsekotājam tā trajektorīja ir ierakstīta rupjā datu formātā?? varu derēt ka tur viņi arī to visu kautkādā savā formātā saarhivēja.




> Piemērs: zirga (koka) ratu "developeriem" uztic F1 bolīda/šasijas izstrādi...


 Ja tie zirga ratu developeri kādreiz neķersies klāt tā F1 bolīda šasījas būvei tad viņi tā arī paliks par zirgu ratu developeriem, ja kautkas tomēr pieķersies tad varbūt paveiksies un kautko arī uztaisīs (veiksmes% protams ir mazs (domāju ka ap 1-5%), 
šeit tāpat veiksmes % ir zems, bet ja nemeģināsi tad tā arī nekad nezināsi ! 

labs ir es cepu savu arhivātoru pēc "Līkās" metodes.  ::

----------

