Discussion:
Kilka pytań o STM32F407VGT6
(Wiadomość utworzona zbyt dawno temu. Odpowiedź niemożliwa.)
Atlantis
2020-11-21 08:12:27 UTC
Permalink
Do tej pory wszystkie swoja bardziej "zaawansowane" projekty (takie,
które wymagały zastosowanie MCU o większej mocy obliczeniowej i bogatym
zestawie peryferiów) robiłem głównie na układach PIC24/PIC32, wcześniej
ATXmega. Miałem już trochę do czynienia z STM-ami, ale głównie w formie
prostych STM32F103. Teraz przymierzając się do pewnego projektu
przyglądam się bardziej zaawansowanemu układowi z tej rodziny -
STM32F407VGT6. Gdy przeglądałem dokumentacje i przeklikiwałem się przez
konfigurator STM32CubeMX, nasunęło mi się kilka pytań:

Sposób podłączenia USB w trybie host:
Na stronie 186 dokumentacji
(https://www.st.com/resource/en/datasheet/stm32f407vg.pdf) znajduje się
schemat. Pin VBUS gniazdka USB jest na nim podłączony za pośrednictwem
"current limiter power switch" albo przynajmniej "basic power switch",
sterowany pinem GPIO.
W STM32CubeMX nigdzie nie widzę możliwości wyboru tego wyjścia
kluczującego zasilanie, które byłoby przypisane do konkretnego
interfejsu USB. Mam rozumieć, że już z poziomu kodu wybiera się dowolny
pin GPIO?
Pytam, ponieważ w układach PIC32 był do tego przeznaczony sterowany
sprzętowo pin VBUSON, z którego stosowania można było zrezygnować w
konfiguracji, co zresztą robiłem, ponieważ w moim urządzeniu do hosta
USB był na stałe podłączony pendrive, nie było wiec konieczności
kluczowani zasilania - było ono wyprowadzone na gniazdku na stałe.
Rozumiem, że w przypadku STM32 sterowanie zasilaniem jest obowiązkowe i
powinienem w swoim projekcie uwzględnić ten switch?
Poza tym widzę, że można aktywować/dezaktywować jeszcze dwa piny
przypisane do interfejsu USB: VBUS oraz SOF. Rozumiem, że VBUS służy do
wykrywania zasilnia na gniazdku USB i jest stosowany w trybach device
orz OTG. Schemat w dokumentacji dla trybu host nie uwzględnia tego pinu,
jednak STM32CubeMX pozwala na jego użycie nawet w trybie "Host only".
Jaka jest jego funkcja w tym przypadku? Rozumiem, że mogę z niego
zrezygnować, jeśli urządzenie m być hostem?
I jeszcze jedno pytanie odnośnie USB. DO tej pory we wszystkich swoich
projektach stosowałem drabinkę transili tuż obok gniada USB. Schematy w
dokumentacji ich nie uwzględniają. To uproszczenie schematu, czy celowe
działanie? Rozumiem, że nadal mogę stosować to zabezpieczenie z STM32?


Magistrala równoległa do podłączenia LCD:
Z tego co widzę, mikrokontroler posiada sprzętową magistralę do
komunikacji z pamięciami, którą można także wykorzystać do podłączenia
wyświetlacza LCD.Dysponuję takim wyświetlaczem:
Loading Image...
Czy będzie się go dało podłączyć za pomocą tego interfejsu? Jeśli tak, w
jaki sposób? Do którego pinu powinien iść sygnał "LCD register select"?
Czy ten interfejs wymaga już jakiegoś specjalnego sposobu prowadzenia
ścieżek?


Przetwornik cyfrowo-analogowy:
Widzę, że ten układ posiada dwa wyjścia DAC. Sprawdzą się w roli wyjść
audio (odtwarzanie muzyki) czy lepiej zastosować osobny układ, np. na I2S?


Interfejs SDIO:
Z tego co widzę, układ posiada również interfejs SDIO. To dla mnie pewna
nowość, bo do tej pory zawsze podłączałem karty SD przez SPI. Czy
powinienem o czymś pamiętać projektując płytkę? Linie SDIO trzeba już
prowadzić w jakiś określony sposób? Który tryb pracy (SD/MMC) i
szerokość magistrali (1/4/8 bit) będą najbardziej odpowiednie?
MKi
2020-11-24 08:39:07 UTC
Permalink
Post by Atlantis
Na stronie 186 dokumentacji
(https://www.st.com/resource/en/datasheet/stm32f407vg.pdf) znajduje się
schemat. Pin VBUS gniazdka USB jest na nim podłączony za pośrednictwem
"current limiter power switch" albo przynajmniej "basic power switch",
sterowany pinem GPIO.
W STM32CubeMX nigdzie nie widzę możliwości wyboru tego wyjścia
kluczującego zasilanie, które byłoby przypisane do konkretnego
interfejsu USB. Mam rozumieć, że już z poziomu kodu wybiera się dowolny
pin GPIO?
Tak
Post by Atlantis
Pytam, ponieważ w układach PIC32 był do tego przeznaczony sterowany
sprzętowo pin VBUSON, z którego stosowania można było zrezygnować w
konfiguracji, co zresztą robiłem, ponieważ w moim urządzeniu do hosta
USB był na stałe podłączony pendrive, nie było wiec konieczności
kluczowani zasilania - było ono wyprowadzone na gniazdku na stałe.
Rozumiem, że w przypadku STM32 sterowanie zasilaniem jest obowiązkowe i
powinienem w swoim projekcie uwzględnić ten switch?
Jeśli przewidujesz sytuację, że device weźmie za dużo prądu,
ogranicznik poda sygnał "overcurrent" i trzeba będzie zasilanie
odłączyć - wtedy ten port jest potrzebny. Dowolny.
Post by Atlantis
Poza tym widzę, że można aktywować/dezaktywować jeszcze dwa piny
przypisane do interfejsu USB: VBUS oraz SOF. Rozumiem, że VBUS służy do
wykrywania zasilnia na gniazdku USB i jest stosowany w trybach device
orz OTG. Schemat w dokumentacji dla trybu host nie uwzględnia tego pinu,
jednak STM32CubeMX pozwala na jego użycie nawet w trybie "Host only".
Jaka jest jego funkcja w tym przypadku?
To już moje rozważania teoretyczne, nigdy nie robiłem hosta.
Ale wydaje mi się, że VBUS jest wejściem monitorującym 5V i
generującym przerwanie, gdy napięcie spanie poniżej normy.
Post by Atlantis
Rozumiem, że mogę z niego
zrezygnować, jeśli urządzenie m być hostem?
Jeśli jesteś pewny źródła 5V można z niego zrezygnować.
W Reference manualu (rev. 13, str. 1255) jest przykładowy
układ bez VBUS.
Post by Atlantis
I jeszcze jedno pytanie odnośnie USB. DO tej pory we wszystkich swoich
projektach stosowałem drabinkę transili tuż obok gniada USB. Schematy w
dokumentacji ich nie uwzględniają. To uproszczenie schematu, czy celowe
działanie? Rozumiem, że nadal mogę stosować to zabezpieczenie z STM32?
Ja stosuję układ https://www.st.com/en/protection-devices/usblc6-2.html
Nie było przypadku uszkodzenia portu.
Post by Atlantis
Z tego co widzę, mikrokontroler posiada sprzętową magistralę do
komunikacji z pamięciami, którą można także wykorzystać do podłączenia
https://barth.pl/pictures/TFT_320GVT_9341_bottom.jpg
Czy będzie się go dało podłączyć za pomocą tego interfejsu? Jeśli tak, w
jaki sposób? Do którego pinu powinien iść sygnał "LCD register select"?
Ja stosuję inne wyświetlacze, ale nazwy pinów są takie same. Połączenia:
LCD - STM32
RS - A16
RD - NOE
WR - NWE
CS - NE1
Reset - dowolny port
Post by Atlantis
Czy ten interfejs wymaga już jakiegoś specjalnego sposobu prowadzenia
ścieżek?
Ja się nigdy nie specjalnie nie przejmowałem i zawsze działa.
Nie znam się i się nie wypowiem :(

Pozdrowienia,
MKi
Atlantis
2020-11-25 08:43:37 UTC
Permalink
Post by MKi
Jeśli przewidujesz sytuację, że device weźmie za dużo prądu,
ogranicznik poda sygnał "overcurrent" i trzeba będzie zasilanie
odłączyć - wtedy ten port jest potrzebny. Dowolny.
Hmm... To jest realizowane przez bibliotekę do obsługi USB, czy muszę to
sam zaimplementować w pętli głównej/funkcji obsługi przerwania
zewnętrznego? Pytam, bo chciałbym się upewnić, czy mogę dostosować się
zarówno do elementów, gdzie pin EN jest aktywowany stanem niskim, jak i
wysokim.

Rozumiem, że nic nie stoi na przeszkodzie, żeby zamiast "switcha"
zastosować przetwornicę, którą mogę wyłączyć zewnętrznym sygnałem?
Urządzenie będzie zasilane z akumulatorka, więc przetwornica i tak jest
jedynym sposobem na uzyskanie 5V do zasilania USB.
Post by MKi
Ja stosuję układ https://www.st.com/en/protection-devices/usblc6-2.html
Nie było przypadku uszkodzenia portu.
Dokładnie tych samych używam od dawna z PIC32 oraz Xmega. Dzięki za
potwierdzenie, że nie ma z nimi problemu w przypadku STM32. ;)
MKi
2020-11-25 09:04:12 UTC
Permalink
Post by Atlantis
Post by MKi
Jeśli przewidujesz sytuację, że device weźmie za dużo prądu,
ogranicznik poda sygnał "overcurrent" i trzeba będzie zasilanie
odłączyć - wtedy ten port jest potrzebny. Dowolny.
Hmm... To jest realizowane przez bibliotekę do obsługi USB, czy muszę to
sam zaimplementować w pętli głównej/funkcji obsługi przerwania
zewnętrznego? Pytam, bo chciałbym się upewnić, czy mogę dostosować się
zarówno do elementów, gdzie pin EN jest aktywowany stanem niskim, jak i
wysokim.
Sam implementujesz. Tylko od zastosowanego układu ograniczającego
prąd zależy, czy EN będzie aktywowane Hi czy Lo.
Post by Atlantis
Rozumiem, że nic nie stoi na przeszkodzie, żeby zamiast "switcha"
zastosować przetwornicę, którą mogę wyłączyć zewnętrznym sygnałem?
Urządzenie będzie zasilane z akumulatorka, więc przetwornica i tak jest
jedynym sposobem na uzyskanie 5V do zasilania USB.
Jak dla mnie jak najbardziej. Tylko musisz skądś wziąć
sygnał "overcurrent".

Pozdrowienia,
MKi
Atlantis
2020-11-25 14:45:47 UTC
Permalink
Post by MKi
Jak dla mnie jak najbardziej. Tylko musisz skądś wziąć
sygnał "overcurrent".
Może znajdzie się jakaś przetwornica, która daje taki sygnał? ;)
Zbych
2020-11-25 15:25:05 UTC
Permalink
Post by Atlantis
Post by MKi
Jak dla mnie jak najbardziej. Tylko musisz skądś wziąć
sygnał "overcurrent".
Może znajdzie się jakaś przetwornica, która daje taki sygnał? ;)
Jak poszukasz to na pewno :-)

