mikronkontrolerów na Raspberry

Nie mam co prawda wielkiego doświadczenia w programowaniu. Elektroniką amatorsko interesowałem się od dawna i około roku temu zacząłem się uczyć programowania AVR-ów w C. Od tamtego czasu udało mi się już sklecić kilka projektów, więc mniej-więcej już jakieś doświadczenie mam. ;)

Pomyślałem, że warto byłoby spróbować z inną platformą i pobawić się z wbudowanymi systemami na Linuksie. Na biurku od jakiegoś czasu leży Raspberry Pi. Zainstalowałem WiringPi, podpiąłem diodę LED do pinów GPIO i pomigałem nią przez chwilę, potem przyszedł czas na wyświetlacz 2x16. Zanim jednak zabiorę się za dalsze eksperymenty, wolałbym rozwiać kilka wątpliwości.

1) Środowisko programistyczne. Swoje RPi obsługę zdalnie, przez SSH. Nie mam do niego podpiętego monitora i klawiatury, nie korzystam też z żadnego pulpitu zdalnego. Jestem skazany na pisanie w nano, czy też może jest jakieś rozwiązanie, które umożliwiłoby mi pisanie i kompilowanie programów na windowsowej maszynie (analogicznie do hex-ów dla Atmegi)? Bo jedyną alternatywą jaka przychodzi mi do głowy jest udostępnienie folderu przez SMB, pisanie pod Windowsem, a kompilowanie z wiersza poleceń. 2) Jak to właściwie jest z wielozadaniowością i wykorzystaniem zasobów systemowych? Czy dobre nawyki z mikrokontrolerów zachowują aktualność w świecie Linuksa? Chodzi mi głównie o to, czy również niewskazane jest często korzystanie z delay-ów i zamiast tego powinienem jak najszybciej "przemiatać" pętlę główną, a opóźnienia realizować na timerach? W jaki sposób pisać kod, żeby minimalizować zużycie zasobów? 3) Czy możliwe jest współdzielenie interfejsów pomiędzy programami? Nie chodzi mi tutaj o takie peryferia jak bluetooth czy Ethernet, ale np. o SPI albo I2C. Jeśli skonfiguruję sobie pod systemem obsługę DAC-a albo RTC pod I2C, będę mógł nadal używać innych urządzeń na tej magistrali z poziomu np. wiringPi? To samo pytanie tyczy się także SPI.

I tak przy okazji: Ktoś z was zna może jakąś bibliotekę do przewijania większej ilości tekstu przez wyświetlacz 2x16? Niby mniej-więcej wiem jak mógłby wyglądać kod realizujący takie zadanie, ale jeśli ktoś już otworzył te drzwi, po co je wyważać? Poza tym zakładam, że jeśli ktoś już to napisał, to zrobił to lepiej, niż ja byłbym w stanie. ;)

Reply to
Atlantis
Loading thread data ...

Możesz odpalić nawet Eclipse na nim, ale przy tak małych zasobach natywne IDE nie ma sensu. Zastanow się lepiej nad lepszym rozwiązaniem: pisz gdziekolwiek, kompiluj na targecie i "gdziekolwiek". Od razu będziesz miał nawyki pisania przenośnego i z abstrakcjami. Kto mówi że muszisz mieć prawdziwe SPI? Nie możesz wpiąc mocka lub jakiegoś wiekszego emulatora zamiast niego i odpalać na windowsie? To nie dość że jest łatwe to jeszcze uczy dobrego stylu pisania kodu.

Możesz odpalić na windowsie Eclipse, Netbeans, CodeBlocks i użyc kroskompilacji jesli koniecznie musisz mieć odpalane natywnie. W dodatku możesz kompilować natywnie na windowsa i kross na arm. I debugowac na win.

Nie. Jest zupełnie inaczej. Pi to nie jest mikrokontoler w sensie Atmega. To jest *NORMALNY* komputer.

Masz ich tak dużo że nie ma to sensu. Stosuj te same techniki co na pecetach.

Możesz napisać demona który steruje SPI a pozostałe programy komunikują się z nim i to on zarządza dostępem. Technika dowolna, to się da zrobić na tyle sposobów że aż mi się nie chce ich wymieniać :)

Reply to
Sebastian Biały

To zalezy. Bezkrytyczne podazanie ta sciezka moze sie zle skonczyc. Programuje ostatnio urzadzenia z CPU na 800 MHz i musze stosowac tricki aby uzyskiwac zadowalajace czasy odpowiedzi. Bo ktos kto pisal biblioteke sql z ktorej korzystam podchodzil w sposob jaki piszesz.

Pozdrawiam

Marek

Reply to
Marek Borowski

Marek Borowski snipped-for-privacy@borowski.com napisał(a):

Ale chyba nikt nie mówił, że można sobie dowolnie marnotratwić zasoby. Trzeba nimi zarządzać oszczędnie, ale właśnie podobnie jak na PC, a nie jak na mikrokontrolerze z 1 kB RAM i taktowaniem 8 MHz. Raspberry Pi bliżej do leciwego peceta niż do mikrokontrolera.

Reply to
Grzegorz Niemirowski

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.