STM32F3 Discovery. ESP8266

[MasteR_PuppetS]

Witam.

Docelowo zamierzam sterować z komputera dwoma silnikami podłączonymi do STM32 za pomocą modułu WiFi ESP8266.

Na razie jednak nie potrafię nawet nawiązać komunikacji modułu z STM32.

Może ktoś również korzystał z tego modułu i mógłby przedstawić przykładowy program?

Albo chociaż jakąś wskazówkę - gdzie szukać.

Byłbym wdzięczny za wszelką pomoc.

Pozdrawiam.

[deshipu]

ESP8266 daje się programować bezpośrednio i nie potrzeba do niego dodatkowych mikrokontrolerów. Ostatnio nawet jest opcja programowania go bezpośrednio z Arduino IDE, więc chyba łatwiej być nie może.

Osobiście mam doświadczenie w programowaniu tych modułów za pomocą lua i micropythona.

Którą wersję modułu masz? Jak go podłączasz? W czym dokładnie leży problem?

[MasteR_PuppetS]

Posiadam tylko plytke stm32f3 discovery. Istnieje mozliwosc programowania go za pomoca tejze?

Posiadam (chyba) ta najbardziej podstawowa wersje. 8 pinow

Tx do Rx, Rx do Tx, GND, VCC, CH_PD i RESET do VCC przez rezystor 9k. GPIO0 i GPIO2 niepodlaczone.

Probuje napisac program:

#include "stm32f30x.h"
#include "stm32f3_discovery.h"
#include "stm32f30x_tim.h"
#include <string.h>
#include <stdio.h>
#include <stdlib.h>

GPIO_InitTypeDef  GPIO_InitStructure;
USART_InitTypeDef usartConfig;

void SendString(char *s)
{
 while(*s)
 {
   while(USART_GetFlagStatus(USART1, USART_FLAG_TXE) == RESET);

   USART_SendData(USART1, *s++);
 }
}

int main(void)
{
RCC_AHBPeriphClockCmd(RCC_AHBPeriph_GPIOA, ENABLE);

GPIO_PinAFConfig(GPIOA, GPIO_PinSource9, GPIO_AF_7);
GPIO_PinAFConfig(GPIOA, GPIO_PinSource10, GPIO_AF_7);

GPIO_InitStructure.GPIO_Pin = GPIO_Pin_9 | GPIO_Pin_10;
GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AF;
GPIO_InitStructure.GPIO_OType = GPIO_OType_PP;
GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
GPIO_InitStructure.GPIO_PuPd = GPIO_PuPd_NOPULL;
GPIO_Init(GPIOA, &GPIO_InitStructure);

RCC_APB2PeriphClockCmd(RCC_APB2Periph_USART1, ENABLE);
USART_Cmd(USART1, ENABLE);

usartConfig.USART_BaudRate = 9600;
usartConfig.USART_WordLength = USART_WordLength_8b;
usartConfig.USART_StopBits = USART_StopBits_1;
usartConfig.USART_Parity = USART_Parity_No;
usartConfig.USART_Mode = USART_Mode_Rx | USART_Mode_Tx;
usartConfig.USART_HardwareFlowControl = USART_HardwareFlowControl_None;

USART_Init(USART1, &usartConfig);

SendString("AT\n");

SendString("ATB\n");

       while(1)
   {
   }
}

I nie wiem, czy to co napisalem jest poprawne, oraz nie wiem jak poczynic dalsze postepy.

[deshipu]

Chyba najwygodniej jest eksperymentować używając USB2TTL, ja mam to jako osobne urządzenie, ale jestem pewien, że możesz zaprogramować tą płytkę discovery żeby się zachowywała podobnie. Niestety nie wiem jak, bo z STM32 mam styczność na razie bardzo małą. Można takie urządzenie też po prostu kupić za jakieś 2 dolary, tylko upewnij się, że to, co kupujesz, ma opcję 3.3V.

Jak już masz USB2TTL, to masz kilka opcji.

1. Możesz używać domyślnie wgranego firmware-u, który reaguje na komendy AT jak w twoim przykładzie. Z tym, że chyba działa na 115200 a nie 9600, i wymaga "\r\n" na koncu linii, a nie tylko "\n". Z parsowaniem odpowiedzi jest trochę zabawy, ale da się.

