Przeszukaj forum

Niejednokrotnie tworząc różne roboty, maszyny oraz platformy terenowe, miałem do czynienia z łączeniem wielu modułów lub tworzenia prowizorycznych układów na płytkach uniwersalnych. Problem pojawiał się na tyle regularnie, że postanowiłem wykonać układ umożliwiający w zasadzie bezpośrednie podłączenie napędu oraz jego obsługę za pomocą modułu NRF24L01. Uniwersalny sterownik robotów to płytka oparta na Atmega328AU, która umożliwia sterowanie radiowe dwoma silnikami DC oraz 6 portami IO. Układ jest rozpoznawany przez komputer jako Arduino Nano, dzięki czemu jest wygodny w obsłudze oraz kompatybilny ze środowiskiem Arduino IDE. W PROJEKCIE WYKORZYSTANO MIĘDZY INNYMI: Mikrokontroler Atmega328P-AU, Złącze USB B SMD, Diody LED statusowe zielone 0603, Moduł radiowy NRF24L01, Złącza XT30 M, Złącza ARK 2pin 5mm, Oscylator 12MHz, Oscylator 16MHz, Stabilizator 3V3, Stabilizator 5V, PEŁNA LISTA KOMPONENTÓW BOM: FUNKCJE SPRZĘTOWE STEROWNIKA: ⦁ Wbudowane złącze zasilania XT30 przyjmujące maksymalnie 28V DC, ⦁ Złącze włącznika, ⦁ Wbudowane statusowe diody zasilania, ⦁ Konwertery napięcia 5V oraz 3,3V, ⦁ Listwę zasilającą 5V, ⦁ Przycisk reset, ⦁ Wbudowane dwa mostki H - BD62130AEFJ-E2, ⦁ Wyprowadzenie pod moduł nrf24l01, ⦁ 6 portów IO (2x PWM, 4x ADC, 1xI2C), ⦁ Komunikacja przez mini USB B, ⦁ Komunikacja przez SPI, ⦁ Komunikacja przez I2C, STEROWANIE SILNIKA DC: Obsługa silników szczotkowych odbywa się za pomocą dwóch zintegrowanych z PCB mostków H BD62130AEFJ-E2. Umożliwiają one pracę silników do 28V oraz 3A. Ich obsługa odbywa się po przez piny: ⦁ PD2 (Arduino port 2) – M1A, ⦁ PD3 (Arduino port 3) – M1B, ⦁ PD4 (Arduino port 4) – M2A, ⦁ PD7 (Arduino port 7) – M2B, PEŁEN SCHEMAT ELEKTRYCZNY: ZDJĘCIA ZMONTOWANEJ PCB: PODSUMOWANIE: Ten projekt bardzo usprawnił moją pracę oraz przyspieszył postępy nad innymi projektami. Głównie przez oszczędność czasu oraz wygodę w obsłudze i debbugowaniu problemów. W przyszłości planuję ponownie pochylić się nad tym sterownikiem, próbując zmniejszyć jego gabaryty oraz wyprowadzając więcej pinów mikrokontrolera.

Cześć, Chciałem pokazać Wam mój projekt, który powstał głównie dla frajdy. Co dokładnie robi ten system? Pozwala z poziomu aplikacji Android: - włączać i wyłączać przekaźniki (np. światła w akwariach), - ustawiać harmonogram działania (czas startu i końca) dla pierwszego przekaźnika (z ogólnie 4 możliwych). Od strony tzw. "backendu": - Raspberry Pi 5 ma uruchomione mosquitto (MQTT), które dostępne jest na publicznym IP przez port TLS (8883) - mam więc dostęp do tego systemu w sposób (stosunkowo) bezpieczny, z dowolnego miejsca na świecie, z pomocą telefonu. - Całość komunikacji jest szyfrowana (zarówno mosquitto, apka na Androidzie, jak i urządzenia docelowe z Pico W korzystają z certyfikatów x509). Dodatkowo na brokerze jest login i hasło. Dodatkowo na Raspberry działa fail2ban, więc łatwo do systemu włamać się nie da. Procedura generowania kluczy opisana jest w README w repozytorium projektu. Dodatkowy bajer: urządzenia Pico W są wykrywane automatycznie – bez ręcznego dodawania ich do aplikacji Androidowej. Zajmuje się tym demon systemowy na Raspberry (aqua_topic_provider/provider.c). Lista wykrytych urządzeń wysyłana jest następnie do brokera MQTT, który udostępnia listę wykrytych urządzeń dla każdego zainteresowanego klienta (tu - aplikacja Android). Dodanie nowego urządzenia do systemu jest więc stosunkowo proste: Dla każdego nowego urządzenia z Pico W wystarczy lekko zmodyfikować konfigurację firmware (dodać sprzętowy MAC Pico W, ilość przycisków (przekaźników) oraz (dowolną) nazwę hosta - pod tą nazwą urządzenia występują na liście w aplikacji na Androidzie). Potem wystarczy skompilować, wgrać na Pico W, i tyle - apka na Androidzie po chwili pokaże nowe urządzenie na liście. Więcej info w readme na repo: pliki (Credentials.h / MacHostMapping.cpp) Architektura systemu System składa się z trzech głównych komponentów: 1. Raspberry Pi Pico W – jednostka wykonawcza: - steruje przekaźnikami, - reaguje na fizyczne przyciski, - obsługuje MQTT przez TLS (PubSubClient + WiFiClientSecure), - synchronizuje czas lokalny przez NTP (protokół pobierania aktualnego czasu z internetu), - nasłuchuje na UDP 0.0.0.0 (wszystkie interfejsy lokalne) / port 12345 - by dać się wykryć, - maszyna stanów obsługuje cykl życia aplikacji. Urządzenia wyglądają trochę topornie, ale to nie musi być piękne, tylko ma działać Program na Pico W korzysta z frameworka arduino-pico / https://github.com/earlephilhower/arduino-pico Do tego Arduinowy driver OLED (Adafruit_SSD1306), WiFi, MQTT (PubSubClient). Jest też zaimplementowana opcja update firmware urządzeń z Pico W przez OTA (ArduinoOTA). Całość firmware napisana jest jednakże w c++ (jedyny plik .ino ma raptem kilka linijek), i gdzieś mi chodzi po głowie by oddzielić biblioteki Arduino w osobnym module, i kiedyś zmigrować całość na jakieś inne środowisko, ale ogólnie chyba nie ma to sensu - systen działa stabilnie i bezproblemowo 24/7). 2. Raspberry Pi 5 – serwer i broker: - działa tu Mosquitto (MQTT broker), - demon w C cyklicznie wysyła pakiety UDP ("AQUA_DISCOVER" na 239.255.255.250:12345), (wspomniany wyżej provider.c) - Pico W odpowiada pakietem UDP "AQUA_FOUND|MAC|IP|hostname|amountOfSwitches" (DiscoverMe.cpp), - na podstawie tych odpowiedzi budowany jest JSON i publikowany na topicu: AQUA_DEVICES_UPDATE Przykładowa odpowiedź: { "devices": [ { "mac": "28:cd:c1:05:b8:76", "ip": "10.8.0.2", "hostName": "akwarium_duże_w_salonie", "switches": 1 }, { "mac": "28:cd:c1:05:b8:64", "ip": "10.8.0.3", "hostName": "akwarium_bojowniki_w_salonie", "switches": 2 } ] } 3. Aplikacja Android – interfejs użytkownika: - napisana głównie w Javie (bo lubię), z drobnymi elementami w Kotlinie, - korzysta z Eclipse paho w trybie klienta MQTT (org.eclipse.paho.client.mqttv3) - zapisuje się na główny topic AQUA_DEVICES_UPDATE, i później na pomocnicze topici AQUA_DEVICE_* - na tej podstawie buduje listę urządzeń widoczną w aplikacji, - każde urządzenie dostaje pozycję na liście (nazwa, przełączniki, przycisk ustalania harmonogramu). - komunikacja jest dwukierunkowa - czyli w apce włączam/wyłączam przekaźniki w urządzeniach, a w urządzeniach naciśnięcie danego przycisku odświeża stan switcha w apce w czasie rzeczywistym. Komunikacja przez brokera Gdy użytkownik: - zmienia stan przekaźnika (np. ON/OFF), - ustawia nowy harmonogram (np. 7:00–22:00), aplikacja Android publikuje odpowiedni JSON na MQTT: Włączanie przekaźnika: Topic: AQUA_DEVICE_SWITCH_SET/akwarium_duże_w_salonie { "isOn1": true } Ustawienie harmonogramu: Topic: AQUA_DEVICE_TIME_SET/akwarium_duże_w_salonie { "dateHourStart": 420, "dateHourEnd": 1320 } Te liczby to po prostu ilość minut od godziny 0:00. Pico W odpowiada statusem: Topic: AQUA_DEVICE_STATUS/akwarium_duże_w_salonie { "status": "ok", "dateHourStart": 420, "dateHourEnd": 1320, "isOn1": true [...] } Aplikacja na Pico W sama decyduje, czy pierwszy przekaźnik ma być włączony/wyłączony na podstawie lokalnego czasu i ustawionego harmonogramu. Można oczywiście ręcznie ten przekaźnik włączyć/wyłączyć, ale ostatecznie o określonych godzinach jego stan zostanie nadpisany przez ustalony harmonogram. Oczywiście prócz tego Pico W działają w pełni autonomicznie. Broker w tym przypadku służy tylko do ustawiania parametrów, i kontroli stanu przycisków przez aplikację. Pliki konfiguracyjne + submoduł W repozytorium nie ma plików z danymi wrażliwymi. Sam projekt wymaga by sklonować go z odświeżeniem submodułów: git clone --recurse-submodules https://github.com/jaszczurtd/lights-timer.git Ważne jest, by zawartość folderu "libraries" przekopiować do folderu "libraries" zarządzanego przez Arduino. Ważne jest również by odpowiednio skonfigurować i uzupełnić zawartość plików libraries/Credentials/ca_cert.c, oraz libraries/Credentials/MacHostMapping.h/.cpp – trzeba je dostosować do: - nazwy i hasła WiFi, - loginu/hasła/ip (domeny) do brokera MQTT, - certyfikatu x509 - przypisania MAC → hostname i liczby przekaźników. Sama wersja Arduino IDE z której korzystam to 2.3.x. Nie wiem czy to zadziała z wcześniejszymi wersjami. Po resztę informacji odsyłam do README w repozytorium. Dlaczego w ogóle to zbudowałem? Oczywiście wiem, że istnieją gotowe systemy smart home, które to wszystko robią lepiej, i pewnie jeszcze więcej – ale nie w tym rzecz. Prócz samej chęci tworzenia, jestem jednym z tych, którzy chcą mieć sterowanie domem w komórce, ale maja awersję do chmur wszelakich - stwierdziłem że nie chcę żeby światło w moich akwariach zależało od jakiegoś serwera cholera wie gdzie, albo nawet w Chinach. I najważniejsze - lubię malinki. Jedna chodzi 24/7, i robi za domowe centrum sterowania wszechświatem, więc idealnie nadaje się jako pośrednik dla tego systemu. I jeszcze pewnie odpowiedź na pytanie które się kołacze w głowie niejednego z was - ten projekt może się wydawać swoistym overkillem w temacie zdalnego włączania przekaźników. I tak pewnie by było, gdyby chodziło tylko o te przekaźniki. Ale struktura tego projektu i całe środowisko tak naprawdę zbudowałem z myślą o kilku ciekawszych rzeczach, którymi się pochwalę w przyszłości, i przy których to całe security, brokery, discovery itp, jest po prostu niezbędne. A co planuję dodać jeszcze do tego konkretnego projektu? - na pewno konfigurację WiFi dla Pico W z poziomu urządzeń (teraz trzeba to zmieniać w źródłach), - będzie pomiar temperatury wody w akwariach, - przyda się sterowanie chłodzeniem/grzaniem wody w akwariach, - może rozbuduję harmonogram, - reszta pomysłów jest na razie tajna Na razie moja żona (zapalona akwarystka) nie zgłasza konkretnego, dodatkowego zapotrzebowania, więc chwilowo zostaje tak jak jest. Ale to się wkrótce zapewne zmieni. Chętnie odpowiem na pytania, wyjaśnię dlaczego coś jest tak, a nie inaczej, etc. Pewnie są jakieś bugi, których chwilowo nie wykryłem, pewnie są miejsca które można lepiej ogarnąć, wiadomo. Repozytorium kodu https://github.com/jaszczurtd/lights-timer Pozdrawiam! Marcin (jaszczurtd)

Witam panowie, pilnie potrzebuję osoby która zbuduje dla mnie mini robota mobilnego zdalnie sterowanego z kamerką i mikrofonem. Proszę tylko o kontakt osoby które są w stanie zbudować takie urządzenie. Kontakt do mnie 729 797 649.

