Elektroda.pl
Elektroda.pl
X
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.

msiuel 07 Maj 2018 12:24 2106 39
  • #31
    zster

    Poziom 28  
    NoweMillennium napisał:
    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ć.


    Tak samo, jak ty nadal nie zauważyłeś tematu wątku. Tak samo, jak ty nie odpowiedziałeś na moje pytania - odnośnie prędkości I2C, przerwań w bibliotekach, pytań o sens PEŁNEJ obsługi przycisku w przerwaniu w tym konkretnym. przypadku. Rzuciłem Ci kilka razy rękawicę - przyjedź, zabiorę Cię na kilka swoich instalacji, zobaczysz nad czym teraz pracuję i zobaczysz, co jest w mojej strefie marzeń, a co nie.
    NoweMillennium napisał:
    Widać kolega nie likwiduje drżenia styków tak jak powinno się to robic tylko wstawia delay
    W przypadku urządzeń, które produkuję, stosuję sprzętową eliminację drgań styków na dedykowanych do tego układach.
    NoweMillennium napisał:
    Trzeba je więc odczytywac kilka razy częściej np co 1 czy 5ms.
    Odczytywać kilka razy częściej i.. co dalej? Samo odczytywanie co 1ms to żaden debouncig, prawda? A z użyciem np. timera kolega nie umie ?

    Wiesz, dlaczego nie wrzuciłem żadnego kodu? Z takiego samego powodu, dla którego nie proszę o kod od ciebie - sprawy tu opisywane nie są żadnym odkryciem i każdy może sobie w sieci znaleźć fragment cudzego kodu, skopiować i wkleić tu. I co to udowodni? Nic. Dlatego piszę - przyjedź a sam się przekonasz. Zaczniemy od wykonania pomiaru prędkości I2C,
    NoweMillennium napisał:
    to współdzielenie I2C w programie głównym i przerwaniu, jest tylko w sfeże marzeń.

    Projektuję urządzenia i piszę programy tak, by nie stosować tego typu rozwiązań ( nadal nie doczekałem się odpowiedzi, po jaką cholerę w przerwaniu chcesz realizować PEŁNĄ obsługę przycisku i jego "otoczki" dla UI ) choć to w zupełności możliwe.
  • #32
    NoweMillennium
    Poziom 17  
    zster napisał:
    przyjedź, zabiorę Cię na kilka swoich instalacji, zobaczysz nad czym teraz pracuj

    Miały byc jakies fotki czy filmy ale jeszcze nie ma.

    zster napisał:
    W przypadku urządzeń, które produkuję, stosuję sprzętową eliminację drgań styków na dedykowanych do tego układach.

    Jak sie niepotrafi izrobić programowo, to sięga się po sprzęt. To pewnie nie sa tanie konstrukcje, jak uC jest otoczuny dziesiątkami układów, które sa zbędne.

    zster napisał:
    Samo odczytywanie co 1ms to żaden debouncig, prawda? A z użyciem np. timera kolega nie umie ?

    Umię, bo w przeciwieństwie do kolegi nie sięgam do rozwiązań sprzętowych w przypadku tak banalnych rzeczy. Dla kolegi coś takiego pozostaje w swerze marzeń.
    zster napisał:
    Projektuję urządzenia i piszę programy tak, by nie stosować tego typu rozwiązań ( nadal nie doczekałem się odpowiedzi, po jaką cholerę w przerwaniu chcesz realizować PEŁNĄ obsługę przycisku i jego "otoczki" dla UI ) choć to w zupełności możliwe.

    Pytanie tak samo bezsensowne jak np dlaczego obsługiwać usart na przerwaniach (nadawanie i odbiór) czy mulipleksowanie wyświetlacza.
    Można sobie obsługiwać klawiaturę na delay, ale w ten sposób to czy Intel8080 czy ARM 600MHz to para idzie w gwizdek. Wystarczy sie zastanowić lub przeczytać, jak często trzeba wywoływac funkcje obsługi USB czy Ethernetu w pętli głównej, aby sobie uświadomic, że przez bezsensowne dely w pętli główej położymy USB czy Ethernet. Nawet bufor odbirczy usarta (zwłaszacza w 99% AVR,które mają śladowe ilości RAM) nie jest nieskończony i nie mozna go odczytywac co sekundę a np co 100 czy 10ms. Jeden delay 100ms i wszystko może paść.


    Chciałem zobaczyć te profesjonalne konstrukcje ale strona z-ster.pl nie działa.
    Stacja pogodowa oparta na Arduino + WiFi - projekt, link.
  • #33
    zster

    Poziom 28  
    NoweMillennium napisał:
    Miały byc jakies fotki czy filmy ale jeszcze nie ma.

    Spokojnie, skoro nie chcesz podjąć rękawicy i przyjechać, to wstawię :)

    NoweMillennium napisał:
    Jak sie niepotrafi izrobić programowo, to sięga się po sprzęt. To pewnie nie sa tanie konstrukcje, jak uC jest otoczuny dziesiątkami układów, które sa zbędne.

    Tak? To po co sięgasz po ARMa? PO co Ci 2 i więcej magistral I2C czy UART? Przecież można to zrobić programowo. I masz rację - nie są to tanie rzeczy. Przy koszcie samych czujników na poziomie > 12k zł , parę zł za "niepotrzebne" układy to faktycznie rozrzutność. Rozumiem, że w rozwiązaniu przemysłowym najlepiej podpiąć przycisk bezpośrednio do uC, włączyć rezystor podciągający i cieszyć się, że działa? ;) A o debouncig programowy pytałem - na timerze kolega nie umie?
    NoweMillennium napisał:
    Pytanie tak samo bezsensowne jak np dlaczego obsługiwać usart na przerwaniach (nadawanie i odbiór) czy mulipleksowanie wyświetlacza.
    Można sobie obsługiwać klawiaturę na delay, ale w ten sposób to czy Intel8080 czy ARM 600MHz to para idzie w gwizdek. Wystarczy sie zastanowić lub przeczytać, jak często trzeba wywoływac funkcje obsługi USB czy Ethernetu w pętli głównej, aby sobie uświadomic, że przez bezsensowne dely w pętli główej położymy USB czy Ethernet. Nawet bufor odbirczy usarta (zwłaszacza w 99% AVR,które mają śladowe ilości RAM) nie jest nieskończony i nie mozna go odczytywac co sekundę a np co 100 czy 10ms. Jeden delay 100ms i wszystko może paść.

    Po kiego grzyba znów mieszasz i porównujesz różne aplikacje i różne rozwiązania? Gdzie ja wspomniałem, by klawiaturę realizować na delay()?? Gdzie była mowa o multiplexowaniu czy USB?? Pytanie było jasne i dokładne :
    Masz układ z wyświetlaczem i paroma przyciskami do zmian parametrów itp. Czemu, według ciebie nie wystarczy w przerwaniu od przycisku ustawić flagi a resztę obsługi zostawić w pętli głównej?
    NoweMillennium napisał:
    Chciałem zobaczyć te profesjonalne konstrukcje ale strona z-ster.pl nie działa.

    90% konstrukcji objętych jest umowami NDA. Prostymi konstrukcjami nie mam emocjonalnej czy biznesowej potrzeby chwalenia się.
  • #34
    NoweMillennium
    Poziom 17  
    zster napisał:
    Spokojnie, skoro nie chcesz podjąć rękawicy i przyjechać, to wstawię

    Już jadę 500km. Chory musiałbym być albo nie mieć za dużo czasu i pieniędzy, zresztą po co skoro
    zster napisał:
    90% konstrukcji objętych jest umowami NDA.

    Program może jest napisany w Bascom ale wstyd się przyznać?

    zster napisał:
    To po co sięgasz po ARMa?

    Powtórze jeszcze raz:
    Cytat:

    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)

    Ile jeszcze razy mam to napisać? Jak w szkole, przepisac 100 razy?
    Prosze wymienić zalety AVRmega. Ile ich będzie? Trzy istotne?


    Nie lepiej aby kolega przyznał, że odczytywanie w przerwaniu danych z ekspandera po I2C w sysuacji gdy program główny może transmitowac dane, nie jest sprawą prostą.
    Jesli byłoby to takie proste, to zobaczyłbym kod i kolega by się niezasłaniał NDA albo tym, że
    zster napisał:
    Prostymi konstrukcjami nie mam emocjonalnej czy biznesowej potrzeby chwalenia się.

    Klepnąl kolega głupotę a teraz próbuje odwieść dyskusję od nieszczęsnej wypowiedzi i udowadnia, po co drżenie styku realizować na przerwaniach, po czo więcej niż I2C 9(ci z STM-a to głupole bo zrobiliw jednym uC 6 I2C), proponuje realizowac programowe I2C które działa jak delay i w czasie transmisji zajmuje 100% mocy uC.
    Czy kod obsługi I2C na przerwaniach w AVR jest banalnie prosty i
    zster napisał:
    Prostymi konstrukcjami nie mam emocjonalnej czy biznesowej potrzeby chwalenia się.
    czy może NDA? Nie zobaczę kodu kolegi programowego I2C na przerwaniach, wystarczy policzyć jaka bedzie zajętość procesor przy przerwaniach 400kHz. To jakieś 80..90%. Mylę się? Prosze pokazać fragment kodu albo chiciaż algorytm.

    Zarzuca mi kolega nieznajomośćbibliotek Arduino, jak się kolega odniesie do wypowiedzi https://www.elektroda.pl/rtvforum/viewtopic.php?p=17207983#17207983
    Znów zasłoni się NDA? Chciałbym zobaczyć te umowy NDA kolegi, z jakimi firmami sa podposane, bo odnosze wrażenie, że niedawono prowadzona dyskusja na ten temat na forum pozwoliła koledze dowiedzieć się o tego typu umowach.
  • #35
    zster

    Poziom 28  
    NoweMillennium napisał:
    Czas transmisji bajtu po I2C przy 100kHz (Arduino tyle nie wyciąga, przynajmniej na AVR)

    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.

    NoweMillennium napisał:
    Już napisałem, sprawdziłem organoleptycznie oscyloskopem.


    Kod: c
    Zaloguj się, aby zobaczyć kod

    Stacja pogodowa oparta na Arduino + WiFi - projekt, link.
    Stacja pogodowa oparta na Arduino + WiFi - projekt, link.
    Chiński klon Arduino UNO. PCF8574N.Bzdetny, najbanalniejszy kod napisany w Arduino IDE z użyciem dziurawej biblioteki Wire. Chińska płytka stykowa, rezystory podciągające jakie miałem pod ręką, chyba 7.5k. Teraz czekam, co wymyślisz.

    Dodano po 8 [minuty]:

    NoweMillennium napisał:
    Program może jest napisany w Bascom ale wstyd się przyznać?

    Oczywiście :)
    Piszesz, że programowe to i tamto "obciąża" uC, chwalisz ARMy za mnogość peryferii ( popieram - tu niczego nie neguję ) a jednocześnie ganisz mnie za stosowanie sprzętowego debouncingu przycisków w profesjonalnych rozwiązaniach gdzie koszt to sprawa drugorzędna a na wspomnienie, że w "zabawkach" używam timerów do tego - milczysz. Jednocześnie chcesz pełnej obsługi przycisku w przerwaniu, zamiast wrzucić odczyt portu do pętli głównej a w przerwaniu tylko wystawiać flagę... rozdwojenie jaźni? Temat jest prosty - Stacja pogodowa na arduino. Co chwilę wyskakujesz z rzeczami, które z tym związku nie mają. Odczyt przycisku w ciągu 3ms znaczenia tutaj nie ma. Równie dobrze może to być 50ms, z czym pętla główna poradzi sobie "z zapasem".
    Reszty nie chce mi się komentować. Przyjedź - zobaczysz. Nie chcesz - nie komentuj i nie mierz wszystkich swoją miarą.
  • #36
    NoweMillennium
    Poziom 17  
    zster napisał:
    Odczyt przycisku w ciągu 3ms znaczenia tutaj nie ma. Równie dobrze może to być 50ms, z czym pętla główna poradzi sobie "z zapasem".

    Jesli czyta się co 50ms to można zakłócenia potraktowac jako naciśnięcie przycisku. Dlatego kolega uzywa zewnetrzych układów, bo niepotrafi, bez delay, odczytac kilka razy stanu GPIO (np co 1 czy 5ms), zrealizowac filtr RC lub w inny sposób pozbyc sie stanów nieustalonych. Waracamy więc do tego, że aby dobrze odczytać stan przycisku, trzeba czytać go co kilka ms. Praw fizyki pan nie zmienisz. Styk drga 20..30ms i to jest fakt. Nie potrafisz sobie kolego zrobić tego programowo, sięgasz po sprzet. To też jest fakt.

    Co do I2C, niezrobiłem zrzutów ekranu oscyloskopu. Tranzmisja była wolna, dowolne zakłócenie I2C (np brak rezystora podciągającego) zawieszał program. Może przez 2 lata cos się zmieniło, nie mam ochoty tego sprawdzać. Wystarczy gdy portuje biblioteki na ARM abym zobaczył jak (bardzo czesto) są napisane beznadziejnie.

    Nadal kolega odniega od głównego tematu naszej dyskusji, prostego realizowania transmisji I2C w przerwaniu i programie głównym.

    Co do tego, dlaczego używam ARM mogę dodac:
    - argument liczbowy w sprintf, scanf itp nie jest ograniczony do int
    - przesówane bitu (na pewno w lewo) nie jest ograniczone do 15.
    Prosze wymienic zalety AVR.
  • #37
    zster

    Poziom 28  
    Zaśmiecanie wątku kończę, dyskusja, jak zaproponowałem na samym początku, przeniesie się na PW, chyba, że moderatorzy zechcą wydzielić ją do osobnego wątku.
    Koledze autorowi, jeśli zechce, służę pomocą i udostępnieniem kodu by mógł ruszyć, jakiekolwiek rozwiązanie wybierze.
  • #38
    NoweMillennium
    Poziom 17  
    zster napisał:
    Zaśmiecanie wątku kończę

    Faktycznie śmiecenie. Dużo zostało napisane a prostego rozwiązania transmisji I2C w programie głównym i przerwaniach jak nie było tak nie ma. A wydawało sie to banalne, pozwolę sobie przypomieć:
    zster napisał:
    NoweMillennium napisał:
    I problemy gdy trzeba obsłużyc przerwania od expanderów.

    Jakież to problemy ??

    Kilka problemów wskazałem, prostego rozwiązania kolego @zster jak nie było tak nie ma.
  • #39
    msiuel
    Spec od TV
    Niestety dyskusja stała się trochę za bardzo emocjonalna i Odbiegła od tematu głównego.

    Pozdrawiam.
  • #40
    msiuel
    Spec od TV
    Dodano po 50 [sekundy]:

    Dyskusja odbiegła od tematu głównego + emocje.

    Pozdrawiam.