Loading Image...
Atlantis
2020-11-27 08:21:57 UTC
Permalink
Post by MKi
Ja stosuję inne wyświetlacze, ale nazwy pinów są takie same.
Mogę jeszcze zapytać jakichś wyświetlaczy używasz?
Bo szukając informacji na temat mojego egzemplarza przekonałem się, że
nie jest to zbyt popularny model. Chińczycy chyba przestali go
produkować, zastępując nieco nowszą wersją, która ma inny pinout. Ciężko
będzie kupić zastępczy egzemplarz albo drugi taki sam wyświetlacz do
kolejnego projektu...
MKi
2020-11-27 09:03:19 UTC
Permalink
Post by Atlantis
Post by MKi
Ja stosuję inne wyświetlacze, ale nazwy pinów są takie same.
Mogę jeszcze zapytać jakichś wyświetlaczy używasz?
Bo szukając informacji na temat mojego egzemplarza przekonałem się, że
nie jest to zbyt popularny model. Chińczycy chyba przestali go
produkować, zastępując nieco nowszą wersją, która ma inny pinout. Ciężko
będzie kupić zastępczy egzemplarz albo drugi taki sam wyświetlacz do
kolejnego projektu...
Używam dwóch:
https://www.unisystem.pl/pl/products/lcd-tft/standard/wf43gtibedbt0.html
https://www.unisystem.pl/pl/products/lcd-tft/standard/wf70htifgdbt0.html

