Przeszukaj forum

Streszczenie W jednym zdaniu: moduł zewnętrzny LIN dla płytek prototypowych (sterowniki dla Pi Pico (C++) są dostępne tutaj). Urządzenie ma na celu umożliwić korzystanie z LIN poprzez port UART. Poglądowy model płytki Opis działania Sercem płytki jest układ TLIN2029 (albo NCV7329). Reszta to opisane w notach katalogowych peryferia. Układ można podłączyć do dowolnej płytki prototypowej (Arduino, Pi Pico, ESP32). Wspiera zarówno logikę 5V jak i 3.3V. Napięcie 5V służy jako zasilanie magistrali LIN (standardowe napięcie), aczkolwiek można wylutować rezystor podłączający ten pin do VSUP i podłączyć zasilanie LIN do header'a LIN. RX podłączamy do RX płytki, TX do TX płytki. (nie zamieniamy RX i TX jak to ma miejsce w przypadku UART). Schemat C1 dla slave powinien wynosić 220pF, dla Master'a 1nF. R1 służy do podłączenia zasilania 5V do magistrali LIN. R7 jest rezystorem podciągającym 5V do pinu EN dla transceivera. D1 i R2 to wymagane przez LIN zabezpieczenie magistrali po stronie Master'a (tylko i wyłącznie) C2 jest kondensatorem stabilizującym zasilanie VSUP. W zależności od płytki powinien wynosić 100nF-10uF. LIN1 to header magistrali - tam podłączamy zasilanie, komunikację oraz masę. LIN2 to header do płytki prototypowej - podłączamy zasilanie 5V oraz GND. LRX podłączamy do RX płytki, LTX do TX płytki. Komunikacja przy użyciu płytki (9600bitps), zrzut pochodzi jeszcze z momentu, gdy algorytm źle wyliczał sumę kontrolną, co zostało już poprawione 😉 A tutaj [cenzura] zlutowana płytka 😉 Pliki projektu EasyEda - JSON w załączniku 😉 EasyEda PCB_LIN Breakout Module_2021-06-06.zip

Cześć, napotkałem dziś dziwny problem. Po dodaniu do projektu STM32H743IIT6 pakietu X-CUBE-AI przestała działać komunikacja USART. Mam na PCB wyprowadzone USART2 oraz USART3 i żaden z nich nie działa. Zdaje się, że pozostała część programu działa, ale dokładnie tego nie sprawdzałem, jedynie miganie diod. Sprawdzałem wersje 7.3 oaz 8.0 pakietu AI. Najdziwniejsze jest to, że już samo zaznaczenie Core w Select Components (STM32CubeIDE) powoduje problemy. Późniejsze odznaczenie tego nie przywraca działania. Problem nie tkwi w pliku main.c. Przywrócenie pliku sprzed zmian nic nie daje. Komunikacja po USART realizowana jest poprzez programator z Nucleo F1. Wcześniej korzystałem z pakietu AI razem z USART na rdzeniu F7 i nie było problemów. Czy macie jakieś pomysły, gdzie szukać problemu?

