atlantis86

Ok, chyba moja poprzednia hipoteza okazała się być prawidłowa. Sam mikrokontroler działa. Dodałem sterownik Ethernet i lwIP. Urządzenie się nie zawiesza, ale po podłączeniu go do sieci lokalnej nie znajduję go też na liście w routerze. Stąd kolejne pytanie - kod wygenerowany przez STM32CubeMX wystarczy do uruchomienia stosu TCP/IP z DHCP na urządzeniu, czy trzeba jeszcze coś ręcznie dopisać?

Ok, źle zinterpretowałem twój komentarz. Tak, to ma być radio Internetowe z wykorzystaniem DP83848 i dekodera VS1003. Projekt zacząłem rozwijać jakiś czas temu, początkowo na na PIC24 z ENC28J60, potem przeniosłem się na PIC32 wykorzystując wbudowany interfejs RMII, aż w końcu postanowiłem zrobić (mam nadzieję) ostateczną wersję płytki z STM32, na której dokończę projekt. Wcześniejsze wersje mają uruchomiony sprzęt, więc w sumie jeśli już napiszę warstwę aplikacji, to będzie ją można w miarę łatwo przenieść na tamte płytki. W sumie przyszła mi do głowy jeszcze jedna możliwość. W STM32Cu

Spróbowałem ustawić HSI. Płytka zachowuje się dokładnie tak samo. Gdzie jeszcze mogę szukać możliwej przyczyny? BOOT0 podłączony do masy, NRST podciągnięty d 3,3V rezystorem 10k.

A może by tak coś więcej? Czytałem i wydaje mi się, że konfiguracja z obrazka wrzuconego wcześniej jest ok. Jeśli wiesz co jest nie tak, to wypadałoby po prostu powiedzieć, a nie odsyłać do dość obszernej dokumentacji bez podania szczegółów.

Wygląda na to, że winę za mój oryginalny problem ponosił źle przylutowany pin mikrokontrolera. Programator zaczął widzieć układ po ponownym przygrzaniu padów lutownicą. Niestety, to nie koniec problemów: 1) Jestem w stanie wgrać kod z poziomu STM32CubeIDE, jednak najwyraźniej nie jest on wykonywany. Nie zmienia się nawet stan linii, które ustawiłem na początku programu. Moje pierwsze podejrzenie to błędna konfiguracja zegara, ale nie wiem co mogłoby być z nią nie tak: 2) Jak widać powyżej, konfigurację projektu (plik .ioc) stworzyłem jeszcze w STM32CubeMX, a potem wyekspor

Zabrałem się właśnie za budowę jednego z urządzeń swoich projektów. Płytka wytrawiona i zlutowana, układ zasilania wytwarza właściwe napięcia. Podpiąłem więc programator celem sprawdzenia czy mikrokontroler (STM32F107RCT6) będzie przez niego wykrywany. Niestety, uzyskuję następujący wynik: st-flash read dummy.bin 0 0xFFFF st-flash 1.6.1-201-g4bfaab0 2021-01-22T18:15:05 WARN usb.c: NRST is not connected 2021-01-22T18:15:05 WARN common.c: Invalid flash type, please check device declaration Failed to connect to target st-info --probe Found 1 stlink programmers version: V2J17S4 serial

Nie. Oni udostępnili jakieś API do wrzucania danych do ich sieci? Bo kiedy kilka lat temu budowałem pierwszego EtherGeigera wysłałem maila z pytaniem, ale nigdy nie otrzymałem odpowiedzi. Wtedy chyba można było korzystać tylko z ich czujników. Coś się w tej materii zmieniło?

Ja niczego nie kalibrowałem. Zresztą jak miałbym to robić nie mając dostępu do żadnego certyfikowanego, naukowego przyrządu pomiarowego i kontrolnego źródełka promieniowania? Lat temu, zabierając się za pierwszą iterację tego projektu na jakimś forum natrafiłem na informację o tym, o przez ile trzeba przemnożyć ilość impulsów na minutę, żeby uzyskać z grubsza prawidłowy wynik w uS/h. Uzyskiwana wartość pasowała do przeciętnego promieniowania tła. Dzięki uprzejmości znajomego fizyka miałem też okazję stwierdzić, że przyrząd prawidłowo reaguje na obecność nieznacznie promieniotwórczego ka