Pozdrowienia,
MKi
Atlantis
2020-12-19 14:31:17 UTC
Permalink
Post by MKi
https://www.unisystem.pl/pl/products/lcd-tft/standard/wf43gtibedbt0.html
https://www.unisystem.pl/pl/products/lcd-tft/standard/wf70htifgdbt0.html
Dzięki. Tak jeszcze dla porządku zapytam, bo właśnie kończę projektować
płytkę: czy któreś linie interfejsu LCD wymagają podciągania rezystorami
do zasilania?
MKi
2020-12-21 08:39:34 UTC
Permalink
Post by Atlantis
Post by MKi
https://www.unisystem.pl/pl/products/lcd-tft/standard/wf43gtibedbt0.html
https://www.unisystem.pl/pl/products/lcd-tft/standard/wf70htifgdbt0.html
Dzięki. Tak jeszcze dla porządku zapytam, bo właśnie kończę projektować
płytkę: czy któreś linie interfejsu LCD wymagają podciągania rezystorami
do zasilania?
Nie, ten interfejs (zasadniczo to jest interfejs pamięci NOR Flash,
sterowanie LCD jest tak przy okazji) jest całkowicie samodzielny.
A w ogóle to STM ma swoje własne pullupy i pulldowny, możesz je
włączać i wyłączać programowo.

Pozdrowienia,
MKi
Atlantis
2020-12-21 16:17:41 UTC
Permalink
Post by MKi
Nie, ten interfejs (zasadniczo to jest interfejs pamięci NOR Flash,
sterowanie LCD jest tak przy okazji) jest całkowicie samodzielny.
A w ogóle to STM ma swoje własne pullupy i pulldowny, możesz je
włączać i wyłączać programowo.
Niby tak, ale tutaj kierowałem się pamięcią o tym, że w niektórych
przypadkach i tak zalecane było stosowanie zewnętrznych pullupów, w celu
uniknięcia stanów nieustalonych na krytycznych liniach po restarcie,
zanim program zdąży skonfigurować dany pin. Chociażby linie CS w SPI...

