Różnice pomiędzy pracą z prockami różnych producentów są duże, czy raczej symboliczne?
Jeśli przyzwyczaję się do STM-ów, będę mógł względnie łatwo przygotować projekt na czymś od Atmela?
Zdecydowałem się na STM32 z kilku powodów. Po pierwsze z tego co widzę są one stosunkowo łatwo dostępne i całkiem popularne. Po drugie można łatwo kupić do nich podręczniki. Generalnie już zaopatrzyłem się w te dwie pozycje: Mikrokontrolery STM32 w praktyce i Mikrokontrolery STM32 w sieci Ethernet w przykładach




Chyba masz rację. Z jakiegoś powodu ubzdurałem sobie, że chodzi o maksymalny rozmiar kodu wynikowego.
Jakby nie patrzeć, to jednak dość znaczące ograniczenie.

Mimo, że rdzeń ten sam różnice są znaczne. Każdy producent obudowuje rdzeń swoimi peryferiami. Migracja jest możliwa tylko w ramach jednego producenta.

_________________
Dragonus Cracovus: Biomagia

Zależy co przez to rozumiesz.
Mamy tu dwie sytuacje - jedna to "ogarnięcie sprzętowo/programowe" rodziny mikrokontrolerów czyli poznanie specyfiki danego producenta, która zazwyczaj bywa różna już na poziomie dokumentacji, nazewnictwa rejestrów, bibliotek obsługujących peryferia (jak wspomniana już SPL dla STM32), plików
nagłówkowych, itd, itp...

Z drugiej strony układy peryferyjne często muszą stosować się do różnego rodzaju standardów transmisji np. I2C, SPI, serial port, itd, itp...więc funkcjonalnie mniej więcej odpowiadają sobie. Jeżeli nie używamy w programie jakiś nietypowych, specyficznych tylko dla danej rodziny sprzętowych "ficzerów", to generalnie kod - dzięki programowaniu w C daje się łatwo przenosić.
Nawet między tak różnymi rodzinami jak MIPS i ARM (mam na myśli tutaj akurat PIC32 i STM32 - w miarę równoważne funkcjonalnie produkty).
Wystarczy tylko "wypełnić warstwę sprzętową" specyficznymi dla danej rodziny danymi (inicjalizacje peryferiów i nazwy rejestrów), a reszta pozostaje taka sama.
O ile się za intensywnie nie korzysta z producenckich bibliotek (dopuszczalne na poziomie inicjalizacji peryferiów, ale już używanie ich na każdym kroku przy odwoływaniu się do rejestrów danych w peryferiach sprawi, że ten kod nie będzie łatwo"przenaszalny" na inne rodziny procesorów - a po grzyba pisać za każdym razem od nowa obsługę wyświetlacza LCD na HD44780 )

Tak właśnie zastanawiam się jak to jest z programowaniem innych układów.
Mam na przykład w szufladzie kilka fajnych PIC-ów od Microchipa, z wbudowanym sterownikiem Ethernet. Z tego co wiem firma dostarcza do nich całkiem zaawansowany stos TCP/IP. Trochę kusi mnie, żeby zrobić na jednym z nich któryś z planowanych projektów. Do tej pory wszystko co robiłem, robiłem na AVR-ach. Kiedyś przeglądałem kod źródłowy jakiegoś projektu na PIC-u i wydawał mi się on względnie jasny i zrozumiały, pomijając oczywiście takie kwestie jak nazewnictwo rejestrów czy sposób sterowania pinami.

Mogę w miarę spokojnie zaprojektować układ na takim procku, a potem na spokojnie pisać wsad posiłkując się tutorialami i notą katalogową?
Oczywiście przed przystąpieniem do projektowania płytki sprawdziłbym zalecany sposób podłączenia wszystkich zewnętrznych komponentów. Jednak czy to wystarczy? Mogę się gdzieś spodziewać jeszcze jakichś innych "pułapek", rzeczy unikalnych, których nie znam z AVR-ów?

