Čítanie impulzov z CTS na RS232 – C / C++ – Fórum – Programujte.com

Dobrý deň.

Vytvoril som si program vo WinApi na komunikáciu s PIC obvodom, a potrebujem čítať impulzy z jedného jeho pinu. Rozhodol som sa ku tomuto účelu využiť port CTS na zbernici RS232. K jeho čítaniu používam funkciu:

bool GetCTS(void)
{ DWORD ModemStatus;
  GetCommModemStatus(ComHandle, &ModemStatus);
  ModemStatus = ModemStatus & MS_CTS_ON;
  return ((bool)ModemStatus);
}

Túto funkciu potom volám k vyskúšaniu v handleri:

case WM_KEYDOWN:
{    switch (wParam)
     {    case VK_RETURN:
          {   pocitadlo = 0;
              for ( f = 0;  f < 100;  f++ )
              {   if ( GetCTS() )
                      signal_CTS = 1;
                   else
                       signal_CTS = 0;
                   pocitadlo++;
               }
           }
      }
}

Čiže keď stlačím ENTER a nechám si zobraziť premennú počítadlo, vizuálne vidím, koľko času asi uplynulo, než 100x prečíta port CTS na RS232. Je to celkovo asi 2 sekundy. To je však pre môj účel veľmi-veľmi pomaly. Funkcia GetCTS() síce číta impulzy správne (z obvodu PIC16F628), to už som inde vyskúšal, po tejto stránke som spokojný, avšak číta to veľmi pomaly. Neviem čo ďalej robiť. Vyskúšal som všetko možné, čo som vedel. Googlením som strávil radu dní, čo pri tom sedím od rána do večera, a nič som nevyriešil.
 Vyskúšal som aj takú vec, že som zámerne napísal chybné číslo COMu. Vtedy po stlačení ENTER ten cyklus for prebehne okamžite. Aj keď zvýšim cieľovú hodnotu na 100000, prebehne takmer okamžite. Toto by mi úplne vyhovovalo. Avšak akonáhle je COM port načítaný správne, číta to opäť veľmi pomaly.

Port otváram pomocou funkcie:

HANDLE ComHandle;

CloseHandle(ComHandle);

ComHandle = CreateFile(
                             "COM3",
                             GENERIC_READ | GENERIC_WRITE,
                             0,
                             0,
                             OPEN_EXISTING,
                             FILE_FLAG_OVERLAPPED,
                             0);

. . . . . . . . .

CloseHandle(ComHandle);

 Skúšal som sa hrať aj so štruktúrou DCB (i keď bežnú sériovú komunikáciu RS232 tx/rx nevyužívam, lebo ju nepotrebujem). Testovall som i rôzne nastavenia - napr.:

        DCB dcb;

        dcb.DCBlength = sizeof(DCB);

        GetCommState(ComHandle, &dcb);

        dcb.BaudRate = 9600;
        dcb.ByteSize = 8;
        dcb.Parity = NOPARITY;
        dcb.StopBits = ONESTOPBIT;    
         .
         .
         . . . ale nič nepomohlo. Menil som aj rôzne ďalšie paramete, ale nič nepomohlo. Stále rovnako pomaly.

Skúšal som i funkcie SetCommMask(), WaitCommEvent(), a štruktúru OVERLAPPED, ale ani to nepomohlo.

Cyklus správ vo funkcii WinMain() používam klasický:

    while ( GetMessage ( &Msg, NULL, 0, 0 ) > 0 )
    {   TranslateMessage( &Msg );
        DispatchMessage( &Msg );
    }
    return Msg.wParam;

Mohli by ste mi prosím poradiť? -Neviem, ako ďalej.

V prvé řadě Windows nejsou RTOS.Počítání impulzů bych na Windows dělal asi jen v případě, že by jejich perioda byla řádově sekundy a více. Navíc tyto signály nejsou k počítání impulzů určeny, pokoušíš se o nestandartní použití. Další problémy s časovou prodlevou mohou vzniknout použitím převodníku COM/USB. Spíš bych volil na jednočipu provést časově kritické věci a posílat to přes COM jako data, Pro práci s COMem se osvědčila TSerialEvent. Druhá možnost jednočip připojit do USB pomocí převodníku např. FT245 a pak s tím pracovat jako s USB zařízením pomocí API které k tomu FTDI dávají.

