Przesyłanie pliku hex

[cyki]

Witam
Piszę program w LabView 7.1 który ma za zadanie zaprogramować przez port szeregowy RS232 procesor. Procesor najpierw musi otrzymać komendę "debug on" (zwykły bajt), po czym trzeba przesłać skompilowany program w postaci pliku z rozszerzeniem hex. Zwykłe komendy potrafię wysyłać, natomiast pliku nigdy nie przesyłałem przez RS232. Będę wdzięczny za wszelkie rady.

[jogurt_owocowy]

No jak dla mnie to takie coś jak na obrazku wystarczy. Oczywiście pozostałe wejścia klocków też trzeba odpowiednio podłączyć w zależności od potrzeb.

[cyki]

Dzięki za odpowiedź.
Chcę jeszcze zrobić pasek postępu procesu ładowania tego hexa do procesora. Może mi ktoś pomóc?

[jogurt_owocowy]

Przy takim rozwiązaniu jak na obrazku nie da się.
Jeśli koniecznie chcesz mieć pasek postępu (bo np. klient sobie życzy) to rozbij dane z pliku na ileś tam części i wyślij je jedna po drugiej uaktualniając pasek pomiędzy wysłaniami. Może to zadziała, ale to zależy... spróbuj.

Pozdrawiam

[Mikrobi]

A może tak...?

[jogurt_owocowy]

Ale cyki to wysyła po RSie do procka, a nie do pliku. Nie od dziś wiadomo, że 17. to dobra pora na kawę ;)

[Mikrobi]

Żelazny Karle Imieniem Wasyl.... ;) znaczy się jogurcie_owocowy...
To poglądówka, z możliwością szybkiego przetestowania.
Jednak jeśli o kawie mowa to....

...może być Lavazza 8)

[jogurt_owocowy]

Żelazny Karle Imieniem Wasyl....

:?:
Mikrobi, ty chyba coś jednak już piłeś i nie była to kawa
No widzisz... bez poglądówki nie zajęło Ci wiele więcej czasu. Od razu lepiej. A sprawdzałeś czy to działa na jakimś żywym sprzęcie? Jak tak i działa to nie mam więcej pytań, ale jak nie sprawdzałeś, to napiszę co mnie w tym gryzie.
PS. Narobiłeś mi smaka na tą Lavazzę. Jej cena powoduje u mnie zimny dreszcz na plecach, ale chyba w końcu się skuszę

[Mikrobi]

nie sprawdzałem, coś cię gryzie...? korozja wcześnie się zaczyna w tym roku...
;)

Poglądówka była mi potrzebna do sprawdzenia metody. Nie sprawdzałem tego przez programowanie mikrokontrolera, jeśli o to pytasz.

[cyki]

Panowie powiedzcie co sądzicie. Program który piszę docelowo ma programować 4 procesory jednoczesnie. Będą zainstalowane dodatkowe 2 porty RS232. Zasanawiam się jak to będzie chodziło, bo aplikacje w LabView jak mi wiadomo do najszybszych nie należą. Problem w tym, że te procki mają się programować jak najszybciej się da przez RS232. Czy nie będzie problemó z zawieszaniem sie programu z powodu jednoczesnej obsługi 4 portów. Może lepiej to napisać w Builderze C++... :?

[bogdani]

Witaj

Co masz na myśli do najszybszych nie należą ?

Jeśli chodzi o wysyłanie 4 potoków z szybkością 115 kb/s to nie widzę najmniejszego problemy i zostanie jeszcze zapas. No ale wszystko zależy od komputera jakim dysponujesz, bo masz normalny PC (współczesny) a nie jakiś eksponat w stylu 486...

bogdani

[cyki]

Słyszałem po prostu, że LabView nie nadaje się do pisania programów, które muszą działać bardzo szybko (np. dobrze napisany program w assemblerze będzie wykonywał się szybciej niż ten sam program napisany w C czy właśnie w LabView, z tym że w Labview dużo wolniej niż w C na przykład). Ale tak sobie mysle, że jeżeli chodzi o przesyłanie danych po RS to nie ma znaczenia w czym to napiszę. Program nie będzie jakiś tam super wypasiony (proste 4 okienka z wyborem COM-a, scieżki dostępu do hexa i pasek postępu procesu ładowania pliku do procka. Gdzies u góry wersja ładowanego softu (będzie ich kilka-kazda w innym katalogu gdzies na dysku) wspólna dla wszystkich 4 okienek - to wszystko. Co sądzicie? Ma to prawo dobrze działać?

[Mikrobi]

Słyszałem po prostu, że LabView nie nadaje się do pisania programów, które muszą działać bardzo szybko

Jest to oczywistą brednią. Opinia taka wywodzi się od ludzi, którzy nie znają się na programowaniu w LabVIEW, za to np. dosyć swobodnie programują w C lub assemblerze. Przenoszą oni swoje nawyki języków w których programują na codzień do LabVIEW, nie zwracając uwagi na to że metoda tworzenia kodu i jego filozofia jest inna.
Oczywiście ponoszą porażkę, ale lekko i bezmyślnie zrzucają winę na środowisko i "opiniotwórczo" wyrażają właśnie takie poglądy.

Tak, w G, C, C++, VB, C# czy asemblerze istotna jest architektura programu, czyli mówiąc wprost sposób jego wykonywania.
W każdym z tych języków można napisać prosty program w sposób tak zagmatwany lub niespójny z danym językiem że będzie on stanowił pseudo-przykład "nienadawania się" danego języka.

Co do samego programu: prosty program, dobry do ćwiczeń i przyswojenia podstaw prawidłowego tworzenia kodu.

[cyki]

Oto co narazie udało mi się zrobić. Mikrobi możesz mi wyjaśnić, jak zrobiłes Maximum.Scale dla slide. Jak sądzicie, czy to będzie działać. Co z tą pętlą, bo mikrobi uczynił ją nieskończoną, ja dałem 200 cykli zeby mi sie nie wieszał program.

[jogurt_owocowy]

1. Kliknij prawym klawiszem na kontrolce Slide (Wykonano), Create -> Property Node i tu wybierz własność Scale.Maximum.
2. Skasuj to 200 przy terminalu N pętli. Ona wcale nie jest nieskończona - wpisz w helpie "autoindexing" i poczytaj dlaczego.

Słyszałem po prostu, że LabView nie nadaje się do pisania programów, które muszą działać bardzo szybko

A Twój program w takiej postaci będzie kolejnym niby-potwierdzającym tę nieprawdziwą tezę.
Jeśli już upierasz się na pasek postępu, to da się go zrobić w taki sposób jak Mikrobi pokazał (zresztą to tylko przykład idei), ale efektywność tego (rozumiana jako szybkość ładowania programu do procka) będzie wątpliwa - na pewno nie najwyższa jaką LV oferuje.