Cześć, ponownie wrócił u mnie temat wysyłania z uC danych z czujników MPU9250 do PC. Poprzednio robiłem to z użyciem funkcji printf i terminala CoolTerm i w przypadku 6 osi (akcelerometr + żyroskop) i szybkości próbkowania 20 Hz nie było problemu. Obecnie potrzebuję przesłać dane z 24 osi (4 akcelerometry i 4 żyroskopy na 4 IMU) z szybkością 500 Hz. No i tutaj printf nie wyrabia. Próbowałem też użyć sprintf oraz funkcję HAL_UART_Transmit, HAL_UART_Transmit_IT, HAL_UART_Transmit_DMA. (Z tą ostatnią mam problem, ponoć jest jakiś kłopot z CubeIDE i serią F7. Pierwsze testy pokazały mi jednak, że IT działa tak samo szybko jak DMA. Jeśli to prawda, to na razie ten problem pomijam. Jeśli jednak będzie potrzebne DMA, to tutaj też będę prosił o pomoc. W STM32F410RB Nucleo działa mi bez zarzutu.) Tutaj jednak przy przesyłaniu 24 wartości typu float czas przesłania danych jest zbyt duży i rzeczywista szybkość próbkowania mi spada. Wpadłem na pomysł, by zamiast danych typu float i funkcji (s)printf przesłać po prostu surowe wartości uint8_t z 2 rejestrów (lub jeszcze lepiej połączone od razu w uint16_t) dla każdej osi. Ale tutaj napotykam na problemy. Po pierwsze - jak wysłać te dane? Kolejno po sobie wartości z każdej osi? Czy jakoś je spakować "do kupy" i zrobić jedną transmisję w każdym przerwaniu zegarowym 500 Hz? Pierwszy pomysł wyglądałby mniej więcej tak (od razu proszę o korektę): int16_t MPU9250_aX_A, MPU9250_aY_A ... MPU9250_gZ_D); HAL_UART_Transmit_IT(&huart3, MPU9250_aX_A, sizeof(MPU9250_aX_A)); HAL_UART_Transmit_IT(&huart3, MPU9250_aY_A, sizeof(MPU9250_aY_A)); HAL_UART_Transmit_IT(&huart3, MPU9250_aZ_A, sizeof(MPU9250_aZ_A)); . . . HAL_UART_Transmit_IT(&huart3, MPU9250_gX_D, sizeof(MPU9250_gX_D)); HAL_UART_Transmit_IT(&huart3, MPU9250_gY_D, sizeof(MPU9250_gY_D)); HAL_UART_Transmit_IT(&huart3, MPU9250_gZ_D, sizeof(MPU9250_gZ_D)); Kolejny problem to odbiór tych danych i ich konwersja do postaci zrozumiałej dla człowieka. Na razie otrzymuję w terminalu coś w stylu: BĽR–ˇÍ.h)B*]+ ,Ş.A,Ş)B+ )BŐń."únôA-0Ŕ,."-0~,ŞˇÍÉČÚą.hŐńçÖ~´)Uź˝..áR–)BBĽŐńĺ.Ŕ,çÖ~..ú‰‡.˙,Ş`“+ á.}.ÉČ­mnô[`¦“.űëm.ś '—..˝.††`J.ĹV-0|<’ ĺ.D.›@úí.÷hú..^[.˝J„–÷h‰‡A+ .Š.‰‡~UźçÖ`“Ü÷˛h0`“JahUź©;BĽëmÉČÚą.˙á.ŠUź8\‰‡‰‡éjĺ.Aöš)B+ Korzystam z STM32F746ZG Nucleo, STM32CubeIDE 1.10.1, MCU Package 1.17.0. Na razie dane przesyłam z Nucleo poprzez USB, docelowo będzie to nowy układ z rdzeniem STM32F756VGT6 i komunikacja poprzez BT lub WiFi. 4 czujniki mam podłączone do 2 magistrali I2C. Proszę o wszelkie porady i pomysły, jak szybko przesłać wszystkie potrzebne dane i je poprawnie odczytać w PC.

Witam wszystkich, bez zbędnych szczegółów mam do zrobienia układ który będzie musiał: Obsługa Xbee za pomocą magistrali UART Obsługa przetwornika A/C C/A (wstępnie myślałem nad układem pod magistralę I2C) Obsługa wyświetlacza OLED (również myślałem nad magistralą I2C ze względu na to że posiadam już takowy) Obsługa wyświetlacza LCD (chyba po magistrali SPI ok 3 cali) podgląd z kamery poprzez WiFi Obsługa WiFi jak w punkcie powyżej. Posiadać USB do kontrolera Ze względu na studencki budżet udało mi się kupić w bardzo dobrych pieniądzach (jak na obecną sytuację z "malinami") a są to Raspberry Pi zero wersje 1.3 oraz 1.1. Obawiam się, że jedna malinka nie podoła. Myślałem nad połączeniem dwóch za pomocą magistrali I2C ale wyczytałem, że Rasberry Pi może pracować tylko jako urządzenie typu Master i teraz nie wiem czy jedna dałaby rade podołać wszystkiemu czy dałoby radę jednak jakoś mądrze połączyć je i przesyłać proste informacje (może nawet kilka bitów) czy po prostu szukać czegoś mocniejszego aby obsługiwało wszystko. Miałby ktoś jakiś pomysł jak można by było ogarnąć temat z wykorzystaniem tego co mam, bądź co dałoby radę obsłużyć wszystkie potrzebne mi funkcje bez płacenia milionów monet? Zależy mi aby układ był stosunkowo niewielki i energooszczędny. Z góry dziękuję za wszystkie sugestie i pomysły oraz proszę o wyrozumiałość nie jestem aż tak biegły w temacie jak niektórzy doświadczeni użytkownicy i pasjonaci. Pozdrawiam!

