Alternatywy dla VB.NET w komunikacji RS232 z urządzeniem PIC 16F877A Delphi, C czy coś innego?

Sat Oct 06, 2007 12:47 pm   

Witam.
Czy mozecie polecic cos innego niz VB.NET do "robienia" sterowania po
RS232 jakims urzadzeniem ? Zrobilem na PIC-u urzadzenie i w sumie
dziala poprawnie, ale dobija mnie komunikacja z PC. Do magistrali
RS485 w urzadzeniu wykorzystalem RS232 z PIC-a, bo chcialem zeby bylo
pewnie (sprzetowo), a komunikacje urzadzenia z PC po RS-232 napisalem
samodzielnie.
Chcialem sie dowiedziec, czy np. w Delphi, czy czyms podobnym nie
bedzie tak jak w VB.NET, ze jak zaczynam dzialac z jakims programem
np. Word, a ten do komunikacji z urzadzeniem dziala w tle, to nie ma
"plynnosci" ? Juz tlumacze.

Mam timer-y w VB.NET, ktore np. co 10ms wysylaja cos do urzadzenia po
magistrali RS-485 i odczytuja odpowiedz. Uzywam piezo do sygnalizacji
przeslania kilku bajtow, wiec slysze jak przebiega komunikacja. Jesli
mam przed soba aplikacje, to jest ok. Jesli zostawie ja w tle, to
slysze ze przestaje to dzialac plynnie, a przez to co jakis czas
komunikacja pada. Program w PIC-u mi sie zawiesza, bo mam jedna jedyna
petle goto $-1, w ktorej procek czeka na opadajace zbocze w sygnale
RS-232 z PC.

Komunikacja jest na 115200, PIC 16F877A z kwarcem 16M i nie mam zbyt
wiele czasu na sprawdzanie warunkow.
Zrobilem juz licznik, ktory po przepelnieniu powinien wyjsc z
procedury, ale przez to zdarza sie, ze przegapiam moment opadania tego
zbocza i nadal nie jest to to o co mi chodzilo.
Pozostaje zrobic to na przerwaniu, ale to tylko polsrodek, bo
komunikacja nadal nie bedzie plynna.
Czy to windows XP tak dziala i nic nie poradze ?
Pewnie ktos napisze, ze jesli program na PC, to tylko w C, ale to
raczej odpada, bo
wymaga duzo wiecej czasu, a ja mam prosty programik na PC i to by mnie
dobilo.
No i kupilem dawno temu VB.NET, wiec forsy byloby szkoda.
Jesli jednak okaze sie, ze w C bedzie idealnie plynnie, bez problemow
i cudownie, to poprosze o jakies linki do opisu jak napisac
komunikacje z PC po RS-R232 w C i skad wziac jakies darmowe C.

Pozdrawiam,
Mariusz

Sat Oct 06, 2007 1:20 pm   

marcom napisał(a):

to że nie ma płynnej transmisji wynika z własciwości systemu
operacyjnego, który rozdziela zasoby procesom, więc jeśli program do
komunikacji jaest aktywny to prawdopodobnie ma częstszy dostęp do
procesora. Można zwiększyć priorytet procesu: alt+ctr+del, procesy,
prawy przycisk myszy na procesie i ustaw priorytet, jeśli dasz na "Czasu
rzeczywistego" prawdopodobnie nigdy nie będzie problemów z transmisją,
ale nawet wskaźnik myszy nie drgnie. Rozwiązaniem wg mnie jest albo
zmniejszenie szybkości transmisji, albo zastosowanie bufora w uC, albo
taki program w uC, który czeka na kolejny bajt.

Sat Oct 06, 2007 1:24 pm   

Sat, 06 Oct 2007 04:47:41 -0700 jednostka biologiczna o nazwie marcom
<marcom@marcom.webserwer.pl> wyslala do portu 119
jednego z serwerow news nastepujace dane:


Nie wiem, ale mam wrażenie że to bardziej wina systemu który nie
zawsze radzi sobie z obsługą wątków na czas. Poza tym spróbuj ustawić
opowiednio wysoki priorytet wątku, służy do tego funkcja
SetThreadPriority (z kernel32.dll).
Możliwe jednak że VB wstawia do kodu sporo śmieci które spowalniają
pracę programu. Spróbuj napisać swój program w OpenWatcomie, albo w
CBuilderze.


O ile pamiętam to Borland CBuildera można teraz ściągnąć za darmo
(legalnie).
Zresztą polecam BCB na początek zamiast Watcoma - bez porównania
szybciej i łatwiej się robi okna programu i ich obsługę.

O, tu jest v 6.0, na stronie Borlanda jakoś nie mogę wygrzebać:
http://www.dhost.info/download/details.php?id=0821490141

OpenWatcom - kiedyś bardzo drogi (bo profesjonalny) kompilator, teraz
za darmo jako OpenSource:
www.openwatcom.org

Przykładów jak napisać obsługę RS-232 pod Windows masz w sieci
mnóstwo.





--
RUN"
Press PLAY then any key:

Sat Oct 06, 2007 1:39 pm   

Sat, 06 Oct 2007 14:24:29 +0200 jednostka biologiczna o nazwie
__Maciek <i80c586@cyberspace_NO_SPAM_.org> wyslala do portu 119
jednego z serwerow news nastepujace dane:


