Tytył książki: "Maszyna stanów logicznych"
Masakra jakaś. Żeby zwykly algorytm nazywać maszyną. To jak jakieś
podniecanie się wyborami partyjnymi żeby wzbudzić zainteresowanie.
Wogóle to nie ma co nazywać przechodzenie w pętli z jednego stanu do
drugiego bez blokowania.

Sorry.
Starość.

do góry

On Fri, 23 Oct 2015 19:52:22 +0200, "pawel" <p...@p...onet.pl>
wrote:
> Tytył książki: "Maszyna stanów logicznych"
> Masakra jakaś. Żeby zwykly algorytm nazywać maszyną. To jak jakieś
> podniecanie się wyborami partyjnymi żeby wzbudzić zainteresowanie.
> Wogóle to nie ma co nazywać przechodzenie w pętli z jednego stanu
do
> drugiego bez blokowania.

akurat analogia (co z tego, że abstrakcyjnego bytu) do maszyny jest
dość trafna, być może bardziej po polsku "automat skończony"
bardziej by Ci pasowało?

--
Marek

do góry

W dniu 2015-10-21 o 11:27, Marek pisze:

> Są te same nazwy rejestrów specjalnych (GPIO) np. PORTC, TRISC, LATC
> itd. stąd kod jest przenośny. Ze względu na to, że na pic32 dostęp do
> tych "standardowych" rejestrów w trybie kompatybilności wstecznej nie