Mój projekt to robot/samochód na module esp32 zawierający kamerę internetową ESP32 CAM. Popularny moduł kamery postanowiłem umieścić na serwomechaniźmie sterowanym zdalnie. Rzecz która moim zdaniem wyróżnia mojego robota jest pilot który tak samo jak robot jest zbudowany na module esp32 ale w wersji Wemos d1, mam na myśli to że większość projektów znalezionych przeze mnie w Internecie do sterowania robotem wykorzystuje telefon co jest prostszym ale mniej dla mnie ekscytującym rozwiązaniem. Początkowo robot miał mieć na swoim pokładzie dobrze znane arduino uno i moduł nrf24 jednak moje umiejętności programistyczne nie pozwoliły mi na wykorzystanie tego Modułu. Prób było wiele jednak za każdym razem nie potrafiłem sparować ze sobą tych dwóch modułów. Nie odpuściłem i postanowiłem wykorzystać właśnie Esp32 na którym już za pierwszym razem wszystko poszło zgodnie z planem. Do komunikacji między modułami wykorzystuję ESP-NOW. Do sterowania silnikami pojazdu użyłem popularnego sterownika silników DC , natomiast do zasilania wykorzystuję 3 ogniwa Lion 3,7V. Poniżej znajduje się kod do zaprogramowania robota : #include <ESP32Servo.h> #include <analogWrite.h> // Samochód na esp 32 sterowany zdalnie // Napęd na 4 koła // Autor: Patryk #include <esp_now.h> #include <WiFi.h> //prawy silnik int enableRightMotor=22; int rightMotorPin1=16; int rightMotorPin2=17; //Lewy silnik int enableLeftMotor=23; int leftMotorPin1=18; int leftMotorPin2=19; int buz = 13; int pos; #define MAX_MOTOR_SPEED 100 const int PWMFreq = 1000; const int PWMResolution = 8; const int rightMotorPWMSpeedChannel = 4; const int leftMotorPWMSpeedChannel = 5; #define SIGNAL_TIMEOUT 1000 //maksymalny czas oczekiwania na sygnał unsigned long lastRecvTime = 0; const int SERVO_PIN = 26 ;// ESP32 pin GPIO26 connected to servo motor Servo servoMotor; struct PacketData { byte xAxisValue; byte yAxisValue; byte xAxisValue2; byte yAxisValue2; byte switchPressed; byte switchPressed2; }; PacketData receiverData; bool throttleAndSteeringMode = false; // funkcja realizowana gdy sygnał jest dostępny void OnDataRecv(const uint8_t * mac, const uint8_t *incomingData, int len) { if (len == 0) { return; } memcpy(&receiverData, incomingData, sizeof(receiverData)); String inputData ; inputData = inputData + "values " + receiverData.xAxisValue + " " + receiverData.yAxisValue + " " + receiverData.switchPressed+ " " + receiverData.xAxisValue2 + " " + receiverData.yAxisValue2 + " " + receiverData.switchPressed2; Serial.println(inputData); simpleMovements(); lastRecvTime = millis(); } void simpleMovements() { if (receiverData.yAxisValue >= 175) //do przodu>= 175 { rotateMotor(MAX_MOTOR_SPEED, MAX_MOTOR_SPEED); } else if (receiverData.yAxisValue <= 75) //do tyłu { rotateMotor(-MAX_MOTOR_SPEED, -MAX_MOTOR_SPEED); } else if (receiverData.xAxisValue >= 175) //prawo { rotateMotor(-MAX_MOTOR_SPEED, MAX_MOTOR_SPEED); } else if (receiverData.xAxisValue <= 75) //lewo { rotateMotor(MAX_MOTOR_SPEED, -MAX_MOTOR_SPEED); } else //Stop { rotateMotor(0, 0); } } void rotateMotor(int rightMotorSpeed, int leftMotorSpeed) { if (rightMotorSpeed < 0) { digitalWrite(rightMotorPin1,LOW); digitalWrite(rightMotorPin2,HIGH); } else if (rightMotorSpeed > 0) { digitalWrite(rightMotorPin1,HIGH); digitalWrite(rightMotorPin2,LOW); } else { digitalWrite(rightMotorPin1,LOW); digitalWrite(rightMotorPin2,LOW); } if (leftMotorSpeed < 0) { digitalWrite(leftMotorPin1,LOW); digitalWrite(leftMotorPin2,HIGH); } else if (leftMotorSpeed > 0) { digitalWrite(leftMotorPin1,HIGH); digitalWrite(leftMotorPin2,LOW); } else { digitalWrite(leftMotorPin1,LOW); digitalWrite(leftMotorPin2,LOW); } ledcWrite(rightMotorPWMSpeedChannel, abs(rightMotorSpeed)); ledcWrite(leftMotorPWMSpeedChannel, abs(leftMotorSpeed)); } void setUpPinModes() { pinMode(enableRightMotor,OUTPUT); pinMode(rightMotorPin1,OUTPUT); pinMode(rightMotorPin2,OUTPUT); pinMode(buz, OUTPUT); pinMode(enableLeftMotor,OUTPUT); pinMode(leftMotorPin1,OUTPUT); pinMode(leftMotorPin2,OUTPUT); servoMotor.attach(SERVO_PIN); //sygnał pwm do sterowania szybkoscią samochodu ledcSetup(rightMotorPWMSpeedChannel, PWMFreq, PWMResolution); ledcSetup(leftMotorPWMSpeedChannel, PWMFreq, PWMResolution); ledcAttachPin(enableRightMotor, rightMotorPWMSpeedChannel); ledcAttachPin(enableLeftMotor, leftMotorPWMSpeedChannel); rotateMotor(0, 0); } void setup() { setUpPinModes(); pos=90; Serial.begin(115200); WiFi.mode(WIFI_STA); // ESP-NOW if (esp_now_init() != ESP_OK) { Serial.println("Error initializing ESP-NOW"); return; } esp_now_register_recv_cb(OnDataRecv); } void loop() { if(receiverData.switchPressed == true){ digitalWrite(buz, HIGH); }else{ digitalWrite(buz, LOW); } //sygnał nieznaleziony unsigned long now = millis(); if ( now - lastRecvTime > SIGNAL_TIMEOUT ) { rotateMotor(0, 0); } servoMotor.write(pos); if(pos<180){ if(receiverData.yAxisValue2>150){ pos++; delay(20); } } if(pos>0){ if(receiverData.yAxisValue2<120){ pos--; delay(20); } } } Mamy robota to teraz czas na kamerę tutaj wykorzystałem już gotowy kod który pozwoli na wyświetlenie obrazu w przeglądarce internetowej. Jedyne co trzeba zrobić to podłączyć się do tego samego Internetu co mamy kamerę i wpisać tam adres IP podany w porcie szeregowym Arduino IDE po wgraniu kodu.Cameraesp32.zip Teraz zajmiemy się pilotem który na swoim pokładzie ma tak jak wspomniałem wcześniej esp32 Wemos d1 mini, dwa joysticki analogowe oraz 5 diod(cztery większe sygnalizują kierunki poruszania robota a jedna mała pomarańczowa, czy robot jest podłączony). Poniżej podrzucam kod: // Pilot do samochodu z użyciem esp32 d1 mini // sterowany joystickiem // Autor: Patryk //esp32 1.0.6 wersja wymagana //WEMOS D1 MINI ESP32 #include <esp_now.h> #include <WiFi.h> #define Gdioda 4 #define Hdioda 27 #define Pdioda 22 #define Ldioda 16 #define ON 17 #define X_AXIS_PIN 33 #define Y_AXIS_PIN 34 #define X_AXIS_PIN2 32 #define Y_AXIS_PIN2 35 #define SWITCH_PIN 26 #define SWITCH_PIN2 25 uint8_t receiverMacAddress[] = {0x3C,0x71,0xBF,0x11,0x70,0x70}; //AC:67:B2:36:7F:28 struct PacketData { byte xAxisValue; byte yAxisValue; byte xAxisValue2; byte yAxisValue2; byte switchPressed; byte switchPressed2; }; PacketData data; int mapAndAdjustJoystickDeadBandValues(int value, bool reverse) { if (value >= 2200) { value = map(value, 2200, 4095, 127, 254); } else if (value <= 1800) { value = map(value, 1800, 0, 127, 0); } else { value = 127; } if (reverse) { value = 254 - value; } return value; } // callback when data is sent void OnDataSent(const uint8_t *mac_addr, esp_now_send_status_t status) { Serial.print("\r\nLast Packet Send Status:\t "); Serial.println(status); Serial.println(status == ESP_NOW_SEND_SUCCESS ? "Message sent" : "Message failed"); if(status == 0){ digitalWrite(ON, HIGH); }else{ digitalWrite(ON, LOW); } } void setup() { Serial.begin(115200); WiFi.mode(WIFI_STA); // Init ESP-NOW if (esp_now_init() != ESP_OK) { Serial.println("Error initializing ESP-NOW"); return; } else { Serial.println("Succes: Initialized ESP-NOW"); } esp_now_register_send_cb(OnDataSent); esp_now_peer_info_t peerInfo; memcpy(peerInfo.peer_addr, receiverMacAddress, 6); peerInfo.channel = 0; peerInfo.encrypt = false; if (esp_now_add_peer(&peerInfo) != ESP_OK) { Serial.println("Failed to add peer"); return; } else { Serial.println("Succes: Added peer"); } pinMode(SWITCH_PIN, INPUT_PULLUP); pinMode(SWITCH_PIN2, INPUT_PULLUP); pinMode(Gdioda, OUTPUT); pinMode(Hdioda, OUTPUT); pinMode(Pdioda, OUTPUT); pinMode(Ldioda, OUTPUT); pinMode(ON, OUTPUT); } void loop() { data.xAxisValue = mapAndAdjustJoystickDeadBandValues(analogRead(X_AXIS_PIN), false); data.yAxisValue = mapAndAdjustJoystickDeadBandValues(analogRead(Y_AXIS_PIN), false); data.xAxisValue2 = mapAndAdjustJoystickDeadBandValues(analogRead(X_AXIS_PIN2), false); data.yAxisValue2 = mapAndAdjustJoystickDeadBandValues(analogRead(Y_AXIS_PIN2), false); data.switchPressed = false; data.switchPressed2 = false; if(mapAndAdjustJoystickDeadBandValues(analogRead(X_AXIS_PIN), false) <100){ digitalWrite(Gdioda, HIGH); }else{ digitalWrite(Gdioda, LOW); } if(mapAndAdjustJoystickDeadBandValues(analogRead(X_AXIS_PIN), false) >150){ digitalWrite(Hdioda, HIGH); }else{ digitalWrite(Hdioda, LOW); } if(mapAndAdjustJoystickDeadBandValues(analogRead(Y_AXIS_PIN), false) <100){ digitalWrite(Pdioda, HIGH); }else{ digitalWrite(Pdioda, LOW); } if(mapAndAdjustJoystickDeadBandValues(analogRead(Y_AXIS_PIN), false) >150){ digitalWrite(Ldioda, HIGH); }else{ digitalWrite(Ldioda, LOW); } if (digitalRead(SWITCH_PIN) == LOW) { data.switchPressed = true; } if (digitalRead(SWITCH_PIN2) == LOW) { data.switchPressed2 = true; } esp_err_t result = esp_now_send(receiverMacAddress, (uint8_t *) &data, sizeof(data)); if (result == ESP_OK) { Serial.println("Sent with success"); } else { Serial.println("Error sending the data"); } if (data.switchPressed == true) { delay(500); } else { delay(50); } } Do pilota zrobiłem własną płytkę pcb więc czemu miałbym się nią nie podzielić. Niżej podrzucam plik gerber do płytki Gerber_esp32-pilot_PCB_esp32-pilot_2025-03-09.zip Napisane kody są oczywiście wgrywane do esp32 za pomocą Arduino IDE, bardzo ważną rzeczą którą muszę podkreślić jest to że do skompilowania tych kodów potrzebujemy bibliotekę płytek esp32 w wersji nie najnowszej a 1.0.6 ponieważ w nowszych wersjach nie ma niektórych zawartych w kodzie funkcji. Na sam koniec podrzucam parę zdjęć z początkowej fazy projektu jeszcze na czystym mostku H bez płytki pcb. Jestem otwarty na jakiekolwiek pytania dotyczące projektu.