2. Możesz tam wgrać inny gotowy firmware. Ja na przykład używam Nodemcu, który pozwala mi pisać programy w postaci skryptów LUA i wgrywać te programy na płytkę. Wtedy możesz napisać program, który słucha na jakimś porcie i steruje twoimi silnikami bezpośrednio, albo przekazuje komendy do tych silników po serialu albo I²C do innej płytki. Ten moduł, który masz, jest dosyć biedny, bo do wykorzystania masz tylko 4 GPIO (TX i RX też można wykorzystać jako GPIO), ale może to wystarczy do sterowania podwójnym mostkiem H. Nodemcu z tego co pamiętam ma wbudowane tylko 3 kanały PWM, ale to powinno ci wystarczyć.

3. Możesz zaprogramować tę płytkę sam, używając publicznie dostępnego toolchaina albo po prostu Arduino IDE. I wtedy znowu masz dwie możliwości, sterować silnikami bezpośrednio albo komunikować się z inną płytką.

[Polecacz 101]

Produkcja i montaż PCB - wybierz sprawdzone PCBWay!
   • Darmowe płytki dla studentów i projektów non-profit
   • Tylko 5$ za 10 prototypów PCB w 24 godziny
   • Usługa projektowania PCB na zlecenie
   • Montaż PCB od 30$ + bezpłatna dostawa i szablony
   • Darmowe narzędzie do podglądu plików Gerber
Zobacz również » Film z fabryki PCBWay

[Chumanista]

Szczerze nie polecam NodeMCU do sterowania silnikami. A właściwie do niczego gdzie czas ma znaczenie. To jest LUA, język interpretowany, najprostsze rzeczy zajmują setki jak nie tysiące cykli (włączenie timera to 20mln cykli o ile dobrze pamiętam).

[deshipu]

Szczerze nie polecam NodeMCU do sterowania silnikami. A właściwie do niczego gdzie czas ma znaczenie. To jest LUA, język interpretowany, najprostsze rzeczy zajmują setki jak nie tysiące cykli (włączenie timera to 20mln cykli o ile dobrze pamiętam).

O nie! To straszne! Taki silnik potrafi się w tym czasie obrócić prawie o 0.0001°! A do tego przez WiFi, z którego pochodzi sygnał sterujący, w tym czasie zostanie przesłane dodatkowe pół bita!

PWM jest na sprzętowym timerze, więc nie widze problemu. Nie przesadzajmy.

[Chumanista]

Jeśli przez pół sekundy twój silnik obraca się o 0.0001° to powinieneś zastosować inny moduł. ESP8266 nie jest certyfikowanie do użytku w sterownikach płyt tektonicznych.

[Bobby]

deshipu, nie podałeś żadnych liczb (oprócz z kosmosu wziętego 0.0001*), natomiast Chumanista pokazał przebiegi jak dla mnie jednoznacznie dyskwalifikujące ten moduł w roli bezpośredniego sterownika silników. IMO sensowność ładowania tam interpretowanego języka jest taka sama jak stawiać Linuxa na AVR, czyli nikła (pomijając aspekt edukacyjny).

[Elvis]

Panowie, nie ma co się tak denerwować. Każde rozwiązanie może być dobre do jednego problemu, a zupełnie nieakceptowalne do innego. Jeśli sterownik działa przez WiFi to na pewno nie działa w czasie rzeczywistym i nie jest (nie powinien) być krytyczny ze względu na bezpieczeństwo. Z WiFi wiadomo jak to bywa, czasem są zakłócenia na kanale, interferencje z innymi urządzeniami, czasem pakiet musi być retransmitowany - i wtedy opóźnienia mogą być całkiem spore.

Z drugiej strony jeśli piszemy aplikację krytyczną ze względu na czas, a może i bezpieczeństwo, nawet pisanie w C może się nie sprawdzić. Czasem prosty z pozoru kod kompilator może przetłumaczyć na różne sposoby (chociażby rozwinąć wywołanie funkcji w miejscu, albo wykonać skok). Kolejna sprawa to operacje bitowe, często mogą być implementowane na różne sposoby, więc kod typu PORTA |= 0x01 może być jedną instrukcją maszynową, albo kilkoma. Wtedy konieczne jest nawet używanie asemblera.

Ale najważniejsze - dobrać rozwiązanie do problemu, a nie odwrotnie. Więc jeśli piszemy program, żeby się czegoś nauczyć, albo to co robimy nie jest krytyczne ze względu na czas (np. jeśli zmienimy prędkość za 5s zamiast za 5ms to i tak nic się złego nie stanie), można spokojne używać rozwiązań wysokopoziomowych, np. obiektowości (Arduino, C++), czy nawet języków skryptowych (Lua, Python, czy Javascript). Najważniejsze to wiedzieć i rozumieć jakie są plusy i minusy każdego rozwiązania.