Swoją drogą, używałeś może interfejsu RMII w STM32 do obsługi Ethernetu?
W jego przypadku konieczne będzie jakieś specyficzne prowadzenie linii
(np. wyrównywanie ich długości poprzez meandrowanie albo ekranowanie ich
masą) czy też wystarczy, jeśli będą możliwie krótkie? W końcu
częstotliwość pracy tej magistrali wynosi 50 MHz...
Grzegorz Niemirowski
2020-12-21 18:51:10 UTC
Permalink
Swoją drogą, używałeś może interfejsu RMII w STM32 do obsługi Ethernetu? W
jego przypadku konieczne będzie jakieś specyficzne prowadzenie linii (np.
wyrównywanie ich długości poprzez meandrowanie albo ekranowanie ich masą)
czy też wystarczy, jeśli będą możliwie krótkie? W końcu częstotliwość
pracy tej magistrali wynosi 50 MHz...
Piszę firmware dla urządzenia korzystającego z RMII w STM32. Żadnego
specjalnego prowadzenia ścieżek tam nie zastosowano. Niemniej zaleca się,
żeby różnica w długości nie była większa jak 2 cale, a nawet 10 mm według
jednego źródła. Ekranowanie również jest zalecane.
--
Grzegorz Niemirowski
https://www.grzegorz.net/
Atlantis
2020-12-21 20:55:42 UTC
Permalink
Post by Grzegorz Niemirowski
Piszę firmware dla urządzenia korzystającego z RMII w STM32. Żadnego
specjalnego prowadzenia ścieżek tam nie zastosowano.
Widziałem kiedyś tutorial, w którym płytka discovery została połączona z
modułem PHY za pomocą zwykłych kabli ze złączami do goldpinów, więc
podejrzewałem, że ten interfejs nie jest aż tak wymagający. Z drugiej
strony to, że coś działało w tutorialu nie oznacza, że będzie działało
stabilnie w finalnym urządzeniu, więc wolałem zapytać.
Post by Grzegorz Niemirowski
Niemniej zaleca się, żeby różnica w długości nie była większa jak 2
cale
Ten warunek niemal na pewno jest spełniony. Mikrokontroler i PHY
znajdują się w odległości 1.25". Biorąc pod uwagę fakt, że ścieżki
zakręcają i omijają przeszkody, najdłuższe z nich będą pewnie miały
długość nieco większą niż 2", ale różnica pomiędzy najdłuższą i
najkrótszą na pewno nie będzie tego rzędu
wielkości.
Post by Grzegorz Niemirowski
a nawet 10 mm według jednego źródła.
Ze spełnieniem tego warunku będzie już trudniej. Niemniej różnice w
długościach wynikają głównie z faktu, że nieraz trzeba się dostać do
wyprowadzeń po różnych stronach układu scalonego, omijając jakieś
elementy albo pola lutownicze.
Post by Grzegorz Niemirowski
Ekranowanie również jest zalecane.
Z tym też będzie ciężko. Warunek jest spełniony częściowo w tym sensie,
że linie RMII są zgrupowane razem i oblane polem masy. Niektóre z nich
przynajmniej na części długości mają masę między sobą. Niemniej płytka
jest modyfikacją projektu, który zaczął powstawać jeszcze w czasach, gdy
PCB projektowałem z myślą o termo/fototransferze, więc grubsze ścieżki i
większe pola lutownicze zajmują trochę miejsca, którego nie zostaje zbyt
wiele na "meanadry". Nie ma też przelotek pod układami.
Atlantis
2020-12-28 09:10:39 UTC
Permalink
Post by Grzegorz Niemirowski
Piszę firmware dla urządzenia korzystającego z RMII w STM32. Żadnego
specjalnego prowadzenia ścieżek tam nie zastosowano. Niemniej zaleca
się, żeby różnica w długości nie była większa jak 2 cale, a nawet 10 mm
według jednego źródła. Ekranowanie również jest zalecane.
Właśnie skończyłem projektować swoją płytkę z STM32107 i DP83848.
Jest szansa, że będzie stabilnie i prawidłowo działało w trybie Fast
Ethernet?
Atlantis
2020-12-28 09:12:25 UTC
Permalink
Post by Grzegorz Niemirowski
Piszę firmware dla urządzenia korzystającego z RMII w STM32. Żadnego
specjalnego prowadzenia ścieżek tam nie zastosowano. Niemniej zaleca
się, żeby różnica w długości nie była większa jak 2 cale, a nawet 10 mm
według jednego źródła. Ekranowanie również jest zalecane.
Właśnie skończyłem projektować swoją płytkę z STM32F107 i DP83848. To
amatorski projekt, więc nie oczekuję, że przeszłoby to jakąkolwiek
certyfikację. :) Można jednak liczyć na to, że będzie działało stabilnie
i prawidłowo w trybie Fast Ethernet?

https://ibb.co/rZn7LtF
Grzegorz Niemirowski
2020-12-28 10:59:38 UTC
Permalink
Post by Atlantis
Właśnie skończyłem projektować swoją płytkę z STM32F107 i DP83848. To
amatorski projekt, więc nie oczekuję, że przeszłoby to jakąkolwiek
certyfikację. :) Można jednak liczyć na to, że będzie działało stabilnie i
prawidłowo w trybie Fast Ethernet?
https://ibb.co/rZn7LtF
Myślę, że bez problemu. Co do płytki, to same ścieżki wyglądają OK jeśli
chodzi o kąty, równoległość i długość. Natomiast powinno się unikać
przelotek, widać dwie w okolicach C48. Możesz zerknąć na zalecenia
producenta w datasheecie, rozdział 8.1.1 PCBLayoutConsiderations.
--
Grzegorz Niemirowski
https://www.grzegorz.net/
Atlantis
2020-12-28 11:52:20 UTC
Permalink
Post by Grzegorz Niemirowski
Myślę, że bez problemu. Co do płytki, to same ścieżki wyglądają OK jeśli
chodzi o kąty, równoległość i długość. Natomiast powinno się unikać
przelotek, widać dwie w okolicach C48. Możesz zerknąć na zalecenia
producenta w datasheecie, rozdział 8.1.1 PCBLayoutConsiderations.
C48 jest podłączony do układu VS1003 (DAC/dekoder MP3) a przelotka po
jego prawej stronie znajduje się na interfejsie SPI, któremu to nie
powinno przeszkadzać. DP83848 znajduje się po lewej stronie płytki.
Grzegorz Niemirowski
2020-12-28 20:30:36 UTC
Permalink
C48 jest podłączony do układu VS1003 (DAC/dekoder MP3) a przelotka po jego
prawej stronie znajduje się na interfejsie SPI, któremu to nie powinno
przeszkadzać. DP83848 znajduje się po lewej stronie płytki.
Uh, nie wiem czemu zasugerowałem się, że jest z prawej. Co do przelotek, to
jeśli nie dało się inaczej, to będą musiały już tak zostać.
--
Grzegorz Niemirowski
https://www.grzegorz.net/
Atlantis
2021-01-12 07:45:53 UTC
Permalink
Post by Grzegorz Niemirowski
Uh, nie wiem czemu zasugerowałem się, że jest z prawej. Co do przelotek,
to jeśli nie dało się inaczej, to będą musiały już tak zostać.
Hmm... Udało mi się złożyć i uruchomić układ wykorzystujący DP83848 na
magistrali RMII. Na pierwszy ogień poszedł nieco starszy design tej
płytki, wykorzystujący PIC32MX795F512L (w pisaniu kodu dla PIC-ów mam
nieco większe doświadczenie niż STM32). Interfejs Ethernet znajduje się
tam nieco dalej od MCU niż na płytce STM32, której obrazek wrzuciłem
parę wiadomości wcześniej.

