ESP8266 LUA PCF8563 RTC prosty przykład

Na szybko napisałem, odczyt danych z RTC PCF8563, może ktoś skorzysta.


wynik działania programu:
22:06:35 01-07-2016

Funkcja zapisu daty i czasu

W funkcji GETtime pierwsze i2c.stop jest zbędne. Nie musisz zatrzymywać transmisji. Wystarczy, że ponowisz warunek startu.

Tego typu szkodliwe wpisy, po winne trafiać do kosza. Producent narzucił pewne zasady i tego należy się trzymać. Można owszem nie zastosować zatrzymania transmisji, ale to dodatkowo skomplikuje aplikację. Wynikiem Twojej bądź co bądź złej sugestii jest taka odpowiedź programu:

dofile('PCF8563A3.lua')
315:715:715 07-115-20715
>

Kolejne efekty jakie da się zauważyć jeśli jest brak poprawnej komunikacji to losowe resety PCF8563.

Nie spiesz się z szafowaniem wyroków. Nie jest to mój wymysł ani złośliwość, tylko zalecenia producenta układu. Załączam Ci screena z noty katalogowej Twojego układu:

Jak widzisz sam producent zaleca wyżej wspomniana metodę. Zresztą jest to powszechnie stosowana metoda w przypadku odczytu po I2C. Jeśli w Twoim przypadku powoduje ona błędną transmisję to najprawdopodobniej masz błędnie zbudowaną funkcję i2c.start.
Źródło grafiki:

Jak wyżej, brak stopu, powoduje losowe resety. W przykładzie podana jest prawidłowa sekwencja i tego należy się trzymać. Jest to przykład otwarty, można go wykorzystać na własne potrzeby, więc jeśli jest Tobie zbędny bit stopu, usuń. Efekty usunięcia Bitu Stop podałem wyżej.

Zapomniałem dodać, że aplikacja nie korzysta z funkcji specjalnych,(bit, math) to też działać będzie na firmware oficjalnym NodeMCU jak i Custom

Dzięki piotr411 za kody z Lua. Proszę o więcej.
Adam

Do czego potrzebujesz kody?

Napisałem apkę na Androida, która ma łączyć się z serwerm na ESP8266.
Teraz zrobiłem to w ten sposób:
Esp ma wsad ai thinker i komunikuje się z apką na Androidzie.
Do esp podłączony jest avr przez uarta a avr steruje przekaźnikiem.
Wczoraj dostałem Link i tu zaczęły się schody bo chcę pozbyć się AVR'a i zastosować tylko Sonoff'a.
Po poszukiwaniach w sieci postanowiłem wgrać NodeMCU i napisać (dopisać do obsługi wifi w tym wsadzie) polecenia w lua które odbiorą mi komendę, sparsują ją i wysterują GPIO do przekaźnika.
A do tego chciałbym by ESP pracował jako AP.
To dopiero drugi dzień szukania info o ESP więc jestem jeszcze zielony i szukam pomocy.

Zacznij od nadania nazwy i hasła:



A tu serwer. W zmiennej d będzie to co wyślesz z Androida


Tu zmiana stanu GPIO :

Do tej pory rozumiem. Dzięki.
Wyczytałem w necie jak czekałem na Twoją odpowiedź, żę funkcja (tmr.delay) nie jest zalecana ze względu na to, że ta funkcja blokuje procesor na czas opóźnienia. Jest na to lepszy sposób, należy użyć funkcji
Zgadasz się z tym?

Analizuję Twój kod i będę pytał dalej.

Tak, tmr wstrzymuje na czas, dalsze działanie. Podałem przykład do sprawdzenia. Sposobów odliczania czasu jest wiele, który wybierzesz zależy od potrzeb aplikacji, masz do dyspozycji timery, ale i funkcje tmr.time(). Do dyspozycji masz też modul rtc i funkcje rtc.get()

