Elektroda.pl
Elektroda.pl
X
Computer Controls
Proszę, dodaj wyjątek dla www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

[Rozwiązano] Stacja pogodowa oparta na Arduino + WiFi - projekt, link.

29 Kwi 2018 18:16 1797 39
  • Spec od TV
    Witam.
    Niestety od jakiegoś czasu szukam bezskutecznie opisu stacji pogodowej w konfiguracji:
    - część zewnetrzna: moduł WiFi + DHT 22 + BMP
    - cześć bazowa: Arduino +wyświetlacz + DHT + WiFi.

    Znalazłem kilka projektów opartych na komunikacji radiowej, lub zaprogramowej w Bascomie, albo w C.
    Problem w tym, że nie wiem jak skomunikować (i wyświetlić dane) Arduino przy pomocy modułu ESP z drugim modułem WiFi.

    Proszę o pomoc w tym temacie.

    Pozdrawiam.
  • Computer Controls
  • Pomocny post
    Poziom 33  
    msiuel napisał:

    - część zewnetrzna: moduł WiFi + DHT 22 + BMP

    Zewnętrzny czujnik z WiFi w praktyce wymaga zasilacza sieciowego. Jest to dość poważna wada. Zwróć uwagę, że w fabrycznych stacjach pogodowych stosuje się tylko czujniki zasilane bateryjnie.
  • Computer Controls
  • Spec od TV
    U mnie lokalizacja czujnika zewnętrznego pozwoli na skorzystanie z zasilacza sieciowego.
  • Poziom 17  
    msiuel napisał:
    Znalazłem kilka projektów opartych na komunikacji radiowej, lub zaprogramowej w Bascomie, albo w C.

    Skoro znalazłeś w C to jaki problem?
  • Spec od TV
    Szukam rozwiazania na platformie Arduino (oprogramowanie).

    Pozdrawiam.
  • Pomocny post

    Poziom 28  
    TvWidget napisał:
    Zewnętrzny czujnik z WiFi w praktyce wymaga zasilacza sieciowego.


    Niekoniecznie. Chyba, że chcemy wysyłać pakiety co sekundę to tak, zasilanie bateryjne odpada. Ale jeśli aktualizacja może być co 10..15 minut, to już ma to sens.
    msiuel napisał:
    Szukam rozwiazania na platformie Arduino (oprogramowanie).


    Czego dokładnie potrzebujesz? Tylko przesłania kilku zmiennych z czujnika zewn. do stacji ? W zasadzie wszystko jest w przykładach do Arduino IDE, jeśli masz już zainstalowane ESP8266 w tym środowisku.
  • Spec od TV
    Na razie chciałbym przesłac tylko informację o temperaturze i wilgotności. Na zewnątrz chcę zastosować moduł WiFi, aby mieć również pogląd z poziomu przeglądarki, a w przyszłości poszerzyć funkcjonalność (ESP07...12, Nodemcu).
    Na obecna chwilę to moje 1_sze podejście do komunikacji bezprzewodowej w Arduino...

    Pozdrawiam.
  • Poziom 33  
    Dostępne przez przeglądarkę mają być tylko pomiary on-line czy również archiwalne ?
  • Pomocny post

    Poziom 28  
    Jeśli czujnik zewnętrzny miałby być zasilany baterujnie, to odpada wykorzystanie go jako server do podglądu danych przez przeglądarkę. Można zastosować dwa moduły ESP - jeden w stacji, działający jako server oraz odbierający dane z modułu umieszczonego na zewnątrz, który będzie wysyłał dane np. co 15 minut. Dane archiwalne można zapisywać w SPIFFS modułu ESP.
    Tak czy inaczej musisz zastosować dwa moduły ESP i wygodniej będzie wykorzystać ten "wewnętrzny" jako server. A zasilanie zewnętrznego zrobić wedle uznania.
    Jeśli miałeś już do czynienia z programowaniem arduino, to mogę Ci udostępnić fragmenty kodu do komunikacji między dwoma ESP a także serwującego stronę www z AJAXem.
  • Spec od TV
    Dzieki za informacje. Chciałem, aby przy Arduino zastosować ESP8266 ze względu na rozmiary. A z tego co piszesz będę musiał znależć więcej mniejsca.

    ESP mam zainstalowane w środowisku Arduino. Widzę, że czeka mnie kolejne wdrożenie i zadawanie pytań...
    Pozdrawiam.
  • Pomocny post

    Poziom 28  
    Myślę, że Arduino ( jako płytkę, moduł ) możesz spokojnie pominąć. Wszystko zrobisz "lepiej i szybciej" na samym ESP8266. Jeśli potrzebujesz więcej I/O to wystarczy tani expander na I2C czy SPI.
  • Poziom 17  
    zster napisał:
    Wszystko zrobisz "lepiej i szybciej" na samym ESP8266. Jeśli potrzebujesz więcej I/O to wystarczy tani expander na I2C czy SPI.

    I problemy gdy trzeba obsłużyc przerwania od expanderów.

  • Poziom 28  
    NoweMillennium napisał:
    I problemy gdy trzeba obsłużyc przerwania od expanderów.


    Jakież to problemy ??
  • Poziom 17  
    zster napisał:
    NoweMillennium napisał:
    I problemy gdy trzeba obsłużyc przerwania od expanderów.


    Jakież to problemy ??

    Trwa transmisja po I2C, np do wyświetlacza LCD, następuje przerwanie i jak w czasie przerwania obsłużyc I2C, na którym może trwa transmisja?

  • Poziom 28  
    NoweMillennium napisał:
    Trwa transmisja po I2C, np do wyświetlacza LCD, następuje przerwanie i jak w czasie przerwania obsłużyc I2C, na którym może trwa transmisja?


    Oj kolego, długa droga przed Tobą ;) Nie wiem jak piszesz programy, skoro przerwania psują Ci I2C ale.. nie tędy droga ;) Rozumiem, że mając rzeczony LCD na I2C nie można niczego odczytywać ze sprzętowego UARTa? Ani nawet "arduinowego" millis() ? ;)
  • Poziom 17  
    zster napisał:
    NoweMillennium napisał:
    Trwa transmisja po I2C, np do wyświetlacza LCD, następuje przerwanie i jak w czasie przerwania obsłużyc I2C, na którym może trwa transmisja?


    Oj kolego, długa droga przed Tobą ;) Nie wiem jak piszesz programy, skoro przerwania psują Ci I2C ale.. nie tędy droga ;) Rozumiem, że mając rzeczony LCD na I2C nie można niczego odczytywać ze sprzętowego UARTa? Ani nawet "arduinowego" millis() ? ;)

    To proszę napisac jak podczas praktycznie nieprzerwanej transmisji po I2C w programie głównym, zareagować na przerwanie z expandera i po I2C odczytać stan portu ekspandera. Zakładam, że pętla główna wykonuje się 300ms a na przerwanie trzeba zareagowac w 1ms. Ekspander może zgłaszać przerwania na wielu liniach (w PCF8574 akurat nie ma innego wyboru), więc nie wystarczy stwierdzić, że nastąpiło przerwanie, trzeba określić na którym pinie ekspandera.

  • Poziom 28  
    W czym problem ? ( prócz jakiegoś kosmicznego czasu pętli głównej i wymogu reakcji na przycisk w 1ms ) ? Pytanie brzmi - JAK chcesz zareagować na to przerwanie?
    Napisałeś :
    NoweMillennium napisał:
    Trwa transmisja po I2C, np do wyświetlacza LCD, następuje przerwanie i jak w czasie przerwania obsłużyc I2C, na którym może trwa transmisja?

    Zakładasz więc, że przerwanie rozwala całe TWI i.. co ? LCD się wykrzaczy? Nie wiem.. może ja mam jakieś magiczne podzespoły, skoro nigdy nie miałem tak dziwnego problemu.. A może po prostu nie wpierniczam do obsługi przerwania dziesiątek linijek kodu pochłaniającego setki taktów zegara )....

    PS - w założeniach zapomniałeś o jeszcze jednej, bardzo istotnej rzeczy. Podpowiem, że związana jest z TWI... ( na dokładniej z konfiguracją TWI ).

    Dodano po 15 [minuty]:

    NoweMillennium napisał:
    To proszę napisac jak podczas praktycznie nieprzerwanej transmisji po I2C w programie głównym,


    Dlaczego nieprzerwanej? I nieprzerwanej w pętli wykonującej się 300ms ?? ;) ;)
  • Poziom 17  
    zster napisał:
    Dlaczego nieprzerwanej? I nieprzerwanej w pętli wykonującej się 300ms

    Klasyczny przepadek Arduinowca, dziesiąki delay. Nawet nie będzie, ze pętla główna wykonuje się 0ms ale obsługujemy w niej LCD przez PCF8574czyli 100kHz i 4 przesłania na jeden bajt:
    danaL + E=H
    e=L
    danaH +E=H
    E=L
    Wyswietlacz ma 20x4, więc 160znaków co daje 640 danych do wysłania (adres zapisu I2C można pominąc). Czas transmisji bajtu po I2C przy 100kHz (Arduino tyle nie wyciąga, przynajmniej na AVR) to 1.1ms. Wysłanie danych do LCD trwa więc 704ms. Powiedzmy, ze to LCD 16x2 czyli transmisja 140ms.
    Zakładam, ze właśnie trwa transmisja do LCD, expander zgłasza przerwanie, jak w 1ms (niech będzie 3, bo 1ms to jeden bajt po I2C) opdczytać źródło przerwania?

  • Poziom 28  
    Już widzę kogoś, kto opiera pętlę główną na delay() i próbuje odczytać przyciski do 3ms ;) ( swoją drogą - po co ? )
    Ale.. Nie ma i z tym problemu.
    1- w obsłudze przerwania z expandera, odczytujesz rejestry expandera z poziomu niskiego dostępu do interfejsu TWI ( bez użycia przerwań )
    2- Zdziwię Cię, ale nawet w obsłudze przerwania, w której to inne przerwania są zawieszone, można włączyć i użyć przerwanie
    NoweMillennium napisał:
    (Arduino tyle nie wyciąga, przynajmniej na AVR
    i odczytać slave'a I2C. Nawet z użyciem biblioteki Wire. Spróbuj, polecam ;)
    Polecam także buforować dane do LCD ;)
    Zastanów się trochę - jakim cudem ciągle działają liczniki i timery ? Gdyby było tak, jak Tobie się wydaje to praktycznie nic by nie działało. To, że ktoś nie radzi sobie z kodem, nie rozumie sprzętu na którym działa, nie optymalizuje obsługi przerwań czy używa ich tam, gdzie nie są potrzebne, nie oznacza że czegoś nie da się zrobić i coś nie działa.
    NoweMillennium napisał:
    (Arduino tyle nie wyciąga, przynajmniej na AVR

    Kolejna bzdura. Z zegarem 16MHz bez zająknięcia działa 400kHz.

    Dodano po 12 [minuty]:

    NoweMillennium napisał:
    Wysłanie danych do LCD trwa więc 704ms.

    Jeśli ktoś pisze kod, gdzie transmisja 160 znaków do wyświetlacza I2C zajmuje ponad 700ms to..wybacz, wymiękam .. ;) Aż boję się wspomnieć, że można z całym buforem LCD20x4 zejść do ok. 50ms... ;)
  • Pomocny post
    Poziom 17  
    zster napisał:
    Już widzę kogoś, kto opiera pętlę główną na delay() i próbuje odczytać przyciski do 3ms ;) ( swoją drogą - po co ? )

    Fotokomórka zatrzymująca prasę aby niezmiarzdżyła ręki. Reakcja po np 0,7sekundy nie wchodzi w grę.
    Albo obsługa enkodera
    Dekodowanie DCF77
    Mnożyć dalej przykłady?

    zster napisał:

    1- w obsłudze przerwania z expandera, odczytujesz rejestry expandera z poziomu niskiego dostępu do interfejsu TWI ( bez użycia przerwań )

    Trwała transmisja do LCD, w przerwaniu generuję start (LCD interpretuje jako ponowny start) obsługuje ekspander (tu wszystko ok), generuje stop (LCD interpretuje stop). Program główny wysyła dalej dane do LCD i jaki efekt? wysyła dane a przecież w międzyczasie pojawił się stop. Gdzie te dane tyrafią?
    Aby nie było niedomówień, w wyliczeniach napisałem pomijam adresowanie PCF8574 dla LCD, bo jakie to ma znaczenie przy transmisji 200 czy 700bajtów. Aby LCD obsłużyc szybko wysyłam start, adres zapisu, dane ..... dane stop. "dane" to sekwencja danaL +E=H itd.
    Jeśli miałbym po każdym przesłanym bajcie wysyłac stop, ponownie star, adres to transmisja (juz wolna) trwała bedzie dwa razy dłużej.

    zster napisał:

    Zastanów się trochę - jakim cudem ciągle działają liczniki i timery ?

    MNa przerwaniach ale należy zaóważyć, że aby odczytac czy zapisac rejest nie realizuje sie transmisji kilku, kilkunastu bajtów w dodatku po magistrali szeregowej dzielonej z innymi układami.

    zster napisał:

    NoweMillennium napisał:
    (Arduino tyle nie wyciąga, przynajmniej na AVR

    Kolejna bzdura. Z zegarem 16MHz bez zająknięcia działa 400kHz.

    AVR tak, Arduino nie. Sprzawdziłem organoleptycznie. Kolega sprawdzał na PCF8574? Owszem, w bibliotece dla LCD po I2C na czas transmisji do niego, rejestr predkości jest ustawiany na 400kHz, następnie przywracana poprzednia wartość. Nie pamiętam jaką ale nie było to 100kHz, cos blizej 50.

    zster napisał:

    NoweMillennium napisał:
    Wysłanie danych do LCD trwa więc 704ms.

    Jeśli ktoś pisze kod, gdzie transmisja 160 znaków do wyświetlacza I2C zajmuje ponad 700ms to..wybacz, wymiękam .. ;)

    Widziałem bardzo wiele projektów z LCD obsługiwanym przez konwerter I2C. Naturalnie to głupota, bo jeśli już to używa się LCD z I2C, tam transmistuje się start, adres, cmd, dane..... Komunikacja jest więc około 4 razy szybsza niż w przypadku konwertera na PCF. Nie zmienia to faktu, że wiele osób tak robi. W uC ma nieużywane GPIO ale nie potrafi taki fachowiec zmienić programu tak aby niekomunikował się przez konwerter.

  • Poziom 28  
    NoweMillennium napisał:
    Fotokomórka zatrzymująca prasę aby niezmiarzdżyła ręki. Reakcja po np 0,7sekundy nie wchodzi w grę.

    I taki program pisze ktoś, kto nie potrafi z przerwań skorzystać??? Od tego są dedykowane rozwiązania SPRZĘTOWE, na pierwszej linii.
    NoweMillennium napisał:
    MNa przerwaniach ale należy zaóważyć, że aby odczytac czy zapisac rejest nie realizuje sie transmisji kilku, kilkunastu bajtów w dodatku po magistrali szeregowej dzielonej z innymi układami.

    NoweMillennium napisał:
    Albo obsługa enkodera

    Jakiego enkodera? Jeśli prostego impulsatora jako elementu UI to i tak bez sensu. Zwłaszcza ze względu na drgania styków. A i aktualizacja "danych" co 3ms to w tym wypadku gruba przesada. Jeśli enkoder do pomiaru prędkości - to raczej ktoś, kto z takiego elementu korzysta, nie podłącza go do PCF8574 ...
    Ale pomijając nawet to - nie ma żadnego problemu z obsługą takich ( i krótszych ) czasów. Żadnego.
    NoweMillennium napisał:
    MNa przerwaniach ale należy zaóważyć, że aby odczytac czy zapisac rejest nie realizuje sie transmisji kilku, kilkunastu bajtów w dodatku po magistrali szeregowej dzielonej z innymi układami.

    Więc jak to jest, że mimo przerwań ( generowanych przez TWI ) spokojnie i bez problemów działa kilkadziesiąt układów na tej samej magistrali? Do tego przerwania z kilku UARTów, liczniki, timery, ADC itd..?
    NoweMillennium napisał:
    AVR tak, Arduino nie. Sprzawdziłem organoleptycznie. Kolega sprawdzał na PCF8574? Owszem, w bibliotece dla LCD po I2C na czas transmisji do niego, rejestr predkości jest ustawiany na 400kHz, następnie przywracana poprzednia wartość. Nie pamiętam jaką ale nie było to 100kHz, cos blizej 50.

    Bzdura. Zdziwię Cię jeszcze bardziej, ale spokojnie rusza 800kHz. Weź sobie UNO, Mega czy co masz pod ręką, wrzuć : https://github.com/RobTillaart/Arduino/tree/master/sketches/MultiSpeedI2CScanner , podłącz ten nieszczęsny PCF8574 i patrz. Aż sobie sprawdziłem na szybko, także oscyloskopem i.. niesamowite, ale działa ! ;) Jeśli Kolega nadal będzie niedowiarkiem, to w poniedziałek wrzucę "dowody".
    To, że jakaś biblioteka jest schrzaniona, nie znaczy że coś nie działa.
    NoweMillennium napisał:
    Widziałem bardzo wiele projektów z LCD obsługiwanym przez konwerter I2C. Naturalnie to głupota, bo jeśli już to używa się LCD z I2C, tam transmistuje się start, adres, cmd, dane..... Komunikacja jest więc około 4 razy szybsza niż w przypadku konwertera na PCF.

    Jeszcze raz powtórzę - LCD 20x4 na PCF8574. Cały bufor wysłany w niecałe 50ms. Nie oczekuj takich efektów po bibliotece LiquidCrystal ale jeśli nie chcesz pisać "od podstaw" obsługi, to jest także gotowa biblioteka oferująca takie rezultaty.
    To jest sedno pewnego problemu - ludzie wrzucają w IDE jakieś biblioteki, nie zawsze dobrze napisane i są rozczarowani "szybkością" czy niezawodnością. A później czyta się posty, gdzie ktoś poleca jakiegoś "potężnego" ARMa do zrobienia "przysłowiowego kalkulatora" z 4 działaniami...
    I odbiegł kolega znacznie od sedna dyskusji - czyli wykorzystania ESP8266 "do wszystkiego" w projekcie stacji pogody, gdzie odczyt przycisku może trwać nieco dłużej niż 3ms, aktualizacja danych na LCD może być nawet co 200ms ( i więcej ) i nic nikomu ręki nie urwie ;)
  • Pomocny post
    Poziom 17  
    zster napisał:
    Więc jak to jest, że mimo przerwań ( generowanych przez TWI ) spokojnie i bez problemów działa kilkadziesiąt układów na tej samej magistrali? Do tego przerwania z kilku UARTów, liczniki, timery, ADC itd..?

    Czy uC komunikujac się z timerem, usartem używam magistrali szeregowej czy równoległej?

    Po co te wywody o
    zster napisał:
    Od tego są dedykowane rozwiązania SPRZĘTOWE, na pierwszej linii.

    czy
    zster napisał:
    Jakiego enkodera? Jeśli prostego impulsatora jako elementu UI to i tak bez sensu.


    Proszę napisać jakie to proste komunikowac się po I2C w programie głównym i jednocześnie odczytywac I2C w przerwaniu. Przypomne wypowiedzi:
    NoweMillennium napisał:
    zster napisał:
    NoweMillennium napisał:
    Trwa transmisja po I2C, np do wyświetlacza LCD, następuje przerwanie i jak w czasie przerwania obsłużyc I2C, na którym może trwa transmisja?

    Oj kolego, długa droga przed Tobą ;) Nie wiem jak piszesz programy, skoro przerwania psują Ci I2C ale.. nie tędy droga ;) Rozumiem, że mając rzeczony LCD na I2C nie można niczego odczytywać ze sprzętowego UARTa? Ani nawet "arduinowego" millis() ? ;)

    To proszę napisac jak podczas praktycznie nieprzerwanej transmisji po I2C w programie głównym, zareagować na przerwanie z expandera i po I2C odczytać stan portu ekspandera. Zakładam, że pętla główna wykonuje się 300ms a na przerwanie trzeba zareagowac w 1ms. Ekspander może zgłaszać przerwania na wielu liniach (w PCF8574 akurat nie ma innego wyboru), więc nie wystarczy stwierdzić, że nastąpiło przerwanie, trzeba określić na którym pinie ekspandera.


    Czekam więc na te proste rozwiązanie a nie wywody po co i dlaczego mają byc obsługiwane przerwania zgłaszane z układów I2C. Skoro układy mają takie wyjście (expandery, zegary, UARTY) to czemuś to służy.
    Zagadnienie nie jest proste. W książce @tmf można znaleźć rozwiązanie i nie są to trzy linijki kodu. Może jednak kolega ma takie proste rozwiązanie, z chęcią z tego skorzystam. Może niepotrzebnie robię kolejki komunikatów i cała komunikację realizuje na przerwaniach. Może wystarczy przesyłac sobie dane w programie głównym a jak wystąpi przerwanie, to rzucić na stos stan I2C, zrobic swoje, przywrócić stan I2C w wrócic z przerwania.

  • Poziom 28  
    NoweMillennium napisał:
    Czy uC komunikujac się z timerem, usartem używam magistrali szeregowej czy równoległej?

    Tak.
    Choć w tym nieprecyzyjnym pytaniu zapewne chodziło Ci o TWI, USART , SPI itd. Zobacz, co postulowałeś na samym początku. Przerwania wpłyną na transmisję I2C. To twierdziłeś Teraz próbujesz dorobić teorię do swoich mylnych wyobrażeń. Więc pytam - czy te przerwania ( a może ich być "w tle" całkiem sporo ) uniemożliwiają Ci jakoś pracę z TWI? Czym one się różnią od zewnętrznego przerwania z nieszczęsnego PCF8574? ? Zadałem to pytanie kilkukrotnie. Ile czasu potrzeba na odczytanie 8 bitów z PCF? Czekam na odpowiedź.
    NoweMillennium napisał:
    Po co te wywody o

    Mam wrażenie, że pod tym nickiem siedzą dwie osoby. A przynajmniej dwie osobowości ... Czy to ja, w wątku o stacji pogodowej, ni z gruszki, ni z pietruszki wtrąciłem "urywanie rąk przez maszyny", przy okazji pokazując, że jednak masz blade pojęcie o takich zabezpieczeniach? I czemu nagle umilkłeś z Twoimi twierdzeniami że I2C na arduino to "z biedą" 100kHz? I że obsługa wyświetlacza po I2C zajmuje Ci 700ms? Nie umiesz inaczej - ok, każdy się uczy. Ale przestań pierniczyć trzy po trzy, złap Arduino ( czy cokolwiek masz pod ręką ) i sam sprawdzaj.
    Co do odczytu I2C w przerwaniu to już podałem Ci dwa najprostsze rozwiązania. Programator w dłoń i przekonaj się sam. Albo, jesli chcesz wyzwanie - to zapraszam do siebie, do firmy. Zobaczysz, z czego od paru ładnych lat żyję i, w przeciwieństwie do Ciebie, teoretykiem nie jestem. A książki Pana Tomasza cenię i wiem co w nich jest.
    NoweMillennium napisał:
    Może niepotrzebnie robię kolejki komunikatów i cała komunikację realizuje na przerwaniach. Może wystarczy przesyłac sobie dane w programie głównym a jak wystąpi przerwanie, to rzucić na stos stan I2C, zrobic swoje, przywrócić stan I2C w wrócic z przerwania.
    Nie wiem, bełkot. Jakie dane? Jakie komunikaty? Gdzie przesyłać? Jakie przerwanie?
    Ostatni raz powtórzę - to, że Tobie coś nie działa bo korzystasz z bibliotek i/lub nie umiesz inaczej ( udowodniłeś to choćby twierdzeniem o zegarze TWI czy kosmicznym czasie obsługi LCD ), nie oznacza że to nie działa w ogóle.
    Wątek jest o stacji pogodowej na Arduino. Jak chcesz nadal dorabiać swoje teorie - zapraszam na PW lub do siebie. Naocznie pokażę Ci, na wielu przykładach, co można zrobić, co działa i dlaczego tylko wydaje Ci się, że nie ma prawa działać.
  • Poziom 17  
    zster napisał:
    czy te przerwania ( a może ich być "w tle" całkiem sporo ) uniemożliwiają Ci jakoś pracę z TWI?

    Dałem konkretny przykład. Trwa transmisja po I2C do wyświetlacza, do PCF wysyłane są dane bo zaadresowany był raz. Następuje przerwanie, w przerwaniu obsługuję expander, czyli (powtarzam) generuje start, który zostanie zinterpretowany jako ponowny start, adresuję expander (pcf od lcd nie bedzie zaadresowany) odczytuję ekspander, generuje stop, wychodzę z przerwania. Program główny kontynuuje wysyłanie danych do lcd. I co się dzieje? Gdzie trafiają dane? W "kosmos" bo ostatnio był zaadresowany pcf od LCD a dodatkowo został wygenerowany stop.
    Jeśli teoria nie trafia do kolegi to prosze sprawdzic to w praktyce. Dołączam obrazek aby kolega zrozumiał gdzie leży problem.Stacja pogodowa oparta na Arduino + WiFi - projekt, link.

    zster napisał:
    I czemu nagle umilkłeś z Twoimi twierdzeniami że I2C na arduino to "z biedą" 100kHz?

    Już napisałem, sprawdziłem organoleptycznie oscyloskopem.
    zster napisał:
    Ostatni raz powtórzę - to, że Tobie coś nie działa bo korzystasz z bibliotek i/lub nie umiesz inaczej ( udowodniłeś to choćby twierdzeniem o zegarze TWI czy kosmicznym czasie obsługi LCD ), nie oznacza że to nie działa w ogóle.

    Nie uzywam Arduino. To sie do niczego powaznego nie nadaje. Przenosiłem biblioteki LCD z Arduino na ARM i napisane są kiepsko. Wyświetlanie napisów jest żałośnie wolne. Akurat w tym konkretnym przypadku,problem nie leży w szybkości SPI tylko beznadziejnej implementacji rysowania znaku. Biblioteki do TM1637 porażka.
    O przerwaniach nadawczych dla TWI, USART, SPI to autorzy bibliotek dla Arduino nie słyszeli.

  • Poziom 28  
    Musisz trochę doczytać o I2C ;) Wiedziałeś, że I2C jest multi - Master? Doczytaj co i jak tam jest realizowane. Ale abstrahując od tego - skoro w obsłudze przerwania nie umiesz ustawić flagi, by po wyjściu z obsługi komunikacja z PCF od LCD została powtórzona ( programowe NACK) a w dodatku upierasz się, że przycisk trzeba obsługiwać w całości przerwaniem, choć to totalna głupota, to już nie mój problem. Widocznie nawet ARMy są dla Ciebie za małe. Dokładniej na resztę bredni odpowiem jutro, zdjęciami.
  • Poziom 17  
    zster napisał:
    Wiedziałeś, że I2C jest multi - Master

    Wiem. Ale kolega chyba nie bardzo. Multimaster uzywany jest gdy do jednej magistrali podłączone sa dwa mastery. Jeden z masterów, w przypadku równoległej transmisji przegrywa i odłącza się. Który z AVRmega ma dwa I2C?
    Skoro nie ma takich, co i tak nierozwiązało by problemu, to arbritraż jest realizowany na adresie a nie danych gdy już trwa transmisja, to po co wyjeżdzac z trybem multimaster? Ardgumenty sie kończą czy kolega chce zabłysnac wiedza na temat I2C?

    zster napisał:
    Ale abstrahując od tego - skoro w obsłudze przerwania nie umiesz ustawić flagi, by po wyjściu z obsługi komunikacja z PCF od LCD została powtórzona ( programowe NACK)

    Zaczyna się komplikować a wydawało by się, ze to jest proste
    zster napisał:
    Jakież to problemy ??

    Powiedzmy, że ustawiam flagę. W programie głównym dowiem się, że nie straciłem rozwiązanie. Transmisję rozpoczac od poczatku? A co jak przerwania od expandera przychodza tak często, ze całej transmisji nie jestem w stanie zrealizować? Moge oczywiście zapamiętać ile bajtów wysłałem, aleto nie wszystko. Mogłem pisac w CGRAM niekoniecznie od zera.
    Niech bedzie, ze jest to jakies wyjście, ale w przerwaniu od ekspandera nie bede obsługuwał TWI na zasadzie przeglądania rejestrów:
    TWI - wygeneruj strt
    TWI - czekam na wykonanie
    TWI - wyślij adres
    TWI - czekam na wykonanie
    itd. Prawda? Może kolega tak robi, to gratuluję kunsztu programistycznego. Te operacje trzeba zrealizowac na przerwaniach, czyli w przerwaniu EXTI (od ekspandera) uruchamić przerwania od TWI, które po zakończeniou bierzacego cyklu na TWI zrealizują odczyt bajtu z ekspandera iustawią flagę dla programu głównego.
    Skoro to takie proste, prosze pokazac program, który to zrealizuje.


    zster napisał:
    dodatku upierasz się, że przycisk trzeba obsługiwać w całości przerwaniem, choć to totalna głupota

    Pozwole sobie tego niekomentowac. Zaraz pewnie się dowiem, że niepotrzebna eliminacja drżenia styków a wyświetlacz muliplekowany obsługuje się w pętli głównej.

    Dodano po 24 [minuty]:

    zster napisał:
    Widocznie nawet ARMy są dla Ciebie za małe

    Używam ARM bo
    - Przeważnie są tańsze niż AVR o podobnym wyposażeniu.
    - Mają więcej pamięci ram i moge robic bufory nadawcze dla usart, I2c, SPI, USB
    - Maja bogatsze wyposażenie (liczba usart, I2C, SPI, timerów) i większe możliwości tychże peryferii
    - Mają DMA (AVR Mega nigdy o czymś takim nie słyszały)
    - Mają wielopoziomowy system przerwań
    - Tańsze narzedzie (debuger)
    - Nie musze się zastanawiac czy dana jest w ram czy flasch aby użyć stosownej funkcji (z sufiksem _P)

    W ARM problemu z expanderem i przerwanianiami od niego raczej by nie było. Wystarczy ekspander włączyc na osobnej magistrali I2C.
  • Poziom 20  
    NoweMillennium napisał:
    Trwa transmisja po I2C do wyświetlacza, do PCF wysyłane są dane bo zaadresowany był raz. Następuje przerwanie, w przerwaniu obsługuję expander, czyli (powtarzam) generuje start, który zostanie zinterpretowany jako ponowny start, adresuję expander (pcf od lcd nie bedzie zaadresowany) odczytuję ekspander, generuje stop, wychodzę z przerwania. Program główny kontynuuje wysyłanie danych do lcd. I co się dzieje? Gdzie trafiają dane? W "kosmos" bo ostatnio był zaadresowany pcf od LCD a dodatkowo został wygenerowany stop.

    No coż, jest to (i dalszy obrazek) kompletnie bez sensu. Takie rzeczy nie mają prawa wystąpić na magistrali z jednym masterem. Jeśli miewasz takie zdarzenia to nie jest problem zastosowanej biblioteki tylko Twój. Na przykład próbując prostą nieentrantną bibliotekę I2C stosować w przerwaniach. Ale już z takim libem jak ten: Link, który pamięta swój bieżący stan, takiego problemu by nie było bo próba rozpoczęcia transmisji w środku innej wywaliła by błąd BUSY. I co, wtedy byś napisał, że I2C na AVR jest be bo w przerwaniu transmisja nie dochodzi do skutku albo co gorsze program się wiesza?

  • Poziom 28  
    NoweMillennium napisał:
    Który z AVRmega ma dwa I2C?

    A programowo kolega nie umie zrobić? Działa i to dobrze.
    NoweMillennium napisał:
    Ardymenty sie kończą czy kolega chce zabłysnac wiedza na temat I2C?

    "Ardymenty" się nie kończą ale myślałem, że kolega trochę o tym poczyta i coś z tego, co wyczyta, rzuci mu się w oczy w odniesieniu do kontekstu wątku.Widocznie się przeliczyłem
    NoweMillennium napisał:
    Zaczyna się komplikować a wydawało by się, ze to jest proste
    .
    Jeśli ustawienie flagi, odczyt jej stanu w pętli głównej, reakcja na stan i reset flagi są dla kolegi skomplikowane to nie wiem ... rozkładam ręce.
    NoweMillennium napisał:
    Transmisję rozpoczac od poczatku? A co jak przerwania od expandera przychodza tak często, ze całej transmisji nie jestem w stanie zrealizować?

    Przeczytaj jeszcze raz, powoli, temat wątku. Przeczytaj jeszcze raz, powoli, w jakim wątku i dlaczego zaproponowałem użycie ESP8266 do realizacji kompletnej stacji pogodowej, zamiast kombinacji ESP + Arduino. Przeczytałeś? Zrozumiałeś? To teraz powiedz mi, dlaczego użytkownik miałby siedzieć przed stacją i non stop naciskać przycisk co, powiedzmy 1ms ??
    Wątek jest o stacji pogodowej, a Ty wyskakujesz z maszynami urywającymi ręce, koniecznością pełnej obsługi przycisku w przerwaniu w czasie 3ms itd. Jeśli pominąć temat wątku, to ktoś, kto MUSI odczytywać cokolwiek w przerwaniach ciągłych, jednocześnie wysyłając ważne dane ( gdziekolwiek ) i użył do tego wszystkiego expanderów I2C to po prostu spier**ł projekt. Choć i tu spokojnie można sprawę załatwić ale w aplikacjach "krytycznych" tego się nie robi bo to druciarstwo
    .
    NoweMillennium napisał:
    Pozwole sobie tego niekomentowac

    Co będziesz komentować, skoro nie masz racji? Wyjaśnię - co takiego w stacji pogodowej ( czy każdej innej aplikacji z UI ) wymaga pełnej obsługi przycisku w przerwaniu? Co robisz przyciskami? Inkrementujesz zmienną, zmieniasz "menu", zatwierdzasz itp. Ok, zrobisz to w przerwaniu i.. co dalej? Kiedy to zostanie wysłane na LCD? Czy użytkownik musi zobaczyć zmianę w ciągu "Twoich" 3ms?? Zauważy różnicę, jeśli to będzie 20ms zamiast 3??? Na LCD ??? W obsłudze przerwania ustawiasz flagę " przycisk_wcisniety", a resztą zajmuje się pętla główna. Jeśli wpieprzyłeś, jak mówiłeś, pierdyliard delay() w pętlę główną to spieprzyłeś program. Wytłumaczyć jeszcze jaśniej czy chcesz znów wyciągać coś z worka : multiplexing czy eliminację drgań styków ?( a propos - pewnie elimininację drgań styków kolega też by chciał w przerwaniu robić ? ( da się.. ale. . po co ? )
    zster napisał:
    To jest sedno pewnego problemu - ludzie wrzucają w IDE jakieś biblioteki, nie zawsze dobrze napisane i są rozczarowani "szybkością" czy niezawodnością. A później czyta się posty, gdzie ktoś poleca jakiegoś "potężnego" ARMa do zrobienia "przysłowiowego kalkulatora" z 4 działaniami...
    NoweMillennium napisał:
    Nie uzywam Arduino. To sie do niczego powaznego nie nadaje. Przenosiłem biblioteki LCD z Arduino na ARM i napisane są kiepsko. Wyświetlanie napisów jest żałośnie wolne. Akurat w tym konkretnym przypadku,problem nie leży w szybkości SPI tylko beznadziejnej implementacji rysowania znaku. Biblioteki do TM1637 porażka.

    Nawet nie przypuszczałem, że pisałem o Tobie.. a jednak ;) Zdefiniuj "poważne"? I dlaczego musisz uzywać bibliotek ze środowiska Arduino? Napisz własne. Pisz bez bibliotek. Poprawiaj istniejące. Pisz w asemblerze. Płytka Arduino = AVR. A Ty piszesz ( w potach wcześniej ) że na Arduino coś nie działa a na AVR już tak.
    To, co kolega tu wypisuje jako OGROMNY problem ( użycie expanderow do przycisków i LCD, z przerwaniami ) doskonale i bez problemów realizuje nawet dziurawa biblioteka Wire. Bez zająknięcia. Napisałem - nie wierzysz, sprawdź sam. Albo przyjedź do mnie, to Ci to na przykładach pokażę. Na żywo. Bez teoretyzowania.
    Żeby było jasne - nie trzymam sie kurczowo AVR. To już wiekowa architektura i ma sporo ograniczeń. Coś, nad czym na AVR trzeba się nie raz nagłowić, by zrobić, już np. na XMEGA robi się prosto. Ale twierdzenie, że AVR do niczego się nie nadaje, bo używa się dziurawych bibliotek czy nie umie się czegoś zrobić, to zwykła głupota.
    NoweMillennium napisał:
    Wystarczy ekspander włączyc na osobnej magistrali I2C.

    No tak, można też wstawić kolejny uC .. i kolejny, jeśli mamy więcej urządzeń po I2C....
    ex-or napisał:
    I co, wtedy byś napisał, że I2C na AVR jest be bo w przerwaniu transmisja nie dochodzi do skutku albo co gorsze program się wiesza?

    Widocznie NoweMillenium średnio radzi sobie z rozwiązywaniem prostych problemów i czuje imperatyw tworzenia sobie problemów tam, gdzie ich nie ma.
    I PONOWNIE, dla kol. NoweMillenium, temat wątku, gdyby jednak znów przeoczył : "Stacja pogodowa oparta na Arduino + WiFi".

    Dodano po 26 [minuty]:

    NoweMillennium napisał:
    O przerwaniach nadawczych dla TWI, USART, SPI to autorzy bibliotek dla Arduino nie słyszeli.


    To chyba kolega o tym nie słyszał. "Standardowe", dołączane do Arduino IDE biblioteki : HardwareSerial, Wire, SPI używają przerwań przy "nadawaniu" jak i "odbieraniu". Coś jeszcze?
  • Poziom 17  
    zster napisał:
    NoweMillennium napisał:
    Który z AVRmega ma dwa I2C?

    A programowo kolega nie umie zrobić? Działa i to dobrze.

    Niby banalna rzecz ale aby nie blokowoć CPU na czas przesyłania informacji trzeba zrobić to na przerwaniach. Niby prosta sprawa ale w przpadku 400kHz przerwanie następuje co 2,5us. ARM jeszcze daje rabe a biedny AVR? Proszę o przykład takiego "prostego" kodu wraz z zmierzonym(wyliczonym) obciązeniem CPU.

    Dodano po 4 [minuty]:

    zster napisał:
    To teraz powiedz mi, dlaczego użytkownik miałby siedzieć przed stacją i non stop naciskać przycisk co, powiedzmy 1ms ??
    Wątek jest o stacji pogodowej, a Ty wyskakujesz z maszynami urywającymi ręce, koniecznością pełnej obsługi przycisku w przerwaniu w czasie 3ms itd. J

    W jaki sporób realizuje się skuteczną likwidację drżenia styków? Styki drżą ok 20..30ms. Trzeba je więc odczytywac kilka razy częściej np co 1 czy 5ms. Kolega lepszy algorytm? Prosze pokazać. Jak narazie, to zawsze gdy pytam o te "proste" przykłady to kodu nie widzę. Czyżby to była tylko sfera mażeń kolegiaby posiadać taki kod? A może nie jest taki prosty?

    Dodano po 2 [minuty]:

    zster napisał:
    Co będziesz komentować, skoro nie masz racji? Wyjaśnię - co takiego w stacji pogodowej ( czy każdej innej aplikacji z UI ) wymaga pełnej obsługi przycisku w przerwaniu? Co robisz przyciskami? Inkrementujesz zmienną, zmieniasz "menu", zatwierdzasz itp. Ok, zrobisz to w przerwaniu i.. co dalej? Kiedy to zostanie wysłane na LCD? Czy użytkownik musi zobaczyć zmianę w ciągu "Twoich" 3ms??

    To dotyczy likwidacji drżenia styków, więc powstrzymam się od komentarza. Widać kolega nie likwiduje drżenia styków tak jak powinno się to robic tylko wstawia delay. Z chęcią zobaczyłbym program kolegi obsługujący klawiatuyrę.

    Dodano po 1 [minuty]:

    zster napisał:
    No tak, można też wstawić kolejny uC .. i kolejny, jeśli mamy więcej urządzeń po I2C....

    Po co kolejny? STM32F411 ma 6 I2C.

    Dodano po 2 [minuty]:

    zster napisał:
    Widocznie NoweMillenium średnio radzi sobie z rozwiązywaniem prostych problemów i czuje imperatyw tworzenia sobie problemów tam, gdzie ich nie ma.

    Ponownie więc proszę o przykład tego "prostego" kodu. Może skorzystam. Prosiłem już wielkrotnie ale kodu, jak żony Colombo, "ni widu ni słychu".
    Odnoszę wrażenie, że kod taki, wykracza poza mnożliwości intelektualne kolegi @zster. Skoro kolega nie wie jak należy likwidować drżenie styków o czym można się przekonać z wcześniejszych wypowiedzi, to współdzielenie I2C w programie głównym i przerwaniu, jest tylko w sfeże marzeń.
    Prosze pokaać ten kod programowego I2C, może zobaczę tam iskierkę geniuszu. Przekonany jestem jednak, że i2C nie jest realizowany na przerwaniach, nie obsługuje trybu Multimaster, nie realizuje przytrzymania SCL przez slavet itd, itp.

    Jak narazie przeczytałem jakim to jestem kiepskim progamistą ale niezobaczyłem ani kawałka kodu mistrza. Prosze więc pokazać swój kod, z którego mogłbym się czegoś nauczyć.