Efekty:
- Kontrolerowi Ethernet udaje się wynegocjować zestawienie połączenia
100 Mbps.
- Układ działa. Klient DHCP pobiera adres, mogę spokojnie korzystać z
prostego serwerka HTTP, odpalonego na urządzeniu.
- Test pingiem pokazuje, że na około 3500 wysłanych pakietów ICMP, jeden
z jakiegoś powodu pozostał bez odpowiedzi.

Czy takie wyniki są akceptowalne?
Marek
2021-01-12 12:51:27 UTC
Permalink
Post by Atlantis
- Układ działa. Klient DHCP pobiera adres, mogę spokojnie korzystać z
prostego serwerka HTTP, odpalonego na urządzeniu.
- Test pingiem pokazuje, że na około 3500 wysłanych pakietów ICMP, jeden
z jakiegoś powodu pozostał bez odpowiedzi.
Czy takie wyniki są akceptowalne?
Jak masz już http, to uruchom jakieś testowe transfery przez dobę. Na
samym tescie ICMP (niewielki payload i obciążenie interfejsu) bym
stabilności działania interfejsu nie opierał.
--
Marek
Atlantis
2021-01-12 16:55:13 UTC
Permalink
Post by Marek
Jak masz już http, to uruchom jakieś testowe transfery przez dobę. Na
samym tescie ICMP (niewielki payload i obciążenie interfejsu)  bym
stabilności działania interfejsu nie opierał.
Nie jestem jeszcze na 100% pewnie, bo pierwszy test był odpalony
relatywnie krótko, ale chyba udało mi się namierzyć przyczynę gubienia
pakietów ICMP i nie była ona sprzętowa.

Kod n którym testuję urządzenie jest pożyczony z wcześniejszego
projektu, w którym pracował ENC28J60. Poza testem Ethernetu, odpaliłem
też testy innych peryferiów. Jeden z nich (odtwarzanie muzyki na VS1003)
jest tymczasowo napisany w sposób nieoptymalny i niekiedy zatrzymuje
pętlę główną nawet na kilkadziesiąt ms. Najwyraźniej przy 100 Mbps takie
opóźnienie co jakiś czas powoduje czkawkę w pracy Ethernetu, podczas gdy
ENC28J60 pracujący z prędkością 10 Mbps jeszcze wyrabiał.
Marek
2021-01-12 19:16:01 UTC
Permalink
Post by Atlantis
pętlę główną nawet na kilkadziesiąt ms. Najwyraźniej przy 100 Mbps takie
opóźnienie co jakiś czas powoduje czkawkę w pracy Ethernetu, podczas gdy
ENC28J60 pracujący z prędkością 10 Mbps jeszcze wyrabiał.
Rozumiem, że używasz legacy drivera mchp, który działa na polling'u a
nie na przerwaniach?
--
Marek
Atlantis
2021-01-12 20:26:33 UTC
Permalink
Post by Marek
Rozumiem, że używasz legacy drivera mchp, który działa na polling'u a
nie na przerwaniach?
Tak, cały czas używam drivera i stosu TCP/IP z biblioteki MLA.
Powinienem to zmienić? ;)
a***@math.uni.wroc.pl
2021-01-13 00:03:19 UTC
Permalink
Uh, nie wiem czemu zasugerowa?em si?, ?e jest z prawej. Co do przelotek,
to je?li nie da?o si? inaczej, to b?d? musia?y ju? tak zosta?.
Hmm... Uda?o mi si? z?o?y? i uruchomi? uk?ad wykorzystuj?cy DP83848 na
magistrali RMII. Na pierwszy ogie? poszed? nieco starszy design tej
p?ytki, wykorzystuj?cy PIC32MX795F512L (w pisaniu kodu dla PIC-?w mam
nieco wi?ksze do?wiadczenie ni? STM32). Interfejs Ethernet znajduje si?
tam nieco dalej od MCU ni? na p?ytce STM32, kt?rej obrazek wrzuci?em
par? wiadomo?ci wcze?niej.
- Kontrolerowi Ethernet udaje si? wynegocjowa? zestawienie po??czenia
100 Mbps.
- Uk?ad dzia?a. Klient DHCP pobiera adres, mog? spokojnie korzysta? z
prostego serwerka HTTP, odpalonego na urz?dzeniu.
- Test pingiem pokazuje, ?e na oko?o 3500 wys?anych pakiet?w ICMP, jeden
z jakiego? powodu pozosta? bez odpowiedzi.
Czy takie wyniki s? akceptowalne?
Zalazy co chesz. W sieci pecetowej moj standartowy test to

ping -f -l 10 -s 1200 -c 10000

Czyli: maksymalna szybkosc, 10 pakietow w locie, rozmiar 1200,
10000 pakietow w sumie. Warto tez testowac na malych pakietach,
bo to mierzy jak szybko procek potrafi zareagowac na pakiet.

Tak a propo: jak w sieci na koncentryku mialem straty rzedu
1 na kilka tysiecy, to TCP chodzilo bez problemu. Ale,
np. nie dalo sie zbootowac komputera przez siec, bo nie
bylo retransmisji a jeden zgubiony pakiet blokowal tranfer
jadra i start. A przy tych statach i ilosci pakietow zgubiony
pakiet byl praktycznie pewny. W sieci ze switachami
przy malym ruchu nie powinno byc strat. Ten test wyzej
potrafil rozlozyc kombinacje switch + hub tak ze straty byly
bliskie 100%. To wyjasnilo problem z bardzo niska wydajnoscia
sieci. A zmiana switcha na inny typ rozwiazala problem.