Potrzebny mi będzie odpowiednik tej funkcji z C do porównania stringów

oraz do wyłuskiwania


a tak w ogóle to może dałbyś mi jakiś namiar na książkę do nauki Lua a najlepiej w odniesieniu do NodeMCU lub dobrej strony w PL.

Co do operacji na stringach w LUA jest podobnie jak C++, parse działa podobnie.
Zerknij tu
http://lua-users.org/wiki/StringLibraryTutorial
http://nodemcu.readthedocs.io/en/master/en/
Szczerze to nie znam Książek do Nodemcu. LUA jest dość prosta, uczyłem się ze strony LUA, dwa wieczory starczyły by dość swobodne kodować

O dzięki za linki.
Powiadasz dwa wieczory? Toś pewnie młody człowiek. Mi tak szybko do głowy nie wchodzi. Dzięki. Biorę się za naukę, bo na to nigdy nie za późno.

Pewnie, ze młody 35 lat po studiach.

najprostszy sposób porównania stringów jest:

Jeśli chodzi szukanie ciągu znaków trochę temat morze, podaj ciąg znaków, to postaram się jakoś podpowiedzieć.
https://www.elektroda.pl/rtvforum/viewtopic.php?p=15715027#15715027

To mi wystarczy. Dzięki.

Patrząc na kod w lua zauważyłem, że używa się krótkich nazw.
W związku z tym mam pytania:
1. Skoro pliki zapisywane są do ESP to czy ma znaczenie ich rozmiar ?
2. Jeśli tak, to czego unikać?
- długich nazw zmiennych, funkcji itd
- spacji
- pustych linii itd

Cały kod zapisywany jest do pamięci Flasha w ASCII, czyli każdy znak zajmuje pamięć. Do RAM trafia to co compilator sobie spłodzi. Wiec znacząco mniej.
W ESP jest fatalna organizacja zmiennych, tablic etc...
Kiedy uzywasz zmiennej rezerwuje ona, aż 256bajtow pamięci RAM wiec tu oszczędzaj. Jeśli piszę duże aplikacje, działam na małych plikach zapisanych we Fleshu. Wyniki zapisuje też w osobnym pliku. Warto też pamiętać, by tablica nie miała więcej niż 255 znaków bo potrafi ESP się resetować. Unikać gotowych modułow zwłaszcza string, bin, math, gpio, kradną pamięć jak ZUS i US razem wzięte z partią rządzącą

Te małe pliki to takie odpowiedniki metody, funkcji czy raczej klasy?
Lepiej z nich korzystać przez dołączenie pliku: czy raczej przez moduły: Programy pisać w oddzielnych folderach?

Przykład pierwszy, ale nie jest to funkcja, a alokacja podprogramu, ale nie tylko:
http://nodemcu.readthedocs.io/en/master/en/modules/file/#fileopen
Chodzi o zapis do plików na fleshu.
Tu gromadzisz sobie dane.




A tu odwrócenie sytuacji, zawartośc pliku pobierasz na urządzenie z Androidem linia po linii aż ostania będzie pusta.



Czyli z Androida wysyłasz "XC", a ESP linia po lini z pliku.dat wysyła ciągi znaków.

Czyli juz wiesz jak pisać program na Androidzie lub PC i wysłać go de ESP, czyli bardziej po ludzku piszą masz gotowca do zdalnej aktualizacji programu w ESP:)

Chodzi o oszczędność RAM? (zapisywanie do plików)
Napisz mi jeszcze jak gromadzisz pliki z "metodami","funkcjami" bo w sumie nie wiem jak w lua się nazywają. Chodzi mi o zrobienie sobie takich gotowych bibliotek np. jak w C# czy C.
Trochę ta lua przypomina mi arduino albo bascom.
Piszesz może w C na ESP?