Jak tak patrzę na długość tego wątku i rozważania typu "czy mogę?" (tzn piszę to bez żadnej złośliwości) tylko taka porada - to szybciej zajęłoby ci gdybyś usiadł przez ten czas i zaczął programować te układy - już by ci działały w rękach - zamiast pytać czy możesz? No każdy może i ty też

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Mirek ma rację - ludzie wszystko programują, więc w razie problemów zawsze znajdzie się ktoś, kto już to przerabiał - a w internecie też przykładów mnóstwo.
Na pewno "z marszu" nie da się zrobić projektu na nowej rodzinie - trzeba się w temat nieco wgryźć. No chyba, że mówimy od wgraniu gotowego kodu do gotowej płytki - to można i w 1 dzień zrobić

Specjalnie niczego takiego strasznego w PIC'ach sobie nie przypominam - poza stronicowaniem pamięci w rodzinach 16/18, ale pewnie programując w C ten problem znika.
PIC'e32 są dosyć przyjemne - prostsze niż ARM'y - bardziej podobne do AVR'ów jeśli chodzi o prostotę konfigurowania peryferiów.

Najlepiej zapoznać się z tym i tym

Chodziło mi tylko i wyłącznie o stronę sprzętową. Jeśli wiem jakich interfejsów potrzebuję i wiem, co układ ma robić, to czy mogę obejść etap płytki stykowej i najzwyczajniej w świecie zaprojektować docelowe PCB, a potem na tak złożonej platformie poznawać stronę programową? Załóżmy na przykład, że skopiuję część elektryczną z tego projektu, dokładając do niego potrzebne układy I/O na SPI, UART i wolnych pinach GPIO.
Czy mogę się spodziewać jakichś przykrych niespodzianek, wynikających ze specyfiki tej rodziny mikrokontrolerów? Mam tutaj na myśli coś, czego nie ma w AVR-ach, no nie wiem, na przykład brak dostępu do określonych pinów w przypadku wykorzystania określonej funkcji MCU.

Te układy i tak występują tylko w obudowach TQFP, a więc trudno mówić o wykorzystaniu płytki stykowej. Jakąś płytkę pod nie i tak musiałbym wytrawić, więc dlaczego nie docelową?

Zastanawia mnie tylko jedno. Na tej stronie pojawia się informacje, że:



Trochę dziwnie mało. To pomyłka, czy faktycznie pamięć w PIC-ach jest tak delikatna. Przecież na dobrą sprawę można by ją "zajechać" przy samych próbach, wraz z wgrywaniem kolejnych, drobnych poprawek.




Może faktycznie spróbuję. Ograniczanie się do jednej rodziny może być faktycznie kłopotliwe i mało przyszłościowe, biorąc pod uwagę to, jak szybko się to wszystko teraz zmienia. Z tego samego powodu nie mam zamiaru zabierać się za asembler. Wszystko czego się nauczę momentalnie przestanie być aktualne, gdy trzeba będzie się zapoznać z nowymi MCU. Moim zdaniem lepiej ćwiczyć się w C i potem ewentualnie przejść na C++.

W datasheecie piszą:

Minimum 100, ale typowo 1000 x @ +25 C Mnie się jeszcze nigdy nie zdarzyło zajeździć żadnego PIC'a - a naprawdę niektóre były mocno "męczone"



Jak to mówi ojciec Rydzyk - Alleluja i do przodu


Mnie o przykrych niespodziankach w PIC'ach nic nie wiadomo - jeśli chodzi o dostępność pinów to zawsze jest tak, że jak się używa danego peryferium, to zabiera ono część pinów - o tym pisaliśmy wyżej.

