Panowie posiadam dwa procki PIC

PIC24FJ64GB004

PIC32MX250F128D

ale niestety jestem z nich MEGA NOGA, i dlatego prośba pytanie.

Czy ktoś kto śmiga na co dzień z PIC'kami byłby w stanie napisać mi i skompilować prosty program ? Mogę nawet napisać ten program w C dla AVR i żeby go przerobić na jeden z tych PIC'ków

zadanie jest MEGA proste - tak mi się wydaje, chodzi o to aby:

1. Skonfigurować SPI tak aby SCK miał częstotliwość pomiędzy 250 a 800 kHz (nie mniej i nie więcej)
2. Przygotować dwa buforki w pamięci RAM o wielkości np 9 bajtów - podałbym jakie liczby mają być w tych buforkach
3. W pętli głównej programu wysyłać raz jeden bufor na SPI a raz drugi

to WSZYSTKO nic więcej ...

Qurczę jeszcze się tylko zastanawiam jak ja to wgram - no ale zaraz zdaje się że kiedyś kupiłem i mam programator PICKIT3 oryginalny to chyba dałbym radę no nie ?

Oczywiście jeśli nie dacie rady pomóc to NIC się nie stało - tak tylko pytam i z góry dziękuję

_________________
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 ]

Jak kto ktoś inny ? to ja zadałem to pytanie

_________________
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 ]

Jeśli dalej aktualne to mogę "wyklikać" w MCC kod na PIC24FJ64GB004 + dodać te 2 bufory, kwestia jaki MODE do SPI (Microchip "wiedział lepiej" i trochę namieszali z ustawianiem MODE), jakie liczby w buforze i co jaki czas dane mają być wysyłane.

Ja dzisiaj sobie już zainstawlowałem mplab i kompilator, ale okazało się, że kompilator chyba tylko do 8-bitowych picków eeeh troszkę to pomieszane jak się startuje z tymi PIC'kami

więc jeszcze nie odpaliłem sam ...

A zatem jeśli byś miał możliwość to byłbym wdzięczny

W buforze mogą być same zera a powiedzmy co drugi bajt nie ma wartość = 5;



o! coś takiego

_________________
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 ]

ok - w końcu udało się zainstalować mplab, końpilator i nawet uruchomić w tym pickit3 !

a na dodatek napisałem swój pierwszy program w życiu na PIC24 do migania LED'em



No to teraz tylko zostało mi dorobić w tym SPI hahahaha to będą przeboje

_________________
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 ]

Do uruchomienia SPI polecam zainstalować MCC (Microchip Code Configurator) mega wygodne narzędzie, AVR też do niego powoli dodają.
Najłatwiej MCC dodać w ten sposób: Tools > Plugins Download > "Go To MPLABX Plugin Manager" > Available Plugins tam z listy wystarczy wyszukać MCC Code Configurator.

W załączniku wyklikany projekt z obsługą SPI, 500kHz, MODE 1, RC0 = SCK1, RB3 = SDI1, RB2 = SDO1 - wyprowadzenia do programowania RB0 i RB1. (zmiany MODE trzeba albo w MCC albo sprawdzić w nocie, bo w PIC to nie jest jak wszędzie)
W main dodałem tylko potrzebne includy i w pętli funkcję SPI1_Exchange8bitBuffer(txBuff_1, sizeof(txBuff_1),NULL); plus delay 100ms. Teoretycznie jeśli nigdzie się nie pomyliłem powinien co 100ms wysyłać cały bufor txRuff_1, jeśli nie chce się wgrać to prawdopodobnie inaczej ustawiłem piny programowania ICSP.

Optymalizacja gcc jest na 0, w wersji free można wybrać jeszcze 1 ale do pracy z symulatorem/debugowania polecam 0, w innym przypadku praca krokowa z podpiętym procesorem potrafi zawiesić procka / programator albo zmiany w obserwowanych rejestrach nie pokrywają się z krokami programu z uwagi na optymalizację.

Jeśli zaszła by potrzeba debugowania to makro #ifdef __DEBUG pozwala na wykonanie kodu tylko w trybie debugowania (zarówno symulator jak i PICKIT)

Jak się wyklika porty I/O to MCC generuje też użyteczne makra typu pin_Toggle(), pin_SetHigh(), pin_SetDigitalInput() itp.

Nie pomyliłeś się - działa tak jak piszesz - dzięki.... ale

jakaś masakra jest jak tylko zmienię sobie bufor np:

1. na 4 bajty to jeszcze wszystko działa OK
2. na 5 bajtów i więcej to się dzieje jakaś masakra właśnie, czyli TYLKO RAZ po restarcie wysyła i to jakby nie wszystkie bajty

pomijam już fakt, że saleae nie potrafi zdekodować tego protokołu SPI poprawnie, tzn przesyłanych wartości, NAWET jeśli przesyłam tylko ten bufor 3 bajtowy.

Jak zrobię taki bufor - to lipa, raz się coś wyśle - ale nie wiadomo nawet do końca co - może kilka pierwszych bajtów



a przecież nie powinno być teoretycznie ŻADNEJ różnicy - tzn powinno się wysyłać ... a tu procek się zatrzymuje .... No chyba że gdzieś tam w tym mcc ustawiłeś że bufor może mieć max 4 bajty - no ale wtedy kod jest mega nieczytelny w main.c

------------------------ [ Dodano po: 6 minutach ]

o! a saleae tak dekoduje bufor kilku bajtów - widać EWIDENTNIE że na MOSI coś leci, że są to wartości = 2 w bajcie a on nie potrafi zdekodować, a co gorsze w niektórych bajtach tu nawet nie widać tych dwójek - gdy próbuję dać bufor większy niż te 4 bajty. KOSMOS jakiś



i jeszcze jedno - może saleae nie może zdekodować poprawnie bo PIC (jak dla mnie) też mega dziwnie nadaje - jak się zbliży widok, to przy zboczu NARASTAJĄCYM, na linii MOSI powinien już być stan wysoki, a on tak naprawdę pojawia się chwilę później !!! co to jest? Jak nadaję taki sam kod z AVR czy z ARM to stan wysoki w takim wypadu nieco wyprzedza zbocze narastające na SCK - masakrung

o tak to wygląda - na górze ze strzałką to SCK a na MOSI na dole dopiero po krótkim czasie pojawia się stan wysoki ! (ta różnica to wprawdzie 3,9 ns - no ale jakoś tak dziwnie

_________________
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 ]

Dziś już nie dam rady, jutro po pracy postaram się sprawdzić czy może gdzieś coś źle wyklikałem albo w erracie czegoś nie przeoczyłem (chociaż jeszcze się nie zdarzyło żeby MCC pomijał poprawki z erraty).
PS.
Czasami jak PIC ma podpięty programator, w czasie zwykłej pracy, potrafi działać w nieprzewidywalny sposób, zawiesza się pętla PLL od PWM i ADC i kilku innych peryferii. Nie pamiętam czy SPI zrobiłem też z PLL, jeśli tak to odpięcie programatora może pomóc - o ile programator był podpięty podczas pomiarów.

W kwestii SPI już się na takie rzeczy wypłakiwałem producentowi i ... zostałem odesłany do noty katalogowej Swego czasu nieźle się z tym namęczyłem tyle, że pod dsPIC33.

Nie miałem nigdy do czynienia z PIC'ami tak na poważniej jak teraz - ale też jakoś tak pomyślałem , że to może wina podpiętego programatora i go odłączałem - ale niestety to nic nie zmieniało

Tak jak mówię - z twoim kodem i z buforem co ciekawe to 12 bajtów - wszystko śmiga ... ale jak się jeszcze powiększy bufor to katastrofa i nieprzewidywane rzeczy. Myślę, że ty w tym kodzie nic źle nie zrobiłeś - bo przejrzałem już chyba wszystkie pliki wygenerowane przez ten mcc .... i wygląda że niby wsio jest ok ... ale działa jak działa

------------------------ [ Dodano po: kilkunastu sekundach ]

a tak nawiasem mówiąc - bo nie mogę tego wciąż rozgryźć - jak się przyporządkowuje konkretne piny procka pod SPI ? jakoś nie mogę doszukać się ani słowa o tym w nocie - ale może słabo szukam

_________________
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 ]

W nocie to jest to opisane pod PPS (Peripherial Pin Select) wyjątkowo wygodne jak przez automat idzie, jak się to ręcznie robi to trochę mordęga.
Pin ustawia się w rejestrach RPINRX dla wejść i RPORX, gdzie X to numer rejestru, w nocie dla PIC24FJ64GB004 zaczyna się to na stronie 129 "10.4Peripheral Pin Select (PPS)"
Dla wejść wybiera się pin funkcji czyli coś w ten deseń "RPINR18bits.U1RXR = 0"; (tu U1RXR to UART RX przypisany do RP0)
Dla wyjść wybiera się funkcję dla pinu "RPOR1bits.RP2R = 3;" (Do pinu RP2 przypisano 3 funkcję z tabelki w nocie czyli UART TX)

