W dniu 2016-01-28 o 17:34, Piotr Wyderski pisze:
To fakt. U konkurencji trudno byłoby dostać 32 bitowy mikrokonktroler w obudowie DIP28. Z drugiej strony tę lukę łatają producenci maleńkich "zestawów uruchomieniowych", w formie przypominającej np. DIP40.
Większość Chinskiej (w sensie lokalnych "marek") elektroniki użytkowej jest napędzana ich własnymi klonami 8051. Jest tego mnóstwo.
mikrokonktroler w
Zdawało mi się, że, widziałem stm32 albo lpc w dip16 nawet.
On 2016-01-29 11:28, Atlantis wrote: [...]
Urządzeń zaprojektowanych -naście czy 20+ lat temu i nadal produkowanych[*] pewnie trochę się znajdzie. Poszukiwania zacząłbym od urządzeń fiskalnych.
[*] - co jest bólem dupy producentów ponieważ urządzenia się sprzedają, ale kłopotem jest dostępność MCU oraz problemy z rozwojem oprogramowania (brak pamięci).ogólnie co warto zgrać zanim zniknie? jakie pdfy?
Kiedyś ktoś rzucił link do ARMa w DIP8. Aż tak wygórowanych roszczeń nie mam, ale brak (?) ARMmów w obudowach SO2x jest głównym czynnikiem powstrzymującym mnie od całkowitego porzucenia ośmiobitowców. QFP z odstępami 0,5..0,6mm mnie w moich projektach nie kręci.
dsPICe są.
Pozdrawiam, Piotr
użytkownik Piotr Wyderski napisał:
Ileż producentowi zejdzie uC w DILu?
0,01% tego co w QFN? Patrzę sobie
Microchip jednak robi i fakt kto kogo kupuje pokazuje, że to oni mają rynkowo rację. ;-)
Pozdrawiam, Piotr
Co nadal nie zmienia faktu, że corowo są daleko w tyle za atmegą. Mi chodzi tylko o to, by z nierzetelnyvh porównań nie tworzyć powszechnie funkcjonującej błędnej oceny. User obeznany z atmega słyszy "pice mają fajne peryferia".Zaciekawiony zaczyna googlać, najczęściej trafi w sieci na projekty z archaicznymi 16F (dlaczego - o tym niżej). No to realizuje swój projekt na 16F. Przyzwyczajony do architektury z atmegi mocno się rozczaruje napotykając na archaizmy architektury. Później po rozczarowaniu będzie gadał, że pice (wszystkie 8bitowe) są do bani. Nie, to 16F są do bani. 18F są od nich lepsze, nie tylko corowo ale i peryferiami. Dlaczego 8bitowy pic kojarzy się głównie z 16F? A to już efekt durnej polityki Mchp. Brak darmowych dobrych narzedzi do programowania 18F powoduje, że nie ma parcia na ich zastosowanie. A płatne (XC8) w wersji limitowanej-darmowej generują celowo dummy instructions by spowolnić kod (!). Starsi przyzwyczajeni do pic tkwią w 16F i przez to generują powszechną świadomość, że pic 8bitowy to 16F.
On 2016-01-29 13:07, Piotr Wyderski wrote: [...]
No ale MC w DIP28 robi MIPS-y a nie ARM-y. Chociaż z drugiej strony to prawie "the same shit". :-)
Znaczy się MC kupuje ARM-a? :-D
BTW Proszę bardzo, Cortex-M0 w DIP8:
Owszem, ale chyba nikt poważny nie uważa, że AVR czy 16F to Pentium. A dzieciarnia niech się podnieca mikroskopijną tak czy inaczej mocą obliczeniową, uparcie nie chcąc przy tym zauważyć, że nie po to te mikrokontrolery są.
A to już mi się w głowie nie mieści, ale cóż... to oni kupują Atmela mającego port GCC, a nie odwrotnie. :-)
Pozdrawiam, Piotr
Przecież oczywiście! Niby na podstawie czego ostatnio w mediach przelał się entuzjazm zwiazany z pewna firmą z Bytomia i ich wizjonerskim procesorem do szybszego migania didoami w projektach z lat 70? Jeszcze troche i wznowią MCY7880 z zegarem 4GHz. Czekamy.
Mchp popsucie gcc też niestraszne. Przecież do pic32 zrobili port gcc po czym do kodu gcc dodali licence menager'a aby nie można było bez opłaty $1000 wywoływać gcc z inną opcją optymalizacyjną niż -O1.
A PIC32 to nie jest zwykły MIPS i MC może sobie co najwyżej pogrozić paluszkiem?
W dniu 2016-01-29 o 17:28, Marek pisze:
Mam nadzieję że tak nie ukatrupią AVR-ów i gcc do nich.
Nawet sobie nie zdajesz sprawy ile prostych sterowników jest na tym robione, w przemyśle.
No PIC32MX to jest niezwykły MIPS bo bez MMU. :-) PIC32MZ już mają MMU.
Ale musieli do gcc dodać parę rzeczy, co natywne gcc do mpisa nie wygeneruje w wymikowym pliku bo nie zna "obudowy" arch. pic32 do mipsowego core'a a dystrybucja jest binarna. Oczywiście udostępniają źródła (gpl, wiadomo) ale dla usera windowsowego niezwyczajnego do kernelowania kompili przekompilowanie gcc 4.* wraz z wymaganymi zewnętrznymi libami to nie w kij dmuchał. Na szczęście puścili oko do tych co będą kompilować i w źródłach gcc licence manager jest dodany w bloku
#ifndef DISABLE_LM ... #endif
;-)
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.