Dlaczego lepsze tańsze jest mniej popularnego od gorszego droższego?

Tutaj mozesz poruszać tematy ogólne powiązane z elektroniką, np. dyskusje na temat podzespołów, układów, zasad ich działania. Czyli można pisać o wszystkim czego nie da się przyporządkować do innych działów.
ODPOWIEDZ
es2
-
Posty: 97
Rejestracja: 13 mar 2018, 9:47

Dlaczego lepsze tańsze jest mniej popularnego od gorszego droższego?

Post autor: es2 » 16 sty 2020, 20:31

Nie do końca wiem dlaczego AVR są popularniejsze od ARM, mimo tego, że przy porównaniu możliwości i ceny AVR, przegrywają na całej linii. W linku https://forum.elportal.pl/viewtopic.php ... 905#p97905 znajduje się porównanie 8-nóżkowych ARM i AVR, poniżej porównanie popularnego dzięki Arduino Mega328 z STM32030.
ATMEGA328P-AU (7,64zł) https://www.tme.eu/pl/details/atmega328 ... hip-atmel/
zbliżony cenowo, podobna liczba GPIO:
STM32F030C8T6 (7.45zł) https://www.tme.eu/pl/details/stm32f030 ... ectronics/

Kod: Zaznacz cały

						Mega328P		STM32F030
Rdzeń						8-bit			32-bit
Zegar						20MHz			48MHz
FLASH						32kB			64kB	
RAM     			   		2kB			8kB
EEPROM						1kB			- *
Timery						2 (2x8, 1x16)	11 (16-bit) + SYS w rdzeniu
UART						1 			2 6Mb (wykrywanie prędkości i końca ramki, sprzętowe sterowanie przepływem, sprzętowe sterowanie kierunkiem RS485)
I2C						1 800kHz		2 1Mb
SPI						1 (2***) 10Mb		2 18Mb		
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			15
Kontroler przerwań				-			+
* - 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.
*** - kosztem UART, realny transfer ok 5Mb/s
**** - kosztem timera 2. Wymagane silne wsparcie programowe (wybudzanie uC co zadany czas, najczęściej sekundę).
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ł.
Jak widać, tańsze nie znaczy gorsze, wręcz przeciwnie, tańsze znaczy dużoooooo lepsze.

Dlaczego więc w czasach gdzie głównie liczy się cena, jakość ma mniejsze znaczenie, ARM są mniej popularne? Za dobre są? Wydaje mi się, że powód jest inny, wywołany mitami, podobnymi jak i w przypadku RTOS:
1) Trudna konfiguracja zegara.
2) Trudna obsługa peryferii.
Naturalnie to mity. Co do punktu 1, często zegara nie trzeba konfigurować, jeśli już, to wygodnie robi się to w przypadku STM32, z wykorzystaniem CubeMX.
Co do punktu 2, używając HAL obsługa peryferii jest tak banalna jak i z poziomu Arduino.
Ostatnio zmieniony 20 sty 2020, 11:30 przez es2, łącznie zmieniany 2 razy.

Awatar użytkownika
kayron
Użytkownik
Posty: 2079
Rejestracja: 21 wrz 2008, 12:53
Lokalizacja: Poland
Kontakt:

Re: Dlaczego lepsze tańsze jest mniej popularnego od gorszego droższego?

Post autor: kayron » 16 sty 2020, 22:39

No to ja, trochę z innej beczki.
Dla czego wszyscy zatrzymali się na ARDUINO UNO? Jest przecież ARDUINO ZERO na ARM, skoro chcemy rozmawiać o ARM.
Rozumiem że UNO to taka sztampowa płytka, ale chyba czasy świetności minęły.
Z drugiej strony wyprzedzając, trochę odpowiedz. Skoro użytkownicy ARDUINO w większości nie chcą się rozwijać, poza przykłady, to czy jest to w stanie coś zmienić?
Co do STM32, może jakby ktoś pokazał jak to ruszyć w ARDUINO IDE, to by się coś ruszyło.

es2
-
Posty: 97
Rejestracja: 13 mar 2018, 9:47

Re: Dlaczego lepsze tańsze jest mniej popularnego od gorszego droższego?

Post autor: es2 » 16 sty 2020, 23:45