hu

Dík za radu. Ano, používam prevodník COM/USB.

S tými inštrukciami, ktoré sú však na na tom PIC-čku k dispozícii, sa jedná o dosť nepohodlné a neprehľadné programovanie. Preto som sa snažil zložitejšie úlohy presúvať do PC, a pomocou štruktúrovaných povelov PIC riadiť. Na povely používam port RTS/RS232. Ten kupodivu beží dostatočne rýchlo. S rozlíšením desiatky mikrosekúnd. Porovnávam v PIC dĺžku impulzu k dĺžke medzery. Keď príde na vstup PIC impulz s medzerou dlhšou ako trvanie impulzu, nastane reset, cyklus prejde do čakacej pozície, a vyhodnotí log.0. Keď je medzera kratšia, cyklus čítania pokračuje. Keď takto narazí na 2 impulzy a za nimi medzera dlhšia ako dĺžka prvého impulzu, nastane reset, cyklus prejde do čakacej pozície, je vyhodnotí sa log.1. Tri impulzy znamenajú štart čítania. (každý bajt musí začať tromi impulzmi s medzerou kratšou, ako impulz)
....To mi funguje bez problémov. Kiež by to šlo aj naopak.

Ano, nad USB som premýšľal ako prvé. Nemal som však žiaden návod, literatúru, radu ako začať. Všade, kde som cez google narazil na sériovú komunikáciu medzi WinApi a PIC, bol obšírne a zrozumiteľne vysvetlený len port RS232. Skúsim teda, čo ste mi poradil.

MP

Vůbec nerozumím co je cílem. PIC lze řídit přes UART sekvencí ASCII znaků (R jako reset....), podobně lze stavovou informaci do PC odeslat jako sekvenci ASCII znaků např P0983 (tlak 983mbar), T12538 (teplota 1253,8K). komunikaci ukončit např. znakem <CR>. Signály RTS, CTS ... slouží k hardwarovému řízení datového toku na RS232, používali se při komunikaci s pomalými periferiemi. V podstatě šlo o "chci vysílat", "jsem připraven přijímat".

hu

#4 hlucheucho
Ide o to, že tento spôsob komunikácie je nazávislý na rýchlosti vysielania. Od kedy príde na vstup PIC start bit (tj. tie 3 impulzy), ďalší bit môže prísť už za 100 mikrosekúnd, alebo aj za hodinu. Vždy ho zaradí do registra, až pokiaľ nenapočíta 8 bitov. Keď ich napočíta, vyhodnotí naplnený register a číslo použije k jednému z 256-tich povelov. Zdá sa mi to byť spoľahlivejší prenos, ako klasická sériová komunikácia, kde sa musí nastaviť na oboch stranách rovnaká rýchlosť. A o túto spoľahlivosť mi hlavne ide. Aby sa to nemýlilo. -Ďalšia vec je, že keby som poslal číslo napr. 122 v ASCII, potreboval by som na prenos 3 bajty. Takto mi stačí len jeden. 

Samozrejme, ak už nebude iná možnosť, použijem vami odporučenú klasickú sériovú komunikáciu. Divím sa však, že RTS beží svižne a CTS hentak pomaly.

MP

Souhlasim s hlucheucho, jakekoliv přesné časování na windowsech je ošidné, klidně se může stát že systém přepne ne jiný proces a program se na pár desítek až stovek ms zastaví než bude pokračovat. Může se to lišit pc od pc a od ovladače k ovladači, hodně záleží jak douhá bude ta komunikační smyčka. Je pravda že se to nemusí stávat moc často a dá se různě laborovat, ale hledat pak chybu není nic moc. Určitě je mnohem spolehlivější a jednodušší použít klasický Uart.