Prototyp, to prototyp - zawsze trzeba liczyć się z tym, że o czymś może się zapomnieć, albo coś działa inaczej niż nam się wydawało, że rozumiemy, itd....
Chociaż niektórym szefom firm, wydaje się, że układ od razu zadziała "od pierwszego złożenia" i zamawiają PCB zanim skończono fazę prototypowania - a potem trzeba ciąć ścieżki...brrr....

Ale jak masz sprawdzony schemat (j/w), to na nim trzeba się oprzeć i tyle.

Tak, to oczywiste, że wykorzystując SPI albo UART nie mogę już wykorzystać tych pinów do czegoś innego. Mi chodziło o jakieś dziwne pułapki, których można by się nie spodziewać. Np. mamy pulę wolnych pinów, które zostały nam do wykorzystania (już po zagospodarowaniu UART-u, SPI itp.). I nagle okazuje się, że kilku z nich nie można użyć np. po włączeniu któregoś timerów.



Tak, wiem. Zastanawiam się po prostu na ile dobrym pomysłem jest obejście etapu płytki stykowej/zestawu uruchomieniowego przy rozpoczynaniu zabawy z nową rodziną MCU.

Ja robię "main board" gdzie jest MCU, stabilizator, układ resetu, złącza do programowania/JTAG, a porty wyprowadzone są na goldpiny (podwójne). Do tego mam opracowane małe "płytki developerskie", gdzie są np. matryca klawiszy, diody LED do sygnalizacji, złącza do zwiększania ilości pinów zasilania, I2C - oraz bardziej specjalizowane płytki np. zegar na DS1307, RFM22, płytka karty SD, pamięć EEPROM,
DAC I2S, ENC28J60, itd....
Na czas "pierwszego prototypowania" łaczę to razem kabelkami ze złączami pasującymi do goldpinów i uruchamiam, piszę program.
Jak wszystko działa, to robię dopiero "prototyp drugiego stopnia" z płytką w założeniu docelową i tam patrzę czy wszystko działa (bo np. ze względu na optymalizację PCB zamieniliśmy kolejność podłączenia pinów do układów na płytce, itp...
Jak już wszystko jest OK, to można zamawiać płytkę w firmie i montować urządzenia

A te małe płytki zostają do dalszego prototypowania, bo można je podłączyć do następnej płytki-matki - z nową rodziną procesorów.
Oczywiście jeśli mamy jakieś hi-speed układy, to trzeba by je umieścić już na płytce-matce razem z procesorem, żeby uniknąć przekłamań/odbić itd...

Jeżeli zależy nam na jak najmniejszej ilości zakłóceń EMC emitowanych przez płytkę, to czasem można robić kilka podejść do tematu PCB zanim się uzyska to co się chciało...

Tak to u mnie wygląda, ale oczywiście każdy ma swoje ulubione sposoby

No i warto się zaopatrzyć w jakiś (PC-towy np.) analizator stanów logicznych - wtedy widać co się na liniach transmisyjnych dzieje (aczkolwiek trzeba uważać na wpływ sond na działanie układu przy dużych f) i programowanie idzie o wiele łatwiej.

Tak swoją drogą, to jak ma się wydajność rodziny PIC18F w porównaniu do standardowych, ośmiobitowych AVR-ów (np. ATmega644, ATmega128)? Bo z tego co widzę można je taktować znacznie wyżej - nawet ponad 40 MHz, przy zastosowaniu kwarcu 25 MHz. I to chyba nawet nie wiąże się z koniecznością podnoszenia napięcia, jak w przypadku procków Atmela. Wczytuję się obecnie w notę katalogową rodziny PIC18F67J60 i faktycznie fajnie to wygląda. Może faktycznie warto będzie przyjrzeć się im bliżej przed przesiadką na STM-y?

Samemu ostatnio mieszając sobie strasznie, tj. przeglądając rodziny Kinetis L, STM M0+ po M4, oraz AVRy stwierdzam, że mimo całej palety zalet AVRów, jak prostota programowania, taniość narzędzi oraz ogromny support Mirka i całych zastępów ludzi na forum, do zastosowań Touchsensors, ETH (czyli stos TCP/IP w procesorze), graficzny interfejs to STMy i Kinetis jednak wypada dużo lepiej. O Microchipach nie wiem nic, po za tym że są .
Z drugiej strony zawsze dobrze znać więcej niż mniej . Kwestia tylko inwestycji w narzędzia typu programator i IDE (tu jak nawet darmowe, to trzeba poświęcić czas).
Jest np. taki mbed takie ardunio na ARMy, ale więcej to ma wad niż zalet . W sumie zalety są dwie, prostota implementacji bo sporo gotowych przykładów jest, oraz łatwa przenośność kodu. Tylko kompilator jest online (bez neta ani rusz). No i bałagan w bibliotekach tworzonych przez użytkowników, brak standardu, oraz w sumie arduniowatość kodu a dla mnie to akurat wada nie zaleta.

Jeżeli tylko potrafisz sam z dokumentacji dostępnej ogarnąć nową rodzinę, to nic tylko działaj.
To że jakaś rodzina jest bardziej stabilna od drugiej to Mit. To nie lata 80te, że motorola robiła procki z obsługą wyjątków, gdzie cała reszta z x86 to tylko mogła o tym pomarzyć.
Teraz praktycznie w każdym ARMie masz zaawansowane watchdogi, najczęściej dwa, do tego specjalne porty z pilnowaniem stanów ( nie wiem jak to po polsku nazwać ), gdzie masz jak by kontrolę nad stanem od momentu zasilenia procesora, przez zawieszenie głównego programu itd. czyli nie masz jak w AVR przypadkowych stanów ( pewnie stąd te opowieści że AVRy sie wieszają, bo trzeba było już na poziomie procesora myśleć jak zaprojektować resztę obwodów, gdyż po pierwsze wczesne 89C55 itp lubiły się zatrzaskiwać na wyjściach, oraz np. w AVRach rezystory podciągające włączają się po kilku-kilkunastu ms) podczas włączania czy zatrzymania programu. Dokładniej mówiąc chodzi o to że w ARM możesz mieć w pełni władz nad tym co się dzieje z procesorem, nawet jak rozdeptasz kwarc w układzie .
Sam fakt że PIC szeroko jest wykorzystywany w UPSach powinien już dać do myślenia o ich zaletach, co nie znaczy że AVRy też nie są do tego używane .
Bo to wyłącznie kwestia programisty/projektanta, jak potraktuje procesor/projekt, jak arduniowiec tj. wyciągnie z pudełka, ściągnie biblioteki z neta wgra i zapomni no to nawet najlepszy procesor automotive nie da rady.
Patrząc po datasheetach producentów, nie ma dziś procesorów bez błędów, do każdego wychodzą erraty.

W PIC16/18 każda instrukcja jest wykonywana co 4 cykle zegara czyli de facto szybkość w MIPS'ach dla 40MHz będzie wynosić 10.
AVR'y są wiec szybsze (no chyba, że w przypadku tego konkretnego scalaka Microchip coś ulepszył - trzeba by się wczytać w manuala dokładnie).
Nie dotyczy to PIC32

Wiesz, akurat książki Mirka są dość uniwersalne i w sporej części można by je odnieść do innych rodzin MCU. Szczególnie druga, gdzie mniej jest sprzętowej specyfiki, a więcej wykorzystywania możliwości języka C. Niektóre biblioteki pewnie przydadzą się i na innych prockach, np. ta do parsowania komend AT. Pewnie trzeba będzie coś poprawić, bo pewnie występują jakieś specyficzne różnice (PROGMEM?), ale to problem do obejścia.
Zajmując się nowym AVR-em tak czy inaczej zaglądałem do jego noty, żeby zobaczyć, czy układ rejestrów konfiguracyjnych i nazewnictwo bitów wyglądają tak samo.




Fakt. Strona microchipa podaje, że PIC18F67J60 ma 10,5 MIPS. Jakby nie patrzeć słabiej niż AVR-y. Z drugiej strony można z pełnym taktowaniem pracować przy niskim napięciu zasilania. Ja korzystając z 3,3V taktuję ATmegi zegarem 12,5 MHz. Tak więc generalnie różnica nie jest tak wielka.

Tak swoją drogą jeśli PIC nie zostały wyparte z rynku przez AVR-y, to muszą mieć jakieś zalety względem nich, które niwelują pewne udziwnienia występujące w tej rodzinie (np. różna wydajność prądowa poszczególnych portów) i mniejszą wydajność w MIPS-ach. W dodatku Atmel za darmo udostępnia kompletne, zintegrowane środowisko programistyczne.
Co decyduje o ich popularności? Dlaczego w Sieci widuje się całkiem sporo projektów robionych na prockach z tej rodziny?

W dużej mierze właśnie dostępność darmowego oprogramowania, tańsze programatory, jeżeli chodzi o polski rynek, to zawsze AVRy były u nas tą najtańszą i najbardziej opisaną alternatywą. Zauważ, że w takim USA to juz AVRy nie mają takiej przewagi.
Po za tym przyzwyczajenie samych programistów/konstruktorów. No i cena, cena, cena . Teraz już może nie ma takich różnic, ale te 10-20lat wstecz, to jednak atmel miał najniższe ceny, a po za tym łatwo można było zrobić STK200 na kilku rezystorach, czy nawet na 74HC244 i można było programować, PIC już nie miały tak wesoło i trzeba było kombinować.
Podobnie jest teraz np. w ARMach, bardzo szybko Freescale zareagował wypuszczając M0+, STM spóźnił się trochę z swoimi, ale wiele osób jest przyzwyczajonych do STMa, mają narzędzia, taniego STlinka.
Po za tym wystarczy zobaczyć na dysproporcję literatury w ojczystym języku.

Jak dla mnie PICe (zwłaszcza te małe z rodziny 16/18) mają genialnie stabilne przetworniki A/C.
Nie potrzeba robić żadnego uśredniania - po prostu pomiar stoi tam gdzie się go ustawi (np. za pomocą potencjometru włączonego między '+', a '-' zasilania, a środek podłączony do wejścia przetwornika), a zmienia się tylko o +/-1LSB na granicy stanów.

Robiłem kiedyś projekt sterownika pieca z pomiarem temperatury termoparą K i algorytmem PID na malutkim PIC'u16 i dzięki stabilności przetworników A/C uniknąłem wielu problemów, a pomiar napięcia z termopary "stoi jak skała".

No AVRy w tej kwestii to orłami nie są .



Ja tu raczej mam na myśli bardziej podstawy, bo jednak sterowanie portami itp. są całkowicie inne niż w AVRach, a i sama konfiguracja poszczególnych komponentów od zegara po wybrane interfejsy do prostych nie należy (chyba że wiesz co robić).
W CW, można sobie wyklikać w sumie konfig, ale kompletnie nie wiadomo o co chodzi , powstaje z tego bardzo mocno zagmatwany kod z mnóstwem odnośników do różnych plików.

Witam wszystkich,

Coś więcej można na ten temat,
Jak to wygląda w przypadku Atmela: Atmega i Xmega ?
Jaki hardware jako interfejs do JTAG dla Atmela tani kupić ?
Rozumiem ze Atmegaxx to tylko te co maja JTAG wbudowany ale jak to się ma do openocd i GDB?
Ktoś coś testował praktycznie na open source?
Z jakim wynikiem?


Z poważaniem,
JS
Srodowisko programistyczne mało mnie interesuje , bash, make, gcc, gdb, openodc i linux tekstowy starczy - więcej problemów z ustawianiem niż pożytku.