Wpadłem ostatnio znowu w fazę robienia rekwizytów (czasem mi się to zdarza). Oczywiście nie wszystkie mają coś wspólnego z elektroniką (bateryjki z przetwornicą, wyłącznikiem i 7 ledami nie uważam za szczyt osiągnięć współczesnej elektroniki), ale np. opisywana ostatnio kuchenka już tak. I w tej "fazie" powstał kolejny rekwizyt - ale najpierw kilka słów wprowadzenia. Otóż występująca w bajce postać (Pan Niedźwiedź) to taki gadgeciaż. Wszystko ma składane (krzesełka, stolik, nawet filiżanki do herbaty), dlaczego nie miałby słuchać swojej ulubionej muzyki z jakiegoś składanego sprzętu? Na początku jakoś nie miałem pomysłu co to by miał być za sprzęt aż do chwili, gdy w szufladzie w kuchni zobaczyłem silikonowy lejek. I wtedy mnie olśniło: przecież z tego wyjdzie super patefon! Jako że wszystkie dekoracje i rekwizyty w spektaklu to jakaś forma różnych tekturowych pudełek, wziąłem jakieś pudełko po chińskim filamencie, przyłożyłem do tego lejek... powstała tak absurdalna konstrukcja że stwierdziłem, że muszę to zrobić! Przeszukanie moich rupieci zaowocowało kilkoma elementami: ESP32 Lite (chciałem mieć zasilanie z baterii, ale o tym potem), mały wzmacniaczyk z potencjometrem na PAM8403 (kiedyś kupiony w Botlandzie ale ślad po nim w sklepie zaginął) no i oczywiście mały głośnik. Jako że klika urządzeń na takim zestawie już kiedyś zrobiłem, zabrałem się do pisania prostego programu... No i się zaciąłem. Okazało się, że najnowsze wersje boardu Arduino IDE oraz mojej ulubionej biblioteki ESP8266Audio nie przewidują działania takiego urządzenia. Nie bo nie, i koniec. Próby jakiegokolwiek zmuszenia tego do pracy owocowały wywaleniem jakiegoś mało zrozumiałego błędu i resetem ESP. Na szczęście miałem zarówno starą wersję biblioteki (taką sprzed trzech lat) jak i możliwość przełączenia boardu na wersję 2.x mój ESP wydał z siebie jakiś sensowny dźwięk, postanowiłem więc że nie będę wnikał w powody owego niedziałania i zastosuję po prostu te wersje. Patefon jak to patefon - musi być nakręcany, zdarta płyta ma szumieć i trzeszczeć no i oczywiście przeskakiwać. Czyli sekwencja działań ma być taka: Po włączeniu zasilania patefon czeka Po pokręceniu korbką (czemu ma towarzyszyć odgłos nakręcania) uruchamia się "płyta". Po kilku sekundach płyta się zacina Stuknięcie w obudowę ma spowodować, że igła przeskakuje dalej i patefon gra już bez przeszkód (zwrotka w pętli aż do wyłączenia). Jednocześnie dioda powinna pokazywać stan baterii (pali się - bateria nowa, miga - bateria zużyta). Tak więc schemat połączeń patefonu wygląda mniej więcej tak: I od razu pierwsza uwaga: wzmacniacz ma oczywiście potencjometr z wyłącznikiem, ale służy on do załączenia zasilania wyłącznie do tego wzmacniacza. Trezeba więc zasilanie do reszty układu pobrać zza wyłącznika, jak na poniższym zdjęciu: Główną płytkę wykonałem na bazie płytki uniwersalnej. Z lenistwa po prostu wlutowałem goldpiny od ESP32 do płytki - raczej nie przewiduję demontażu, a w razie czego zawsze można dmuchnąć hotairem. Wlutowane są tylko potrzebne piny. Jak widać na płytce oprócz ESP jest niewiele. Potencjometr służy do wstępnego ustalenia maksymalnej głośności, a wszystko jest spięte moimi ulubionymi złączami. Jeśli chodzi o zasilanie wykorzystałem fakt, że ta wersja modułu ESP32 pozwala na zasilanie z akumulatora. Tak więc połączyłem to tak jak na schemacie powyżej: dioda Schottky'ego zapobiega próbom ładowania baterii przy podłączonym USB (raczej by tego nie przeżyły) a jednocześnie pozwala na prawidłowe filtrowanie napięcia przez kondensator (próby uruchamiania urządzenia bez niego powodowały dość silne zakłócenia w głośniczku, a przy tym ESP okazjonalnie się resetował). Napięcie zasilające podłączone jest do wyprowadzenia BAT+ (pin nie jest wyprowadzony, w pierwszych próbach użyłem po prostu odpowiedniej wtyczki, w docelowym układnie nie miało to większego sensu więc przewód zasilający został po prostu przylutowany do wyprowadzenia z tyłu gniazda). No i kwestia korbki. Długo kombinowałem nad mechanicznym układem (jakieś zębatki z zapadkami które by ładnie trzeszczały, ale jak zrobić żeby patefon zaczął grać?) - potem zdałem sobie sprawę że przecież równie dobrze trzeszczeć może głośniczek, korbka ma napędzać najtańszy enkoder a program ma po prostu wykryć kiedy korbką się kręci (trzeszczy) a kiedy przestaje (gra). Proste, tanie i raczej mało awaryjne. Ostatnim elementem (oprócz diody sygnalizującej włączenie i stan baterii) jest czujnik stuknięcia. Początkowo chciałem użyć MPU6050 ale szkoda mi było użycia go wyłącznie jako akcelerometru, lepiej sprawdził się tu ADXL345. Wszystkie elementy połączone w (działającą) całość przedstawiają się tak: Teraz przyszła kolej na włożenie wszystkiego do pudełka, na razie bez montowania tuby. Ponieważ pudełko było w jednym miejscu lekko uszkodzone - zamaskowałem to tabliczką producenta na tylnej ściance. Skąd nazwa "His Slave's Voice" - to już pozostawiam domyślności czytelnika I jeszcze jedno: jeśli ktoś się uważnie przyjrzy zdjęciu może mieć wrażenie, że część terytorium naszego pięknego kraju (konkretniej Kobierzyce) znajduje się w Chinach... Zamontowanie "tuby" i przyklejenie koszyka na baterie zakończyło pracę nad konstrukcją elektroniczno - mechaniczną. Po złożeniu wysięgnika tuby wygląda to tak (przednia pokrywka jest otwarta - widać, że można w łatwy sposób wymienić baterie): Kilka słów o programie: Jak wspomniałem - użyłem starszej wersji boardu i biblioteki. Prawdopodobnie dałoby się to zrobić na najnowszych wersjach ale po prostu nie chciało mi się kombinować. Problem wystąpił wyłącznie wtedy, gdy chciałem w bibliotece ESP8266Audio użyć wbudowanego DAC jako wyjścia dźwięku. Dla tak prostej aplikacji nie cjhciało mi się kombinować. Dźwięk działa w oddzielnym tasku na rdzeniu 0 - ponieważ nie ma tu WiFi.BT, ma cały rdzeń do dyspozycji. Teoretycznie można by było rozbić na taski wszystkie elementy (akcelerometr, korbka, bateria) ale równie dobrze pracują w pojedynczej pętli. Komunikacja między poszczególnymi sekcjami programu odbywa się poprzez zmienne globalne - w tym przypadku nie trzeba było używać jakichś konstrukcji typu kolejka, semafor czy mutex, krótkie spojrzenie na kod powinno wyjaśnić wszystko. No i na zakończenie ciekawostka: przewidziałem możliwość uszkodzenia akcelerometru (patrz kod). Po zmontowaniu okazało się że akcelerometr nie działa, a zabezpieczenie doskonale zdało egzamin (płyta zacięła się 5 razy i pojechała dalej). Przyczyna była prosta: udało mi się przewiercić taśmę łączącą akcelerometr z główną płytką Tak wygląda patefon gotowy do pracy. Poniżej filmik (bałem się czy automaty YT nie uznają fragmentu "starego niedźwiedzia" za naruszenie praw autorskich, ale jakoś to przepuściły: Dźwięk powstał przy użyciu Audacity (montaż) i sox (niestety, Audacity nie chciał mi wygenerować pliku raw 16 khz 8-bit unsigned co nie powinno dziwić, bo nie do tego służy). Wynikowy plik raw został przekształcony na dane w pliku .h prostym programem w Pythonie: #!/usr/bin/env python3 muza=open('px1.raw','rb').read() print("static const uint8_t muza1[]={") pams=[] lem=len(muza) while len(muza) > 0: partia=muza[:16] muza=muza[16:] parl=list(partia) for n,a in enumerate(parl): #korekta wartości, oryginalne były za ciche a=((a-128) * 3) + 128 if a < 0: a=0 elif a > 255: a=255; parl[n]=a parl=','.join(list("%d" % x for x in parl)) pams.append(parl) print(',\n'.join(pams)) print('};') print ("static const int muza1len = %d;" % lem) #wartości 631808 i 767760 to numery sampli z Audacity przed resamplingiem print ("static const int muza1rpt = %d;" % int((lem *631808)/ 767760)) No i oczywiście kod całości w załączniku: Patefon.zip Zapraszam do Teatru

jak zrobic port zeby zaprogramowac arduino uno r3

Zapraszam do "blogowania" nowych / mniej znanych mikrokontrolerów, które można programować z poziomu Arduino / PlatformIO. W80x - chińska podróbka... chińskiego ESP32. Również oparta na rdzeniu XT804. Wersja W801 ma WiFi i Bluetooth, W806 jest "bezradiowa". Chyba jedyną przewagą nad ESP32 jest nieco niższa cena - poniżej 14zł z przesyłką z Aliexpress. https://github.com/board707/w80x_arduino Boards Manager URL: https://raw.githubusercontent.com/board707/w80x_arduino/hal-v0.6.0/package_w80x_test_index.json LGT8F328P - bezczelna, chińska aluzja do Atmega328P. Parametry podobne, chyba nawet pin compatible, z niewielkimi poprawkami względem pierwowzoru. Wyróżnia go m.in. selekcja zegara 1, 2, 4, 8, 12, 16 oraz 32 Mhz z poziomu Arduino (co pozwala dopasować wydajność i pobór prądu do zastosowań), 12-bitowe ADC (zamiast 10), wbudowany DAC. Toolchain wydaje się być w pełni użyteczny, zwłaszcza przy prostych projektach (używam od paru lat w stacji lutowniczej DIY). https://github.com/dbuezas/lgt8fx Boards Manager URL: https://raw.githubusercontent.com/dbuezas/lgt8fx/master/package_lgt8fx_index.json CH32 RISC-V MCUs Get Official Arduino Support CH32V003 - Test i recenzja https://github.com/openwch/arduino_core_ch32 Boards Manager URL: https://github.com/openwch/board_manager_files/raw/main/package_ch32v_index.json https://github.com/AlexanderMandera/arduino-wch32v003 Boards Manager URL: https://alexandermandera.github.io/arduino-wch32v003/package_ch32v003_index.json CH582F - toolchain chyba nie jest zbyt aktywnie rozwijany. https://github.com/ElectronicCats/arduino-wch58x Ze względu na gorsze wsparcie i w niektórych przypadkach toolchain na bardzo wczesnym etapie, na początku lepiej wybrać sprawdzone ESP8266, ESP32, RP2040, STM32. Z "dziwactw", najciekawsze wydają mi się moduły w stylu Arduino Pro Mini - LGT8F328P SSOP20, WeAct CH32V003F4U6. Zapewniają nieco więcej możliwości od Pro Mini (choć jest jeszcze zmniejszony klon Raspberry Pi Pico - RP2040-Zero).

Problem: Po aktualizacji nie można połączyć się z ESP32 w trybie AP. Rozwiązanie: przed pierwszym uploadem programu trzeba skasować zawartość flash. Dla Arduino1.8.19 w menu trzeba wybrać "Erase All Flash Before Sketch Upload" (musi wskazywać "Enabled"). Dla esptool uruchomić z opcję erase_flash. UWAGA! To skasuje CAŁĄ zawartość pamięci (a więc również preferencje i pliki). Jeśli nie możemy sobie na to pozwolić, trzeba wrócić do wersji 2.0.13 Dopisane po chwili: Cos ta wersja 2.0.14 niespecjalnie się sprawdza, ja wróciłem do 2.0.13 i będę czekał na rozwój wydarzeń, z tego co się zdążyłem zorientować problem jest znany i wynikł z przejścia na nową wersję esp-idf.

Witam chcę aby moja płytka esp8266 wyświetliła mi dares mac. Lecz po załadowaniu programu ten wykonuje się w pętli i wyświetla tylko końcówkę adresu mac. Arduino ide 2.2.1 #include <ESP8266WiFi.h> void setup(){ Serial.begin(115200); Serial.println(); Serial.print("ESP8266 Board MAC Address: "); Serial.println(WiFi.macAddress()); } void loop(){ } A podczas załadowywania i kompilacji kodu konsola wyświetla następujące informacje: "/Users/wojteknowak/Library/Arduino15/packages/esp8266/tools/python3/3.7.2-post1/python3" -I "/Users/wojteknowak/Library/Arduino15/packages/esp8266/hardware/esp8266/3.1.2/tools/upload.py" --chip esp8266 --port "/dev/cu.usbserial-120" --baud "115200" "" --before default_reset --after hard_reset write_flash 0x0 "/private/var/folders/l7/t8lbg_612y1_t6_rzt9m_f6h0000gp/T/arduino/sketches/6EC888AB277E4E894591D3001568582D/WiFiScan.ino.bin" esptool.py v3.0 Serial port /dev/cu.usbserial-120 Connecting.... Chip is ESP8266EX Features: WiFi Crystal is 26MHz MAC: 48:3f:da:40:59:d4 Uploading stub... Running stub... Stub running... Configuring flash size... Auto-detected Flash size: 4MB Compressed 270848 bytes to 199167... Writing at 0x00000000... (7 %) Writing at 0x00004000... (15 %) Writing at 0x00008000... (23 %) Writing at 0x0000c000... (30 %) Writing at 0x00010000... (38 %) Writing at 0x00014000... (46 %) Writing at 0x00018000... (53 %) Writing at 0x0001c000... (61 %) Writing at 0x00020000... (69 %) Writing at 0x00024000... (76 %) Writing at 0x00028000... (84 %) Writing at 0x0002c000... (92 %) Writing at 0x00030000... (100 %) Wrote 270848 bytes (199167 compressed) at 0x00000000 in 19.3 seconds (effective 112.2 kbit/s)... Hash of data verified. Leaving... Hard resetting via RTS pin...

Nie mogę wgrać żadnego programu na płytkę. Najpierw ładuje się bardzo długo a potem wywala błąd avrdude: stk500_recv(): programmer is not responding i temu podobne zaczynające się na avrdude: . Wszystko szło bardzo dobrze robiłem już drugą część kursu arduino aż pewnego dnia nic nie mogę wgrać. próbowałem już zmiany kabla, prze instalowanie arduino, tak port jest wybrany dobry, uruchomienie arduino jako administrator i uruchomienie portu szeregowego (zawiesiło mi komputer i nie mogę teraz zamknąć tego okienka), przytrzymywanie przycisku reset podczas wgrywania na płytkę(zdaje się że wywaliło wtedy trochę inny błąd) mam podejrzenia co do botloadera ale na razie nie mam odpowiedniego kabla żeby wypalić na nowo proszę o pomoc bo zbliża się turniej robotyki a ja jestem z nie działającą płytką

Witam, tworzę aplikację webową, na którą przesyłane będą współrzędne pozyskane z modułu GPS vk2828u7g5lf podłączonego do arduino model: WiFi Shield Arduino ESP8266 WEMOS D1 UNO R3. Tworzę program w arduino IDE lecz mam problem z wgraniem go na płytkę. Stworzyłem przykładowy program, który ma sprawdzić czy wszystko działa i podczas wgrywania wyskakuje taki błąd: A fatal esptool.py error occurred: Failed to connect to ESP8266: Timed out waiting for packet header. Board, który mam wybrany to NodeMCU 1.0 ESP 12-E. Na zdjęciu kod programu. Czy ktoś mógłby pomóc to ogarnąć? Pozdrawiam.

Witam, Zaczynam czytać kursy Arduino i mam problem. Z uwagi na brak USB, nie potrafię zainstalować na moim tablecie Lenovo, programu Arduino IDE. Mam tylko WiFi i Bluetooth, gdy próbowałem skorzystać z pomocy wujka G, to tylko wskazywana była możliwość przesyłu danych przez WiFi, a nigdzie nie mogłem jeżeli ktoś zna na to jakiś sposób, to proszę o podpowiedź. Pozdrawiam

Witam państwa jako że jestem stanowczym człowiekiem i jeszcze trzy dni temu obiecywałem sobie że nie będę się uczył nowych rzeczy, lub takich których nie będę używał w najblizszej przyszlosci jak np. freeRTOS, tak że ten......no od dwóch dni piłuję temat freeRTOS'a i mam w związku z tym kilka pytań, pierwsze.. Tworząc zadania, zadania te uruchomią się automatycznie czy potrzebuje jeszcze wywołać vTaskStartScheduler Bo znalazłem wiele przykładów gdzie ta funkcja jest wywoływana lub nie jest i działa...też wyczytałem różne opinie że jest potrzebna ta funkcja, lub że nie jest potrzebna bo utworzone zadanie startuje automatycznie..jak to jest z tym?

cześć, potrzebuje pomocy z programem do sterowania rębaka no stress. Większość kodu zrobiłem lecz coś nie działa program i nie mam pomysłu co jest nie tak. program ten ma za zadanie po wykryciu 3000 obrotów RPM włączyć przekaźnik sterowania silnikiem do przodu, lecz gdy obroty spadną do 1000 ma on włączyć na 0,5s przekaźnik silnika do tyłu i go zatrzymać. Po osiągnięciu obrotów 3000 ma on od nowa uruchomić silnik do przodu. pin awaria - wyłącznik bezpieczeństwa(wyłącza oba silniki) zmienna walek - włączanie wyłączanie silnika do przodu prowizorycznie RPM zmieniam wartością zmiennej //#define czujnik 2 // - w projekcie obrotomierz jest jako RPM //#define walek 6 //(OPCJONALNIE) czy jest wlaczony walek #define awaria 5 // wyłącza posów #define cewkaPrzod 3 // przekaznik wlaczajacy posow w przod #define cewkaTyl 4 // przekaznik wlaczajacy posow w tyl int RPM = 3001; int a = 0; bool walek; void setup(){ //pinMode(czujnik, INPUT_PULLUP); //pinMode(walek, INPUT_PULLUP); // wlaczyc jesli jest czujnik wałka pinMode(awaria, INPUT_PULLUP); pinMode(cewkaPrzod, OUTPUT); pinMode(cewkaTyl, OUTPUT); } void loop(){ walek = false; if(walek == true){ digitalWrite(cewkaPrzod, HIGH); } if(walek == false){ digitalWrite(cewkaPrzod, LOW); } walek = false; digitalWrite(cewkaTyl, LOW); //digitalWrite(cewkaPrzod, LOW); while(digitalRead(awaria) == HIGH){ if(a == 0 && RPM < 1000) { walek = false; digitalWrite(cewkaTyl, HIGH); delay(500); digitalWrite(cewkaTyl, LOW); a = a + 1; } if(RPM > 3000){ walek = true; a = 0; } } }

Witam, W trakcie robienia projektu (pojazd sterowany pilotem przez Bluetooth) napotkałem problem z nowo kupionym Arduino Nano Every (piny lutowałem sam). Chciałem, aby na pinach cyfrowych (podpiętych do przycisków) odczytywane było napięcie (HIGH lub LOW). Arduino z ustawionymi pinami na INPUT odczytuje stan wysoki - zawsze, choć powinien być stan niski. Wszystko działa dobrze po ustawieniu pinów na OUTPUT. Czy tak powinno być? Z tego co wiem to ustawienie na INPUT służy do odczytu, a odczyt z pinu ustawionego na OUTPUT powinien skończyć się błędem. Dla testu napisałem program: const int pinOut = 6; const int pinIn = 7; void setup() { Serial.begin(9600); pinMode(pinOut, OUTPUT); pinMode(pinIn, INPUT); } void loop() { //Odczyt z pinu 6 if(digitalRead(pinOut) == LOW) { Serial.println("Pin 6: LOW"); } //Odczyt z pinu 7 if(digitalRead(pinIn) == LOW) { Serial.println("Pin 7: LOW"); }else { Serial.println("Pin 7: HIGH"); } delay(1000); } Arduino jest podłączone tylko do komputera, żadne piny nie są połączone. A tutaj wynik: Pin 6: LOW Pin 7: HIGH Pin 6: LOW Pin 7: HIGH Pin 6: LOW Pin 7: HIGH Pin 6: LOW Pin 7: HIGH Pin 6: LOW Pin 7: HIGH Pin 6: LOW Pin 7: HIGH Czy to ja się mylę, czy np. płytka jest uszkodzona? Z góry dziękuję za pomoc.

We wrześniu pojawiła się stabilna wersja Arduino IDE 2.0.0. Osobiście polecam budowanie ze źródeł, ale dostępne są również prekompilowane wersje binarne Wersje prekompilowane: https://arduino.cc/en/software Repozytorium na Github ze źródłami: https://github.com/Arduino/arduino-ide A poniżej, skompilowane i uruchomione przeze mnie środowisko IDE, zrzut ekranu W razie problemów, chętnie pomogę(udzielę porad) w skompilowaniu po OS Linux

Hej, próbuje wysłać przez kolejkę na FreeRTOS strukturę wraz z rozróżnieniem dwóch tasków wysyłających i jednym odbierającym. Tak wygląda mój kod: #include "queue.h" typedef int taskProfiler; typedef enum { eSender1 = 0, eSender2, }DataSource_t; typedef struct { uint8_t ucValue; DataSource_t eDataSource; }Data_t; static Data_t xStructToSend[2] = { (100, eSender1), (50, eSender2) }; QueueHandle_t xQueue; taskProfiler senderTaskProfiler = 0; taskProfiler receiverTaskProfiler = 0; void setup() { // put your setup code here, to run once: Serial.begin(115200); delay(5000); Serial.println(xStructToSend[1].ucValue); xQueue = xQueueCreate(3, sizeof(Data_t)); xTaskCreate(vSenderTask, "Sender Task 1", 8192, &(xStructToSend[0]), 2, NULL); xTaskCreate(vSenderTask, "Sender Task 2", 8192, &(xStructToSend[1]), 2, NULL); xTaskCreate(vReceiverTask, "Receiver Task", 8192, NULL, 2, NULL); } void vSenderTask(void *pvParameters) { BaseType_t xStatus; const TickType_t xTicksToWait = pdMS_TO_TICKS(100); Data_t xReceivedStructure; memcpy(&xReceivedStructure, &pvParameters, sizeof(pvParameters)); while(1) { xStatus = xQueueSend(xQueue, pvParameters, xTicksToWait); if(xStatus != pdPASS) { Serial.println("Could not send to the Queue"); } Serial.println(xReceivedStructure.ucValue); } } void vReceiverTask(void *pvParameters) { Data_t xReceivedStructure; BaseType_t xStatus; while(1) { xStatus = xQueueReceive(xQueue, &xReceivedStructure, 0); if(xStatus == pdPASS) { if(xReceivedStructure.eDataSource == eSender1) { Serial.print("This is from Sender1: "); Serial.println(xReceivedStructure.ucValue); } else { Serial.print("This is from Sender2: "); Serial.println(xReceivedStructure.ucValue); } } else { Serial.println("Could not receive data from the queue"); } } } void loop() { // put your main code here, to run repeatedly: } W "setup()" linia "Serial.println(xStructToSend[1].ucValue);" zwraca mi wartość 0 chociaż teoretycznie powinna 50. Tak samo dzieje się w tasku wysyłającym w linii "Serial.println(xReceivedStructure.ucValue);". Wyglada jakby od samego początku była zła inicjalizacja wartości zmiennych w wysyłanej strukturze. Sam task Receiver zwraca wartość 152 lub 160. Jaki błąd został popełniony w tym kodzie i w jaki sposób prawidłowo mogę zainicjalizować zmienne w strukturze? Z góry dziękuje za pomoc. Pozdrawiam

Witam serdecznie, pracuję nad pewnym projektem i ze względu na niedostateczne umiejętności programowania w C, postanowiłem wykorzystać ArduinoIDE z bliblioteką esp32 do zaprogramowania układu ESP32-C3, zamiast dedykowanego przez producenta frameworka ESP-IDF. Tutaj pojawia się moje pytanie, w jaki sposób przebiega kompilacja takiego projektu w ArduinoIDE ? Czy projekt, który wgrywamy po przez ArduinoIDE de facto też jest zcustomizowanym firmwarem ? czy może to jest instrukcje w c++ uruchamiane są na dedykowanym firmwarze ? Kolejna sprawa: czy gdy wgrywamy nasz program do pamięci płytki to z każdym razem wgrywany jest nowy firmware, czy tylko podmieniany jakiś segment pamięci ? Niestety nie mam specjalistycznej wiedzy w tej materii, dlatego zależy mi na wyjaśnieniu tej kwestii.

Witam wszystkich!!! W poprzednim artykule przedstawiłem swoją wizję platformy Arduino UNO opartej o procesor ATmega 328 THT. Wizja nie do końca doskonała, choć dla mnie na chwilę obecną wystarczająca. Chciałem teraz, aby to było coś wyróżniającego się na tle klonów tej platformy. Coś z powiewem świeżości, nowego!!!. Bo nie sztuką jest zrobić klon 1:1 i to tylko aby zbić cenę a nieraz wykonanie niektórych klonów pod względem jakości jak i działania pozostawiało wiele do życzenia. Pierwsza wersja mojego urządzenia była tak naprawdę tylko wstępem do tego co teraz zamierzałem zrobić, co tym bardziej zachęciło mnie do zrobienia ostatecznej wersji mojego urządzenia. Wersji, która uważam zawiera ciekawe rozwiązania, których mi osobiście brakowało a na pewno znajdą się osoby, które myślą podobnie. Bo czym jest poświęcenie jednej ATmegi, której koszt wynosi mniej niż 10 PLN aby na stałe była zaprogramowana jako programator ISP , dzięki czemu możemy swobodnie wgrywać bootloader do drugiej wymiennej ATmegi, nie używając do tego dedykowanego shielda lub łącząc układ na płytce stykowej. Wygodnie prawda?. Możliwość podłączenia dowolnego konwertera, którego koszt nieraz jest mniejszy niż procesor ATmega 16U2, który dodatkowo trzeba zaprogramować lub inny układ odpowiadający za komunikację. A jako, że takie konwertery są tanie to opłaca się kupić kilka sztuk na tak zwaną "czarną godzinę" lub gdy mamy kilka projektów, które z nich korzystają. Na początku kilka słów samokrytyki!!! Pewne rozwiązania były zrobione na szybko. Owszem działały jednak na przykład: przełączanie zasilania z USB na zasilacz za pomocą przekaźników ogólnie nie jest idealne jak w oryginalnej platformie. Szczerze dla mnie osobiście to akurat było bez znaczenia gdyż tu sugerowałem się posiadanymi przeze mnie elementami oraz tym, że mi osobiście reset procesora nie przeszkadzał w momencie przełączania zasilania z USB za zasilacz i odwrotnie, ale jednak względem oryginalnej platformy, funkcjonalność ta znacznie odbiegała. Tak więc skoro moja wizja ma dorównać a docelowo być lepsza od oryginału i jego klonów, zatem działanie pewnych elementów urządzenia musi być takie samo. Poniżej kilka zdjęć nowej wersji MWuinoUNO-rev3.1 W przedstawionej przeze mnie wersji zrezygnowałem z użycia konwertera, a komunikację z procesorami wykonałem z użyciem układu FTDI232RQ. W plikach urządzenia, przygotowałem łącznie cztery wersje urządzenia. Plik do pobrania jest na końcu artykułu. Pierwszą wersję Rev3.1, którą aktualnie będę przedstawiał z użyciem FTDI 232RQ. Drugą wersja Rev3.2, także z użyciem FTDI232RQ, z tym, że zastosowany jest wydajniejszy stabilizator dla linii 5V - LM340MP-5.0/NOPB o wydajności prądowej 1,5A. Kolejne dwie wersje Rev4.1 oraz Rev4.2 gdzie do komunikacji możemy wykorzystać konwerter, tak jak miało to miejsce w prezentowanej jakiś czas temu pierwszej odsłonie mojego urządzenia, z tym że podobnie jest podobnie jak w Rev3.2, Rev4.2 ma wydajniejszy stabilizator dla linii 5V. Powstanie dodatkowych Rewizji 3.2 oraz 4.2 było podyktowane innymi rolami wyprowadzeń stabilizatora dla linii 5V - LM340MP-5.0/NOPB niż ma stabilizator NCP1117ST50T3G. Zatem obu tych stabilizatorów nie można używać zamiennie w tym przypadku. Podsumowując!!! Poprawiłem pewne niedostatki z wersji pierwszej wprowadzając odpowiednie modyfikację. Przejrzałem dostępne klony platformy UNO R3 z ATmegą 328 THT oraz ciekawe rozwiązania zaadaptowałem w swojej wersji urządzenia oraz dodałem drobne funkcje od siebie. Poniżej zdjęcia prezentujące pierwszą wersję urządzenia MWuinoUNO Rev.1 oraz aktualna prezentowana wersja MWuinoUNO Rev3.1 Uważam, że wszystko jest jak należy i więcej nic nie potrzeba dodawać. Urządzenie jest zbliżonych rozmiarów względem oryginału, a oferuje znacznie więcej niż oryginalna platforma lub jej klony. najważniejszą zaletą jest wygoda!!! W końcu dla hobbystów jak i amatorów wyeliminowanie pewnych rzeczy, które mogą nas irytować uważam że jest ważne. W końcu dla mnie elektronika oprócz zarabiania na życie to pasja, a ta raczej powinna nam zapewnić spokój i skupienie się na tym co robimy. Wiadomo, że nie jesteśmy w stanie wszystkiego przewidzieć, ale zawsze możemy próbować eliminować pewne niedogodności z tym związane. Przejdźmy zatem do omówienia mojego projektu. Porównajmy teraz moją wersję platformy Uno z oryginalną i jej wiernie wykonanymi klonami. Najważniejsze różnice są przedstawione poniżej: Cecha: UNO R3 oraz klony 1:1 MWuinoUNO Rev3.1 MWuinoUNO Rev3.2 MWuinoUNO Rev4.1 MWuinoUNO Rev4.2 Napięcie pracy 5V 5V/3,3V 5V/3,3V 5V/3,3V 5V/3,3V Jumper Bootloader Nie Tak Tak Tak Tak Złącze USB USB B micro USB micro USB nie dotyczy-brak nie dotyczy-brak Włącznik zasilania Nie Tak Tak Tak Tak Wyjście 3,3V* Prąd 150mA Prąd 300/500mA Prąd 300m/500mA Prąd 300/500mA Prąd 300/500mA Wyjście 5V Prąd 1A Prąd 1A Prąd 1,5A Prąd 1A Prąd 1,5A Oscylator Ceramiczny Kwarcowy Kwarcowy Kwarcowy Kwarcowy Wgrywanie bootloaderów Tylko z użyciem shielda Tak Tak Tak Tak lub podłączonego układu na płytce stykowej Sterownik USB ATmega16U2 FT232RQ FT232RQ UART/RS232 TTL UART/RS232 TTL konwerter konwerter Sterowanie diodą (L) wzmacniacz operacyjny MOSFET BSS138 MOSFET BSS138 MOSFET BSS138 MOSFET BSS138 *- Montujemy jeden z dwóch stabilizatorów w zależności od naszych potrzeb. Ze względu na to, że ich wyprowadzenia pełnią taką samą rolę można ich używać zamiennie. W prezentowanej wersji zamontowany jest stablizator o wydajności 300mA, gdyż 500mA na chwilę zamawiania elementów do montażu, nie był dostępny. Napięcie pracy: 5V/3,3V Przełącznik konfiguracji napięcia 3,3V/5V: ustala jakim napięciem jest zasilany mikrokontroler a tym samym z jaka logiką pracuje cały system, do wyboru 3,3V lub 5V. Jumper Bootloader: W trybie ON płytka się zresetuje po podłączeniu napięcia zasilania lub portu USB. W trybie OFF : program zapisany ruszy natychmiast po podłączeniu zasilania, płytka nie zresetuje się po podłączeniu portu USB do PC. Złącze USB: Możliwość użycia popularnego mniejszego kabla micro USB używanego w większości smartphonów, itp. Włącznik zasilania: Aby odłączyć urządzenie od zasilania nie trzeba już wyciągać wtyczki z gniazda. Można to zrobić włącznikiem ON/OFF. Wyjście 3,3V: MWuinoUNO zapewnia wyższą wydajność prądową stabilizatora 3,3V. Wyjście 5V: MWuinoUNO w Rev3.2 oraz Rev4.2 zapewnia wyższą wydajność prądową stabilizatora 5V. Oscylator: Rezonator kwarcowy zapewnia wyższą dokładność taktowania. Wgrywanie bootloaderów: W MWuinoUNO wystarczy do podstawki IC2 włożyć czysty procesor i wykonując odpowiednie czynności wgrać bootloader. Sterownik USB: Układ FT232 w MWuinoUno jest wspierany w każdym popularnym systemie operacyjnym lub wersja bez układu komunikacji FT232, gdzie możemy podłączyć dowolny konwerter UART/RS232 TTL. Sterowanie diodą (L): Sterowanie diodą LED w UNO i klonach podyktowane jest oszczędnością a tym samym wykorzystaniem drugiego wzmacniacza operacyjnego gdyż LMV358 zawiera dwa wzmacniacze. To zastosowanie ma pewne wady takie jak, że wzmacniacz operacyjny nie przenosi pełnego pasma sygnału CLK. Tak więc jasność LED nie będzie dobrze oddawała pinu CLK. Lepiej do tego celu nadaje się tranzystor, który steruje LED-em. Tranzystory MOSFET są sterowane napięciowo, więc podobnie jak wzmacniacz w konfiguracji wtórnika emiterowego, nie obciąża sygnału z pinu CLK. Tutaj też się przyznam, że większość z rozwiązań są skopiowane. Po przejrzeniu klonów platformy UNO wybrałem te użyteczne. Fakt faktem nie było tego dużo, więc wybrałem prawie wszystkie. Moje rozwiązania to tak jak w pierwszej odsłonie projektu zintegrowanie programatora ISP, dzięki, któremu możemy wgrywać bootloader do wymienialnego procesora IC2. Urządzenie posiada także sygnalizację zasilania z USB diodą LED. Rozwiązanie to niesie ze sobą dodatkową korzyść. Jak widać na schemacie załączonym w pliku: MWuinoUNO.zip - na przykład Rev3.1. Dioda LED USB jest sterowana stanem niskim wzmacniacza operacyjnego, pełniącego rolę komparatora. Generalnie do porównywania napięć przeznaczone są do tego celu komparatory. Jako, że nie mam ostatnio czasu bawić się w eksperymenty zastosowałem coś co jest sprawdzone i działa choć tutaj zastosowałem wzmacniacz, który był użyty w poprzedniej wersji do sterowania dioda użytkownika (L). Dobierając wtedy ten wzmacniacz patrzyłem pobieżnie na pewne parametry, ale zaryzykowałem i przy okazji postanowiłem zobaczyć czy się sprawdzi. No i jak widać wszystko działa dobrze. Teraz napiszę na czym polega dodatkowa korzyść z zastosowania diody LED USB oraz jej sterowania z wyjścia wzmacniacza. Rozwiązanie ze wzmacniaczem w roli komparatora jest skopiowane. Przeanalizujmy najpierw działanie wzmacniacza operacyjnego (IC10) w roli komparatora. Opis ten odnosi się do rev3.1 oraz 4.1, gdzie rezystory R18,R19 dzielnika napięć mają jednakową wartość rezystancji-10k. Zatem: Napięcie z zasilacza (VIN) jest podane na dzielnik napięcia złożonego z rezystorów R18, R19 o wartości 10 kOhm każdy, który działa w proporcji 1:2. Napięcie mierzone przez wzmacniacz (na wejściu nieodwracającym +) jest na rezystorze R19 dzielnika i jest porównywane z napięciem wzorcowym 3,3V mierzonym na (wejściu odwracającym -) wzmacniacza, które pochodzi z dodatkowego stabilizatora (IC5). Więc jeśli napięcie zasilania (VIN) jest równe lub nieco wyższe od 6,6V, tranzystor T1 nie jest sterowany z wyjścia wzmacniacza i tym samym nie przewodzi. Dioda LED USB nie świeci i do zasilania całego urządzenia wykorzystywany jest zasilacz. Najprościej rzecz ujmując: Napięcie na rezystorze R19 osiąga wartość 3,3V przy napięciu zasilania równym lub nieco wyższym od (VIN)=6,6V. Wyjście wzmacniacza operacyjnego sterującego tranzystorem T1 i diodą LED USB jest w stanie wysokim przez co tranzystor ten nie przewodzi oraz nie świeci dioda LED USB, co informuje nas, że do urządzenia podłączone jest zewnętrzne zasilanie, które także zasila nam całe urządzenie. Tutaj kluczowa jest też wartość napięcia zasilacza ze względu na minimalną wartość napięcia zasilania stabilizatora 5V. Standardowy stabilizator zastosowany w UNO i niektórych jego klonach na wejściu potrzebuje minimum 6,5V aby na jego wyjściu napięcie stabilizowane, którym zasilane są wszystkie podzespoły urządzenia, wyniosło 5V. W przypadku zastosowania stabilizatora LM340MP-5.0/NOPB minimalne napięcie zasilania tego stabilizatora wynosi 7,5V. Zatem aby urządzenie przełączało nam zasilanie z USB na zasilacz i tym samym aby mieć napięcie 5V na wyjściu tego stabilizatora, musimy zmienić wartość jednego z rezystorów dzielnika napięcia tak aby przy napięciu zasilania z zasilacza - 7,5V na rezystorze R19, napięcie wynosiło 3,3V. Zatem od czego najpierw zaczynamy. Z poniższego rysunku, (aby było nam łatwiej ustalić parametry dzielnika) widzimy, że musimy ustalić: Spadki napięć "UR18", "UR19" na rezystorach, prąd "Ir" płynący przez rezystory naszego dzielnika oraz wartość rezystancji "R18". Pierwszym krokiem będzie ustalenie rozkładu napięcia VIN na poszczególnych rezystorach dzielnika. Jako że wejście nieodwracające (+) wzmacniacza jest podłączone pomiędzy R18 a R19 to znaczy, że wzmacniacz mierzy napięcie na R19. Wiemy, że napięcie na R19 ma wynieść 3,3V przy napięciu zasilania VIN=7,6V. Zatem UR19=3,3V Znając napięcie na R19 Obliczymy teraz spadek napięcia jaki musi być na R18. Wystarczy, że od napięcia VIN odejmiemy napięcie na R19 UR18=VIN-UR19=6,7V-3,3V=4,3V. Zatem spadek napięcia na R18 wynosi 4,3V. Jak widać napięcie VIN jest sumą spadków napięć na poszczególnych rezystorach naszego dzielnika zatem: VIN=UR18+UR19=4,3V+3,3V=7,6V. Ustalamy wartość jednego z rezystorów dzielnika. Jest to istotne aby obliczyć prąd płynący przez dzielnik. Dla ułatwienia wybrałem R19 i niech będzie miał on wartość 10k. Jak widać dzielnik napięcia to po prostu połączone ze sobą dwa rezystory szeregowo. Cechą szeregowego połączenia rezystorów jest to, że płynie przez nie ten sam prąd "Ir". Zatem znając wartość rezystora R19 i spadek napięcia na nim, możemy obliczyć prąd "Ir" płynący przez oba rezystory, korzystając z prawa Ohma I=U/R zatem Ir=UR19/R19=3,3V/10k=0,33mA Z kolei znając wartość prądu płynącego przez rezystory R18, R19 dzielnika oraz spadek napięcia na R18, znów korzystając z prawa Ohma po przekształceniu wzoru I=U/R do postaci R=U/I, obliczmy rezystancję rezystora R18. Zatem R18=UR18/Ir=4,3V/0,33mA=13k Jak widzimy nasz rezystor R18 ma wartość 13k Jak widzimy w tym przypadku wyliczenie wartości potrzebnego nam rezystora jest bardzo łatwe. Dzięki temu nasz układ przełączając się z zasilania USB na zasilacz dostarczy do stabilizatora odpowiednio wysokie napięcie na jego wejście, aby na wyjściu tego stabilizatora uzyskać napięcie 5V potrzebne do zasilania podzespołów naszego urządzenia, a my dzięki diodzie LED USB będziemy wiedzieć czy tak się stało. Właśnie to jest ta zaleta. Oczywiście aby to działało sprawnie musimy obserwować diodę USB oraz ustawić odpowiednią wartość napięcia zasilania na zasilaczu. Po podłączeniu zasilania z zasilacza powinna zapalić się zielona dioda LED PWR, a niebieska USB zgasnąć. Musimy pamiętać, że zasilacze wtyczkowe regulowane przełącznikiem, mają podane na sztywno zakresy przełączanych napięć a nie wszyscy mogą wiedzieć że stabilizator aby dać napięcie 5V na wyjściu, musi mieć podane na wejście konkretną wartość napięcia. Najważniejsze, żeby pamiętać aby nie przekroczyć maksymalnego napięcia zasilania dla stabilizatora, aby tym samym go nie uszkodzić oraz innych elementów naszego urządzenia. W zależności od modelu stabilizatora, napięcie jego zasilania może mieć inną wartość. Jeżeli po podłączeniu zasilacza dioda LED USB nie zgaśnie może się okazać, że nasz zasilacz podaje zbyt niskie napięcie niż jest potrzebne do przełączenia się urządzenia z zasilania USB na zasilanie z zasilacza, a tym samym podania na wejście stabilizatora odpowiedniej wartości napięcia, aby na jego wyjściu uzyskać 5V. Będziemy też wiedzieć czy zasilacz jaki zastosowaliśmy ma odpowiednie napięcie aby zasilić nasze urządzenie. Aby ułatwić sprawę napiszę jaką wartość napięcia zasilania można podać dla danego typu stabilizatora: -stablizator NCP1117ST50T3G 5V, 1A. Producent napisał, że maksymalne napięcie wejściowe to max 20V. Natomiast minimalne to 6,5V -stabilizator LM340MP-5.0/NOPB 5V, 1,5A Producent napisał, że maksymalne napięcie wejściowe to max 35V. Natomiast minimalne to 7,5V Jak też widać pomimo, że mechanizm przełączania zasilania jest identyczny jak w platformie uno i jej klonach, to trochę podrążyłem temat co przedstawiłem powyżej. Być może komuś te informacje okażą się przydatne przy projektowaniu własnego urządzenia z użyciem dzielnika napięcia. Dodanie do obwodu diody led oraz podstawowa wiedza na temat stabilizatorów oraz dzielnika napięcia z zastosowaniem wzmacniacza operacyjnego w roli komparatora, dała nam przydatną funkcję, dzięki której wszystkie elementy urządzenia, jak i te które przyłączymy do niego, będą zasilane odpowiednią wartością napięcia. Podsumowując dzięki diodzie LED USB wiemy, czy nasze urządzenie przełączyło się na zasilanie zewnętrzne (zasilacz) tym samym przełączenie to nastąpiło w momencie, kiedy nasz zasilacz ma odpowiednią wartość napięcia potrzebną do zasilenia stabilizatora, aby ten na wyjściu dał napięcie 5V potrzebne z kolei do zasilania podzespołów urządzenia oraz elementów do niego podłączonych. W największym skrócie - jak widać zależność napięcia wejściowego "VIN" (zasilacz), do którego podłączony jest stabilizator, do napięcia wyjściowego "UR19", które steruje wzmacniaczem operacyjnym w roli komparatora, którego rolą jest przełączanie źródła zasilania jest uzależniona od wartości rezystancji dzielnika napięcia. Znając wartość napięcia potrzebnego do zasilenia stabilizatora oraz fakt, że przy tej wartości napięcie na wyjściu dzielnika ma wynieść 3,3V dobieramy odpowiednią wartość rezystorów dla tego dzielnika. Dodam jeszcze, że zrezygnowałem z połączeń pomiędzy dwoma procesorami na liniach MISO, MOSI, SCK za pośrednictwem diod, tak jak to miało w pierwszej odsłonie urządzenia. Okazało się, że w przypadku linii MISO i MOSI jest to zbędne i urządzenie działa bez problemu. Inaczej jest w przypadku lini SCK, ale tutaj zastosowałem rozwiązanie z poziomu hardware niż softu. Jako, że miałem zamówionych więcej układów analog. MUX/DEMUX, to wolałem użyć go do połączenia pinów SCK procesorów IC1 i IC2 niż bawić się w modyfikację kodu. Efekt działania w końcu jest ten sam tylko metoda prowadząca do tego efektu inna. Kolejną rzeczą choć może mniej istotną jest możliwość uśpienia programatora ISP. Jeżeli na przykład drażnią kogoś świecące się diody led. Co mi rzadko ale bywa, że przeszkadza, szczególnie jak nie używamy programatora ISP aktualnie go do wgrywania bootloderów. Oszczędzanie energii w tym przypadku nie jest specjalnie duże (około 50mA), choć z drugiej strony lepiej mieć mniej niż wcale, szczególnie gdzie port USB ma wydajność 500mA. Aby aktywować uśpienie programatora naciskamy najpierw switch S1-RESET, a następnie przez chwilę przytrzymujemy S6-IC1 SLEEP. Diody: PMODE, HBEAT, ERROR powinny na chwilę zamrugać, a następnie razem z diodami BTLDR i PROGR nie powinny się zapalić. Wtedy programator jest uśpiony. W zależności od potrzeb i upodobań danego użytkownika, przygotowałem kilka różnych wersji zmodyfikowanego sketcha ArduinoISP. Mamy do dyspozycji z przytrzymywaniem switcha S2-SELECT na czas wgrywania bootloadera, z trybem uśpienia jak i bez, oraz bez przytrzymywania switcha S2-SELECT bez funkcji uśpienia. W tej wersji urządzenia, zaraz po zmontowaniu potrzebujemy 1szt. procesora z wgranym już bootloaderem, który będzie pełnił rolę programatora ISP - IC1. Najlepiej niech to będzie ATmega8, ze względu na fakt, że jest to do dziś najtańszy procesor oraz ilość pamięci jaką posiada jest wystarczająca do wgrania skecza ArduinoISP. Sam skecz wykorzystuje około 60% pamięci tego procesora. W poprzedniej wersji urządzenia aby wgrać skecz ArdunoISP, trzeba było najpierw ten procesor umieścić w podstawce IC2. Teraz można umieścić go bezpośrednio w podstawce IC1, dzięki czemu nie ma konieczności przekładania go - niekiedy dość upierdliwa czynność. Po włożeniu procesora do podstawki IC1, zakładamy zworkę na piny IC1PROGR. Zapala na się dioda LED IC1-PROGR. Włączamy środowisko Arduino IDE. O tym jak powinno być ono skonfigurowane dla danej wersji procesora i jak wgrać skecz do procesora opisałem w artykule: https://forbot.pl/forum/topic/19357-mwuinouno-bootloader-programmer-i-arduino-w-jednym/ Aby ułatwić szukanie opisu wgrywania skeczy, szukamy podtytuł (pogrubiona czcionka) "Tak więc:" i w tekście poniżej-siódma linijka tekstu, od zdania zaczynającego się od słów "Dla przykładu". Oczywiście zamiast switcha S2 używamy switch S1 i podstawka IC2 używamy IC1. Tutaj jak widać procesor IC1 musimy zresetować ręcznie switchem S1. Na początku myślałem aby to było robione z układu FTDI232RQ, ale w sumie nikt nie będzie często przeprogramowywał tego procesora ewentualnie raz na jakiś czas o ile zajdzie taka potrzeba, a obwód to raz, że więcej elementów, niepotrzebny koszt i stopień komplikacji urządzenia. Chyba lepsze jest aktualne rozwiązanie. Łatwiej jest raz na jakiś czas przed programowaniem nacisnąć przycisk reset niż bawić się w przekładanie procesora z podstawki do podstawki. Gdybyśmy nie mieli zworki tylko przewód połączeniowy, to jeden koniec przewodu podłączamy do pinu VCC a drugi do pinu złącza IC1PROGR oznaczonego kropką. Oczywiście dla urządzenia z układem FTDI232RQ. w momencie wgrywania skecza do procesora IC2 przed wgraniem następuje jego RESET jak to ma miejsce w platformie UNO i jej klonach. W przypadku wersji wymagającej podłączenia zewnętrznego konwertera jest to uzależnione właśnie od posiadanego przez nas konwertera, czy może on resetować procesor przed wgraniem skecza. Zatem jak widać bazowałem przede wszystkim na rozwiązaniach niespotykanych w oryginalnej platformie, a niektórych klonach tej platformy. Mimo wszystko jest też kilka moich pomysłów oraz co najważniejsze i trudne to zaprojektować PCB tak aby te rozwiązania mogły być zintegrowane oraz samo urządzenie możliwie zbliżone do wymiarów oryginalnej platformy UNO. Jak widać wiązało się to z pewnymi zmianami takimi jak inny układ pinów gniazd procesora IC2. Nie podłączymy co prawda do nich shieldów czyli nakładek zwiększających możliwości naszego urządzenia, lecz dzięki bliskości tych złącz, łącząc układ na płytce stykowej powinny nam wystarczyć przewody jednakowej długości, aby wykorzystać wszystkie piny procesora. Wiedzmy też, że prócz shieldów możemy też kupić funkcjonalne moduły na mniejszych PCB niż zaprojektowane shieldy i przy pomocy przewodów połączeniowych podłączyć je do urządzenia. Tak więc pomimo niestandardowego układu wyprowadzeń, dalej jesteśmy w stanie zbudować potrzebne nam urządzenie. Niewielką rekompensatą tego rozwiązania jest umieszczenie dodatkowych złączy w wersji męskiej. Dzięki czemu możemy stosować przewody połączeniowe z końcówka męską lub żeńską. Jednak postanowiłem jeszcze oprócz samego urządzenia i korzystając z tego, że JLCPB ceny są dość atrakcyjne, zaprojektować trzy nakładki do swojego urządzenia. Pierwsza "adapter shield" to nakładka, która umożliwia przejście z niestandardowego układu pinów mojej wersji platformy uno, na układ pinów zgodny z oryginalną platformą, dzięki czemu można używać dedykowanych shieldów. Zauważyłem, że niektóre shieldy mają dodatkowo złącze ICSP w wersji żeńskiej do podłączenia, jako że nie posiadam takiego shielda, nie jestem w stanie określić czy będzie on działać w pełni po podłączeniu do adapter shield. Jeżeli nie to pozostaje tylko skorzystać modułu w postaci PCB podłączanego do pinów przewodami połączeniowymi. Tak jak mamy na przykład ethernet shield oraz moduł ethernet w postaci małej płytki PCB z wyprowadzeniami podłączanymi przewodami połączeniowymi. To co wyróżnia się najbardziej to otwory na PCB, umieszczone nad diodami USB i PWR MwuinoUNO, dzięki czemu nie ma potrzeby stosowania diod LED na nakładce oraz zawsze niewielka, ale oszczędność pobieranego prądu. Mamy również otwory pod przełącznik napięcia 3,3V/5V oraz na włącznik zasilania Co jest widoczne na zdjęciach poniżej. 1. Wszystkie nakładki - strona BOTTOM 2. Nakładka "adapter shield" strona TOP podłączona do MWuinoUNO Drugą nakładką jest sensor shield. Płytka z pinami do podłączeń, sensorów i różnych modułów PCB, pozwalająca tworzyć nam bardziej zaawansowane układy. To co wyróżnia się najbardziej to otwory na PCB, umieszczone nad diodami USB i PWR MwuinoUNO, dzięki czemu nie ma potrzeby stosowania diod LED na nakładce oraz zawsze niewielka, ale oszczędność pobieranego prądu. Shield ten od większości dostępnych dla oryginalnej platformy UNO, posiada filtrację zasilania składającą się z kondensatorów ceramicznych i elektrolitycznych. Dwie pary kondensatorów. W każdej parze kondensator ceramiczny z kondensatorem elektrolitycznym umieszczone w odpowiedniej odległości aby zapewnić odpowiednią filtrację zasilania modułów, czujników itp. Dzięki temu mamy pewność, że nasz projekt będzie działać niezawodnie i stabilnie. Mamy również otwory pod przełącznik napięcia 3,3V/5V oraz na włącznik zasilania Co jest widoczne na zdjęciach poniżej. Nakładka "sensor shield" strona TOP podłączona do MWuinoUNO Trzecią nakładką jest gniazdo procesora, a dokładniej podstawka testowa ZIF. Umożliwia nam ona szybką wymianę procesora, za pośrednictwem dźwigni dociskającej jego piny do styków podstawki. Domyślnie można na PCB dla podstawki zamontować rezonator kwarcowy z kondensatorami i używać jej kiedy mamy do zaprogramowania dużą ilość procesorów. Możemy także na niej zamontować dodatkowo kondensatory filtrujące zasilanie, dławik, rezystor oraz switch do pinu reset. Mamy tym samym spełnione minimalne podłączenie procesora i możemy podpiąć przewodami połączeniowymi jakiś prosty moduł celem sprawdzenia jego działania z procesorem. Możemy też do jego gniazd włożyć listwę kołkową męską i wystające piny listwy wpiąć na płytkę stykową, nie podłączając elementów wymaganych do samej pracy procesora a podłączać tylko te którymi nasz procesor ma sterować lub te, które mają dostarczać sygnały do niego. Nakładka IC2 socket adapter strona TOP podłączona do MWuinoUNO Na zakończenie dodam, że jest to już ostatni artykuł z serii o Arduino UNO, gdzie starałem przedstawić się zalety jak i swoją wizję tej platformy. Następne moje projekty będą się tyczyć urządzeń zbudowanych a oparciu o platformę UNO. Mam nadzieję, że wszystkie informację, które do tej pory przedstawiłem okazały się pomocne, szczególnie dla osób początkujących, które zdecydowały się na wybór Arduino UNO jako platformy, z którą zaczynają naukę programowania i budowania urządzeń. Plik do pobrania: MWuinoUNO.zip W pliku tym znajdziemy dokumentację oraz wszystkie niezbędne pliki, gdybyśmy chcieli wykonać urządzenie, w tym skecze ArduinoISP do zaprogramowania IC1, a nawet sterownik dla układu FTDI232RQ dla WIN10.

Witam serdecznie, potrzebuję małej pomocy przy przerwaniach programując ESP32 przy pomocy Arduino IDE. Chciał bym liczyć ilość wciśnięć przycisku za pomocą przerwań. Po wciśnięciu przycisku wyświetla się napis że przycisk został wciśnięty. Jednak po puszczeniu przycisku ponownie wyświetlany jest komunikat o wciśnięciu przycisku. Fizycznie przycisk został wciśnięty 7 razy a wyświetla się że był wciśnięty 14 razy. Może ktoś ma pomysł jak rozwiązać wskazany problem? #define DEBOUNCE_TIME 250 volatile uint32_t DebounceTimer = 0; #define PIN_BUTTON 12 uint32_t button_count = 0; void IRAM_ATTR buttonpressed() { if ( millis() - DEBOUNCE_TIME >= DebounceTimer ) { DebounceTimer = millis(); button_count += 1; Serial.printf("Przycisk wciśnięty %u razy.\n", button_count); } } void setup() { Serial.begin(115200); pinMode(PIN_BUTTON, INPUT_PULLUP); attachInterrupt(PIN_BUTTON, buttonpressed, FALLING); } void loop() { }

Cześć Minęło już sporo czasu odkąd kolega deshipu opublikował bardzo ciekawy i inspirujący artykuł traktujący o Micropython. https://forbot.pl/forum/topic/8588-micropython-na-esp8266/?tab=comments#comment-88039 Przez ten czas spora część entuzjastów elektroniki, programowania, majsterkowiczów no i czytelników Forbota wszak, zaznajomiła się przynajmniej na przyzwoitym poziomie z możliwościami zastosowania mikroprocków AVR w swoich projektach. Powstawały przy tym mniej lub bardziej udane konstrukcje, które cieszyły, zaskakiwały i rozwijały twórczo, cokolwiek to oznacza. Jeśli w tym czasie miałem jakiś niedosyt, czy poczucie, że czegoś tu jeszcze brakuje, że można zrobić coś lepiej, coś zmienić lub rozbudować, to tylko z korzyścią dla siebie i dla nas samych, bo chyba nie piszę tu tylko o sobie, prawda? Podstawowy moduł Arduino R3, jakkolwiek bardzo przydatny i udany projekt z czasem zrobił się ciut niewystarczający. Brakowało komunikacji, ta szeregowa, I2C czy SPI to za mało. Apetyt rośnie w miarę jedzenia. Przydałby się Ethernet (powstawały nakładki z modułem Ethernet, samodzielne moduły np. Arduino Yun), przydałaby się sieć WiFi (np. WiDo moduł WiFi WG1300). Jeśli dysponujesz wolnym czasem i kwotą około 30 zł. do wykorzystania, to proponuję zakupić jeden z dostępnych modułów, opartych na ESP32 / ESP8266 i zacząć zabawę z alternatywnym IDE, jakim jest Thonny (z wbudowanym Pythonem), zamiast IDE z Arduino i gcc. Jest w internecie sporo gotowych poradników i rozwiązań opartych na programowaniu modułów ESP za pomocą IDE Arduino, natomiast stosunkowo niewiele można znaleźć o Micropythonie. Znam C i C++(przynajmniej z czasów kiedy wręcz obowiązkową pozycją była "Symfonia C++" Grębosza), poznanie i przyswojenie innych języków, C#, Javy czy shell-a Bash nie sprawia mi szczególnych trudności. Czas zatem zabrać się za Pythona i poznać dla niego konkretne zastosowania praktyczne. Język Python jest stosunkowo prosty i wręcz intuicyjny, sprawia, że można w miarę szybko opanować jego podstawy przynajmniej w zakresie zastosowań do programowania mikrokontrolerów. Mikropython z kolei jest własnie tym czego potrzebujemy. To minimalny, niezbędny podzbiór języka Python, gdzie umieszczono szereg narzędzi i modułów do sterowania i komunikacji z mikrokontrolerami. Przyznaje, że początkowo dość sceptycznie podchodziłem do Pythona, ze względu na wcześniejsze przyzwyczajenia co do deklaracji typów dla obiektów w C, zmiennych tablic i w ogólności składni, a tutaj jest dużo prościej i przejrzyściej, przynajmniej w tym zakresie jaki akurat jest mi potrzebny na tym etapie. Nie chciałbym przy tym rozpoczynać dyskusji na temat wyższości jednego języka nad drugim. Kieruje się tylko chęcią poznania nowego języka i alternatywnych narzędzi dla programowania mikrokontrolera. Micropython to minimalny podzbiór... tylko tyle ile jest niezbędne i tylko tyle aby zostawić dla nas jak najwięcej miejsca w pamięci takiego procka. Tak, micropython flashujemy (wgrywamy)na nasz procek i cały system wraz z szeregiem niezbędnych modułów i poleceń. Trochę to przypomina znaną już malinkę (raspberry pi), gdzie instaluje się jedną z dystrybucji linuxa i mamy tam pełnoprawny system operacyjny w dużym pudełku zapałek. Micropython i ESP32/8266 w dużym uproszczeniu przypomina nieco dystrybucję minilinux z wbudowanym micropythonem. (czy ten osioł przypomina nieco kurę? CK Dezerterzy) Jak zacząć? Sporo się zmieniło na plus przez te kilka lat istnienia micropythona. W necie można znaleźć kilka wartościowych poradników jak zainstalować (flashować) procesory... większość zaczyna od instalacji Pythona, potem niezbędnych narzędzi (pip, esptool, ampy, potem jakiegoś środowiska/edytora IDE dla Pythona), co w konsekwencji robi się nieco flustrujące. Dobra wiadomość jest taka, że nie musimy już tego wszystkiego robić. Wystarczy pobrać i zainstalować Thonny IDE dla Pythona. Thonny w wersji 3.2.7 pobierzemy stąd: https://www.downloaddrivers.info/download-thonny-3-2-7/ , przewijamy okno w dół i mamy niebieski odnośnik: Rozpakowujemy pobrane archiwum zip i instalujemy program. Przy instalacji warto ustawić skrót do aplikacji na pulpicie. Na chwilę obecną dysponuję modułem ESP-WROOM-32, dostępnym np. w https://botland.com.pl/pl/moduly-wifi/8893-esp32-wifi-bt-42-platforma-z-modulem-esp-wroom-32-zgodny-z-esp32-devkit.html?search_query=esp32&results=65 , ale nic nie stoi na przeszkodzie aby wykorzystać dowolny moduł oparty na ESP32/8266. Na tym etapie dobrze jest wybrać taki z wbudowanym gniazdem USB, bowiem będziemy mogli bezpośrednio wpinać go do naszego komputera i programować/komunikować się z modułem w locie. Podpinamy nasz moduł kablem USB (powinien wykryć nasz moduł i przypisać do niego nr portu COM). Odpalamy Thonny IDE, i z menu wybieramy Uruchom->Wybierz Interpreter: a tam MicroPython (ESP32) i wybieramy nasz rozpoznany port COM. Następnie musimy pobrać obraz naszego systemu, aby wgrać go do naszego ESP32. Wchodzimy na stronę http://micropython.org i pobieramy z zakładki Download najbardziej odpowiedni obraz dla naszego modułu. Dla nas jest to Generic ESP32 Module i poniżej z listy Firmware with ESP-IDF v3.x wybieramy najlepiej najnowszą stabilną wersję (ja wybrałem esp32-idf3-20200902-v1.13.bin, czyli tą stabilna, bez słowa unstable w nazwie). Po pobraniu pliku obrazu .bin klikamy w Thonny na opcję menu Uruchom->Wybierz Interpreter ... i tam w pole : Otwórz okno dialogowe instalacji lub aktualizacji MicroPython... następnie wybieramy port i ścieżkę z naszym pobranym właśnie plikiem .bin. Klikamy Install Po chwili powinna rozpocząć się procedura flashowania naszego modułu. Uwaga... jeśli program zgłosi niepowodzenie uruchom ponownie Install przytrzymując na chwilę przycisk Reset w naszym module. Po flashowaniu zamykamy aktywne okno. Resetujemy ponownie moduł, zaś w polu Powłoki mamy znak zachęty naszego micropythona: >>> To oznacza, że możemy zacząć zabawę z micropythonem. Okno Thonny składa się z 2 głównych okien - okno powłoki i okno edytora. W górnym oknie możemy tworzyć/edytować skrypty Pythona, a w dolnym - i tu niespodzianka mamy dostęp do powłoki shell naszego micropythona. Czym szczególnym wyróżnia się ta powłoka? Ano możemy bezpośrednio komunikować się z naszym modułem i wydawać mu polecenia do wykonania, niejako adhoc, czyli w locie!!! Nie trzeba tak jak w Arduino najpierw kompilować całego programu aby zobaczyć w monitorze portu szeregowego "Hello World".... tutaj po prostu po znaku zachęty >>> napisz: print('Hello World') ... i tyle - poniżej otrzymasz odpowiedź z ESP32 Dobra... nie masz pewności czy aby procek odpowiada (bo może to robić sam Thony), więc zrób to: wpisz po znaku zachęty po kolei te linie:(po każdej daj Enter) import machine led = machine.Pin(2, machine.Pin.OUT) led.on() led.off() Będziesz teraz zapalał i gasił wbudowaną diodę Led. Powłoka zapamiętuje wpisane wcześniej polecenia, więc możesz klawiszami strzałka góra/dół wracać do nich, bez konieczności ponownego wpisywania z palucha poleceń. Więcej o możliwościach Thonny doczytasz w Necie. Na chwilę obecną wystarczy zaznajomić się z możliwościami powłoki Micropythona. Planuję kolejny post w tematyce mikropythona, gdzie umieszczę swoje zmagania z tym nowym i dla mnie tematem. W szczególności ciekawy jest proces bootowania (uruchamiania) takiego ESP z wgranym micropythonem, do czego służą pliki boot.py i main.py , jak dodać i wgrać do procka własny skrypt/moduł .py do struktury katalogów i jak z niego korzystać. Kolejne tematy, z którymi ostatnio byłem za pan brat, (całość za pomocą micropythona - czyli alternatywa do tego co już można zrobić za pomocą Arduino IDE) : podpięcie do sieci WiFi, server i klient pobranie akt. czasu (RTC, time, utime) korzystanie z Telegram Bot przy pomocy micropythona i modułu urequests tryb głębokiego uśpienia (deep sleep mode) dla jednego (ext0) i wielu pinów (ext1) własny moduł/biblioteka użytecznych funkcji Pozdrawiam i zachęcam do zabawy z micropythonem, nie zaszkodzi Wielkie dzięki dla kol. deshipu !

Mam problem. Od dwóch dni próbuję stworzyć program, który będzie wyświetlał różne animacje. Chciałbym wrzucić kilka animacji do jednego programu, by móc potem zmieniać je poprzez naciśnięcie przycisku. Zaznaczam, że dopiero się uczę Arduino i jeżeli robię jakiś błąd posłucham rady od was. Podczas włączania animacji program nie chce jej odtworzyć, puszcza tylko jedną sekwencję. Chodzi o tryb 2. Trzeba użyć pętli? Jak tak to jak ją napisać? #include "FastLED.h" int buttonPin = 2; bool state = 0; int tryb = 0; //////////////////////////////////////////////////////////////////////////////////////////////////// // // RGB Calibration code // // Use this sketch to determine what the RGB ordering for your chipset should be. Steps for setting up to use: // * Uncomment the line in setup that corresponds to the LED chipset that you are using. (Note that they // all explicitly specify the RGB order as RGB) // * Define DATA_PIN to the pin that data is connected to. // * (Optional) if using software SPI for chipsets that are SPI based, define CLOCK_PIN to the clock pin // * Compile/upload/run the sketch // You should see six leds on. If the RGB ordering is correct, you should see 1 red led, 2 green // leds, and 3 blue leds. If you see different colors, the count of each color tells you what the // position for that color in the rgb orering should be. So, for example, if you see 1 Blue, and 2 // Red, and 3 Green leds then the rgb ordering should be BRG (Blue, Red, Green). // You can then test this ordering by setting the RGB ordering in the addLeds line below to the new ordering // and it should come out correctly, 1 red, 2 green, and 3 blue. // ////////////////////////////////////////////////// #define NUM_LEDS 10 // For led chips like WS2812, which have a data line, ground, and power, you just // need to define DATA_PIN. For led chipsets that are SPI based (four wires - data, clock, // ground, and power), like the LPD8806 define both DATA_PIN and CLOCK_PIN // Clock pin only needed for SPI based chipsets when not using hardware SPI #define DATA_PIN 7 #define CLOCK_PIN 13 CRGB leds[NUM_LEDS]; void setup() { // sanity check delay - allows reprogramming if accidently blowing power w/leds delay(2000); Serial.begin(57600); Serial.println("resetting"); LEDS.setBrightness(10); pinMode(buttonPin, INPUT_PULLUP); pinMode(LED_BUILTIN, OUTPUT); // Uncomment/edit one of the following lines for your leds arrangement. // ## Clockless types ## // FastLED.addLeds<SM16703, DATA_PIN, RGB>(leds, NUM_LEDS); // FastLED.addLeds<TM1829, DATA_PIN, RGB>(leds, NUM_LEDS); // FastLED.addLeds<TM1812, DATA_PIN, RGB>(leds, NUM_LEDS); // FastLED.addLeds<TM1809, DATA_PIN, RGB>(leds, NUM_LEDS); // FastLED.addLeds<TM1804, DATA_PIN, RGB>(leds, NUM_LEDS); // FastLED.addLeds<TM1803, DATA_PIN, RGB>(leds, NUM_LEDS); // FastLED.addLeds<UCS1903, DATA_PIN, RGB>(leds, NUM_LEDS); // FastLED.addLeds<UCS1903B, DATA_PIN, RGB>(leds, NUM_LEDS); // FastLED.addLeds<UCS1904, DATA_PIN, RGB>(leds, NUM_LEDS); // FastLED.addLeds<UCS2903, DATA_PIN, RGB>(leds, NUM_LEDS); // FastLED.addLeds<WS2812, DATA_PIN, RGB>(leds, NUM_LEDS); // GRB ordering is typical // FastLED.addLeds<WS2852, DATA_PIN, RGB>(leds, NUM_LEDS); // GRB ordering is typical FastLED.addLeds<WS2812B, DATA_PIN, RGB>(leds, NUM_LEDS); // GRB ordering is typical // FastLED.addLeds<GS1903, DATA_PIN, RGB>(leds, NUM_LEDS); // FastLED.addLeds<SK6812, DATA_PIN, RGB>(leds, NUM_LEDS); // GRB ordering is typical // FastLED.addLeds<SK6822, DATA_PIN, RGB>(leds, NUM_LEDS); // FastLED.addLeds<APA106, DATA_PIN, RGB>(leds, NUM_LEDS); // FastLED.addLeds<PL9823, DATA_PIN, RGB>(leds, NUM_LEDS); // FastLED.addLeds<SK6822, DATA_PIN, RGB>(leds, NUM_LEDS); // FastLED.addLeds<WS2811, DATA_PIN, RGB>(leds, NUM_LEDS); // FastLED.addLeds<WS2813, DATA_PIN, RGB>(leds, NUM_LEDS); // FastLED.addLeds<APA104, DATA_PIN, RGB>(leds, NUM_LEDS); // FastLED.addLeds<WS2811_400, DATA_PIN, RGB>(leds, NUM_LEDS); // FastLED.addLeds<GE8822, DATA_PIN, RGB>(leds, NUM_LEDS); // FastLED.addLeds<GW6205, DATA_PIN, RGB>(leds, NUM_LEDS); // FastLED.addLeds<GW6205_400, DATA_PIN, RGB>(leds, NUM_LEDS); // FastLED.addLeds<LPD1886, DATA_PIN, RGB>(leds, NUM_LEDS); // FastLED.addLeds<LPD1886_8BIT, DATA_PIN, RGB>(leds, NUM_LEDS); // ## Clocked (SPI) types ## // FastLED.addLeds<LPD6803, DATA_PIN, CLOCK_PIN, RGB>(leds, NUM_LEDS); // GRB ordering is typical // FastLED.addLeds<LPD8806, DATA_PIN, CLOCK_PIN, RGB>(leds, NUM_LEDS); // GRB ordering is typical // FastLED.addLeds<WS2801, DATA_PIN, CLOCK_PIN, RGB>(leds, NUM_LEDS); // FastLED.addLeds<WS2803, DATA_PIN, CLOCK_PIN, RGB>(leds, NUM_LEDS); // FastLED.addLeds<SM16716, DATA_PIN, CLOCK_PIN, RGB>(leds, NUM_LEDS); // FastLED.addLeds<P9813, DATA_PIN, CLOCK_PIN, RGB>(leds, NUM_LEDS); // BGR ordering is typical // FastLED.addLeds<DOTSTAR, DATA_PIN, CLOCK_PIN, RGB>(leds, NUM_LEDS); // BGR ordering is typical // FastLED.addLeds<APA102, DATA_PIN, CLOCK_PIN, RGB>(leds, NUM_LEDS); // BGR ordering is typical // FastLED.addLeds<SK9822, DATA_PIN, CLOCK_PIN, RGB>(leds, NUM_LEDS); // BGR ordering is typical } void fadeall() { for(int i = 0; i < NUM_LEDS; i++) { leds[i].nscale8(250); } } void loop() { if(digitalRead(2) == HIGH ) // Jezeli wcisniemy przycisk podlaczony pod pin nr 2 { if(tryb != 2) tryb++; else tryb = 0; while(digitalRead(2) == HIGH); } if(tryb == 0) { leds[0] = CRGB(255,0,0); leds[1] = CRGB(255,0,0); leds[2] = CRGB(255,0,0); leds[3] = CRGB(255,0,0); leds[4] = CRGB(255,0,0); leds[5] = CRGB(255,0,0); leds[6] = CRGB(255,0,0); leds[7] = CRGB(255,0,0); leds[8] = CRGB(255,0,0); leds[9] = CRGB(255,0,0); FastLED.show(); delay(1); } if (tryb == 1) { leds[0] = CRGB(255,0,0); leds[1] = CRGB(0,255,0); leds[2] = CRGB(0,0,255); leds[3] = CRGB(0,255,0); leds[4] = CRGB(0,0,255); leds[5] = CRGB(0,0,255); leds[6] = CRGB(255,0,0); leds[7] = CRGB(0,0,255); leds[8] = CRGB(0,255,0); leds[9] = CRGB(0,0,255); FastLED.show(); delay(1); } if(tryb == 2) { static uint8_t hue = 0; Serial.print("x"); // First slide the led in one direction for(int i = 0; i < NUM_LEDS; i++) { // Set the i'th led to red leds[i] = CHSV(hue++, 255, 255); // Show the leds FastLED.show(); // now that we've shown the leds, reset the i'th led to black // leds[i] = CRGB::Black; fadeall(); // Wait a little bit before we loop around and do it again delay(10); } Serial.print("x"); // Now go in the other direction. for(int i = (NUM_LEDS)-1; i >= 0; i--) { // Set the i'th led to red leds[i] = CHSV(hue++, 255, 255); // Show the leds FastLED.show(); // now that we've shown the leds, reset the i'th led to black // leds[i] = CRGB::Black; fadeall(); // Wait a little bit before we loop around and do it again delay(10); } } }

Dzień dobry, Posiadam Arduino UNO. Za pomocą tej płytki robiłem zamieszczony tutaj kurs dla początkujących. Przy pierwszym podłączeniu wszystko było ok. Zrobiłem kilka części kursu(zatrzymałem się na LCD). Problem, jaki pojawił się w pewnym momencie to brak możliwości zaprogramowania płytki poprzez port USB, używając do tego dedykowanego środowiska (ver. 1.8.12). Pracuję na Win10. Sprawdziłem ustawienia i połączenia: 1. Menedżer urządzeń rozpoznaje płytkę -> Porty->Arduino Uno(Com4) 2. W środowisku mam wybrane: płytkę Arduino UNO, port COM4 programator AVRISP mkii Na powyższych ustawieniach pracowałem do tej pory. Wszystko zasilane z USB, ewentualnie z zewnętrznego zasilacza(kurs o serwomechanizmie). Zasilanie sygnalizowane przez zieloną diodę. Zanim napisałem ten post, poczytałem forum odnośnie takich przypadków. W większości ten problem to skasowany bootloader. Zaznaczam, że do programowania płytki używałem tylko połączenia USB(nie posiadam zewnętrznego programatora). Sprawdziłem też inny przewód USB. Postanowiłem też kupić procesor z wgranym już bootloaderem. Po zmianie procesora, problem nadal istnieje. Błąd jaki otrzymuję to: Czy ktoś z Forumowiczów spotkał się z takim problemem? Pozdrawiam, Łukasz

Witam Z góry dziękuję z wszelką pomoc! Na podstawie pewnego projektu z internetu (Ten projekt, tyle że bardzo skrócony. Oryginał też na tej stronie tylko że po Turecku). Program działa na zasadzie zainstalowanej biblioteki do Winamp która wysyła rożne sygnały poprzez port szeregowy. Następnie program w Arduino odczytuje je i w odpowiedni sposób interpretuje. Wizualizacja odbywa się na ekranie LCD 16x2. Ja do własnych celów, do innego projektu chciałbym aby zamiast wyświetlania się danych na ekranie informacje z każdego "słupka" były zapisywane i aktualizowane w "int-ach". Czyli np. pierwszy słupek od lewej int1, następny int2 i tak dalej. Jeśli ktoś pomógłby mi w tym byłbym bardzo wdzięczny. Dodam jeszcze że oryginalny projekt działa u mnie (wszystko zainstalowane poprawnie, chodzi mi tylko o przerobienie programu). Link do stron: https://hase85.wordpress.com/2013/09/25/16x2-lcd-spectrum-analyzer-plugin-for-winamp/ Kod arduino: /* CrownSoft LCD Spectrum Analyzer Interface (c) 2013 CrownSoft Inc. a level-1 b level-2 c level-3 d level-4 e level-5 f level-6 g level-7 h level-8 i set cursor & draw char j set cursor & draw level k clear screen examples: i00H first col first row set 'H' j01b first col second row set level-2 k clear all */ #include <LiquidCrystal.h> LiquidCrystal lcd(12, 11, 5, 4, 3, 2); byte custChars[8][8] = { {B00000, B00000, B00000, B00000, B00000, B00000, B00000, B11111}, {B00000, B00000, B00000, B00000, B00000, B00000, B11111, B11111}, {B00000, B00000, B00000, B00000, B00000, B11111, B11111, B11111}, {B00000, B00000, B00000, B00000, B11111, B11111, B11111, B11111}, {B00000, B00000, B00000, B11111, B11111, B11111, B11111, B11111}, {B00000, B00000, B11111, B11111, B11111, B11111, B11111, B11111}, {B00000, B11111, B11111, B11111, B11111, B11111, B11111, B11111}, {B11111, B11111, B11111, B11111, B11111, B11111, B11111, B11111} }; byte serial_getch() { while (Serial.available() == 0); return Serial.read(); } void setup() { Serial.begin(19200); lcd.begin(16, 2); lcd.clear(); // create custom characters for(int i=0;i<8;i++) { lcd.createChar(i, custChars[i]); } /* for(int i=0;i<8;i++) { lcd.setCursor(i,0); lcd.write(i); }*/ } void loop() { byte rxbyte = serial_getch(); if(rxbyte=='j') // set cursor & draw level { lcd.setCursor(serial_getch()-'0',serial_getch()-'0'); lcd.write((uint8_t)(serial_getch()-'a')); }else if(rxbyte=='i') // set cursor & draw char { lcd.setCursor(serial_getch()-'0',serial_getch()-'0'); lcd.write((char)serial_getch()); }else if(rxbyte=='k') // clear { lcd.clear(); } } Pozdrawiam Piotrek

Witam, na wstępie przepraszam, jeśli podobny temat już był, sam jednak nie mogłem znaleźć tego o co mi chodzi. Mój problem wygląda tak. Podczas jednego z kursów Arduino na Forbocie prawdopodobnie zepsułem swój mikroprocesor. Środowisko pokazuje, że kod został wgrany bez problemów lecz nie wykonuje się on, a na płytce prototypowej miga dioda z podpisem "L". Na szczęście mam drugą atmegę328, lecz kupiłem wersję bez bootloadera ponieważ była tańsza, a sam chciałem wypalić loader przy pomocy Arduino. Teraz skoro atmega nie działa zastanawiam się nad kilkoma opcjami. 1. Kupno nowej atmegi z bootloaderem i wypalenie bootloadera na drugiej. 2. Kupienie programatora. W przypadku programatora mam kilka pytań. Czy przy pomocy programatora da się w jakiś sposób wypalić bootloader na czystej atmedze? Jakiego rodzaju programator byłby dobry na początek i czy potrzeba do niego jakieś szczególne sterowniki (nie ukrywam, że wolałbym mieć coś kompatybilnego z linuxem, ponieważ używam praktycznie tylko tego systemu). Jeśli miałbym programator, to jak wygląda pisanie kodu w czystym C na atmegę? Czy istnieją alternatywne środowiska do Atmel Studio, które działają na systemie z pingwinem? Z góry dziękuje za wszelkie odpowiedzi i pozdrawiam!