Cześć, chciałbym prosić o pomoc w kwestii podpięcia modułu Pmod BLE do płytki Zybo Z7-10. Opis projektu Chciałbym podłączyć Pmod BLE do płytki Zybo Z7-10. Chciałbym by testowa aplikacja mogła wysyłać i odbierać dane po bluetooth (do testowania chciałbym użyć jakiejś aplikacji z AppStore). Na początku mogłoby to być wysyłanie zwykłego ciągu znaków, jak np: "Cześć Zybo" i "Cześć telefon" czy coś podobnego. Próby podłączenia Znalazłem podobny przykład w intrnecie (tutaj -> link autorstwa osoby o nicku: ralphjy). Próbowałem odtworzyć projekt, który opisał w tym artykule jednak nie udało mi się to. Poniżej zamieszczam swój block diagram, który jest podobny do tego który prezentuje ralphjy. Dołączam jeszcze constraints mojego projektu. Niestety nie wiem jak dokładnie powinny być one podpięte. Na końcu problemu zamieszczam link do constraint dla Zybo. Oczywiście próbowałem wygenerować bitstreama, ale bezskutecznie :(. Może ktoś z Was miał już do czynienia z modułem Pmod BLE i byłby w stanie pomóc :)? Btw. dzięki wielkie za jakiekolwiek wskazówki! Sprzęt Zybo Z7-10 -> link Pmod BLE -> link Software Zybo-Z7 Constraints -> link pliki źródłowe Pmod BLE-> link

Witam, Mam dość nietypowy problem. Podczas debugowania Usart działa prawidłowo, wchodzi w przerwanie i wykonuje prawidłowo program. Dopiero po wyłączeniu zasilania i ponownym włączeniu mikrokontroler wysyła dane ale już nie odbiera (nie wchodzi w przerwanie). NVIC jest włączony, przed funkcją while(1) HAL_UART_Receive_DMA(&huart2, RxBuffer_Master, 1); lub HAL_UART_Receive_IT(&huart2, RxByte_Master, 1); są włączone, i ten sam efekt. brak wejścia do funkcji: void HAL_UART_RxCpltCallback(UART_HandleTypeDef *UartHandle) Projekt generowany przez STM32CubeMX. Jakby ktoś miał jakiś pomysł to proszę o odpowiedź. Pozdrawiam

Witam chciałbym się pochwalić moim growboxem (gwowbox-częściowo lub całkowicie zamknięty system do uprawy roślin). Na samym początku małe wyjaśnienie, projekt powstał ponad rok temu, „plony” już dawno zebrane. Skrzynia stoi i się kurzy więc trzeba się jej pozbyć. Zaczynając projekt moim jedynym doświadczeniem z programowaniem mikrokontrolerów było ukończenia kursu z Arduino na Forbocie 🙂 . Bardzo ale to bardzo przepraszam za nieład w przewodach i jakość wykonania, zdjęcia były robione dziś a sam box podczas swojej pracy przechodził różne updaty i finalnie nie chciało mi się już tego jakoś sensownie układać. Sorki za długi wstęp. Do projektu wybrane zostało Arduino Mega a raczej jego klon (Połączenie dwóch układów Mega2560 z ESP8266). Ze względu na cene 49,99 🙂 Wyświetlacz to 7 calowy Nextion, ekran pojemnościowy bardzo czytelny. Bardzo łatwo się go programuje a na YT można znaleźć polskie tutoriale. Połącznie Andino i wyświetlacza odbywa się tak samo jak z ESP po UART, działa to może trochę topornie ale wbrew pozorom całkiem dobrze. Wyświetlacz wykorzystywany był w celu wyświetlania informacji, które arduino odczytało z czujników i przedstawienie ich w przejrzysty sposób oraz wprowadzania wartości zmiennych dla arduino. Jako, że płytka arduino wyposażona była w układ esp postanowiłem go w jakimś stopniu wykorzystać i tak najprostsza metodą (komendami AT) dodana została możliwość wyświetlania informacji z czujników po połączeniu się z ip serwera ESP. Wykonanie: Konstrukcja - wykonana została z twardego styropianu o grubości 30mm (Polistyrenu XPS- Produkt cechuje się wysoką odpornością na ściskanie, działanie wilgoci oraz jest bardzo lekki). Wymiary zewnętrzne 120/120/60cm, drzwiczki otwierane na 3 zawiasach uszczelnione, zamykane gumami montażowymi. Środek skrzynki obklejony folią "mylar" (odbija około 90% światła). Lampy – skrzynka posiada dwie lampy, każda z nich składa się z radiatora 290/246/25 mm do którego przyklejone zostały 3 diody COB 50W każda. Diody posiadają własne sterowniki i są zasilane napięciem sieciowym. Ze względu na wysokie temperatury do lampy dołożony został wentylator którego prędkość obrotowa zależy od wskazania czujnika LM35 doklejonego do radiatora. Wentylacja – skrzynka wyposażona została w wentylator który tłoczył powietrze do środka, trzy wentylatory mieszające powietrze w środku, oraz wentylator wyciągający powietrze. Działanie i funkcjonalności: Po włączeniu zasilania na wyświetlaczu ukazuję się ekran główny z poziomu, którego możemy sterować oświetleniem, wentylacja, wilgotnością, temperaturą, podlewaniem, ustawić profil automatyczny, podejrzeć obecną datę i godzinę, datę i godzinę ostatniego podlewania oraz przejść do ustawień. Strona oświetlenie daje nam możliwość zapalenia/gaszenia każdej z 6 diod COB, dodatkowo pokazuje moc każdej z lamp oraz jej temperaturę. Strona Wentylacja pozwala na ustawienie prędkości wentylatorów nawiewu, wyciągu oraz mieszaczy powietrza wewnątrz skrzynki. Strona Wilgotność i temperatura pozwala ustawić wartości wilgotności i temperatury poniżej których załączy się nawilżacz powietrza oraz grzałka. Ponadto na bieżąco wyświetla informacje o obecnie panującej temperaturze i wilgotności powietrza oraz wilgotności gleby doniczek. . Strona Podlewanie w zamyśle miała włączać i wyłączać pompkę podlewającą rośliny, jednakże zabrakło czasu i chęci do dokończenia. Strona Profile jest w zasadzie najważniejsza ze wszystkich, po jej dodaniu inne strony przestały być potrzebne. Podzielona jest na 4 części w których mamy do wypełnienia po 8 pól. Podział na 4 części daje możliwość rozbicia doby na rano, południe, wieczór i noc dzięki czemu możemy symulować roślinie normalny cykl dnia. Pod przyciskiem „i” pokaże nam się strona z informacjami jak ów pola uzupełnić. Strona Ustawienia daje możliwość ustawienia daty i godziny oraz jasności ekranu. Dodatkowo można stąd przejść do strony Serwer info gdzie wyświetlane jest czy połącznie z siecią Wifi się powiodło oraz pod jakim adresem IP możemy podejrzeć wartości panujące w skrzynce. Na koniec krótki filmik jak to działa 🙂