Jutro jeszcze zerknę może coś da się z tym SPI zrobić.

dzięki za info z tym przypisywaniem - teraz już wiem gdzie i co szukać - ale na razie sam jeszcze nie umiem rozwiązać tego problemu że większe bufory powodują kaszankę

_________________
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 ]

W erracie jest opisany chyba dokładnie taki błąd:
Module: SPI (Master Mode)When operating in Enhanced Buffer Master mode,the Transmit Buffer Full flag, SPITBF, may becleared before all data in the FIFO buffer hasactually been set. This may result in data beingoverwritten before it can be sent.This has only been observed when the SPI clockprescalers are configured for a divider of greaterthan 1:4. This behavior has not been observed when themodule is operating in any other mode.
Work around
Several options are available:
•If possible, use a total clock prescale factorof 1:4 or less.
•Do not use SPITBF to indicate when newdata can be written to the buffer. Instead,use the SPIRBF or SPIBEC flags to trackthe number of bytes actually transmitted.
•If the SPITBF flag must be used, alwayswait at least one-half SPI clock cycle beforewriting to the transmit buffer.

Funkcja z MCC wykorzystuje oczywiście " SPITBF" a dla uzyskania właściwej częstotliwości preskalery wynoszą 1:4 i 1:8 więc wpisuje się to w opis problemu.

W załączniku projekt z znacznie wolniejszym taktowaniem procesora (bez PLL) ale preskalery są ustawione tak, że nie powinno być problemu z nadawaniem danych, częstotliwość SCLK = 500kHz jak poprzednio.

No i super - bardzo dziękuję, jutro z przyjemnością to sprawdzę.... i dam znać

_________________
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 ]

No już nawet udało mi się samemu w końcu okiełznać ten MCC Configurator i tak ustawić SPI, tylko w moim przypadku - to w main, jakaś masakra - bo nie widzi np funkcji SpiExchange itp ... tzn widać, że trzeba porobić jakieś inkludy ale jak dodałem __delaya to już w ogóle ... No ale dobra to mniej ważne.

Twój kod teraz ładnie oczywiście działa (DZIĘKUJĘ!) z jedną tylko uwagą i pytaniem zarazem. Już wcześniej o tym pisałem ale teraz zrobiłem dokładne porównanie.

Tak wygląda w dekoderze analizatora logicznego Saleae przebieg SPI gdy generuję go z procka AVR, takie same wartości jak w tym kodzie do PIC



Widać, że dekoder Saleae ładnie dekoduje wartość przesłaną na MOSI = 5, do tego widać też że tuż przed zboczem narastającym CLOCK'a pojawia się ładnie stan wysoki na MOSI i chyba dlatego Saleae ładnie to dekoduje.


W przypadku tego samego przebiegu na SPI ale na PIC, dekoder pokazuje, że jest ZERO w tym bajcie pomimo że na MOSI widać w okolicy narastającego zbocza stan wysoki na MOSI, ale NIESTETY jest opóźniony czyli jakby PIC wystawia go na MOSI kilkadziesiąt ns po zboczu narastającym. Generalnie to działa ale dekoder w saleae nie dekoduje i spodziewam się problemów przy transmisji SPI - tzn tak coś czuję. Z czego wynika takie dziwne podejście do transmisji SPI w PIC - nie wiem czy we wszystkich - może to tylko w tym procku co ja mam ?

_________________
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 ]

Wyklikany w MCC projekt miał SPI w MODE 1, a przebieg z AVR jest w MODE 0, pewnie stąd problem, nie widzę żebym gdzieś napisał w jakim MODE działa SPI - mój błąd przepraszam, trochę zabiegany jestem ostatnio. W załączniku projekt z zmienionym MODE na 0.

W kwestii generowania kodu z MCC, moim zdaniem najwygodniej korzysta się z kodu wygenerowanego z pozycji nie opisanych jako Foundation Services Library by Microchip.
Żeby w main odpalić cokolwiek wyklikanego w MCC należy zainkludować np.:

Po "mcc_generated_files/" jest po prostu nazwa peryferii dla których wygenerowano kod.

