Chętni do zabawy z CH32V307 ?

[tuxcnc]

Pisałem już o tym module kilka-sterownikow-na-jednym-porcie-ethe ... ml#p880102
Cóż, moduł z całkiem przyzwoitym procesorem i wbudowanym LAN za 25 PLN jest chyba warty trochę wysiłku...
Problem polega na tym, że ja mam od cholery innych zajęć, a chińska myśl techniczna jest dla Europejczyka czymś zupełnie obcym...
Nie jest to żaden rasizm, po prostu Chińczycy mają swoją kulturę i swoją cywilizację, które oparte są na nieco odmiennych podstawach...
Nie będę tego wątku ciągnął, w każdym razie to, co dla Chińczyka jest wystarczająco dobre, dla Europejczyka może być wystarczająco złe...
Pisałem o IDE Embeetle, które stworzone jest dla masochistów. Korzyść z jego zainstalowania jest taka, że dowiedziałem się, że jest sporo przykładowego kodu, który po drobnych modyfikacjach może być całkiem użyteczny.
O tym, że z Embeetle coś poszło nie tak wie sam producent układów WCH i poleca MounRiver. Problem jest taki, że przykładów z Embeetle nie da się eksportować/importować do MounRiver. Brakuje plików konfiguracyjnych, co może i nie jest błędem, ale sprawę zamyka. Zupełnie przypadkiem dowiedziałem się, że jest dostępna w necie wersja tych samych przykładów dla MounRiver. Oczywiście nie znaczy to, że będą się kompilować bez problemów, ale tym razem wywaliło bardzo precyzyjne komunikaty błędów, z których wynikało, że źródła muszą być w określonej lokalizacji, albo trzeba sobie edytować plik ze ścieżkami...
W każdym razie doszedłem do tego, że potrafię już skompilować programy, które po wgraniu do procesora prawidłowo funkcjonują.
Tylko tu zaczynają się prawdziwe schody, czyli brak dokumentacji.
W przykładach są odwołania do funkcji bibliotecznych, które cholera wie gdzie są zadeklarowane i cholera wie jak ich używać.
No można się czegoś domyślać i próbować, ale to kosztuje czas i nerwy...

Teraz do rzeczy.
Wiem, że na forum są ludzie, którzy pisali programy na STM32 (CH32V307 to prawie to samo, z tym że "prawie czyni różnicę").
Zadanie polegało by na przepisaniu mojego SpindleETH na ten sprzęt.
Nie chcę się nikim wyręczać, po prostu SpindleETH (licencja GPL) jest doskonałą bazą do bardziej ambitnych projektów, bo jakiego sterownika nie chciałoby się zbudować, to sprzętowa obsługa enkodera, sprzętowy PWM, cyfrowe I/O i komunikacja kontroler-LinuxCNC będą potrzebne...

Jak będą chętni, to opiszę szczegóły.

[tuxcnc]

Temat powoli staje się nieaktualny.
Wymęczyłem obsługę enkodera i indeksu, teraz pójdzie to na testy na rzeczywistej tokarce, a jak się powiodą, to dopiszę resztę.
Z pisaniem kodu jest masakra, bo nie tylko kompletny brak dokumentacji, ale i kompilator ma swoje fochy.
Pierwszy raz w życiu miałem taki cyrk, że przerwanie zewnętrzne działało tylko raz. Po resecie procesora można je było wyzwolić, ale potem było już martwe. Cały dzień się z tym męczyłem i do dzisiaj nie wiem co było przyczyną, bo nagle "ten sam kod" zaczął działać prawidłowo. Podejrzewam jednak, że to specyfika kompilatora, który pewne rzeczy widzi tylko wtedy, gdy są we właściwym dla niego miejscu... Przykładowo, jest plik ch32v30x_it.c który odpowiada za obsługę przerwań, ale z niego nie widać zmiennych zadeklarowanych w main.c więc obsługę EXTI0 przeniosłem właśnie tam. Najwyraźniej kompilator czegoś nie widział i produkował błędny kod...
W każdym razie skompilowałem, wgrałem na tą płytkę przypominającą Nucleo i wszystko działało, więc zabrałem się za tą mniejszą i tańszą. No i tutaj szlag mnie trafił. Wszystko niby działało, debug dawał prawidłowe komunikaty, a pecet nie widział urządzenia w sieci...
Znowu brak dokumentacji...
Przykładowo, w necie jest schemat w takiej jakości, którą Chińczyk najwyraźniej uznał za "wystarczająco dobrą":

(To fragment żeby plik był lżejszy.)
Dzisiaj, już całkiem zrezygnowany, postanowiłem obejrzeć płytkę pod lupą (może jakiś zimny lut albo inna cholera?) i zupełnie przypadkiem znalazłem rozwiązanie:

Otóż gniazdo rj45 nie jest połączone z procesorem(!).
Zasadniczo to nie jest źle, bo ktoś może chcieć wykorzystać te piny do czegoś innego, ale takie rzeczy należy opisywać, a tutaj nic i nawet Google o tym nie wie...
Wystarczy polutować te cztery mostki (przy odrobinie szczęścia sama cyna wystarczy) i komunikacja zaczyna działać.

[tuxcnc]

Powiem wam, że chińska filozofia zaczyna mnie irytować...
W domu mam Ryzen3 a w warsztacie (~10 km) AMD A10. To, że jeden komputer jakieś 2x szybszy od drugiego, tutaj nie ma znaczenia. Chodzi o to, że Ryzen to mini SSF i daje się instalować dodatkowe karty, a AMD A10 to taki kieszonkowy pecet, ze 3 cm grubości, i trzeba sobie radzić z tym, co producent zamontował, a zamontował jedno gniazdo RJ45, czyli jeden port LAN. Natomiast do Ryzena założyłem sobie kartę 4XLAN, czyli w sumie mam pięć portów. Jak się ma pięć portów, to po cholerę używać switcha? Ale jak się ma jeden port, to wyboru nie ma...
Tak więc pojechałem do warsztatu (~10 km) z przetestowaną płytką CH32V307 i okazało się, że nic z tego... Jak się podłączy bezpośrednio do peceta, to działa, ale przez switcha Edimax to urządzenia nie widać...
Wróciłem więc do domu (~10 km) i okazało się, że z chińskim switchem za 10 PLN działa, a z Edimaxem ni cholery...
No cóż, gorsze rzeczy się zdarzały, w końcu stwierdzenie, że jakiś sprzęt się ze sobą gryzie, to jeszcze nie koniec świata, bo z innym działa i w sumie wystarczy o tym wiedzieć...
Ale ja lubię wiedzieć więcej...
Po tym doświadczeniu przypomniało mi się, że już od dawna podejrzewałem Chińczyków o totalną fuszerkę, czyli zasadę "jeśli działa wystarczająco dobrze, to jest dobre".
Tak więc postanowiłem sprawę drążyć, do czego Chińczyk z zasady nie ma motywacji.
Użyłem jako bazy dla swojego projektu gotowego przykładu, nie z lenistwa, tylko z braku danych.
Gdzieś wyczytałem, że WCHNET to kod własnościowy, bez źródeł, udostępniany z łaski, "sam się domyśl co jest do czego" i wszystko wskazuje na to, że to prawda.
Tak więc trzeba zacząć od czegoś, co powinno działać, bo inaczej to będzie wędrówka niewidomego we mgle...
Tak więc do udostępnionego przykładu dopisałem swoje funkcje i kod działa, ale od początku miałem wątpliwości czy aby wszystko jest tam potrzebne....
No i dzisiaj powiedziałem "sprawdzam"...
Po wywaleniu 3/4 kodu program nadal działa...
Co bardzo istotne, tam była obsługa przerwania z TIM_2, która może i do czegoś była potrzebna, ale na pewno nie tutaj, więc jej wywalenie skutkowało uwolnieniem tego timera i można go teraz użyć do czego się zechce. Jak ktoś programował STM32, to wie, że timerów nigdy za wiele i jeden więcej to czasami sukces albo fiasko projektu...

[tuxcnc]

Zupełnym przypadkiem dowiedziałem się czegoś ważnego.
Otóż ch32v307 ma wbudowane układy MAC 1 Gbit i PHY 10 Mbit.
Krótko mówiąc, te płytki dostępne na Aliexpress będą pracować tylko na 10 Mbit, bo używają wbudowanego PHY.
Teoretycznie można mieć gigabitowy ethernet, ale trzeba by było zaprojektować własną płytkę z zewnętrznym układem PHY.
To tłumaczy, dlaczego dostajemy pięć plików do obsługi ethernetu, ale działa tylko eth_driver_10M.c

[atom1477]

Ale głupoty pieprzysz. Doczytaj najpierw co to w ogóle jest MAC i PHY zanim cokolwiek powiesz.

[tuxcnc]

Ale głupoty pieprzysz. Doczytaj najpierw co to w ogóle jest MAC i PHY zanim cokolwiek powiesz.

Następną gównoburzę chcesz zrobić?

[atom1477]

To że chińczyk tak napisał, nie znaczy że masz powielać te bzdury.

[tuxcnc]

To że chińczyk tak napisał, nie znaczy że masz powielać te bzdury.

Spadaj stąd trollu!