Warning: Illegal string offset 'name' in [path]/includes/functions.php on line 6439
Atmelis 328P (arduino nano) dziļajā miegā. -
+
1 2 3

thread: Atmelis 328P (arduino nano) dziļajā miegā.

  1. #21
    Senior Member
    Nov 2009
    Jēkabpils
    2,046

    Mļaķ!!!! Nu jā esmu lohs . Izrādās tajā bibliotēkā džeki sarakstījuši vienas un tās pašas funkcijas gan c gan asmā. Es biju iedomājies, ka daļa uzrakstīta asmā, lai kaut kādas funkcijas būtu ātrākas, bet vajadzīga ir visa biblene...

    p.s. sorry par palagu.

  2. #22
    Senior Member
    Nov 2009
    Jēkabpils
    2,046

    Laba diena tiem, kas te vēl palikuš!

    Radās jautājums par komandu nosūtīšanas algoritmu. Spēlēties ar šiem mazajiem transīveriem mani uzbudināja šis raksts. Ar minētajām MRF49 (e-līča) mikrenēm pirmajā piegājienā cietu pilnīgi neveiksmi, tāpēc pārgāju uz SI4432 gataviem modulīšiem. Bet stāsts ir par ko citu. Par algoritmu šīm te 10 pogām. Džeks izejas kodu nerāda. Darbības princips - nospiežot vienalga cik pogas kopā otrā galā izšauj attiecīgie stobri, pogas atlaižot šaušana beidzas. Cik saprotu viss darbojas nepārtraukti noraidot fiksēta izmēra datu paketes, katram stobram savs(i) bits(i). Teorētiski, ja kanāls "apraujas" pie nospiestas pogas, attiecīgais stobrs turpina šaut. Jebšu ņemam kaut kādas zināmas milisekundes starp paketēm un, ja nav paketes, tad slēdzam stobru ārā? Tad principā, ja neviena poga nav nospiesta, var slēgt raidītāju ārā?

  3. #23
    Senior Member
    Jun 2006
    Cēsu novads
    986

    Manuprāt daudz kas ir atkarīgs no tā, cik vadāmā ierīce ir autonoma tieši drošibas ziņā. Ja tā nav pietiekami saprātīga, lai spētu pati atpazīt avārijas situācijas un izslēgties, no drošības viedokļa prātīgākais tiešām būtu - ja pārtrūkst sakari, pēc brīža slēdzam visu ārā. Citādi Dievs zina, kādas ziepes var sataisīt, ja tiek ieslēgts kāds mehānisms, un pēķšņi to vairs nevar izslēgt. Bet ja iekārta spēj darboties un apstrādāt avārijas situācijas autonomi, tad tas nav vajadzīgs. Piemēram garāžas vārtu motors, kurš ir ieslēgts, kamēr turam nospiestu pults pogu. Nospiežam pogu, kontrolieris ieslēdz raidītāju nosūta komandu ieslēgt garāžas vārtu motoru un slēdzam raidītāju ārā. Kamēr turam pogu nospiestu, raidītājs ir izslēgts, brīdī, kad pogu atlaižam, kontrolieris ieslēdz raidītāju, nosūta komandu izslēgt motoru un slēdz raidītāju ārā. Ja pults sabojāsies pēc pirmās komandas nosūtīšanas, nekas slikts nenotiks, garāžas durvis atvērsies pilnībā, nostrādās gala slēdzis un motors apstāsies. Cita situācija, ja ar to pašu verķi vadīsim auto pacēlāju garāžā ar zemiem griestiem. Tā var kādu džipu saplacināt.

  4. #24
    Senior Member
    Nov 2009
    Jēkabpils
    2,046

    Nu jā. Paldies, M_J! Velns, pat prātā neienāca šāds algoritms, ka piespiežot pogu nosūtās komanda vienu reizi un tad gaida atlaišanu. Kaut kā bija iesēdies galvā, ka vajag visu laiku raidīt.

  5. #25
    Senior Member
    Nov 2009
    Jēkabpils
    2,046

    • Brīnumainā kārtā sačiņījis gāzes katlu, atkal ķeros atpakaļ pie C/C++.
    Ir definēti stringi programmu atmiņā:
    :
    static const uint8_t mnu1[] PROGMEM = {"RED"};
    Pēc tam tiek definēta struktūra un pointeris uz šādu struktūru un salikti šim dati.
    :
    void loop() {
      struct mnu_item
      {
        uint8_t *title;
        uint8_t active = false;
        uint8_t selected = false;
        uint8_t *value;
      };
    
      struct mnu_item  *mnu_red;
      mnu_red = malloc(sizeof(struct mnu_item));
      
      mnu_red->title = (uint8_t*) mnu1;
      *(mnu_red)->value = 150;
      mnu_red->active = true;
      mnu_red->selected = true;
    Sākumā nebija tās atmiņas piešķiršanas rindiņas (malloc). Kompilieris lamājās, ka:
    warning: 'mnu_red' is used uninitialized in this function [-Wuninitialized]
    bet (gan jau pats visu sakārtoja) tālāk sekojošais kods uz nokias LCD izvadīja pareizi "RED true true 150"
    Bet nu tas nav smuki, ka kāds lamājas. Sekass ar gūgli un sapratu, ka es definēju pointeri, bet nepiešķiru atmiņu.
    Nu OK. Kompilieris vairs nelamājas, bet tam "value" varu rakstīt ko gribu, šis dod ārā 129.
    WTF?!?! Gūgle man tūlīt banu iedos

    Reizēm ir ļoti noderīgi parunāt pašam ar sevi (nakts vidū ). Lohs esmu, atzīstu .
    Nodefinēju pointeri, bet nevis iedevu šim adresi, kur glabājas mainīgais, bet mēģināju iebarot mainīgā vērtību. Velns, tas kompilieris ir pārāk gudrs, pārāk daudz cenšas izdarīt programmētāja vietā. Tāpēc jau laikam tās Marsa zondes gāžas lejā, ka kodu šām iekš Arduino raksta !

  6. #26
    Senior Member
    Nov 2009
    Jēkabpils
    2,046

    Labs vakars!
    :
    uint64_t ncOffset0 = ((uint64_t) bps * (131072 * 1)) / (62500 * (1 + 2 * 1));
    uint64_t ncOffset1 = ((uint64_t) bps * (65536 * 1)) / (31250 * (1 + 2 * 1));
    uint64_t ncOffset2 = ((uint64_t) bps * (32768 * 1)) / (15625 * (1 + 2 * 1));
    Tur, kur tas "*1" patiesībā ir mainīgais, kurš šajā gadījumā pieņem vērtību "1". Tas tā, lai būtu vienkāršāk.
    Tātad. Ar pirmo rindu viss ok. Abas pārējās esot "integer overflow". Var kāds apskaidrot, kas par h..u?

  7. #27
    Senior Member
    Apr 2007
    2,087

    Nebija īsti laika iedziļināties, bet varbūt niķis tur, ka PROGMEM nozīmē, ka mainīgā dati reāli tiks glabāti flash, bet normāli jebkurš mainīgais C/C++ reprezentē kaut ko RAMā. Tāpēc PROGMEM datus tipiski pārlādē kādā citā mainīgajā, kurš nav PROGMEM, ar visādām speciālām pgm_read_xxx bibliotēkas funkcijām. Pointeris uz PROGMEM datiem patiesībā nav pointeris uz RAM datiem, lai gan tiek interpretēts kā tāds (līdzīgi, kā strādājot ar EEPROM). Vārdu sakot, tur ir visas iespējas sapīties meistarībā. https://www.arduino.cc/en/Reference/PROGMEM un http://www.nongnu.org/avr-libc/user-.../pgmspace.html

  8. #28
    Senior Member
    Nov 2009
    Jēkabpils
    2,046

    Paldies, karloslv, bet tā situācija atrisinājās. Es tur toč biju sapinies meistarībā ar pointeriem uz struktūras "locekļiem".
    Bet tā problēma manā nākamajā postā paliek. Nesaprotu, kāpēc ar lielākiem skait;liem viss ir ok, bet ar mazākiem - "overflow".
    Hmm, atrisinājās problēma saucējā arī "pievedot tipu" uz uint32_t, bet jautājums paliek - kāpēc pirmajā rindā ir ok.
    Es pašlaik saprotu tā. 62500 kompilators paņam kā uint16_t. Sareizinot šo ar 3 noteikti varētu sanāk "overflow", bet tur ir ok.
    Otrajā rindā ir tāda pati situācija. 31250 iekļaujas uint16_t, bet sareizinot ar 3 ir par daudz. Bet atšķirībā no pirmās rindas jau ir "overflow".
    Savukārt trešajā rindā gan 15625 gan 15625*3 iekļaujas uint16_t, bet vienalga ir "overflow".
    :
    uint64_t ncOffset0 = ((uint64_t) bps * (131072 * 1)) / (62500 * (1 + 2 * 1));
    uint64_t ncOffset1 = ((uint64_t) bps * (65536 * 1)) / ((uint32_t)31250 * (1 + 2 * 1));
    uint64_t ncOffset2 = ((uint64_t) bps * (32768 * 1)) / ((uint32_t)15625 * (1 + 2 * 1));
    Bet pats trakākais, ja ieraksta šādi:
    :
    uint64_t ncOffset2 = ((uint64_t) bps * (32768 * 1)) / ((uint16_t)15625 * (1 + 2 * 1));
    tad viss ir kārtībā. Kāpēc piespiedu kārtā jānorāda, ka 15625 ir uint16_t?

+