Tak, chodzi o oszczędność RAM, bardzo szybko się kończy. Dlatego czekam na oficjalne moduły ESP3231, te które dostałem do testów, sprawiają mega problemy. W ESP86, musisz dać o każdy bajt, optymalizować do bólu. Jedna z metod jest właśnie tworzenie podprogramów.
Pewnie znajdziesz jakiś własny sposób, który będzie właściwy dla twoich nawyków. Kwestia tworzenia bibliotek, to zapisuje je jako funkcje do aplikacji albo wklejam, albo tworzę podprogram,zależy od potrzeb i samej struktury aplikacji. Tak piszę programy w FreeRTOS. Choc wolę LUA bo jest bardziej czytelna i kiedy wracam do aplikacji lub robię jakieś poprawki, łatwiej jest to odszukać poprawić. Po za tym część aplikacji dla Android piszę w Basic'u lub Phyton'e którym bliżej do LUA, dlatego padł wybor na ten język. A pakowanie do apk robię już klasycznie w Android Studio, bo zarówno Basic jak i Phyton dają kopletne pliki do pakowania + keystone.

Czy można nasłuchiwać na dwóch portach?

piotr411 wrote:

Kiedy uzywasz zmiennej rezerwuje ona, aż 256bajtow pamięci RAM wiec tu oszczędzaj. Jeśli piszę duże aplikacje, działam na małych plikach zapisanych we Fleshu. Wyniki zapisuje też w osobnym pliku. Warto też pamiętać, by tablica nie miała więcej niż 255 znaków bo potrafi ESP się resetować. Unikać gotowych modułow zwłaszcza string, bin, math, gpio, kradną pamięć

To nie jest kwestia organizacji pamięci w ESP, ale kwestia tego jak beznadziejnie robi to LUA. Ja korzystam z bibliotek pod Arduino i nie mam problemu z zapisaniem i obsługą tablicy o rozmiarze 4096 bajtów, nic się nie zawiesza...

Sam z racji, że piszę w C/C++ mam lekki wstręt jak widzę składnię i nawiasologię LUA.

Ogólnie dla mnie odpalanie języka interpretowanego na takim sprzęcie to lekka przesada
A ESP32 - jakoś nie widzę osobiście skoku w stosunku do ESP8266. Szczerze liczyłem na rdzeń ARM, a nie znów Xtensa.

To masz niedrogie moduły RTL-00, RTL-01.
- A mi LUA przypadła bardzo do gustu, zwłaszcza ze względu na bardzo czytelną składnie. Nawiasy, klamy i operatory to niestety spadek po C. Pewnie gdyby nie nodemcu nigdy by się za ten język nie zabrał, ale zważywszy, że ostatnio stał się popularny w PLC, to sobie go przyswoiłem, wiele starych programów przeportowałem w ramach ćwiczeń i przyznam się że jest naprawdę fajny. W przypadku ESP jest okrojony z wiadomych przyczyn, a wielu przypadkach irytujący zwłaszcza kiedy występują różnice pomiędzy oficjalnym firmwarem, a wersją build i brak jakiejkolwiek adnotacji na ten temat.

Dodano po 1 [godziny] 37 [minuty]:

panbosman wrote:

Czy można nasłuchiwać na dwóch portach?

Code: lua

Log in, to see the code

A to mi zabiłeś ćwieka
Tego nie robiłem, a czemu to ma służyć?
Jeśli nawet się da, to się nie da;)
Pewnie nic z tego nie wyjdzie po pierwsza za mało pamięci RAM.
Trzeba by sprawdzić czy ESP8266EX obsługuje kilka kanałów jednocześnie.
Bo z jednej strony masz ograniczenia programowe, z drugiej sprzętowe.
Stawiam tezę w ciemno, że nie wykonalne.