kayron pisze:
16 sty 2020, 22:39
No to ja, trochę z innej beczki.
Dla czego wszyscy zatrzymali się na ARDUINO UNO?
Nie wszyscy. Są taco co zakochali się w ESP ale ESP8266 sprzętowo prezentuje się skromie a ESP32 też ma spore ograniczenia, przypomina taki słabiutki RPi ZERO ze swoimi ograniczeniami co do liczby GPIO oraz peryferii.
Na razie wykorzystuje ESP8266 głównie w roli karty sieciowej, rzadko znajduję zastosowania, w których mógłby działać samodzielnie.
kayron pisze:
16 sty 2020, 22:39
Jest przecież ARDUINO ZERO na ARM, skoro chcemy rozmawiać o ARM.
Najlepszy uC nic nie zmieni w Arduino gdy:
- Nie będzie bibliotek wykorzystujących możliwości uC. Aby wykorzystać możliwości ARM trzeba używać sprzętu (przerwań, DMA) czego arduinowe biblioteki nie robią. Przenosiłem biblioteki obsługi LCD z Arduino na ARM i to co widziałem tam woła o pomstę do nieba. W konsekwencji przeniesienie biblioteki daje praktycznie zerowe przyspieszenie. Dopiero gdy zagoniłem DMA do pracy wyświetlacz zaczął działać z max prędkością. One Wire, WS2812 kolejne przykłady jak nie pisać bibliotek. Nawet obsługa banalnego TM1637 i podobnych jest zrealizowana źle, przez delay i "machanie" pinem. Jak sięgam pamięcią nie widziałem biblioteki dla Arduino, która byłaby napisana "z głową", przypominają mi one czasy 8051 czy Z-8, gdzie większość interfejsów realizowano programowo ale było to spowodowane brakiem interfejsów sprzętowych w uC lub wysoka ceną uC wyposażonych w odpowiednie interfejsy. AVR interfejsy ma, ale Arduino ich nie używa! W zakresie wykorzystania sprzętu lepiej wygląda Bascom.
- Najszybszy uC zostanie skutecznie spowolniony przez "programistę" używającego delay itp.
kayron pisze:
16 sty 2020, 22:39
Z drugiej strony wyprzedzając, trochę odpowiedz. Skoro użytkownicy ARDUINO w większości nie chcą się rozwijać, poza przykłady, to czy jest to w stanie coś zmienić?
Niestety, też widzę, że chęci nauki nie ma o czym świadczą tematy zakładane na forach.
kayron pisze:
16 sty 2020, 22:39
Co do STM32, może jakby ktoś pokazał jak to ruszyć w ARDUINO IDE, to by się coś ruszyło.
Arduino IDE można kazać używać za karę. Brak debugera skutecznie zniechęca aby na tym czymś, zwanym IDE, pracować. Porażka na całej linii. Wbudowane biblioteki mają różne "kwiatki", które widać w obsłudze GPIO oraz przerwania "systemowego".

Dla STM32 proponuje CubeIDE. Wcześniej używałem CubeMX + KEIL ze względu na problemy z połączeniem Eclipse z GCC. CubeIDE rozwiązuje ten problem i przyznam, że Eclipse bije na głowę płatnego KEILA. Co do GCC vs KEIL to nie robiłem porównań "jakości" generowanego kodu ale jeśli chodzi o szybkość kompilacji to różnica ponad 6 krotna. Kompilacja wszystkich plików (ten sam projekt) GCC 8 sekund, KEIL ponad minutę. Teraz nie będę już czekał 25minut na kompilację dużego projektu podczas której można zrobić śniadanie i je zjeść.
kayron pisze:
16 sty 2020, 22:39
Rozumiem że UNO to taka sztampowa płytka, ale chyba czasy świetności minęły.
Zwłaszcza, że są dostępne wypasione tanie płytki NUCLEO. STM32F1 i F4 są obsługiwane przez ArduinoIDE więc niby nie ma problemu aby ich używać, właśnie, niby. Wiele arduinowych bibliotek nie zadziała z innym uC niż AVR. Wygląda to tak jakby społeczność Arduino nie zauważało uC innych niż AVR podobnie jak firma Atnel a takie postępowania, na dłuższą metę, doprowadzi do upadku. Niewątpliwie biznes półprzewodników napędzają nie amatorzy ale odbiorcy hurtowi a ceny uC mówią same za siebie.
Większość peryferii pracuje przy max 3,6V. Niby AVR może być zasilany takim napięciem ale wtedy max zegar to nie 20MHz lecz np 12. Spowalniać powolny uC to raczej zły pomysł. Trzeba więc dodawać konwertery poziomów co generuje koszty, zmniejsza niezawodność, zwiększa pobór prądu, powierzchnię na PCB itd. Można oczywiście przetaktować uC ale to na własny użytek a nie w seryjnej produkcji, choć są kamikadze, np MiniPlayer Atnela przetaktowany o 20%.
Niedużym firmom też nie opłacają się AVR. W tym przypadku, kilkuzłotowa różnica w cenie uC, przy cenie końcowego produktu 100..200zł czy więcej nie ma znaczenie ale znaczenia nabiera czas a co za tym idzie koszt opracowania urządzenia (napisania programu). Program na ARM pisze się szybciej niż na AVR czyli taniej.

