C: plūsmas un bloķējošās funkcijas

[argonaut]

Ir iegultais projekts, kur galvenajā plūsmā ir vairāki stāvokļu automāti, lai nebloķējošā veidā apstrādātu atbildes no attālām iekārtām. Pieprasījumu sūtīšanu un atbilžu saņemšanu nodrošina cits stāvokļu automāts jau pārtraukumu plūsmā.

Aptuveni šādi:

void ISR1(void)
{
    CAN1_tasks();
}

void ISR2(void)
{
    CAN2_tasks();
}


void Sensor1_tasks(void)
{
    switch(CAN1_status)
    {
         case...
            break;
         ....
    }
}

void main(void)
{
    Init();
    while(1)
    {
        Sensor1_tasks();
        Sensor2_tasks();
        Sensor3_tasks();
    }
}

Gadījās jauna iekārta, kurai ir gatava bibliotēka ar daudzām funkcijām paredzētām izmantošanai bloķējošā veidā:

//HW abstraction daļā jābūt šādām funkcijām
bool SendData(byte *buf, int count);
bool ReadData(byte *buf, int count);

//Kuras izpildās bloķējošā veidā, t.i. atgriež vērtību tikai, kad dati  reāli ir saņemti

void InitDevice(void)
{
    SendData(....);
    ReadData(....);
    //Viskkas

    SendData(....);
    ReadData(....);
    //utt
}

Līdz ar to uz lēno komunikāciju tiek zaudēts CPU laiks.

Vai ir kāds nesāpīgs veids, kā realizēt SendData, ReadData  nebloķējošā veidā, lai nav jāizmanto OS?

[AndrisBB]

Manuprāt pamaz informācijas, kas par OS, uz ko raksta (UART, CANBUS), kas par biblotēku. Pagaidām var tikai minēt.

[argonaut]

No OS tieši gribētos izvairīties, visas iekārtas tiek aptaujātas cikliski (round robin princips). Konkrēti aparātiski bloki arī nav būtiski. Jautājums vairāk tieši par C iespējām: ja ir bloķējošās (gaida uz ārējās iekārtas atbildi) funkcijas prototips, kuru izsauc jaunās iekārtas bibliotēka, vai būtu kādā veidā iespējams šo funkciju realizēt nebloķējošā veidā? Pagaidām jaunā bibliotēka gaida atbildi, bet pārējās programmas daļas pa to laiku netiek pie izpildes..

[nevertell]

Ja nav thread'i/OS un funkcijas tiešām bloķē, un nevar nekādi poll'ot informāciju, tad būs vien ciets ekskrements.

[AndrisBB]

 

 

Jautājums vairāk tieši par C iespējām:

Tur jau mazs sakars ar pašu C kā tādu, ja tā bibotēka sēž loopā, kamēr gaida uz piemēram UARTU pēc jauna baita, tad tur neko nepadarīsi. Ja ir pieeja kodam, tad var jau pamainīt, lai piemēram liktu visu ienākošo kautkādā buferī un tad biblētēka lasa no bufera nevis pa taisno no porta.

Nav jau arī zināms ko tā biblotēka izmanto, ja kautkādus standarta putc utt, tad var standarta libc vietā paņemt kautkādu newlib vai redlib, kuriem viegli var mainīt pašu apakšējo slāni (write, read). Tad tava implementācija sakrāmēs visu ienākošo bufferī izmantojot interruptus. Kad tur kautkas sakrājies, tad tu izsauc to ReadData un tā bibliotēka paņems to, kas tur jau ir sabuferojies.

Vienmēr var izdomāt kautkādus workaroundus, bet bez informācijas kā jau teicu var tikai minēt.

[argonaut]

Kā jau iepriekš rakstīju, bibliotēka atsaucās uz lietotāja veidotajām send/receive funkcijām, kuras tad savukārt izmanto secīgi (call-return), bez poološanas. Tātad, ja izsaucu bibliotēkas "Init" vai "Run", tad nekas cits neatliek kā sagaidīt return.

Pie bibliotēkas koda tieku, vienkārši to funkciju ir daudz un visas pārtaisīt paņems laiku. Izskatās, ka būs ar to jāsamierinās. Vai jādomā par OS.

 

Paldies par atbildēm!