esp8266 profesjonalnie?

Jeśli dodasz jakis przekaźnik coby odcinać zasilanie w razie zwiechy plus soft, który przewiduje wszystkie anomalne zachowania to pewnie w zastosowaniach profesjonalnych się nada.

Nie dotyczy oczywiście to tylko ESP8266 ale większosci "nowoczesnych" rozwiązań będących przedmiotem intensywnych prac różnych "startupów".

jp

Zrobienie watchdoga to mus w każdym *krytycznym* urządzeniu. Nie widze nic przeciwko uzywaniu ESP w jakimkolwiek urządzeniu.

c.

Pod warunkiem, że reset jest wystarczający do "wstania" urządzenia ze startapów, co jak się często okazuje wcale nie jest oczywiste.

W dniu 2017-02-22 o 19:00, Ghost pisze:

Nie używałem nigdy ESP8266 w żadnych "profesjonalnych" projektach, ale sam hardware wydaje się być stabilny. Jakiś czas temu robiłem na tym projekty, które miały uptime liczony w miesiącach, a reset następował z powodu braku prądu, konieczności wprowadzenia jakichś zmian itp. To było już jakiś czas temu. Ostatnio z powodu ograniczonej ilości czasu nie pisałem niczego pod ESP, więc pewnie w międzyczasie zdążyło wyjść kilka nowych wersji SDK.

Moim zdaniem większość historii mówiących w o niestabilności ESP8266 bierze się albo ze źle filtrowanego zasilania (układ faktycznie mocno wybredny pod tym względem) albo z powodu korzystania z firmware'u do komend AT. Nie wiem jak teraz, ale gdy ja z nim eksperymentowałem był dość mocno niedopracowany.

Coś mi po głowie chodzi, że chyba w Commodore64 można było podmienić wektor resetu tak, że klawisz "reset" nie pomagał, trza było zdjąć prąd; prawda li to? Chyba RAM się bankowało, co pod ROMem leżał.

jp

W dniu 2017-02-23 o 20:32, jacek pozniak pisze:

Nie wiem, czy prawda, lecz to mi przypomniało moją ocenę co do przyczyn fiaska z modelem C-16 (i zbliżonych, które razem z nim wyszły). Otóż model ten miał wbudowany program "monitor" pozwalający zrobić to-i-owo z softem: wgrywało się jakiś program chroniony zabezpieczeniami, które nie pozwalały na kopiowanie, ale po wciśnięciu [reset] uruchamiał się {monitor} i można było bez problemu zapisać chroniony program. Albo wyedytować jakieś linie kodu. Dla użytkownika wielce to było użyteczne, ale wg oceny autorów softu - wq***wiające. Więc po prostu na tą maszynę nie chcieli pisać. A każdy chyba wie, co jest wart komputer bez oprogramowania: tyle co złom! I tak model przyczynił się do wielkich problemów firmy Commodore.

Użytkownik "jacek pozniak" snipped-for-privacy@flowservice.pl napisał w wiadomości news:58af38c5$0$5151$ snipped-for-privacy@news.neostrada.pl...

Tak, to prawda. Po nciśnięciu reset, powodowany był skok procesora pod określony wektorem adres, można było teoretycznie zatem w ogóle kompa resetem powiesić. Pod adresem #32768 umieszczało się 5-znakowa sekwencję znaków ASCII "CBM80" (duźymi literami OIDP), dodatkowo oczywiście właściwy program maszynowy i np. naciskam reset, a komp mi nagle zaczyna animować obrazek i grać muzyczkę. W każdym kompie (przynajmniej 8-bitowym) reset powoduje wyskok pod określony adres i wykonanie umieszczonego tam programu. NB reset ZX Spectrum, gdyby nie umieszczono go w ROM, podobno niszczyłby sam siebie, 5 pierwszych komórek. Co do C64, jest jeszcze jedno, co można ciekawie oprogramować - przerwanie NMI, nie da się go wyłączyć, można jedynie przestawić wektor obsługi, aby przerwanie było ignorowane, zwykła instrukcja NOP i powrót z podprogramu. Przerwanie to jest wyprowadzone oficjalnie na zewnątrz - wywoływane jest po naciśnięciu klawisza RESTORE, klawisz ten bezpośrednio uglebia odpowiedni pin w procku. Teoretycznie można by oprogramować reset i NMI tak, żeby nawzajem przełączać się miedzy dwoma programami. Co do bankowania - tak, C64 miał pełne 64 kB RAM, oraz hmm... ok 20 kB ROM. Można było całe 64 wykorzystać. Więc C64 na pewno bankował pamięć. Dzięki tej sztuczce, procek 6502/6510, teoretycznie może fizycznie zaadresować do

512 kB RAM, oczywiście, naraz mając tylko 64 kB, bo adresacja jest tylko 16-bitowa, oraz mamy 3-bitową linię do przełączania banków - 3 bity, 8 razy 64kB = 512 kB teoretycznie.

Użytkownik "HF5BS" napisał w wiadomości grup dyskusyjnych:o8ntl1$1ir$ snipped-for-privacy@node2.news.atman.pl...

Niemożliwe!!!

Ojej