Z makrem __delay_ms() i __delay_us() jest nieco zabawniej, bo MCC do tej pory nie potrafi wygenerować kodu z nim kompatybilnego (albo tylko ja tego nie umiem zrobić). Definicje delayów znajdują się w pliku libpic30.h tyle, że ten plik wymaga zdefiniowania FCY, którego MCC nie definiuje... od lat... - na szczęście wystarczy po prostu w pliku mcc_generated_files/clock.h dopisać:

Gdzie "CLOCK_InstructionFrequencyGet()" jest wygenerowane przez MCC.

ale przestań za co ty przepraszasz - i tak jak na moje pierwsze zetknięcie z PIC'ami to dostarczyłeś mi kopalnię wiedzy i bardzo dziękuję - teraz na podstawie kolejnych wskazówek - spróbuję sam wyklikać od początku do końca taki projekcik w MCC ... najwyżej jeszcze zadam jakieś pytanie. Ciekaw jestem jak mi pójdzie z tym delayem ale skąd zwykły początkowy zjadacz chleba mógłbym o takiej sztuczce wiedzieć .... i tym gorzej, że jak piszesz od iluś lat to nie działa dobrze .... oj niedobrze

ale dziękuję ślicznie za wszystkie podpowiedzi - bo już działa to SPI z tymi buforami - DZIĘKI !

------------------------ [ Dodano po: 12 minutach ]

Qurdę no i działa ! z tym delajem ta twoja sztuczka ! ... ciekawe tylko ile jeszcze takich sztuczek trzeba znać

_________________
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 ]

eeeeh miałem już nie marudzić ale jeszcze jedno pytanie - bo pomyślałem sobie, że w takim razie teraz sam sobie wyklikam taki projekt w MCC ale dla tego procka PIC32MX co podałem na górze .... hmmm pierwsze koty za płoty, MCC drze się, że brakuje mu bibliotek - no to ok nawet chyba sam znalazłem taką i zainstalowałem o taką

PIC32MX MCUs v.1.35

niby najnowsza - to taki mały plik *.jar

no i pomimo tego i restartowania IDE - wciąż głupi MCC drze się, że nie ma odpowiednich bibliotek - no to już mi ręce opadają .... może znowu na to trzeba znać jakąś sztuczkę ?

_________________
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 ]

Faktycznie MCC w najnowszej wersji 4.02 nie działa z procesorami 32MX - przypuszczam, że Microchip bardzo chce "zachęcić" użytkowników do przejścia na "Harmony" z 32 bitowcami albo to zwykły babol z ich strony.
W każdym razie, żeby rozwiązać problem trzeba usunąć aktualny MCC: Tools > Plugins > w zakładce "Installed" wybrać i odinstalować MCC 4.02 po czym ponownie uruchomić MPLAB X.
Następnie z archiwum microchipa pobrać MCC w wersji 3.95 http://www.microchip.com/mymicrochip/filehandler.aspx?ddocname=en1001461
Żeby zainstalować starszą wersję MCC: Tools > Plugins > zakładka "Downloaded" > Add Plugins. Tam wybrać ściągnięty i wypakowany MCC 3.95, z wszystkich plików *.nbm w folderze, należy wybrać com-microchip-mcc-3.95.0.nbm
Po ponownym uruchomieniu MPLAB powinien działać z procesorami 32MX - ewentualnie będzie trzeba znowu dodać bibliotekę.

Tak to MCP lubi ułatwiać życie - mam nadzieje że szybko to poprawią bo dziś nie wyobrażam sobie pracy bez MCC.

Jeśli chodzi o sztuczki, to bardzo wygodnie działa samo IDE jeśli chodzi o komentarze. Jesli komentarz w pliku nagłówkowym zaczyna się od:

(koniecznie dwie *) i kończy


Podczas wpisywania nazwy funkcji w edytorze można nacisnąć ctrl + spacja, co wyświetli menu kontekstowe z komentarzem spomiędzy /** i */, dodanie @ przed nazwą stworzy nagłówek, tak samo \n daje nową linię.

Przykład z pliku MCC


Drugim bardzo wygodnym rozwiązaniem jest dodawanie komentarza do pola struktury
Jeśli komentarz będzie poprzedzony:

To po wpisaniu nazwy struktury i kropki w menu kontekstowym pojawi sie komentarz który był dodany powyżej pola.

Przykładowo:


Ten drugi mechanizm sprawił, że jeśli tylko mogę to większość programów na PIC w C piszę trochę "udając" C++ i tworzę sobie wskaźniki na funkcję w strukturach tak żeby naśladowały metody.