Potrzebuję sygnału zegarowego z tego układu https://cdn.sparkfun.com/datasheets/Dev/Arduino/Other/CH340DS1.PDF do taktowania mikrokontrolera. Czy mogę go pobrać z pinów XI XO, jeśli tak to z którego? XO? Druga część pytania - o przejściówkę BT - jak narysuję schemat 🙂 Update: na wyjściu XO jest sygnał sinus 12MHz o wartości 2.56Vpp chcę go doprowadzić do CLKI w AtTiny13

Mam pytanie odnosnie wyliczania UBRR... Mamy na to wzor, w nocie i sa tez inne, miedzy innymi M.K podal na swoim blogu lepszy. Tylko, ze w nocie mamy rowniez podane te wartosci dla poszczegolnych predkosci. Wiec czemu nie wpisywac bezposrednio wartosci UBRR z noty, a nizeli sie martwic, czy wzor bedzie poprawny i dokladny. Ja wiem, ze mozna mowic, ze trzeba zagladac do noty, zmieniac to itp.. Jednak, gdy bedziemy chcieli zmienic wartosc baud rate tak czy siak musze zagladac do noty. Mowie tu akurat z perspektywy osoby poczatkujacej. Co wiecej, wpisujac bezposrednio wartosc UBRR z noty do Uart_init pozbywamy sie 2 linijek kodu #define baud rate i #define (wozr na ubrr) To takie moje przemyslenie i chcialbym, zeby ktos sie do tego odniosl, byc moze sa inne powody, dla ktorych warto uzywac wzoru.

#define zielona 8 #define czerwona 9 String odebraneDane = ""; //Pusty ciąg odebranych danych boolean stanZ = false; //stan zielonej diody - wyłączona boolean stanC = false; //stan czerwonej diody - wyłączona void setup () { Serial.begin(9600); pinMode(zielona, OUTPUT); pinMode(czerwona, OUTPUT); digitalWrite(zielona, LOW); digitalWrite(czerwona, LOW); } void loop(){ if(Serial.available() > 0) { //Czy Arduino odebrało dane //Jeśli tak, to odczytujemy je do znaku końca linii i zapisz w zmiennej odebraneDane odebraneDane = Serial.readStringUntil('\n'); if(odebraneDane == "zielona"){ if(stanZ = false){ digitalWrite(zielona, HIGH); stanZ = true; Serial.println("włączono zieloną diodę \n"); } else { digitalWrite(zielona, LOW); stanZ = false; } } if(odebraneDane == "czerwona"){ if(stanC = false){ digitalWrite(czerwona, HIGH); stanC = true; Serial.println("włączono czerwoną diodę \n"); } else { digitalWrite(czerwona, LOW); stanC = false;; } } } } Cześć. Starałem się zrobić poniższe zadanie. [Zadanie trudniejsze, z gwiazdką . Napisz program, który po wysłaniu koloru diody zmieni jej stan na przeciwny. Jeśli dioda jest włączona, to zostanie wyłączona i na odwrót. Podpowiedź: koniecznie użyj dodatkowych zmiennych typu bool, które będą pamiętały aktualny stan diod.] Na arduino zapala się dioda odbioru danych ale, diody LED się nie zapalają. Nie wiem gdzie jest błąd, proszę o pomoc.