[deshipu]

Nie podałem liczb, bo ich nie znam. Natomiast używam tego modułu właśnie z Nodemcu do sterowania robotami, zarówno z silnikami jak i z serwomechanizmami i nie zauważyłem mierzalnych opóźnień, stąd podejrzenie, że albo kolega wyssał te "20 milionów cykli" z palca, albo dotyczy ono zupełnie innej specyficznej sytuacji.

Timer ustawia się raz na samym początku, a potem tylko zmienia się wypełnienie na poszczególnych kanałach. Timer robiący PWM jest sprzętowy, więc na jego szybkość nie ma wpływu w jakim języku został ustawiony.

Na koniec linki do moich robotów używających NodeMCU (ten drugi miał silniki przed przebudową):

https://hackaday.io/project/3736-bob-biped-robot

https://hackaday.io/project/3454-trinket-turtle

Oba działają poprawnie i bez widocznych problemów z szybkością sterowania, ale może ja po prostu robię coś źle.

A tak na marginesie, mam też robota zaprogramowanego w Micropythonie, co zapewne też jest dla was kompletnym świętokradztwem. No cóż, czasy się zmieniają i pomału powstają rozsądne narzędzia. Nie ma się co napawać syndromem sztocholmskim.

[Chumanista]

A może zamiast poczucia wyższości nad resztą świata zaczniesz słuchać co cię do Ciebie mówi? No chyba że dane z analizatora stanów logicznych to wysysanie z palce. A, i nie 20mln a ~40mln - 80MHz*0.48. Nabierz trochę pokory, dla własnego dobra.

EDIT: Jakim syndromem sztokcholmskim? Nikt żadnego z nas nie porwał. Ani my nikogo nie porwaliśmy. Nie używaj losowych słów bo to głupio wygląda.

[deshipu]

W tym przykładzie, który tam dałeś, mierzysz prędkość transmisji poleceń przez seriala, który dla NodeMCU, o ile dobrze pamiętam, ma domyślnie prędkość 9600. Nic dziwnego, że wychodzi wolno. Jak robisz takie eksperymenty, to rób je porządnie. Na przykład wrzuć ten kod do funkcji i wykonaj funkcję. Niestety nie mam pod ręką oscyloskopu ani analizatora, żeby pokazać jak to powinno wyglądać.

Co do syndromu sztocholmskiego, to jest to takie zjawisko psychologiczne, w którym ofiara (na przykład osoba, która musiała spędzić lata swego życia używając niewygodnych narzędzi) broni swojego oprawcę (na przykład rzucając się z zębami na wszystkich, którzy zaproponują coś wygodniejszego).

Co do pokory, to mam dość jej dość sporo w stosunku do rzeczywistości. Jeśli coś, co jakaś losowa osoba w Internecie pisze nie zgadza się z obserwowanymi faktami, to albo ta osoba się myli, albo pisze o czymś zupełnie innym, albo mam problem z obserwacją, Dla pewności jeszcze raz sprawdziłem swoje roboty -- działają bez półsekundowych opóźnień, nie przyśniło mi się. Zatem albo się mylisz, albo chodzi ci o zupełnie co innego niż ja zrozumiałem.

A wracając do sedna problemu, czyli sterowania przez WiFi dwoma silnikami (bo to, czy programować w lua czy w C jest nieistotne, skoro można i w jednym i w drugim), to jeszcze przydałoby się wiedzieć do czego te silniki i co mają dokładnie robić, bo to może mieć wpływ na to jak najlepiej nimi sterować.

[Chumanista]

Nope. Te instrukcje nie są wysyłane 1000 razy, NodeMCU je buforuje. Mam to udowodnić? Na prawdę mpżesz przyznać że nie miałeś racji. A o co chodziło z tym syndromem?

EDIT: Mógłbyś nie edytować postów w taki sposób? To sprawia że wyglądasz mało poważnie.

[Harnas]

No ale w czym problem? Timer inicjalizuje sie 0,48 S, a GPIO można zmieniać z częstotliwością prawie 4KHz (0,12ms). Wydaje mi sie prawdopodobne że zapis do rejestrów sprzętowego timera jest tak samo szybki jak do rejestrów GPIO. Czyli można zmieniać prędkość obrotową silnika z minimalnym opóźnieniem.

[Bobby]

Elvis pozamiatał 🙂