Jeszcze jest SetPriorityClass i możliwość ustawienia priorytetu
procesu na REALTIME_PRIORITY_CLASS, że zacytuję helpa:

"REALTIME_PRIORITY_CLASS Specify this class for a process that
has the highest possible priority. The threads of the process preempt
the threads of all other processes, including operating system
processes performing important tasks. For example, a real-time process
that executes for more than a very brief interval can cause disk
caches not to flush or cause the mouse to be unresponsive."




--
RUN"
Press PLAY then any key:

Sat Oct 06, 2007 1:58 pm   

Nie wiem co za urządzenie robisz, ale jesli jest ono uzależnione od
transmisji z innym do tego stopnia, że przestaje działać to musisz to
zmienić. Zanik transmisji jest rzeczą, która może sie przytrafic i nie
powinno to prowadzić do zawieszenia sie urządzenia. Zastosowanie w takim
przypadku przerwań nie jest półśrodkiem, a bardzo dobrym rozwiązaniem. W
krótkim przerwaniu buforujesz dane, które wykorzystujesz gdzieś indziej.

Sat Oct 06, 2007 4:40 pm   

On Sat, 06 Oct 2007 04:47:41 -0700, marcom
<marcom@marcom.webserwer.pl> wrote:


C#.NET? :-)


wygląda na to, że masz problem z programem w PIC i jeszcze do tego
dowiedziałeś się, że XP to nie system czasu rzeczywistego :-)


raczej tak. Nie masz gwarancji, że Twój program dostanie zasoby zawsze
100 razy na sekundę (pytanie jeszcze: jakie opóźnienie względem 10ms
dopuszczasz).


VB.NET 2005 Express jest darmowy. Polecam.
--
pozdrawiam,
Jarek Andrzejewski

Sun Oct 07, 2007 4:36 pm   

On 6 Pa , 14:24, __Maciek <i80c586@cyberspace_NO_SPAM_.org> wrote:

Witam.
Dziekuje, juz sciagam. Jesli to bedzie proste, to sprawdze na
pierwszym lepszym przykladzie.

Pozdrawiam,
Mariusz

Sun Oct 07, 2007 4:49 pm   

On 6 Pa , 14:58, "Bogdan G" <b_gutknecht_usu...@interia.pl> wrote:

Witam.
Zdaje sobie z tego sprawe, ale nie wiem czy nie zmienie PIC-a na
takiego z 2 RS-232.. bo to wiele by ulatwilo.
W prostych programach nie uzywalem nigdy sterowania przeplywem, a
teraz moze sie okazac, ze to tez wypadaloby zaimplementowac. Juz dawno
bym to wszystko zrobil, ale problem.. lub specyfika tych
bledow...polega na tym, ze to sie dzieje rzadko. Doslownie jak puszcze
to w petli na PC, zeby sie testowalo, to sie powoli rozpedza i pozniej
juz dziala.
Najgorzej jest na poczatku. Jest kilka sposobow, zeby sobie z tym
poradzic i pewnie
przyjdzie mi jeszcze zmniejszyc predkosc z 115200 na 57600..bo inaczej
nie zdaze tego obsluzyc z moim kwarcem
Na przerwaniu zrobilem transmisje RS-485 i jest bezbledna,a mam wolne
wejscie INT w tym PIC-u .. i pewnie je wykorzystam. Szkoda tylko, ze
okazuje sie to teraz, bo pisze wszystko w ASM (jakos nie umiem sie
przestawic na C)
i przesuna mi sie wszystkie adresy. Bedzie ciezko to od nowa
poprzesuwac.
Program nawet nie tyle sie wiesza, ale podejrzewam, ze w momencie
kiedy ma petle goto $-1 i czeka na bit startu
a w czasie transmisji padnie komunikacja z PC, to pozniej czyta jakies
poprzesuwane bajty z PC i sie na tym zapetla (bo kazda paczke z PC
koncze znacznikiem konca pakietu i on przez to przesuniecie sie gubi).
Rozpisalem sie, ale moze cos sie komus nasunie i mnie naprowadzi...
Najszybciej bedzie chyba odpalic timer na czas transmisji i jak
wygeneruje on przerwanie, to program przeskoczy dalej i nie bedzie sie
wieszal.
Mam wiele pomyslow, ale przy tej predkosci takie czeste przerwania
troche przeszkadzaja (na jedna transmisje przypadnie ich kilka).


Dziekuje,
Mariusz

Sun Oct 07, 2007 4:51 pm   

On 6 Pa , 14:39, __Maciek <i80c586@cyberspace_NO_SPAM_.org> wrote:

Dzieki, sprawdze to.
Wkurzam sie, ze np. MPLAB programuje PIC-a i moge robic co chce na
komputerze, a on sie i tak zaprogramuje bez problemu. Dioda mruga
miarowo, czasami nawet zatrzymuje sie na ekranie licznik bajtow i
mozna pomyslec, ze wszystko stoi (tak obciazam komputer czyms innym),
ale w efekcie koncowym wszystko sie pewnie programuje i dziala. Tez
bym tak chcial.

Mariusz

Sun Oct 07, 2007 10:14 pm   

On Sun, 07 Oct 2007 08:51:54 -0700, marcom
<marcom@marcom.webserwer.pl> wrote:


napisz porządnie część na PICa i będzie tak
--
pozdrawiam,
Jarek Andrzejewski