Cześć. Wydaje mi się, że jest to dość nietypowa sytuacja. Pracując nad wyświetlaczem w pewnym momencie zauważyłem, że UART zamiast małych liter wyświetla tylko jakieś dziwne znaki. Początkowo to zignorowałem bo i tak docelowo UARTa niepotrzebuję, ale później okazało się ze wyświetlacz, który czyta czcionki z karty SD również nie wyświetla poprawnie malych liter. Precyzując zauważyłem, że w obu przypadkach znaki są wyświetlane do 92 numery w kodzie ASCII. Sterowanie wyświetlaczem w żaden sposób nie jest powiązane z UARTem a problem, który tam występuje, domyślam się że pochodzi z niewłaściwego odczytywania znaków przed graficzną reprezentacją znaku na karcie SD w stylu: ! --#-- --#-- --#-- ----- --#-- Przez to pewnie pojawia się jakieś przesunięcie w odczycie czcionki. Próbowałem też wygenerować nowy, pusty projekt gdzie w mainie umieściłem: HAL_UART_Transmit(&huart3, (uint8_t*)"ABCDabcd", 10, 100); Oczywiście tylko cztery pierwsze znaki zostały poprawnie wysłane. Probowałem też wyczyścic pamięć przez ST-Linka, również bez pozytywnego efektu. Domyślam się, że obie sytuacje są w jakiś sposób powiązane lecz nie mam pojęcia jak. Sprawdzałem czy nie uwalil się proc i jakiś zapis do pamięci przez co ucina wartości ale w debugerze nic podejrzanego nie zauważyłem. Sprawdzając przez STM Studio np. wartość 'a' widzę ją poprawnie. Czy ktoś ma jakikolwiek pomysł co mogło się wydarzyć? Układ F429ZI Nucleo.

from machine import Pin, UART import utime keyb = bytearray(4) mouse = bytearray(7) UART1 = UART(1, baudrate=115200, bits=8, parity=None, stop=1) button1 = machine.Pin(7, machine.Pin.IN, machine.Pin.PULL_UP) button2 = machine.Pin(6, machine.Pin.IN, machine.Pin.PULL_UP) keyb = [0xFE,0x04,0x00,0x00,0x00] #mouse = [0XFD,0x05,0x02,0x00,0x00] while True: if button1.value() == 1: keyb[3]=(0x00) elif button1.value() == 0: keyb[3]=(0x1b) if button2.value() == 1: keyb[4]=(0x00) elif button2.value() == 0: keyb[4]=(0x1d) UART1.write(bytes(keyb)) utime.sleep(0.09) #print(bytes(keyb)) Mam taki problem, chciałbym wysłać do buforu tablice hexów po naciśnięciu przycisku dany element w tablicy jest nadpisany . Nie znalazłem nic o buforze protokołu UART w sieci dlatego powstał taki kod, który podmienia jeden element po naciśnięciu przycisku i wysyła poprawnie raport, ale drugi if nie działa i powoduje nadpisanie całego raportu i reset połączenia. Nie wiem czy dla tak prostej operacji muszę zagłębić się w topologię fifo i DMA ?

