-
Data: 2022-07-28 20:55:23
Temat: Re: Rynek pracy STM32
Od: Piotr Gałka <p...@c...pl> szukaj wiadomości tego autora
[ pokaż wszystkie nagłówki ]W dniu 2022-07-21 o 16:41, heby pisze:
>> Na razie o ile wiem to według brata przykład USB na załatwienie
>> prostej rzeczy zabiera 10x za dużo miejsca i nie zostaje miejsca na
>> naszą aplikację, a chcemy się zmieścić w 1/2 flasha z powodu upgrade'ów.
>
> Gcc ma flagę -Os? Symbole debugowe wyłaczone w docelowej binarce?
>
> Raczej nie dam wiary, że jest tak źle. Prosty kod usb UARTa na STM32
> zajmował jakies kilobajty. Ba, w małym AVR potrafili to zmieścić, z
> softwareową emulacją.
Odgrzebię starą wypowiedź bo małe! co nieco mogę powiedzieć.
Z tą objętością to pewnie przesadziłem.
Nie wiem co to flaga -0s
Make ostatnio używałem z Turbo C++ 1.0 w okolicy 1990. Od tamtej pory
używam po prostu środowiska więc nie znam żadnych flag.
Dziś brat trochę mi opowiedział o tym przykładzie USB który ma z jakimś
ich systemem uruchomieniowym. To jest przykład, ale to wygląda jakby
stosowany zestaw funkcji miał być (według słów brata olbrzymią)
biblioteką do obsługi USB w tych procesorach.
To co mogę powiedzieć jest trochę jak głuchy telefon bo wiem, że choć ma
się jakieś wyrobione zdanie trudno jest czasami wszystko wyłożyć komuś
(czyli mi) kto nie zna szczegółów. Mówi się wtedy tylko o prostych
najważniejszych rzeczach i wiele szczegółów ginie.
Mówił mniej więcej tak:
Jakoś w końcu udało mi się przebić przez ten przykład. Wreszcie mi to
zadziałało - urządzenie zgłasza się jako nasze. Tylko tyle tam mi śmieci
zostało z tego co oni napisali...
Nie uwierzysz jak idiotycznie to jest napisane. Po pierwsze wszystko
robią w przerwaniach. Kto to widział. Przerwanie powinno być krótkie, a
nie że jak się zaczyna to końca nie widać. Całe ramki analizują w
przerwaniach. Na dokładkę na cały czas przerwania blokują wszystkie
inne. No jak takie coś ma potem w ogóle działać.
Jest taki endpoint kontrolny do którego przychodzą tylko ramki
sterujące. Jest ramka z danymi z którymi trzeba coś zrobić i jest ramka
na którą ja mam odpowiedzieć. Jak odpowiem to mam dostać potwierdzenie w
postaci pustej ramki. Wyobraź sobie, że oni jak wyślą te dane to
przestawiają cały endpoint kontrolny na odbiór zwykłych ramek (a
przecież do enpointa kontrolnego takie ramki nie mogą w ogóle trafiać) i
w ten sposób odbierają tę pustą ramkę i potem znowu przestawiają
wszystko na odbiór ramek sterujących bo może taka się zdarzy.
Zapytałem, a czy muszą się przestawiać:
Nie w życiu. Tę pustą ramkę swobodnie odbieram bez przestawiania
czegokolwiek. Program jest tak pisany jakby było wiadomo, że teraz ma
przyjść akurat ta pusta ramka. A jak nie dotrze to będzie to wisiało bo
się nie przestawi na ramki sterujące. Przecież tak nie może program
wyglądać. I potem ktoś się wzoruje na czymś takim i mamy jak mamy.
Ja: Jak przestawiony na normalne to kontrolnych nie odbierze?
Nie odbierze.
To był trochę przycinek do mnie, bo moje programy na PC komunikujące się
z naszymi urządzeniami ja tak piszę, że czekam na to co wiem, że ma
przyjść i jak jest coś innego to wywalam błąd. Brat w ogóle nie
akceptuje takiego podejścia i nie omieszka mi tego zawsze wytknąć.
Podobno ratuje mnie tylko to, że moje programiki to są do prostych
operacji z naszymi urządzeniami i jak się coś wysypie to można
powtórzyć. Ale ja uważam, że skoro ja rządzę na łączu to mogę zakładać,
że wszyscy się podporządkują.
Według niego nie można nigdy czekać na to co się wię, że ma przyjść i
nie wiedzieć co zrobić z nieoczekiwanymi ramkami i co zrobić jak się nie
doczekamy (ja w niektórych sytuacjach je celowo gubię i czekam (z
timeoutem) na tę jedną jedyną co wiem, że ma przyjść).
Zawsze trzeba być przygotowanym na wszystko bo może na łącze dostanie
się wcześniej jakaś inna ramka.
To jego podejście chyba głównie jest kopiowaniem podejścia z RS485 gdzie
kompletnie nie wiadomo co przyjdzie, czy do mnie, czy w ogóle inni
rozmawiają, czy może zderzenie ramek. I urządzenie ma w każdej chwili
wiedzieć (czyli tyle co przerwanie na zbocze - a w sensie całej szyny
RS485 najdalej po czasie propagacji zbocza - około 10us), że linia jest
zajęta i jak się ma chęć coś nadać to trzeba poczekać na koniec czyjejś
transmisji.
To wynika z tego, że my na RS485 nie stosujemy odpytywania tylko każdy,
kto coś ma do nadania nadaje. Informacje są przekazywane prawie
najszybciej jak się da. Minimalne przerwy na łączu wynikają z dodawania
losowych opóźnień aby jak dwaj wejdą na raz to przy następnym razie już
jeden był wcześniej od drugiego.
P.G.
Najnowsze wątki z tej grupy
- T-1000 was here
- Ściąganie hasła frezem
- Koszyk okrągły, walec 3x AA, na duże paluszki R6
- Brak bolca ochronnego ładowarki oznacza pożar
- AMS spalony szybkim zasilaczem USB
- stalowe bezpieczniki
- Wyświtlacz ramki cyfrowej
- bateria na żądanie
- pradnica krokowa
- Nieustający podziw...
- Coś dusi.
- akumulator napięcie 12.0v
- Podłączenie DMA 8257 do 8085
- pozew za naprawę sprzętu na youtube
- gasik
Najnowsze wątki
- 2025-02-01 "Nie kupujcie samochodów elektrycznych
- 2025-02-01 jakie małe auto duże w środku :-)
- 2025-02-01 Re: pytanie do oponiarzy lub szybkojeżdzących (opony Hankook Ventus Prime, S1 Evo, alternatywy)
- 2025-02-01 T-1000 was here
- 2025-02-01 Warszawa => DevOps Engineer <=
- 2025-02-01 Katowice => Administrator IT - Operating Systems and Virtualization <=
- 2025-02-01 Warszawa => Spedytor międzynarodowy <=
- 2025-02-01 Śmierć mózgu a narządy do pobrania
- 2025-01-31 A niektórym to naprawdę zależy na ekologi w miastach LPG POWRACA ;-)
- 2025-01-31 Lublin => Programista Delphi <=
- 2025-01-31 Łódź => Programista NodeJS <=
- 2025-01-31 Wrocław => Senior SAP Support Consultant (SD) <=
- 2025-01-31 Warszawa => Full Stack web developer (obszar .Net Core, Angular6+) <=
- 2025-01-31 Gdańsk => iOS Developer (Swift experience) <=
- 2025-01-31 Kraków => UX Designer <=