Niemożliwe!!!

Teoretycznie to prawie dowolna wielkosc

Na nonOS. Z RTOS jeszcze nie eksperymentowałem.

Raczej niezbyt intensywnie. Moduł działał w trybie "station", wysyłając/odbierając niewielkie ilości danych. Jakaś synchronizacja czasu przez NTP, wysyłanie aktualnych odczytów z jakiegoś czujnika itp. Gdybym spodziewał się większego ruchu albo musiał obsłużyć nieco "cięższe" protokoły, pewnie skorzystałbym z jakiegoś małego komputerka na Linuksie.

Chodzi o sytuację, kiedy wykorzystywany był firmware do komunikacji z modułem przez komendy AT. Najwyraźniej był w nim jakiś bug (pewnie nie jeden...), który w losowym momencie powodował zawieszenie się modułu. Próba wykonania jakiejkolwiek operacji skutkowała wywalaniem komunikatu "busy". Wszystko wskazywało na źle napisaną maszynę stanów. Może to w końcu naprawili, nie wiem... W każdym razie korzystanie z komend AT uważam za niezbyt dobry pomysł.

Natomiast nic nie stoi na przeszkodzie, żeby sobie podzielić zadania pomiędzy ESP i jakiś inny MCU, pisząc własny wsad. Można chociażby zaimplementować po stronie ESP całą warstwę aplikacji i wysyłać wyniki przez UART-a.

Tego nie wiem, ale podejrzewam, że wspomniany comodore64 to wyżyny stabilności niedostępne dla owych startapów.

Użytkownik "Marek" snipped-for-privacy@fakeemail.com napisał w wiadomości news: snipped-for-privacy@news.neostrada.pl...

Tak, pod tymi samymi adresami są i ROM, i RAM. Przy zapisie zawsze idzie do RAM pod spodem, więc dzięki temu można np. zmodyfikować jakiś komponent systemowy, gdzie wpierw przepisuje się ROM do RAM prostą sekwencją FOR T=X TO Y:POKE T,PEEK(T):NEXT (lub odpowiednio w "maszyniaku") i już, po wykonaniu pętli możemy sobie modyfikować, następnie przełączamy się na tę pamięć i korzystamy. STabilność - był stabilny, acz niestety, nie było żadnego wsparcia wobec błędów w programie, naruszenia obszaru wspólnego, itd. co oferują dzisiejsze procesory. Po prostu, oprogramowanie Komody wymagało znacznie większej staranności przy kodowaniu, jak i oszczędnego gospodarowania pamięcią.

Powodem fiaska C16, 116, +4 było zastosowanie gorszego układu video i dzwiękowego.

jp

Użytkownik "jacek pozniak" snipped-for-privacy@flowservice.pl napisał w wiadomości news:58b029c7$0$15195$ snipped-for-privacy@news.neostrada.pl...

A także niekompatybilność sprzętowa - inny interfejs stacji i nie pamiętam, magnetofonu? Tak więc nawet gówniany program w BASIC (hehe, kojarzy ktoś, czyj jest BASIC w Komodach?) to nie taka najprostsza sprawa było przenieść. Gdyby to, co zrobiono z 16/116/+4 zrobiono z C64, to mógłby być wielki sukces. A posiadacze starszych maszyn np. wystarczyło by podmienić EPROM, czy dołożyć coś obok i już. Chodzi mi o coś na kształt C128, który nikt mi nie wmówi, że jest inaczej - aktywnie bankuje pamięć programom w BASICu, albowiem zastosowano dość rozrzutny, ale rewelacyjny dla programistów wybieg - osobną pamięć na program i zmienne numeryczne (sprawdzana PRINT FRE(0)), oraz osobna dla łańcuchów tekstowych (sprawdzana PRINT FRE (1)), więc np. programy bazodanowe mogły się czuć jak u Mamy w domu. Nie pamiętam, czy zawarty Z80 (tak, to był jeden z pierwszych komp dwuprockowy, jak też i ma dwa procki obrazu) umiał się dobrać do całości w trybie CP/M. Gdyby paru spraw nie poszkapiono... W ogóle Commodore przespał parę momentów, co go totalnie zgubiło.

Może i się obudzili, ale chyba za późno... i dupło.

W dniu piątek, 24 lutego 2017 14:57:05 UTC+1 użytkownik HF5BS napisał:

Ostatnio widzialem na jakims kanale historie amstradów.

Po obejrzeniu tego stwierdzilem ze zadna platforma inna nie miała szansy z PC. Ani commodore z c64 ani amigą ani zaden mac.

Wywnioskowałem że gdyby commodore nie pokpilo spraw to i tak by umarli tyle ze może dzieki konkurencji troche szybciej bysmy mieli system na miare win95 czy mozliwosci takie jak dawały karty typu gravis czy 3dfx (w sensie wieloprocesorowości). Jak spojrzałem na ilosci sztuk sprzedawanych globalnie to wyszło mi że nawet gdyby amiga królowała w domach to i tak zgodność z biznesowym sprzętem/software byłby kluczowy.

Ale to wogóle inny temat.

Polecam poszukać na jutubie materiału o historii amstrada.