Dość długo zabierałem się za ten projekt, ale w końcu udało się go zrealizować. Powstał on, ponieważ potrzebowałem czegoś, co umożliwi mi szybki wgląd w aktualne obciążenie komputera, bez niepotrzebnego przełączania okienek. Rozwiązanie czysto programowe byłoby też w moim przypadku o tyle mniej praktyczne, że często korzystam z maszyn wirtualnych, a taki zewnętrzny monitor obciążenia pozwala mi na wyświetlanie statystyk wszystkiego jednocześnie. Poza wyświetlaniem informacji zależało mi także na graficznej reprezentacji obciążenia, dzięki czemu można nawet "kątem oka" zauważyć że pojawiło się jakieś duże obciążenie lub że kończy się pamięć RAM. Parę lat temu zbudowałem taki monitor na ekranie LCD 4x20, jednak z biegiem czasu i modernizacją sprzętu coraz ciężej było zmieścić na nim wszystkie informacje które bym chciał, dlatego stwierdziłem że czas na nową odsłonę 😄 Tym razem zamiast ekranu LCD postanowiłem użyć wyświetlaczy OLED. Z kolei do reprezentacji graficznej chciałem wykorzystać diody WS2812. Dość długo zastanawiałem się w jaki sposób je ułożyć i jak to najprościej zrobić. Ostatecznie diody zostały ułożone w dwóch półpierścieniach nad wyświetlaczami. Aby ułatwić sobie życie kupiłem pierścienie 16 diodowe i 24 diodowe i przeciąłem na na pół. Wadą takiego rozwiązania było to, że tylko na jednej połówce miałem do dyspozycji wygodne pola lutownicze z tyłu, a na drugiej musiałem wlutować kable bezpośrednio w pierwszą diodę. Na zdjęciu widać pierwsze przymiarki diod do wyświetlacza: Docelowo planowałem wykonać 4 takie zestawy oled + diody, co wiązało się z pewnym problemem. Wyświetlacze które posiadałem podłącza się przez I2C, a ponieważ miałem 4 identyczne, to wszystkie miały ten sam adres, niestety producent wyświetlaczy nie przewidział takiego scenariusza (niektóre wersje umożliwiają ustawienie ostatniego bitu, co umożliwia podpięcie 2 wyświetlaczy, moje akurat nie miały takiej opcji). Po zrobieniu researchu rozwiązanie tego problemu okazało się bardzo proste. Polega ono na selektywnym doprowadzaniu sygnału zegara do poszczególnych wyświetlaczy. Ja w tym celu wykorzystałem demultiplekser 74HC139. Takie rozwiązanie jest możliwe, ponieważ tylko master (w tym wypadku mikrokontroler) steruje linią zegara, dzięki temu możliwe jest zastosowanie demultipleksera. W przypadku gdyby slave'y też sterowały linią zegara rozwiązanie byłoby bardziej złożone (o ile w ogóle możliwe), bo demultipleksery działają tylko w jedną stronę 😄 Z tego powodu też nie można tego zrealizować na linii danych (nawet jeśli przesyłanie danych odbywa się tylko w jedną stronę, to linia SDA musi być "dwustronna" żeby możliwa była realizacja protokołu I2C). W przypadku diod WS2812 sprawa była prostsza, docelowo każdy półpierścień dostał własny pin procesora, dzięki czemu każdy z nich może być odświeżany niezależnie. Jako mikrokontroler wybrałem Atmegę4809, ponieważ potrzebowałem 4kB ramu na trzymanie klatek z każdego z 4 oledów (128*64*4 = 32kb = 4kB). Możliwa by była realizacja przy mniejszej ilości pamięci, np 2kB, poprzez trzymanie tylko jednej klatki, jednak wiązałoby się to z mniejszą wydajnością całego programu, ponieważ generowanie kolejnej klatki można by było rozpocząć dopiero po zakończeniu przesyłania poprzedniej. W przypadku gdy każdy wyświetlacz ma swój bufor, to w trakcie gdy na przykład dane są wysyłane do pierwszego wyświetlacza możliwe jest generowanie obrazu dla drugiego wyświetlacza itd. Wymaga to asynchronicznej implementacji I2C, co zrealizowałem poprzez kolejkę do której można dodawać wskaźniki na tablice danych które mają być po kolei wysłane i ich obsługa jest w pełni realizowana na poziomie przerwania. Samo generowanie klatek zrealizowane jest w ten sposób, że dla każdego wyświetlacza przygotowany jest szablon zawierający stałe części obrazu, a następnie renderowane są na nim wartości w określonych pozycjach x,y, co łącznie generuje pełną klatkę obrazu. Graficznie wygląda to tak (po lewej templatka, po prawej z wypełnionymi wartościami): Wszystkie przygotowane ekrany wyglądają następująco: Ekrany przygotowane są stricte pod moją konfigurację, oczywiście możliwe by było generowanie wszystkiego po stronie komputera i przesyłanie gotowych klatek, akurat ja wolałem podejście z renderowaniem po stronie uC, ale co kto lubi 😄 Układ został zrealizowany na płytce uniwersalnej, a szkielet i obudowa zostały wydrukowane na drukarce 3D. Projekt ma budowę modułową i działa poprawnie z każdą liczbą modułów między 1 a 4, na ten moment mam zrealizowane dwa, kolejne dwa czekają aż będę miał trochę więcej wolnego czasu. Ponieważ każdy moduł wykorzystuje 4 kable do przesyłania danych (2 do pierścieni i 2 do wyświetlacza), to do ich podłączania wykorzystałem skrętkę, akurat po pół skrętki na moduł. Na ten moment całość prezentuje się następująco, kable z boku są przygotowane dla następnych modułów. Urządzenie łączy się z komputerem poprzez konwerter USB↔UART. Po stronie komputera działa aplikacja napisana w javascripcie, która zbiera dane z komputera na którym działa, używając głównie biblioteki systeminformation. Dodatkowo, nasłuchuje na jednym z portów sieciowych, pod który mogą się podpinać maszyny wirtualne i przesyłać dane o swoim obciążeniu. Technicznie, zamiast maszyn wirtualnych możliwe by było podpinanie innych fizycznych urządzeń, opcji jest wiele, wszystko zależy od potrzeb. Wyświetlanie informacji z dwóch źródeł jednocześnie na pierścieniach realizowane jest poprzez kolory, host wykorzystuje zielony i czerwony, natomiast maszyna wirtualna niebieski.