Hmm... Kupiłem kiedyś książkę do nauki PIC-ów ("Mikrokontrolery PIC w
praktycznych zastosowaniach" Borkowskiego). Z tego co widzę autor skupia
się na linii ośmiobitowych MCU od Microchipa. Na razie nie miałem czasu,
żeby bliżej im się przyjrzeć. Rozumiem, że gdy już jako-tako opanuję
"małe" PIC, to przejście na PIC32 nie powinno być problemem? Nie
potrzeba osobnego podręcznika/kursu, tylko wystarczy poczytać o
różnicach? To nie jest taka przepaść, jak pomiędzy AVR-ami a AT91SAM?

BTW udało Ci się może wysłać te materiały dotyczące biblioteki? Nic do
mnie nie dotarło.

do góry

On Sun, 25 Oct 2015 22:10:11 +0100, Atlantis <m...@w...pl>
wrote:
> Hmm... Kupiłem kiedyś książkę do nauki PIC-ów ("Mikrokontrolery PIC
w
> żeby bliżej im się przyjrzeć. Rozumiem, że gdy już jako-tako opanuję
> "małe" PIC, to przejście na PIC32 nie powinno być problemem? Nie
> potrzeba osobnego podręcznika/kursu, tylko wystarczy poczytać o
> różnicach? To nie jest taka przepaść, jak pomiędzy AVR-ami a
AT91SAM?

Nie wiem jak jest między AVR. Między 8bitowcami PIC a PIC32 jest
oczywiście przepaść technologiczna, tutaj nie ma co ukrywać. Z tym że
MCHP swoim API dość zgrabnie ją przysłania. Podstawowe rejestry
związane z GPIO mają taka, samą semantykę, tak samo rejestry
kontrolujące spi, usart czy np. timery stąd user obeznany w 8bitowej
rodzinie odnajdzie się szybko w pic32 a kod z 8bit praktycznie bez
modyfikacji skompiluje i z powodzeniem uruchomi na pic32. Nie wiem
jaka jest różnica w środowiskach programistycznych jakie daje MCHP
(nie używam, używam własne oparte na Makefile+vim), ale ostatnio to
chyba zintegrowali i ich mplab x obsługuje wszystko w jednym
zunifikowanym środowisku (oparty na eclipse).
PIC32 oczywiście (jak każdy 32 bitowiec chyba) przy przejściu z 8
bitowców daje większą swobodę i komfort, nie trzeba już przejmować
się czy ram/flash starczy, przejmować się używaniem rozpychających
floatów, a domyślny int "starcza" na wszystko, itp. itd. Nie
wspominając już o np. o ogromnie pożytecznym "exception handler" czy
takim babake jak szybkości w działaniu.
Na Twoim miejscu skoro znasz już 8bitowce to nie interesował bym się
specjalnie 8bitowcami PIC, nie widzę potrzeby. No chyba, że
konkretnie zależy Ci na jakimś wbudowanym peryferiu, który nie ma
avr (np. strzelam: sterownik LCD?). Jeśli chcesz przejść na 32bit to
wybierz jakąś platformę, z każdej na pewno znajdziesz tutaj
fachowców. PIC32 jest ma pewno naturalnym wyborem dla tych co są
emocjonalnie i doświadczalnie związani z PIC, ale czy dla
wszystkich?
Oczywiście miło by było pogadać czasem tutaj z kimś o pic32 :), jeden
kolega był ale po jakieś religijnej sprzeczce zniknał.

> BTW udało Ci się może wysłać te materiały dotyczące biblioteki? Nic
do
> mnie nie dotarło.

Wysłałem opis api, nie było reakcji, stąd uznałem, że nie jesteś
dalej zainteresowany.

--
Marek

do góry

W dniu 2015-10-25 o 23:37, Marek pisze:

> Wysłałem opis api, nie było reakcji, stąd uznałem, że nie jesteś dalej
> zainteresowany.

Hmm... Wygląda na to, że nic nie dotarło... Wysłałeś na marekw1986 [na]
gmail.com?

do góry

On Sun, 25 Oct 2015 23:48:31 +0100, Atlantis <m...@w...pl>
wrote:
> Hmm... Wygląda na to, że nic nie dotarło... Wysłałeś na marekw1986
[na]
> gmail.com?

Tak, też z gmail, sprawdź spam.

--
Marek

do góry

On Sun, 25 Oct 2015 23:48:31 +0100, Atlantis <m...@w...pl>
wrote:
> Hmm... Wygląda na to, że nic nie dotarło... Wysłałeś na marekw1986
[na]
> gmail.com?

wyjaśniło się, była liiterówka w adresie, mail dostał ktoś inny.
Wysłałem już na prawidłowy, mam nadzieję.

--
Marek

do góry

On 2015-10-25 23:37, Marek wrote:
[...]
> PIC32 jest ma pewno naturalnym wyborem dla tych co są emocjonalnie i
> doświadczalnie związani z PIC, ale czy dla wszystkich?
No z tą naturalnością wyboru to bym nie przesadzał. Przecież PIC32 ma
zupełnie inny rdzeń. A to, że tytani intelektu z działu marketingu
Microchipa wymyślili sobie, że nazwą ichnią wersję MIPS-a PIC32 to jest
zupełnie inna sprawa.

> Oczywiście miło by było pogadać czasem tutaj z kimś o pic32 :), jeden
> kolega był ale po jakieś religijnej sprzeczce zniknał.
Może po prostu pytaj o ludzi mających pojęcie o MIPS-ach. :-)

do góry

On Tue, 27 Oct 2015 13:02:52 +0100, JDX <j...@o...pl> wrote:
> No z tą naturalnością wyboru to bym nie przesadzał. Przecież PIC32
ma
> zupełnie inny rdzeń. A to, że tytani intelektu z działu marketingu

Wiadomo, że inny ale co z tego? Jeśli w api zachowali semantykę
podstawowych rejestrów z pic16/pic14 to dzięki temu migacz diodą
typowa gospodyni domowa z Gdańska znająca pic14/16 zrobi tak samo na
pic32? :-)


> Może po prostu pytaj o ludzi mających pojęcie o MIPS-ach. :-)

No był tu jeden partyzant od rodzinnego programowania mipsów w
asemblerze to go pogoniliście jak wszystkim na Święta życzył
błogosławieństwa Bożego :(.

--
Marek

do góry