Na MCU jest problem zeby soft zdarzyl zareagowac zanim bufory
w interfejsie sie przepelnia. W komputerze ogolengo
przeznacznie dostatecznie szybki procek i 50k na bufory
powinno byc OK, ale sprzetowe bufory w STM sa znacznie
mniejsze, wiec procek musi odpowiednio szybciej reagowac.
Albo ograniczasz sie do malo wymagajacych zastosowan...
--
Waldek Hebisch
Mateusz Viste
2021-01-13 06:34:02 UTC
Permalink
Post by a***@math.uni.wroc.pl
Tak a propo: jak w sieci na koncentryku mialem straty rzedu
1 na kilka tysiecy, to TCP chodzilo bez problemu. Ale,
np. nie dalo sie zbootowac komputera przez siec, bo nie
bylo retransmisji a jeden zgubiony pakiet blokowal tranfer
jadra i start.
Czy aby na pewno to było przyczyną? TFTP posiada mechanizm
zatwierdzania i powinien wykonać retransmisję. No chyba, że
implementacja była skopana - ale w takim razie to nie protokół (ani
sieć) była problemem.

Mateusz
a***@math.uni.wroc.pl
2021-01-13 13:13:55 UTC
Permalink
Post by a***@math.uni.wroc.pl
Tak a propo: jak w sieci na koncentryku mialem straty rzedu
1 na kilka tysiecy, to TCP chodzilo bez problemu. Ale,
np. nie dalo sie zbootowac komputera przez siec, bo nie
bylo retransmisji a jeden zgubiony pakiet blokowal tranfer
jadra i start.
Czy aby na pewno to by?o przyczyn?? TFTP posiada mechanizm
zatwierdzania i powinien wykona? retransmisj?. No chyba, ?e
implementacja by?a skopana - ale w takim razie to nie protok?? (ani
sie?) by?a problemem.
To bylo w 1993 roku, wtedy to dosc dokladnie badalem i raczej
nie zrobilem grubego bledu. Z tego co pamietam nie bylo
retransmisji na poziomie pakietow. Chyba byla retransmisja
calego pliku, ale to nic nie dawalo bo kolejny transfer
padal tak jak poprzedni. Wtedy zagladalem do dokumentow
i OIDP to moje obserwacje zgadzaly sie opisem TFTP.
ZTW to byla w miare stanartowa implementacja, innym
dzialala OK. W sieci byly (ogolnie o starcie przez siec)
komentarze "jak nie dziala to sprawdz czy siec nie gubi
pakietow".

Pozniej w lepszej sieci glupszy protokol (testowy transfer,
nie do normalnego uzycia) dzialal OK.
--
Waldek Hebisch
Grzegorz Niemirowski
2021-01-13 13:37:18 UTC
Permalink
Czy aby na pewno to by?o przyczyn?? TFTP posiada mechanizm
zatwierdzania i powinien wykona? retransmisj?. No chyba, ?e
implementacja by?a skopana - ale w takim razie to nie protok?? (ani
sie?) by?a problemem.
Mógłbyś już ogarnąć to kodowanie...
--
Grzegorz Niemirowski
https://www.grzegorz.net/
Mateusz Viste
2021-01-13 15:46:41 UTC
Permalink
Post by a***@math.uni.wroc.pl
Czy aby na pewno to by?o przyczyn?? TFTP posiada mechanizm
zatwierdzania i powinien wykona? retransmisj?. No chyba, ?e
implementacja by?a skopana - ale w takim razie to nie protok?? (ani
sie?) by?a problemem.
To bylo w 1993 roku, wtedy to dosc dokladnie badalem i raczej
nie zrobilem grubego bledu. Z tego co pamietam nie bylo
retransmisji na poziomie pakietow.
Nawet najstarsza wersja TFTP (ta sprzed poprawek z 1992) przewidywała
mechanizm retransmisji zgubionych pakietów:

"If a packet gets lost in the network, the intended recipient
will timeout and may retransmit his last packet (which may be data or
an acknowledgment), thus causing the sender of the lost packet
to retransmit that lost packet."

źródło: https://tools.ietf.org/html/rfc783

Przy czym oczywiście implementacje niewątpliwie mogły być różne.
Post by a***@math.uni.wroc.pl
ZTW to byla w miare stanartowa implementacja, innym
dzialala OK.
Mi też działało OK, a testowałem m.in. na łączu na którym sam
symulowałem losowe straty pakietów. Przy kilku procentach strat
załadowanie kernela potrafiło trwać dobre kilka minut, za sprawą nieco
długich domyślnych timeoutów (rzędu sekundy albo może dwóch). Ale
działało - stąd moje zastanowienie.

Mateusz
Atlantis
2021-01-13 08:58:08 UTC
Permalink
Post by a***@math.uni.wroc.pl
Na MCU jest problem zeby soft zdarzyl zareagowac zanim bufory
w interfejsie sie przepelnia. W komputerze ogolengo
przeznacznie dostatecznie szybki procek i 50k na bufory
powinno byc OK, ale sprzetowe bufory w STM sa znacznie
mniejsze, wiec procek musi odpowiednio szybciej reagowac.
Albo ograniczasz sie do malo wymagajacych zastosowan...
Co prawda na w tej konkretnej wersji płytki zastosowałem jeszcze
PIC32MX795F512L, ale to nie ma wielkiego znaczenia, bo te procki mają
zasoby i wydajność zbliżone do popularnych STM-ów. Płytkę z STM32F107
też niedługo wykonam.