Ok, zapytam więc inaczej: jest to tylko kwestia trzymania się specyfikacji USB, czy stoją za tym jeszcze jakieś inne przesłanki, związane ze stabilnością działania czy awaryjnością urządzenia? Rozumiem, że twórcy standardu przewidzieli różne scenariusze, jak np. możliwość programowego wyłączenia napięcia na porcie albo wykrycia zbyt dużego poboru prądu. Jeśli jednak w moim projekcie port będzie ukryty wewnątrz obudowy i ma tak naprawdę tylko służyć do podłączenia pamięci masowej (pendrive'a) to czy mogę sobie pozwolić na takie odstępstwo? Bo tego, że nie spełnię wszystkich wymagań standar

Projektuję właśnie płytkę do pewnego urządzenia na STM32 (konkretnie STM32F107RCT6) i zaczęła mnie zastanawiać kwestia hosta USB. W dokumentacji możemy znaleźć następujący schemat: Powyższy obrazek pochodzi z Internetu, co prawda ten konkretny z datasheeta STM32F411, ale w dokumentacji STM32F107 jest niemalże identyczny.To co zwraca na nim uwagę, to obecność scalonego switcha z zabezpieczeniem nadprądowym. Taki układ komunikuje się z mikrokontrolerem za pomocą dwóch linii GPIO - jedna z nich jest wykorzystywana do włączania/wyłączania zasilania na porcie USB, druga zgłasza wyst

Ok, wszystko działa.

Ja prawdę mówiąc nie wyobrażam sobie pisania dużych projektów od początku do końca w asemblerze. To znaczy wiem, że się da, ale ryzyko popełnienia błędu i dodatkowe utrudnienia w debugowaniu potrafią zamienić zabawę w koszmar. Pisząc kod do swoich projektów na 6502 korzystam z kompilatora CC65. Nie jest idealny, bo chociażby brakuje mu wyższych poziomów optymalizacji, ale do moich zastosowań się nadaje. Oczywiście pewne kluczowe fragmenty kodu - jak na przykład system obsługi przerwań - i tak trzeba napisać w asemblerze. W przypadku projektów na 8080 sytuacja wygląda już gorzej, bo tutaj

No cóż, ja niestety byłem trochę za młody, żeby zajmować się takimi konstrukcjami, gdy ta technologia była młoda. Byłem wtedy w podstawówce i składałem jakieś proste konstrukcje na paru tranzystorach czy układach scalonych, opierając się na opisach z "Młodego Technika". Jednak przeglądałem od czasu do czasu "Radioelektronika", z podziwem patrząc na zaawansowane konstrukcje, oparte na Z80 albo 8051. W tamtych czasach budowanie takich urządzeń byłoby niezwykle złożonym procesem. Części były drogie i trudno do zdobycia, a wytrawienie odpowiednio dokładnej płytki w domowych warunkach nie wchodzi

Trudno jest mi podać konkretne wartości - trzeba by się wczytać w specyfikę zastosowanej "tuby" - w tym przypadku jest to radziecka STS-5. Jest to metalowa rurka wypełniona określonym gazem. Po obydwu stronach są dwie elektrody, do których jest przyłożone napięcie rzędu 400V - normalnie za małe, żeby wewnątrz tuby doszło do jonizacji i przepływu prądu. Jednak jeśli przez tubę przeleci akurat wysokoenergetyczna cząstka, gaz wewnątrz na moment się jonizuje, a miedzy elektrodami zaczyna płynąć prąd. Jest to rejestrowane jako chwilowy spadek napięcia na elektrodach. Im więcej takich spadków, tym w

Docelowo tak. Na razie jest tam wgrany prosty soft testowy, napisany jedynie z myślą o upewnieniu się, że wszystkie peryferia działają. Tak więc na wyświetlaczu pokazują się jakieś komunikaty, działają przyciski, można wysyłać testowe komendy przez RS232 a układ odsyła na nie odpowiedź, no i oczywiście MC6840 generuje przebiegi czasowe, które z kolei "zasilają" logikę sterującą silnikami. Plan jest taki, żeby finalnie wgrać tam coś w rodzaju interpretera języka Logo, który poruszałby robotem w określony sposób. Poszczególne komendy byłyby albo wysyłane przez port szeregowy, albo odczytywa