Elektroda.pl
Elektroda.pl
X
Proszę, dodaj wyjątek www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

BASCOM i DELPHI przez RS232

TomekMus 27 Kwi 2009 01:21 2967 13
  • #1 27 Kwi 2009 01:21
    TomekMus
    Poziom 17  

    Potrzebuje rady a mianowicie chcę napisać protokół transmisji. W jaki sposób zrobić to pomiędzy BASCOM'em a DELPHI, wiem jak odebrać bajt i wysłać w oby językach lecz gdy piszę program i mam wysyłać do ATmeg128 xxx kB to to trwa to wieki lub głubie bajty.

    mam ustawione baud = 115200
    (nie chce buforowania danych bo chce wysylac i odbierac 1 bajt z potwierdzeniem)

    Potrzebuje wysyłać szybko(bardzo syzbko) po RS'ie
    Interesuje mnie coś takiego:

    Krok 1. DELPHI - wyslij 1 bajt
    Krok 2. BASCOM - odbierz 1 bajt
    Krok 3. BASCOM - potwierdz odebrany bajt (najlepiej tym odebranym bajtem - tak myśle)
    Krok 4. DELPHI - odbierz potwierdzenie

    wyślij kolejny krok 1.2.3.4 ... 1.2.3.4 aż do konca transmisji.

    UWAGA:
    Ważne DELPHI wysyła start do uC tak długo aż nie dostanie potwierdzenia gotowości na odebranie xx kB danych



    Code:

    do
      ......
      ......
      dużo instrukcji

      call Get_RS232
    loop


    sub Get_RS232
      ..... instrukcje odczytu RS232 i przetwarzania danych
    end sub

    0 13
  • Pomocny post
    #2 27 Kwi 2009 09:17
    kedzi1
    Poziom 18  

    A ile tych kB przesyłasz? Przy tej prędkości i sposobie transmisji to max. uzyskasz kilka kB na sekundę. Może wysyłaj i potwierdzaj bloki danych. Np. wysyłasz po kilkanaście bajtów z informacją o ilości bajtów i numerze bloku, mikrokontroler potwierdza dwoma bajtami ile danych dostał i który to blok z kolei. Można dodać też jakąś sumę kontrolną.

    0
  • #3 27 Kwi 2009 10:37
    TomekMus
    Poziom 17  

    Ilosc kB nie ma znaczenia bo jest to zmienne i moze miec nawet xMB czas jest proporcjonalny do ilosci danych, lecz mam problem pomiedzy poprawna komunikacja miedzy DELPHI a BASCOM w wymianie tych danych

    teraz robie tak:

    Code:
      #27           0..255         0 - nie będzie kolejnego bajta      #13
    
                                         1 - bedzie kolejny bajt
    START |    DANA        |       BEDZIE NASTEPNA              | KONIEC


    Code:
    do
    
      if Ischarwaiting() <> 0 then
         Znak=Inkey()
         Printbin Znak
      end if
    loop until Znak=27


    Koniec = 0 'bit kontrolny
    do
      'i tu odbieram bajt danej zapisuje sobie go potwierdzam wysylajac ten bajt nastepnie odbieram kolejny bajt ktory informuje mnie czy zakonczyc petle 0 lub 1 i tak w petli az sie nie Delphi wysylania calej informacji
    loop until Koniec=1

    do
      if Ischarwaiting() <> 0 then
         Znak=Inkey()
         Printbin Znak
      end if
    loop until Znak=13

    0
  • Pomocny post
    #4 27 Kwi 2009 11:08
    kedzi1
    Poziom 18  

    Nic dziwnego że to tak długo trwa, masz ogromną nadmiarowość danych. Przesyłaj dane blokami, a nie po jednym bajcie.

    0
  • #5 27 Kwi 2009 11:25
    TomekMus
    Poziom 17  

    No właśnie, lecz jak mam zrobić transmisje blokową bo kazdą co robiłem to nie działała bajty się gubiły lub ustawiały nie tak jak miały w buforze

    Macie jakieś gotowe sprawdzone w 100% protokoły ?

    0
  • Pomocny post
    #6 27 Kwi 2009 13:26
    kedzi1
    Poziom 18  

    PC wysyła wszystko co ma w buforze bajt za bajtem bez czekania. Można zwiększyć odstęp między bajtami, z tego co pamiętam to jest do wyboru szerokość przerwy 1, 1 1/2 lub 2 bity. A jak odbierasz dane? AVR'y nie mają buforu (no jest na 1 bajt, ale to nie bufor), najlepiej umieścić w przerwaniu wywoływanym przez USART podprogram który zapisze kolejne bajty w jakimś buforze, zanim program główny zdąży je obrobić. Albo wysyłaj dane po jednym bajcie odczekując trochę, ale to znowu opóźni transmisję.

    0
  • #7 27 Kwi 2009 13:47
    TomekMus
    Poziom 17  

    No właśnie kolega trafił w 10'tke, tak do końca odbieranie większej ilości bajtów to jest problem i zapisanie je np. w eeprom lub innej pamięci.

    Puśnić 10-20 bajtów i je odebrać to pestka ale kB i je zapisać to już wyczyn w AVR

    0
  • Pomocny post
    #8 27 Kwi 2009 14:27
    kedzi1
    Poziom 18  

    Pozostaje tylko sprawdzić rozwiązania o których pisałem wcześniej. Wysyłając nawet po 10 zyskasz bardzo wiele na szybkości.

    Nie napisałeś czy używasz przerwania do odbioru danych.

    Tak myśle że jak obniżysz trochę prędkość, a zaczniesz przesyłać po kilkadziesiąt bajtów naraz to i tak będzie szybciej niż teraz. Chodzi o to że teraz masz tylko 25% danych w tym co przesyłasz. Obniżając prędkość i pisząc sprawne obieranie w przerwaniu możesz zrezygnować z potwierdzeń.

    Poza tym właśnie takie ramki jak ty używasz to są stosowane dla dużych bloków danych w profesjonalnych systemach teletransmisyjnych gdzie dane przesyłane bit po bicie. RS ma już ramki w których zamknięte są bajty, są tam bity parzystości, które powinieneś wykorzystać do wykrywania błędów. Przesyłając bajt po bajcie nie potrzeba bajtów start i stop. Wystarczy że prześlesz bajty określające ilość danych jakie chcesz przesłać, następnie przesyłaj bajt po bajcie.

    0
  • #9 27 Kwi 2009 23:15
    TomekMus
    Poziom 17  

    A jak zrobić przerwanie które reaguje na pierwszy bajt jaki dostanie i następnie czyta reszte?

    0
  • Pomocny post
    #10 28 Kwi 2009 13:55
    kedzi1
    Poziom 18  

    Nie jestem bascomowcem bo programuje mikrokontrolery zawodowo, więc... Ale spróbuje ci pomóc.

    Przerwanie odebrania znaku nazywa się URXC.
    Piszesz:

    Code:

    enable URCX
    enable interrupts

    on URCX nazawa_podpr


    nazawa_podpr:

    tu obsługa przerwania

    return

    Nie wiem czy dobrze słabo znam bascoma. Poszukaj jeszcze na forum i w helpie bascoma.

    0
  • #11 28 Kwi 2009 15:58
    TomekMus
    Poziom 17  

    Z ostatniego postu wywnioskowałem że Bascom to dla amatorów?

    Jeśli tak to w czym tak naprawde profesjonalnie się programuje np. ATmega128

    0
  • Pomocny post
    #12 28 Kwi 2009 17:55
    mirekk36
    Poziom 42  

    Profesjonalnie to można programować w każdym języku, tylko trzeba go po prostu znać i umieć stosować w praktyce co najważniejsze.

    Dla takich początkujących jak ty Bascom powinien być jednym z lepszych języków tym bardziej, że nie rozumiesz jeszcze przerwań. Bascom daje ci gotowe rozwiązania w tym zakresie na maxa - popatrz sobie na Config Serialin .....

    czyli załączenie właśnie bufora sprzętowego RS232 działającego pięknie w oparciu o przerwania - więc pisząc w Bascomie - nie musisz sobie nawet nimi (tymi od RS232 oczywiście) głowy zawracać

    popatrz sobie przy okazji Config Serialin na coś takiego jak "bytematch"

    ja w Bascomie robiłem duże transmisje na prockach typu ATmega32 przy prędkosciach 115200 i nie miałem najmniejszych problemów

    poszukaj sobie na elektrodzie wypowiedzi kolegi o nicku ZUMEK n/t Bascoma i transmisji RS232 - to na pewno dużo ci pomoże (tak jak mi kiedyś)

    zapewniam cię, że żadnym problemem nie jest odbieranie i wysyłanie dużej ilości danych na AVR'ach i to obojętnie w jakim języku.

    a czym poszługujesz się w Delphi odnośnie komunikacji przez RS232?

    0
  • #13 28 Kwi 2009 19:11
    TomekMus
    Poziom 17  

    Mam takie książki:

    - RS232C Praktyczne programowanie od Pascala i C++ do Delphi i Buildera Wydanie II - Andrzej Daniluk
    - Delphi 7 Kompendium Programisty Adam Boduch
    - BASCOM - Marcin Wiązania

    0
  • Pomocny post
    #14 28 Kwi 2009 21:08
    kedzi1
    Poziom 18  

    Nie wiem jak teraz wygląda bascom, ale kiedy ja zaczynałem programowanie w bascomie składało się tylko z bezmyślnego wykorzystywania gotowych procedur pod postacią poleceń, które nie koniecznie pasują akurat do aktualnego problemu. Nie mówiąc już, że o takich rzeczach ja wskaźniki, definicje, struktury... bascomowwcy mogą poważyć... Co innego C, jednak nie sadzę, że to jedyny słuszny język. Chodziło mi o to, że jest dobry w domowym hobby, jednak jeżeli planujesz w tym kierunku profesjonalną pracę zawodową to lepiej od razu korzystać z C, no i z not aplikacyjnych na stronie producenta. Język angielski jest podstawą zaraz obok języka programowania. :)

    0