PS
Osobiście żadnego marudzenia nie widzę po prostu microchip kilka rzeczy koncertowo skopał w swoim IDE i każdy na początku ma z tym problemy. Jak będę potrafił, będę próbował pomóc, aczkolwiek 32 bitowców od MCP unikam jak ognia, one podobno miewały dłuższą erratę niż notę katalogową - taki żarcik słyszałem kiedyś od kolegów męczących się z nimi.

Dzięki za solidną garść informacji ... a zatem sprawdzę z chęcią tą starszą wersję MCC

sztuczki z komentarzami fajne ... szczególnie jak opisałeś to "udawanie" C++ też często w strukturach w ten sposób używam wskaźników na funkcje - ale metody i ten mechanizm w komentarzach może być tu fajny ....

odnośnie tego

no to prawie spadłem z krzesła ze śmiechu

jak zwykle ślicznie DZIĘKUJĘ za dawkę PicOwiedzy

_________________
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 ]

sorki ale normalnie można się poddać z tymi picami ...

ok zawziąłem się, że zrobię to samo na PIC32mx jak pisałem ... ok dzięki koledze abel11 udało się w końcu odpalić MCC i wyklikać SPI, wygenerował się main ...

ale:

1. tym razem ZONK nie działa wynalazek #include <libpic30.h>
2. ok srał pies - będę nadawał po SPI bez przerwy
3. no to po przypisaniu pinów jak w pic24 - radośnie rzuciłem się do wgrania programu - bo kompilacja przeszła idelanie bez tego __delam_ms

a tu kuźwa ... no nieeee



no i załamka .... ja pierdziu - czy w tych pic'ach działa cokolwiek na zasadzie analogii ? .... czy wszystko ale to wszystko musi być oparte o sztuczki i erraty ?

------------------------ [ Dodano po: 24 minutach ]

żeby nie było że tylko ja mam taki problem
https://v1.escapistmagazine.com/forums/ ... 2-mismatch

------------------------ [ Dodano po: 50 minutach ]

dobra - kładę się spać na dzisiaj, strasznie się wku.........rzyłem ... i uważam, że majkroczip, bez urazy, produkuje swoje czipy i narzędzia na tzw "randoma" ..... albo wyjdzie albo nie wyjdzie ... mega kaszana! Praca z picami to ciągła walka z erratami nie tylko do silikonu ale i do narzędzi ... jednym słowem da się tylko to określić - tragedia. Owszem jak ktoś w tym już siedzi jak kolega abel11 (pełen szacun za rozpracowywanie wielu tematów) ... to jakoś sobie poradzi z takim czy innym problemem. Ale pierwszy raz w życiu używając już kilku rodzin procków (a po pice siegnąłem pierwszy raz) to jeszcze takiego burdelu nie widziałem niestety ....

naprawdę nie dziwię się, że majkroczip tak polował na wykupienie AVR CORE ... dopiero teraz powstaną porządne może procki z ich dobrymi peryferiami. Tylko te mega ich kocie narzędzia ... no masakra.

------------------------ [ Dodano po: 53 minutyach ]

zawsze coś dobrze czułem, że lepiej ze zwykłych 8-porządnych-avr-bitowców lepiej przesiąść się na jakieś ARM'y niż inne egzotyczne wynalazki

troszkę zgorzkniały może jestem ... i jest możliwość, że przesadzam ... bo to początki, ale jeszcze nigdy nie miałem aż tyle problemów z początkami jak przy kocich picach. Przy PICach ... to ARMy są jak świeże bułeczki tzn chodzi mi o przejście z jakichś małych procków na większe

_________________
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 ]

W 32 bitowcach z tego co wiem nie ma w ogóle makra od delay_ms, tak też uważam to za totalny idiotyzm, jak się poczyta ich FAQ w tej kwestii to widać, że wybrali linię obrony przez pogrążanie się...

W kwestii problemu z zaprogramowaniem procesora, z tego co wiem 32 bitowce od Microchipa potrafią tak reagować jak nie mają kondensatorów odsprzęgających lub jeśli umieści się je zbyt daleko od nóżek procesora albo nie przy wszystkich nóżkach zasilania . Podobnie miałem z FPGA XILINX ale tam spodziewałem się problemów z uwagi na moc obliczeniową i idącym za nia skokowym poborem prądu, natomiast w 32bit microchipa nie wiem czym jest to powodowane, na pewno nie wydajnością obliczeniową może wydajnością obliczeń "przypadkowo przecinkowych" Dla kontrastu dsPIC nawet nie "gniewa się" za bardzo na kondensator na linii MCLR, który w 32 bitowcu bezapelacyjnie wyłącza możliwość połączenia się z procesorem.