Cześć, po ponad półrocznej przerwie kontynuuje zmagania z z kamerką OV7675 z użyciem płytki Nucleo z stm32f446RE. DCMI ani DMA jeszcze nie udało mi się uruchomić ale na swój AVR'owy sposób jestem w stanie UARTem (baud 2M) przesłać w grayscale wartości pixeli z stm32 do apki w Python na moim PC. Po wygenerowaniu obraz jest akceptowalny, ale daleko mu do tego co widziałem na youtube, gdzie obraz nie dość że był czysty to jeszcze przsyłany na żywo( u mnie wygenerowanie zdjęcia przy 5 sekundach to jest dość szybko ^^). Problem wygląda tak: przesyłane dane a dokładniej linijki ( pixele przesyłam rzędami: [dane][index linijki] ) są często zlepkiem dwóch linijek, przez to rozmiar linijki często jest dwukrotnie większy niż to jest dla prawidłowego pakietu. Wydaje mi się że problem jest po stronie Pythona/Windowsa, który nie radzi sobie z taką ilością danych i gdy się gubi to skleja mi pakiety, chociaż dokumentacja PySerial mówi o obsłudze jeszcze większych baudrate. Podczas przeszukiwania internetu natknąłem się też na informacje że czasem taktowanie kamerki zegarem z MCU może powodować problemy i potrzebne jest ustawianie rejestrów w kamerce w celu przeskalowania zegara co powoduje jej poprawne działanie. Może miał ktoś podobny problem? Co myślicie?

Witajcie Realizuję komunikację pomiędzy mikroprocesorem STM32F411RE (NUCLEO) a modułem SIM800L. Wykorzystuję do tego interfejs UART. Inicjalizuję go poprzez bibliotekę HAL'a. Samą wymianę danych postanowiłem zrobić ręcznie, odwołując się bezpośrednio do rejestrów UART. Poniżej funkcja inicjalizacyjna: void uart_init(uint32_t baud) { uart_gpio.Pin = GPIO_PIN_9 | GPIO_PIN_10; //TX RX uart_gpio.Mode = GPIO_MODE_AF_PP; uart_gpio.Alternate = GPIO_AF7_USART1; uart_gpio.Speed = GPIO_SPEED_HIGH; uart_gpio.Pull = GPIO_PULLUP; HAL_GPIO_Init(GPIOA,&uart_gpio); usart.Instance = USART1; usart.Init.BaudRate = baud; usart.Init.Parity = USART_PARITY_NONE; usart.Init.StopBits = USART_STOPBITS_1; usart.Init.WordLength = USART_WORDLENGTH_8B; usart.Init.Mode = USART_MODE_TX_RX; HAL_USART_Init(&usart); } Sama komunikacja odbywa się w funkcji "sim_reception", w przerwaniu od timera mikroprocesora. #define SIM_TX_BUF_SIZE 32 #define SIM_RX_BUF_SIZE 32 volatile unsigned char sim_tx_buf[SIM_TX_BUF_SIZE]; volatile unsigned char sim_rx_buf[SIM_RX_BUF_SIZE]; volatile unsigned char sim_tx_len = 0; volatile unsigned char sim_rx_len = 0; enum { handshake, hdsh_resp }; volatile uint8_t sim_states = handshake; #define SIM_HNDSHK "AT\r\n" void sim_reception(void) { //RX //if Receiver not empty flag is set and we have space in rx buffer, we read byte while(USART1 -> SR & USART_SR_RXNE) { if(sim_rx_len < SIM_RX_BUF_SIZE) sim_rx_buf[sim_rx_len++] = USART1 -> DR; //after reading byte we increment buffer length else break; } //TX //if Transmitter empty flag is set and we have data in tx buffer, we send byte while(USART1 -> SR & USART_SR_TXE) { if(sim_tx_len != 0) { USART1 -> DR = sim_tx_buf[0];//send one byte sim_byte_up(sim_tx_buf); //shift one byte up } else break; } switch(sim_states) { case handshake: sim_tx_buf_put(SIM_HNDSHK); sim_states = hdsh_resp; break; case hdsh_resp: break; default: sim_states = handshake; break; } } Na razie chcę wysłać tylko jedno polecenie i odczytać odpowiedź modułu SIM800L. Krótko opiszę nadawanie, które działa bez zarzutu. Wywołuję funkcję "sim_tx_buf_put", która napełnia bufor komendą "SIM_HNDSHK", zdefiniowaną wyżej za pomocą #define. Funkcja bada ile miejsca mamy w buforze i czy wystarczy go jeszcze dla nowego polecenia. Jeśli tak to wstawia je bajt po bajcie i zwiększa odpowiednio zmnienną "sim_tx_len". Nie będe wstawiał kodu tej funkcji, ponieważ działa ona bardzo dobrze, nie mam z nią problemu. Wyżej w kodzie widać, że jest badany stan flagi "Transmitter Empty", gdy się ona pojawi i w buforze Tx są dane przystępuje się do wysyłania danych bajt po bajcie. Po każdym wysłanym bajcie wywoływana jest funkcja "sim_byte_up", która przesuwa bajty bufora "o jeden w górę", czyli sim_tx_buf[0] = sim_tx_buf[1], sim_tx_buf[1] = sim_tx_buf[2] itd. oraz zmniejsza wartość "sim_tx_len" o jeden, następnie wysyłany jest kolejny bajt i tak do opróżnienia bufora. Nadajnik działa jak należy, co pokazuje screenshot z analizatora stanów logicznych. Po wysłaniu wiadomości "AT\r\n" moduł SIM800L odsyła odpowiedź. Zatem flaga "Receiver Not Empty" powinna zostać aktywowana, bufor Rx jest pusty, tak więc coś powinno zostać zapisane w buforze. Jednak nic takiego się nie dzieje. Screenshoty z debugowania. W buforze Rx pojawia się tylko jeden bajt o wartości 127. Dalszych procedur odbioru nawet nie opracowałem, bo skoro w buforze odbiorczym nic nie ma... Nie bardzo wiem z czym jest związany ten problem, próbowałem wyprowadzić Tx i Rx we wszystkich możliwych konfiguracjach, jednak zawsze jest tak samo, nadajnik wysyła bez żadnego problemu a odbiornik nie może nic odczytać. Jeśli ktoś ma jakiś pomysł co może być przyczyną problemu i jak to rozwiązać to byłbym bardzo wdzięczny za pomoc 😉 Pozdrawiam mw