W każdym razie wygląd na to, że faktycznie problemem było przepełnianie
się buforów pomiędzy kolejnymi wywołaniami funkcji odpowiedzialnej
pobieranie pakietów i obsługę stosu. Zakomentowałem fragment
odpowiedzialny za obsługę VS1003 i sytuacja się znacznie poprawiła. Czas
odpowiedzi na ping to teraz nieco ponad 0.1 ms, a na 40 tysięcy
wysłanych pakietów nie zgubił się ani jeden.

Będę musiał przepisać trochę kodu, żeby jego obsługa nie zajmowała tylko
czasu w pojedynczym przebiegu pętli.

BTW ktoś z was eksperymentował może z DP83848 na STM32 z bibliotekami
HAL? Próbuję to sobie wyklikać w STM32CubeMX, ale nigdzie nie widzę
opcji wyboru konkretnego PHY. Można włączyć RMII, można dodać do
projektu bibliotekę lwIP, ale nigdzie nie widzę możliwości zaznaczenia
konkretnego PHY. PIC32 wymagał dodania do projektu odpowiednich plików
.h oraz .c zakładam więc, że tutaj też będą potrzebne. Trzeba je wkleić
ręcznie, czy też wyboru odpowiedniego układu dokonuje się jakąś
makrodefinicją w kodzie?
Grzegorz Niemirowski
2021-01-13 09:10:04 UTC
Permalink
BTW ktoś z was eksperymentował może z DP83848 na STM32 z bibliotekami HAL?
Próbuję to sobie wyklikać w STM32CubeMX, ale nigdzie nie widzę opcji
wyboru konkretnego PHY. Można włączyć RMII, można dodać do projektu
bibliotekę lwIP, ale nigdzie nie widzę możliwości zaznaczenia konkretnego
PHY. PIC32 wymagał dodania do projektu odpowiednich plików .h oraz .c
zakładam więc, że tutaj też będą potrzebne. Trzeba je wkleić ręcznie, czy
też wyboru odpowiedniego układu dokonuje się jakąś makrodefinicją w
kodzie?
Mam projekty na DM9161. Nie trzeba było dodawać żadnych plików. Podejrzewam,
że rejestry PHY (zdefiniowane w stm32f1xx_hal_conf.h) są w miarę
ustandaryzowane. Ja potrzebowałem jedynie dodać definicję rejestru MDINTR,
którego nie było w pliku od ST.
--
Grzegorz Niemirowski
https://www.grzegorz.net/
Atlantis
2021-01-17 16:41:48 UTC
Permalink
Post by Grzegorz Niemirowski
Mam projekty na DM9161. Nie trzeba było dodawać żadnych plików.
Podejrzewam, że rejestry PHY (zdefiniowane w stm32f1xx_hal_conf.h) są w
miarę ustandaryzowane. Ja potrzebowałem jedynie dodać definicję rejestru
MDINTR, którego nie było w pliku od ST.
Swoją drogą, lwIP dołączany przez biblioteki HAL posiada gotowe
rozwiązania do obsługi poszczególnych usług (serwer HTTP, telnet) czy
trzeba to sobie samodzielnie napisać albo ewentualnie zintegrować z
projektem jakąś zewnętrzną bibliotekę?
Grzegorz Niemirowski
2021-01-17 18:03:44 UTC
Permalink
Post by Atlantis
Swoją drogą, lwIP dołączany przez biblioteki HAL posiada gotowe
rozwiązania do obsługi poszczególnych usług (serwer HTTP, telnet) czy
trzeba to sobie samodzielnie napisać albo ewentualnie zintegrować z
projektem jakąś zewnętrzną bibliotekę?
Kilka posiada, możesz sobie zajrzeć do źródeł. Telnetu nie ma bo nie ma
shella.

Directory:
C:\Users\Grzegorz\STM32Cube\Repository\STM32Cube_FW_F4_V1.25.2Middlewares\Third_Party\LwIP\src\apps


Mode LastWriteTime Length Name
---- ------------- ------ ----
d----- 19.12.2020 11:16 altcp_tls
d----- 19.12.2020 11:16 http
d----- 19.12.2020 11:16 lwiperf
d----- 19.12.2020 11:16 mdns
d----- 19.12.2020 11:16 mqtt
d----- 19.12.2020 11:16 netbiosns
d----- 19.12.2020 11:16 smtp
d----- 19.12.2020 11:16 snmp
d----- 19.12.2020 11:16 sntp
d----- 19.12.2020 11:16 tftp
--
Grzegorz Niemirowski
https://www.grzegorz.net/
Atlantis
2020-12-28 11:55:08 UTC
Permalink
Natomiast powinno się unikać przelotek
Niestety, przelotek na RMII nie jestem w stanie uniknąć. Płytka ma tylko
dwie warstwy, a kolejność wyprowadzeń na obydwu układach nie zgadza się,
więc linie się krzyżują w paru miejscach.
Atlantis
2020-12-27 08:42:13 UTC
Permalink
Post by MKi
Jeśli przewidujesz sytuację, że device weźmie za dużo prądu,
ogranicznik poda sygnał "overcurrent" i trzeba będzie zasilanie
odłączyć - wtedy ten port jest potrzebny. Dowolny.
Wracając do tematu: czy stosowanie ogranicznika prądu/switcha na linii
VBUS jest obowiązkowe w przypadku układów STM32 i portu USB pracujcego w
trybie host? Jak już wspominałem, w swoich poprzednich projektach na
PIC24/PIC32 zwykle po prostu łączyłem pin VBUS w gniazdku USB
bezpośrednio z linią 5V. Tylko w przypadku moich projektów port USB
robił zwykle za pamięć masową - był tam na stałe wpięty pendrive o
dającym się określić poborze prądu. Nie występowało zagrożenie, że
użytkownik podłączy dowolne urządzenie (gniazdo było ukryte wewnątrz
obudowy) a za zabezpieczenie nadprądowe robił bezpiecznik na wejściu.