Jak dla mnie, 8 bit i 16 bit (zawężone do dsPIC) od Microchipa naprawdę dają radę, bardzo bogata oferta procesorów (mają nawet 16bit 2 rdzeniowe), dużo peryferii, dopuszczenie do urządzeń bezpieczeństwa itd., natomiast 32 bit w ich wydaniu to marnowanie krzemu, mam nadzieję że będą robili SAM od AVR bo to jedyne rozsądne wyjście - z tego co wiem robią tez FPGA ale nie mam odwagi sprawdzać jak im to wychodzi . Głównie pracuje na 16 bit dsPIC i chwalę je sobie (oczywiście wyłączając punkty z erraty z "Workaround: none"), operacje typu sortowanie danych, obliczanie RMS, FFT itp. można genialnie przyspieszyć, ale trzeba to napisać w asm bo żadna wersja kompilatora nie obsługuje silnika DSP. Niby jak się raz napisze funkcję asm (z kompilacją warunkową dla różnych procesorów) to potem się ją tylko w C wywołuje i po krzyku ale jakoś ciągle mnie to wkurza, już nawet znudziło mi się pytać MCP kiedy dodadzą kompilatorowi instrukcje DSP.


Również podpisuje się pod tym obiema rękoma! W obrębie jednej rodziny sa analogie, a poza nią, ciężko uwierzyć, że to urządzenie tego samego producenta...

ok - to wyczerpuje moje zainteresowanie tym kocim pic32 ... abel11 - jak zwykle DZIĘKUJĘ !!! Chociaż gdy po przebojach z MCC w końcu się udało, i co więcej z radością spojrzałem na konfigurację SPI choć całkiem inną niż w pic24 - no ale na taktowaniu z PLL, mogłem uzyskać moje wymarzone 800 kHz na SPI SCK - to już byłem prawie w 7-mym niebie

Ale faktycznie - odnośnie tych 16-bitowców - jak sobie popatrzyłem na ilości gotowych dostępnych bibliotek, i sporo peryferiów w tych prockach - to też przyznam, że jako tako to wygląda.

Masz rację - chyba spróbuję teraz szczęścia z jakimś prockiem SAM Atmela

.... aha o tych kondkach też czytałem gdzieś w międzyczasie i muszę sprawdzić schemat i PCB tego mojego szilda z tym pic32mx - może coś pyknie

ale ciekawe jest to że program MPLAP X IPE potrafi Qurna ODCZYTAĆ np pamięć i to z tych adresów , dla której przy zapisie pierniczy już komunikatem tym samym, że złe adresy

Qurdę - dzięki tobie abel11 miałem szybki jak na moje warunki start w PIC'ki - jeszcze raz DZIĘKI !

_________________
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 ]

Jeśli SPI na 800kHz jest niezbędne w pic24, to można ustawić PLL i taktować procka wyżej, wystarczy sprawdzać flagę SPIRBF (bufor odbiorczy pełen) lub ilość elementów w buforze SPIBEC, zamiast SPITBF.
Ewentualnie w rejestrze SPI1CON2 wyczyścić flagę SPIBEN (w MCC nie można tego wyklikać) dzięki temu wewnętrzny 8 bajtowy bufor FIFO (źródło problemów) zostanie wyłączony i będzie można sprawdzać flagę SPITBF bez przeszkód.


Przy 16 bitowcach, do odczytu pamięci programu, procesor nie pobiera jakiegoś szczególnego prądu, natomiast podczas modyfikacji własnego FLASH ten prąd jest zauważalnie wyższy, kiedyś mierzyłem oscyloskopem spadek napięcia na rezystorze włączonym w zasilanie. Być może w 32 bit poszli o krok dalej i skoki prądu są jeszcze większe w końcu PIC jadą na innej architekturze.

Jak by były jakieś problemy z PIC to postaram się pomóc, jednak kilka lat na nich pracuje.
Tymczasem wracam do Orange Book, chroniczny brak czasu strasznie spowalnia pochłanianie wiedzy ale jest tyle projektów, które chciał bym wzbogacić o USB