Cześć, jestem początkujący i mam trzy problemy z którymi nie mogę się uporać. 1. Obracający się serwomechanizm Zakupiłem serwo "Tower Pro MicroServo 99", działa one jedynie w przedziale 10-180 stopni (mimo wpisanego kąta nie obraca się o kąt w pełni oczekiwany). Ponadto dla wpisanych wartości obrotu 0-10 serwo nieustannie się obraca. Podobno występują dwa rodzaje serwomechanizmów i prawdopodobnie zamówiłem złe, czy jest to prawdą, czy może moje jest popsute? 2. Błędne działanie kodu Stworzyłem program taki jak na poniższym przykładzie. Chcę tutaj wpisywać z komputera wartości obrotu do serwa oraz otrzymywać komunikat zwrotny o wpisanej wartości. Niestety po każdej wpisanej wartości następna automatyczna wartość to 0. Gdzie popełniłem błąd. #include <Servo.h> Servo myservo; void setup() { myservo.attach(9); Serial.begin(9600); Serial.setTimeout(100); myservo.write(180); } void loop() { static int odebraneDane; if(Serial.available() > 0) { odebraneDane = Serial.parseInt(); Serial.println(odebraneDane); if(odebraneDane > 1 && odebraneDane < 181){ myservo.write(odebraneDane); } else{ Serial.println("Wpisales zly kat mogles spalic servo(wpisz kat od 0-180 stopni): "); } delay(50); } } Otrzymane wyniki: 70 0 Wpisales zly kat mogles spalic servo(wpisz kat od 0-180 stopni): 90 0 Wpisales zly kat mogles spalic servo(wpisz kat od 0-180 stopni): 180 0 Wpisales zly kat mogles spalic servo(wpisz kat od 0-180 stopni): 3. Chciałbym kupić krańcówki do arduino. Na botlandzie znalazłem takie: https://botland.com.pl/pl/czujniki-krancowe/921-wylacznik-czujnik-krancowy-z-dzwignia-prosta-wk315.html Czy będą one kompatybilne? Rozumiem, że na jeden koniec podam 5V na drugi GND, a środkowy pin będzie informował stanem wysokim/niskim o naciśnięciu krańcówki? Z góry dzięki za każdą pomoc.

Witam, Chcialem sie was zapytac, czy ta funkcja jest poprawna? Czy takie rozwiazanie nie bedzie powodowac wyciekow pamieci? Czy rozmiar tablicy jest dobrze alokowany? char * subarray; char buffor[30]; uint8_t bufforElementsNumber = 0; char * getSubArray(int size, char array[]) { subarray = NULL; subarray = malloc(sizeof(char) * size); for (int i = 0; i < size; i++) { subarray[i] = array[i]; } return subarray; }