Mówiący pojemnościowy czujnik wilgotności gleby

Miejsce dobre do dyskusji nad własnymi projektami - pochwal się wszystkim co samodzielnie stworzyłeś.
ODPOWIEDZ
es2
Użytkownik
Posty: 110
Rejestracja: 13 mar 2018, 9:47

Mówiący pojemnościowy czujnik wilgotności gleby

Post autor: es2 » 16 sty 2020, 0:05

Możliwości STM32G030J6M6 są zadziwiające. STMG0 jest tańszy https://www.tme.eu/pl/details/stm32g030 ... ectronics/ od Tiny85 https://www.tme.eu/pl/details/attiny85- ... hip-atmel/, który zmieściłby dwa razy krótszy komunikat. Tak mały uC pozwala na pojemnościowy pomiar wilgotności oraz wypowiadanie komunikatów. Pomiar pojemnościowy pozwala zaizolować elektrody sondy co gwarantuje ich dużą żywotność spowodowaną brakiem elektrolizy.

Filmy: https://www.youtube.com/playlist?list=P ... CF27h4oKdV. Gdy tylko uda się wykonać nagranie lepszej jakości znajdzie się ono na YT. Oczywiście nie należy spodziewać się jakości Hi-Fi, samplowanie 8-bit 8kHz wnosi ograniczenia. Gdy zaimplementuje algorytm G711u/aLaw pozwalającą skompresować 12-bit do 8-bit, jakość dźwięku poprawi się. Kolejną poprawę wniesie zastosowanie na wyjściu filtru dolnoprzepustowego, co wyeliminuje metaliczny pogłos spowodowany PWM-em.


Na razie można zapomnieć o realizacji takiego projektu na Arduino, które nie obsługuje STM32G0 ale trzeba żyć nadzieją, że to się zmieni, nadzieją, której nie mają użytkownicy Bascom, który swój rozwój zakończył na nieudanej, bo drogiej i powolnej rodzinie Xmega.
Kto pamięta Bascom? Czy jest używany? Pewnie "umarł" tak jak Logo, który miał "świetlana" przyszłość bo wprowadzono go do szkół ponadpodstawowych, jeden z "chorych" pomysłów ekipy rządzącej, która nie potrafiła i nie potrafi uleczyć "chorej' służby zdrowia.


Czy rodzina G0 zastąpi małe AVR?
W moim przypadku ARM już dawno zastąpił AVR. Dlaczego?
- ARM przeważnie są tańsze niż AVR o podobnym wyposażeniu oferując zdecydowanie większe możliwości (DMA, więcej bardziej zaawansowanych niż w AVR peryferii) i prędkość działania.
- ARM, przy tym samym zegarze jest ok 7 razy szybszy od AVR, a maksymalne częstotliwości taktowania zaczynają się od 24MHz a kończą na 650 (w przypadku rodziny STM32).
- W przeważającej większości mają więcej pamięci RAM i można robić duże bufory nadawcze dla UART, I2c, SPI, USB.
- Maja bogatsze wyposażenie (liczba USART/UART, I2C, SPI, timerów) i większe możliwości tychże peryferii. 12 UART w STM32 nie jest problemem, AVR max 4. Można dołożyć np SC16IS7xx ale 1 UART to ok 10zł, 2 ok 19zł).
- Mają DMA (AVR ATmega/tiny nigdy o czymś takim nie słyszały).
- Wiele ARM ma USB, w AVR to rzadkość a USB jest teraz pewnym standardem.

- Sprzętowe sterowanie przepływem i kierunkiem transmisji (RS485), wykrywanie końca ramki, określanie prędkości transmisji.
- Wersje z Ethernetem, AVR nie ma z ETH.
- Wszystkie timery 16-bit (można łączyć w 32-bit) a wiele wersji posiada 32-bit.
- ADC 12..16-bit, CA 12-bit.
- ADC do 80MS/s (LPC), 18MS/s (STM32).
- Mają wielopoziomowy system przerwań (15 poziomów, Xmega tylko 3, Mega/Tiny 0 ale najnowsze wersje maja już 2/3 poziomy).
- Zdecydowanie większe pojemności pamięci FLASH (do 2MB) i RAM (do 1MB) o czym nawet AVR Xmega mogą tylko pomarzyć.
- Sprzętowe interfejsy CAN, LCD równoległe, matryce LCD kolor 18-bit.
- Stany wyjątkowe: Błąd magistrali i podobne jak w MC68k (dawne MAC, Amiga).
- Kilkadziesiąt razy tańsze narzędzia. Ddebuger STM32 - 13zł vs bodaj najtańszy klon JTAG-ICE 45zł (tylko JTAG), ATATMEL-ICE-PCB 300zł, w obudowie 700 (Basic 470zł), Dragon ok 450zł.

- CubeMX do konfigurowania i generowania kodu (najnowszy także IDE i kompilator).
- Podczas debugowania na bieżąco widzę stan zmiennych w AVR po zatrzymaniu uC.
- Nie muszę się zastanawiać czy dana jest w ram czy flasch aby użyć stosownej funkcji (z sufiksem _P).
- Argument w sprintf, scanf itp nie jest ograniczony do 16-bit int lecz do 32-bit.
- Przesuwane bitu (w lewo) nie jest ograniczone do 16 bitów.
- W AVR nie ma typu double, ma taki sam zakres jak float. I tak dobrze, że od którejś tam wersji, typ long long ma 64-bity a nie jak wcześniej 32-bit tak samo jak long.
- AVR nie mają FPU, STM32 wiele rodzin posiada FPU.
- Odkładanie na stos w przerwaniu rejestrów, które czasem nie są używane (R0, R1, RAMPZ, rejestr statusu) co wymusza czasem używanie wstawek ASM.


Porównanie Tiny85 z STM32G030:

Kod: Zaznacz cały

     	     	     	Tiny85			STM32G0   
			---------		-------------
Zegar			20MHz			64MHz
Rdzeń			8-bit			32-bit
FLASH			8kB			32kB
RAM        		512B			8kB
EEPROM			512B			- *
Timery			2 (8 i 16 bit)		8 (16-bit) + SYS w rdzeniu
UART			-			2 (wykrywanie prędkości i końca ramki, sprzętowe sterowanie przepływem, sprzętowe sterowanie kierunkiem RS485)
I2C			USI **			2
SPI			USI **			2
RTC			-			+
DMA			0			1 (5 kanałów)
ADC10-bit		10-bit			12-bit
WDG			+			2 (tradycyjny i okienkowy)
Generator CRC		-			+
Licz. poziomów przerwań	1			4
Kontroler przerwań	-			+
Interfejs IR		-			+
* - STM32 ma tak duży FLASH, że można w nim emulować EEPROM, Przeważnie w uC EEPROM jest emulowany w pamięci FLASH "poza świadomością" programisty.
** - Albo I2C albo SPI. Oba interfejsy z silnym wspomaganiem programowym.
Jak widać, tańsze nie znaczy gorsze, wręcz przeciwnie, tańsze znaczy dużoooooo lepsze.

ODPOWIEDZ