Przyglądam się właśnie paru projektom na STM32 (m.in. transceiverowi SDR
mcHF od M0NKA) i widzę, że kluczowanie zasilani na VBUS i stosowanie
osobnego układu zabezpieczającego przed nadmiernym poborem prądu także
niekiedy bywa pomijane.

Czy istnieją jakieś ważne powody, żeby stosować taki układ w STM32?
Powinienem mimo wszystko uwzględniać go w swoich projektach? Może nawet
wskazane jest stosowanie czegoś takiego także w innych rodzinach
mikrokontrolerów? Czy może jednak mogę to sobie odpuścić i nieco
uprościćpłytkę, łącząc VBUS bezpośrednio z 5V?
MKi
2020-12-28 09:03:30 UTC
Permalink
Post by Atlantis
Post by MKi
Jeśli przewidujesz sytuację, że device weźmie za dużo prądu,
ogranicznik poda sygnał "overcurrent" i trzeba będzie zasilanie
odłączyć - wtedy ten port jest potrzebny. Dowolny.
Wracając do tematu: czy stosowanie ogranicznika prądu/switcha na linii
VBUS jest obowiązkowe w przypadku układów STM32 i portu USB pracujcego w
trybie host? Jak już wspominałem, w swoich poprzednich projektach na
PIC24/PIC32 zwykle po prostu łączyłem pin VBUS w gniazdku USB
bezpośrednio z linią 5V. Tylko w przypadku moich projektów port USB
robił zwykle za pamięć masową - był tam na stałe wpięty pendrive o
dającym się określić poborze prądu. Nie występowało zagrożenie, że
użytkownik podłączy dowolne urządzenie (gniazdo było ukryte wewnątrz
obudowy) a za zabezpieczenie nadprądowe robił bezpiecznik na wejściu.
Przyglądam się właśnie paru projektom na STM32 (m.in. transceiverowi SDR
mcHF od M0NKA) i widzę, że kluczowanie zasilani na VBUS i stosowanie
osobnego układu zabezpieczającego przed nadmiernym poborem prądu także
niekiedy bywa pomijane.
Czy istnieją jakieś ważne powody, żeby stosować taki układ w STM32?
Powinienem mimo wszystko uwzględniać go w swoich projektach? Może nawet
wskazane jest stosowanie czegoś takiego także w innych rodzinach
mikrokontrolerów? Czy może jednak mogę to sobie odpuścić i nieco
uprościćpłytkę, łącząc VBUS bezpośrednio z 5V?
Musisz zrobić - uwaga modne słowa - analizę ryzyka. Jeśli wyjdzie Ci,
że prawdopodobieństwo zbyt dużego obciążenia przez device czy
dotkliwość takiej awarii są dostatecznie małe (albo szansa na
wykrycie odpowiednio wcześnie takiej sytuacji jest duża)
- to nie instaluj ogranicznika.

Ja nie znam żadnych powodów oprócz tego, o którym pisałem wcześniej.

Pozdrowienia,
MKi
Atlantis
2020-12-28 09:17:40 UTC
Permalink
Post by MKi
Musisz zrobić - uwaga modne słowa - analizę ryzyka. Jeśli wyjdzie Ci,
że prawdopodobieństwo zbyt dużego obciążenia przez device czy
dotkliwość takiej awarii są dostatecznie małe (albo szansa na
wykrycie odpowiednio wcześnie takiej sytuacji jest duża)
- to nie instaluj ogranicznika.
Ja nie znam żadnych powodów oprócz tego, o którym pisałem wcześniej.
Czyli wychodzi na to, że faktycznie raczej nie muszę instalować
ogranicznika. Pendrive pobiera prąd mieszczący się w granicach
wydajności układu zasilania, a ryzyko podłączenia czegoś innego przez
użytkownika jest znikome, bo:
1) Port USB będzie zamknięty wewnątrz obudowy.
2) Tym użytkownikiem będę ja. ;)

A w najgorszym razie po prostu przepali się bezpiecznik na wejściu.
Rozumiem, że ogranicznik służy temu, żeby można było obsłużyć przypadek
nadmiernego poboru prądu z USB bez przerywania pracy urządzenia? W moim
przypadku jest to tak naprawdę zbędne. :)
MKi
2020-12-30 08:16:01 UTC
Permalink
Post by Atlantis
Post by MKi
Musisz zrobić - uwaga modne słowa - analizę ryzyka. Jeśli wyjdzie Ci,
że prawdopodobieństwo zbyt dużego obciążenia przez device czy
dotkliwość takiej awarii są dostatecznie małe (albo szansa na
wykrycie odpowiednio wcześnie takiej sytuacji jest duża)
- to nie instaluj ogranicznika.
Ja nie znam żadnych powodów oprócz tego, o którym pisałem wcześniej.
Czyli wychodzi na to, że faktycznie raczej nie muszę instalować
ogranicznika. Pendrive pobiera prąd mieszczący się w granicach
wydajności układu zasilania, a ryzyko podłączenia czegoś innego przez
1) Port USB będzie zamknięty wewnątrz obudowy.
2) Tym użytkownikiem będę ja. ;)
A w najgorszym razie po prostu przepali się bezpiecznik na wejściu.
Rozumiem, że ogranicznik służy temu, żeby można było obsłużyć przypadek
nadmiernego poboru prądu z USB bez przerywania pracy urządzenia? W moim
przypadku jest to tak naprawdę zbędne. :)
O, to, to.
Tak powinna wyglądać analiza ryzyka ;)

Pozdrowienia,
MKi
Kontynuuj czytanie narkive:
Loading...