Ohledně USB existují integrované obvody převádějící USB na Uart(většinou TTL, nikoliv RS232).
Výhoda je že k tomu mají ovladače a i v PC se to pak tváří jako Seriový port (takže není nutno měnit aplikaci v PC).
Mezi známé a celkem ověřené patří FTDI. http://www.ftdichip.com/FTProducts.htm
Existují i hotové kabely nebo moduly ale bývají patřičně dražší než samotný čip.

#6 Ovrscout
Souhlasim s hlucheucho, jakekoliv přesné časování na windowsech je ošidné, klidně se může stát že systém přepne ne jiný proces a program se na pár desítek až stovek ms zastaví než bude pokračovat. 

Ano, to je jeden z dôvodov, prečo som spravil henten spôsob prijímania bitov, nezávislý na čase.

Ohledně USB existují integrované obvody převádějící USB na Uart(většinou TTL, nikoliv RS232).

Dík za radu a za link. Vyskúšam to.

Doporučený FT245 je USB na paralelní, odpadá tak potřeba řešit přenosovou rychlost. S ohledem na vlastnosti USB a velikost FIFO u FT245 bych si nelámal hlavu, že je potřeba několik ASCII znaků.

Jistota generování impulzu dané šířky a mezery dané šířky a stejně tak i schopnost ji změřit je u Windows prakticky nulová. Sériová komunikace je tedy spolehlivější. Co se týče baudrate, defaultní je 9600, lze zřídit i autodetect. Pokud sám tvoříš i obslužný SW pro PC, není problém stanovit a naprogramovat "společnou" hodnotu.

hu

#8 hlucheucho
Doporučený FT245 je USB na paralelní, odpadá tak potřeba řešit přenosovou rychlost. S ohledem na vlastnosti USB a velikost FIFO u FT245 bych si nelámal hlavu, že je potřeba několik ASCII znaků.

Dík. Toto určite vyskúšam.

Jistota generování impulzu dané šířky a mezery dané šířky a stejně tak i schopnost ji změřit je u Windows prakticky nulová. 

Na generovanie potrebnej dĺžky, používam funkciu:

void Wait_us(unsigned __int64 medzera)
{     unsigned __int64 frekvencia, citac, stop;
      QueryPerformanceCounter( ( LARGE_INTEGER *) & citac );
      QueryPerformanceFrequency( ( LARGE_INTEGER *) & frekvencia);
      stop = ( ( medzera * frekvencia) / 1000000) + citac + 1;
      while (stop > citac)
           QueryPerformanceCounter( ( LARGE_INTEGER *) & citac );
}

V podstate ani nejde o presné načasovanie, ale iba o to, aby PIC spoľahlivo rozoznal, že medzera je dlhšia ako impulz. To som zabezpečil tým, že do PIC posielam v takom prípade medzeru aspoň 2x dlhšiu, ako impulz. Zatiaľ to funguje spoľahlivo. Smerom z PC do PIC dokonca aj rýchlo. Kiež by to takto rýchlo fungovalo aj naopak.
 

#8 hlucheucho
Rozhodol som sa kúpiť hotový modul s FT245. Chcem sa spýtať: ako sa zahlási v systéme Windows? Aký názov mám potom zadať v parameteri lpFileName vo funkcii CreateFile?
 

První možnost je chovat se k němu jako ke COMu. Jaký virtuální COM mu byl přidělen jde najít ve správci zařízení. Výhoda virtuálního COMu je poznat při testování - pomocí terminálu odešleš na příslušný virtuální COM co potřebuješ bez nutnosti speciálního software, nevýhoda je nutnost hledat správný COM po instalaci na jiný PC. Druhá možnost je s ním pracovat jako s USB zařízením. Pro tyto účely si stáhni D2XX Programmer's Guide  Document Reference No.: FT_000071  přímo na stránkách výrobce http://www.ftdichip.com/ . Dokument obsahuje celé API s příklady, je to v C. V adresáři ovladačů bys měl najít soubory .lib a .h. Zařízení si pomocí utility (také ke stažení na stránkách výrobce) můžeš pojmenovat po svém a pak ho otevírat podle jména.

hu