AVR niewątpliwie "umrą" jak 8051 czy Z-8 i wszystko wskazuje, że ten proces już się rozpoczął. Na Elektrodzie, jeszcze trzy lata temu, więcej było tematów dotyczących AVR, mniej ARM, teraz jest (na szczęście) odwrotnie.
ARM tez kiedyś umrze, prawdopodobnie zastąpi go RISC-V. Jedna jaskółka wiosny nie czyni ale pojawiły się GD32FV1xx. Dobry ruch, bo peryferia są kompatybilne z STM32F1xx, różnica tylko w rdzeniu. Dla programisty w C/C++ to żadna różnica! Inny rdzeń to "problem" kompilatora.

Awatar użytkownika
kayron
Użytkownik
Posty: 2079
Rejestracja: 21 wrz 2008, 12:53
Lokalizacja: Poland
Kontakt:

Re: Dlaczego lepsze tańsze jest mniej popularnego od gorszego droższego?

Post autor: kayron » 17 sty 2020, 17:34

No cóż ja mam na stole dwa ESP8266-01, ale na razie szukam jakiś sensownych materiałów jak to ruszyć?
Na jednym chcę zrobić czujnik temperatury i wilgotności na strych. Na drugim konwerter RS485 MODBUS <>WIFI dla ORNO 504. Przy czym tutaj chyba popełniłem błąd wybierając konwerter RS232<>RS485, bo za pomniałem że ESP pracuje na 3,3V, ale chyba dwie zernerki 3,3V rozwiążą problem.
Na razie nie zdecydowałem czy Domoticz, czy SUPLA, bo tak. Domoticza musiałbym na czymś postawić, a to mi się średnio podoba. Nie widzę sensu dokupowania Raspbbery PI choćby ZERO, nie o to mi chodzi, aby do układziku za 5,50zł dokładać serwer za 85zł. SUPLi jak dotąd nie rozgryzłem z czym to się je? Ale pozbycie się serwera, na rzecz chmury, jest ciekawsze.

es2
-
Posty: 97
Rejestracja: 13 mar 2018, 9:47

Re: Dlaczego lepsze tańsze jest mniej popularnego od gorszego droższego?

Post autor: es2 » 17 sty 2020, 23:05

kayron pisze:
17 sty 2020, 17:34
No cóż ja mam na stole dwa ESP8266-01, ale na razie szukam jakiś sensownych materiałów jak to ruszyć?
Chcesz dobierać się do sprzętu czy użyc Arduinio?
ESP8266 jest skromie wyposażony, raczej odradzam zabawę z nim.
kayron pisze:
17 sty 2020, 17:34
Na jednym chcę zrobić czujnik temperatury i wilgotności na strych. Na drugim konwerter RS485 MODBUS <>WIFI dla ORNO 504.
To już jest http://es2.noip.pl:84/
Nie musisz wyważać otwartych drzwi. Naturalnie ma ograniczenia wnoszone przez "srajduino" i samo ESP.

kayron pisze:
17 sty 2020, 17:34
Przy czym tutaj chyba popełniłem błąd wybierając konwerter RS232<>RS485, bo za pomniałem że ESP pracuje na 3,3V, ale chyba dwie zernerki 3,3V rozwiążą problem.
Użyj MAX3485 lub odpowiedników (ST, AMD) zamiast MAX485 czy odpowiedników zasilanych z 5V.
Sama transmisja (fizyczna) 485/422 to poziomy (różnica) najczęściej +/-200mV i nie ma nic wspólnego z napięciem zasilania układu drivera.
kayron pisze:
17 sty 2020, 17:34
Na razie nie zdecydowałem czy Domoticz, czy SUPLA, bo tak. Domoticza
Dla mnie przereklamowane. Na RPi i AVR, ESP (ARM na razie tam nie ma) zrobiłem http://es2.noip.pl/automatyka/
Nie trzeba jakiś tam Domoticz i uczyć się jak to działa, wystarczy znajomość PHP.
kayron pisze:
17 sty 2020, 17:34
musiałbym na czymś postawić, a to mi się średnio podoba.
Możesz użyc darmowego serwera w Internecie.
kayron pisze:
17 sty 2020, 17:34
Nie widzę sensu dokupowania Raspbbery PI choćby ZERO, nie o to mi chodzi, aby do układziku za 5,50zł dokładać serwer za 85zł.
Nie dokładaj układu za 5,5zł, zrób wszystko (nie zawsze sie da, np dobrze obsłużyć WS281x) na RPi.
kayron pisze:
17 sty 2020, 17:34
SUPLi jak dotąd nie rozgryzłem z czym to się je?
Nie wiem. Nie próbowałem bo jak potrzebuję to robię takie rzeczy w PHP na tym na czym chcę.

ODPOWIEDZ