Wgrałem ESPFlasher'em firmware nodemcu. Później ESPlorer'em zrobiłem upload init.lua i inny.lua. Zmieniałem sobie zawartość plików .lua. Doszedłem do momentu, że wgrany był soft AP. Tu gdzieś zrobiłem błąd, który mi resetuje ESP i nie mogę się połączyć przez ESPlorera.
Dla uratowania sprawy jeszcze raz wgrałem ESPFlasher'em firmware nodemcu.
I tu moje zdziwienie, pomimo, że wgrało się pomyślnie nadal po uruchomieniu ESP znajduję sieć z AP, który był wgrany przed flashowaniem i nadal nie mogę się połączyć przez ESPlorera..
To znaczy, że nowe firmware wgrywane jest od 0x0000 do iluś tam, ale nie jest wcześniej kasowany cały flash?
To jak mam skasować cały cały flash?
A może robię jakiś inny błąd?

Właśnie otworzyłem nową partie modułów, opatrzoną datą firmwara 13 czerwiec 2016 i nie pozwala wgrać nodemcu. Nie jest to jeszcze najnowsza wersja "S". Właśnie szukam rozwiązania co jest przyczyną. Bootloader zgłasza prawidłowo odczyt pinów czyli 1, 7 i przy próbie fleszowania kasuje oryginalny firmware po czym wyświetla błąd odczytu pamięci. Trochę to dziwne, bo jest to model Wendor, który w starszych wersjach fleszuje sie bez problemowo. Sprawdziłem to na kolejnych 10 modułach i problem jest ten sam. Mam jeszcze kilkanaście szt z grudnia 2015 i te fleszują się zupełnie normalnie. Być może Twój problem jest podobny czyli kolejna dziwna mutacja firmwara, który coś albo zmienia, albo ogranicza.

Foto 1 i 2 odczyt z wersji nowej
Foto 3 i 4 odczyt z wersji z zeszłego roku

Jak widać na zdjęciach są różnice w wielkości plików pomiędzy firmware'm.
Co kolejny raz staje się niezwykle uciążliwe, bo sposób fleszowania będzie inny.
Choć dane z Boot Mode potwierdzają prawidłowe ustawienie pinów.
Zdjęcia 2 i 3 ustawiłem obok siebie by można było łatwo porównać obie wersje firmware'a

Zdjęcie 5 odczyt w trybie Boot Mode 3,7 starszej wersji prawidłowy
Zdjęcie 6 odczyt w trybie Boot Mode 3,6 nowej wersji - moduł "martwy"

Ustawienia są prawidłowe zgodnie z dokumentacją
Boot Messages and Modes
The ESP at every boot the Pins 0, 2 and 15.

| GPIO15 | GPIO0 | GPIO2 | Mode |
| ------ | ----- | ----- | -------------------------------- |
| 0V | 0V | 3.3V | Uart Bootloader |
| 0V | 3.3V | 3.3V | Boot sketch (SPI flash) |
| 3.3V | x | x | SDIO mode (not used for Arduino) |

Niezgodność występuje w odczycie przy restarcie, mino GPIO15 pulldown, ESP widzi pullup. I tu jest problem.

boot mode
+
+the first value respects the pin setup of the Pins 0, 2 and 15.
+
+| Number | GPIO15 | GPIO0 | GPIO2 | Mode |
+| ------ | ------ | ----- | ----- | ---------- |
+| 0 | 0V | 0V | 0V | Not valid |
+| 1 | 0V | 0V | 3.3V | Uart |
+| 2 | 0V | 3.3V | 0V | Not valid |
+| 3 | 0V | 3.3V | 3.3V | Flash |
+| 4 | 3.3V | 0V | 0V | SDIO |
+| 5 | 3.3V | 0V | 3.3V | SDIO |
+| 6 | 3.3V | 3.3V | 0V | SDIO |
+| 7 | 3.3V | 3.3V | 3.3V | SDIO |

Czyli, ESP przy próbie zmiany firmware, ustawia Boot Mode w tryb ładowania z karty pamięci, a nie flash.

Następstwem jest komunikat "ets_main.c" oznaczający brak oprogramowania.