Ładowanie się w Z80 wydaje się mocno bez sensu. Dlatego ciągnę ten absurd, skoro i watek absurdalny u podstaw :)
Po co robić ethernet na Z80 :) Chyba nawet gotowe rozwiązanie sprzetowe nie jest wystarczającym argumentem żeby reanimować trupy. *Wszystko* na rynku jest lepsze od Z80 pod dowolnym względem.
W dniu 2012-04-30 23:35, John Smith pisze:
Nie ma sensu emulować Z80 w pełni. W tym przypadku autor chce i tak pisania nowego softu na Z80 (w asemblerze). Więc softu nie ma, a skoro nie ma i trzeba go stworzyć, to łatwiej go stworzyć wprost na ARMa, z wbudowanym w ten soft tcp/ip i całym ethernetem jaki się wymyśli, a nie tworzyć soft na zabytek, w zabytkowym asmeblrze, i jeszcze modzić jak tu do ethernetu to podłączyć, i robić soft na interfejs z80<>eth. Jeśli chodziło mi o emulacje, to o zewnętrzne udawanie Z80 przy pomocy lini i/o ARMa, tak by dostawać się do istniejącego hardware (czyli realnie tylko i/o w przestrzeni adresowej Z80, bo ram i rom jego jest nam niepotrzebny)
Dnia 30-04-2012 o 23:38:13 Sebastian Biały snipped-for-privacy@poczta.onet.pl> napisał(a):
Ma? Na 8-bitowe AVRy też?
Wydaje mi się, że pisanie w C++ na mały mikrokontroler sprowadzałoby się do ciągłego uważania, żeby przypadkiem nie użyć zbyt zaawansowanych funkcji języka. Tu coś podziedziczysz, tam dodasz parę trywialnych metod, bo enkapsulacja obiektu będzie wtedy lepsza (ale kompilator włoży funkcje, zamiast odwołać się bezpośrednio do pamięci), gdzieś tam zrzutujesz wskaźnik i nawet nie zauważysz, że użyłeś identyfikacji typu run-time, i po chwili używasz 2 razy więcej Flasha lub RAMu, niż użyłbyś w C.
Jak już koniecznie programować obiektowo, to od C++ wolałbym język ADA - przynajmniej wtedy otworzyłby się rynek safety-critical.
BTW, sprzętowy stos dotyczy tylko 8-bitowych PICów. I do C++ ma się nijak.
ae
Here we go again ... Reszta grupy niech zamknie oczy.
Ależ oczywiście że ma sens na 8 bit.
[cut crap]Kto tu mówi o pisaniu obiektowym?
Urban legend. Najczęsciej rozpowiadane przez ludzi którzy nie rozumieją C++, nie pisali bądź doczytali że coś tam gdzieś tam komuśtam zjadło więcej flasha. A potem okazało się że to był pierwszy eksperyment z C++ w życiu jakiegoś nerda od pisania w asm.
Kto mówi o pisaniu obiektowym?
Tak, ada już pokazała że jest cafe-critical-full-wypas że ojej.
Dnia 01-05-2012 o 00:10:53 Sebastian Biały snipped-for-privacy@poczta.onet.pl> napisał(a):
Bardzo dziękuję za nazwanie mojej wypowiedzi "gównem". Normalnie, potrzebowałem tego.
Poza tym wyciąłeś tam zdanie: "Wydaje mi się, że pisanie w C++ na mały mikrokontroler sprowadzałoby się do ciągłego uważania, żeby przypadkiem nie użyć zbyt zaawansowanych funkcji języka." Jeśli wytniesz pisanie obiektowe, to robisz dokładnie to, co napisałem - sprowadzasz C++ do proceduralnego C.
Jeśli koniecznie musi być ad personam, to tak się składa, że zawodowo programuję w C, C++ i asm. Od ponad 10 lat. Ale wolałbym trzymać się argumentów merytorycznych, a nie uzasadniać że mam rację, bo mam większego eksperta. Dałem konkretne przykłady rzeczy, na które trzeba uważać programując w C++, bo brak uwagi będzie skutkować wygenerowaniem niepotrzebnego kodu. A ty mi się do nich nie odnosisz, wycinasz i próbujesz sugerować doborem cytatu, że uważam że w C++ kod zawsze musi być większy.
Ada to de facto standard w safety-critical, więc posiadanie kompilatora otworzyłoby mi (jako sprzedającemu procesory) nowy rynek. I tyle. A kod, który zawiera błędy, można napisać w każdym języku. W Adzie podobno trudniej (podobno, bo tu jestem tylko na poziomie "hello world").
ae
crap to beznadzieja. Jesli zaczynasz atakowanie C++ na uC od dyskusji o obiektowości to jest to beznadziejne.
Nie. C++ to znacznie więcej niż obiektowość. *Właśnie* w uC te inne niż obiektowość rzeczy są przydatne. Takie jak destruktory, silne typy, traits i ogólnie szablony w metaprogramowaniu. I nie, te szablony nie muszą generować *ANI* grama kodu. Dostajesz darmowe ciastko. Microchip jednak slusznie zauwazył, że środowisko klepaczy w C nijak nie pojmuje ze jest to smaczne ciastko i jest darmowe. Więc go nie daje i lemmingi C nie widzą różnicy dalej klepiąc kiepskie makra.
Daleś przykład obiektów. To nagorszy pustak jaki mogłeś mieć w tej dyskusji.
Uważam że taki jest urban legend. Twoje wypowiedzi tylko to potwierdzają.
Całe szczeście że na 8-bit nikt nie pisuje w Adzie.
Dnia 01-05-2012 o 15:01:17 Sebastian Biały snipped-for-privacy@poczta.onet.pl> napisał(a):
To by raczej było "hopelessness". A wulgaryzm pozostaje wulgaryzmem. Odniesiony do czyjejś wypowiedzi, jest... mało elegancki.
No cóż - główna cecha różnicująca języki, o których mowa. Faktycznie, nie ma czego wspominać.
Szablony to się właśnie przydają przy dużych programach, gdzie jest potrzeba wykonywania tych samych operacji na różnych typach danych. Przy programowaniu na mikrokontrolery? - może czasem się mogłyby przydać, ale na pewno nie *właśnie* tam.
Destruktory to cecha obiektowa, której zalety wychodzą szczególnie w przypadku typów polimorficznych, ale sam twierdzisz, że prawdziwie obiektowo, to nie chcesz pisać. Przy "zwykłych" typach, nie wnoszą jakiejś jakościowej różnicy, za to przez swoje "samoczynne" uruchamianie się stanowią niezłą okazję do implementacji subtelnych bugów, szczególnie u niezbyt doświadczonych programistów (a piszemy o mikrokontrolerach, które w praktyce, szczególnie w mniejszych firmach, najczęściej programują elektronicy).
Silna typizacja, to kwestia gustu i konwencji, poza tym oba języki mają to na podobnym poziomie - tu i tu jest "static typing", tylko w C łatwiej to obejść bokiem, za to w C++ trzeba zrozumieć 4 różne operatory rzutowania wskaźników, a konwersje "kompatybilnych" typów i tak zachodzą automatycznie i gryzą tak samo jak w C. A jeśli chodzi o traits, to w C++ to nie cecha języka, a jedynie idiom, poza tym chyba żartujesz podając to jako coś ponadmarginalnie przydatnego przy programowaniu mikrokontrolerów
8-bit.
Po co epitety? Dowartościowujesz się obrażając programistów C?
Bardzo dziwną logikę stosujesz, skoro z moich wypowiedzi ma wynikać istnienie jakichś legend.
Na moje stwierdzenie, że aby nie generować nadmiaru kodu, język trzeba by okroić przez samoograniczenie programisty, gwałtownie protestujesz, po czym stwierdzasz, że okroisz go z całego programowania obiektowego. No weź...
Bardzo ciekawe. Akurat na twoje ulubione AVRy jest kompilator - powstał pewnie tylko dla zabawy. Poza tym, tego twojego nagłego czepienia się Ady nie rozumiem już zupełnie. To dlatego, że ja o niej napisałem, to już musisz być koniecznie przeciw?
ae
Nie. Podstawowym zastosowaniem szablonów w małej skali beda traitsy i metaprogramowanie. Nijak nie ma tu mowy o powielaniu kodu w sensie std::vector< T >. To zupełnie inne zastosowanie niż to o którym piszesz. Ja rozumiem to jako podejście w stylu boost::mpl.
Destruktory to cecha która nie wymaga podejścia obiektowego do programowania. Najprościej:
struct CriticalSection { CriticalSection{ cli(); } ~CriticalSection{ sei(); } };
To żadne programowanie obiektowe. A destruktor przydatny.
Odwrotnie: dzieki swojemu samoczynnemu dzialaniu *ochraniają* przed wieloma subtelnymi bugami w stylu "a mi się tu zapomniało zdjąć flagę przerwania".
Mi się przydaje. Przyznaje, idę pod prąd.
Ja juz nie musze się dowartościowywać od czasu kiedy usłyszałem od pewnego programisty uC że najlepszy kompilator to jakieś barachło pod DOSa w którym wszelakie optymalizacje należy i tak robić ręcznie w asm. Dziwnym trafem najczęsciej wlasnie takie teksty słyszę od tzw lemmingów. Ludzi którzy nie mają ochoty na zmiany, a na pewno nie w lepszym kierunku. Microchip doskonale wyczuł sytuacje dostarczając technologie wprost z lat 80. Malo tego, jest cała masa ludzi którzy preparują pseudo-merytoryczne argumenty dlaczego C jest lepsze niz C++ bo przeciez MC nie jest głupi.
A MC nie jest głupi, ale tylko marketoidalnie...
Moje marzenie to PIC w sensie peryferiów i AVR w sensie rdzenia. Ale sie nie doczekalem bo przyszły ARMy i pozamiatały.
Bo po co mi programownie obiektowe na 8-bit z 1k pamięci? C++ dostarcza masę innych narzędzi, obiekty to najmniej ważny element w uC.
Nie muszę. Ada to zacny język, choć obrośnięty legendą jakości która jak widać musi walczyć z faktami. Ale stawianie go obok C++ w kontekscie tej rozmowy uważam za niepoważne. *Nikt* nie pisze w Ada poza szumem statystycznym. Nie zmuszajmy MC żeby pisał kompilator Ady dla 0.01% programistow uC. Ale C++ mógłby. Wystarczylo sportować gcc. No chyba, że architektura PICów nie da się wmontować w backed gcc. Co za pech ..., znaczy design ...
W dniu 2012-05-02 01:28, Sebastian Biały pisze:
To chyba raczej koszmar. Peryferia w PIC to sprytny księgowy projektuje. Jeden port ma podciąganie, inny nie; porty potrafią się różnić obciążalnością. Kanały ADC można włączać tylko zakresami (np.15..7 a nie pojedynczo). Najbardziej podoba mi się ADC w PICach z ethernetem. Jak się przekroczy napięcie zasilania na wejściu ADC to zaczyna płynąć prąd nie do linii Vcc, tylko do kanału aktualnie mierzonego :-). Jakiś humorysta to projektował.
Dnia 02-05-2012 o 01:28:30 Sebastian Biały snipped-for-privacy@poczta.onet.pl> napisał(a):
Ładne. Ale szczerze mówiąc to nie bardzo widzę, jaki problem to rozwiązuje w przypadku programowania naszego 8-bitowca z 1kB kodu.
Sprytne i fajnie pokazuje, jak działa destruktor. Ale ja bym po prostu napisał:
cli(); ... kod krytyczny sei();
Lepiej widać w jednym miejscu co się dzieje, bez szukania definicji klasy CriticalSection, bez zastanawiania się gdzie jej obiekt wychodzi z zasięgu, no i bez ryzyka, że osoba, która nie jest autorem kodu nie zauważy, że wsród paru zmiennych lokalnych jest jakiś dziwny pozornie nieużywany obiekt.
Ja tam wolę widzieć przebieg programu, a nie musieć ciągle pamiętać, że między ostatnią instrukcją funkcji, a '}' uruchomi się jeszcze seria niewidzialnych funkcji. Zresztą, akurat w mojej praktyce programowania małych uC potrzeba nietrywialnej destrukcji "obiektu" zachodzi bardzo rzadko.
Skoro ci się przydaje i masz nawyk ciągłego stosowania takich konstrukcji, to rozumiem że koniecznie chcesz mieć C++.
Architektura 16-bit Microchipa (PIC24, dsPIC33) to właśnie coś takiego. Bardzo elegancko zaprojektowana, przyjemnie się z tym pracuje - moim zdaniem dużo ładniejsza niż MIPS, którego użyli w PIC32, oraz niż ARM.
Nie zmusimy ich do niczego, bo tam kalkulacja jest prosta: zrobienie kompilatora kosztuje tyle, a zyskamy na tym tyle. Jeśli nierówność zaczyna wychodzić zdecydowanie na korzyść, to robią.
gcc zostało przeniesione na architektury 16 i 32 bit. Jeśli chodzi o te 32 bit (rdzeń MIPS) to spodziewam się, że prędzej czy później kompilator C++ się pojawi. Do 16-bit też pewnie mogliby to w miarę tanio zrobić - mi zupełnie jednak na tym nie zależy.
ae
Powiedzmy - dopasowanie typu [char|short] licznika w czasie kompilacji. Policzenie jaki typ nalezy wybrać dla zbioru flag. Policzenie stalej w czasie kompilacji. Kompilacja warunkowa bez #define. Itd.
teraz:
cli() .... return ... goto ... break ... sei();
I już po tobie. A po mnie nie.
Nie zastanawiasz sie. Na pewno wszystkie miejsca działają poprawnie. na tym polega sztuczka. Możesz oderwać się od assemblera i skupić na algorytmie. nadmierne przejmowanie się szczegółami uniemozliwia pisanie czytelnego kodu.
Jesli "pozornie nieuzywan obiekt" nazywa się SekcjaKrytyczna i on tego nie zauważy, to pozostawienie w tym miejscu makra, sei, cli nic nie pomoże - przecież pozornie jest nieużywane. Trudno, nie mówimy tutaj o programistach basica oddelegowanych do poprawiania C++.
A więc dobrze podejrzewałem - jesteś assemblerowcem. Musisz wiedzieć co sie dzieje bo nie ufasz kompilatorom. Ja natomiast odwrotnie. Znajduje zdcecydowanie wiecej bugów we własnym kodzie niż w wygenerowanym przez kompilator.
Mam to za darmo. Używam. PICowcy mogą tylko obejśc się smakiem albo ciągnąć tasiemcowe wywody dlaczego im to nie potrzebne.
Co takiego? Ślepą uliczkę sprzętowego stosu? Brak wsparcia poza żalosnym kompilatorem producenta? Nawt MC sie puknął w czolo i zakopał to cudo głęboko pod ziemią żeby już nie straszyło. Tylko że ARM jest już za tani i za dobry.
Dla mnie nie ma różnicy. Nie pisuje w assemblerze dla niepoznaki nazwanym C.
Jasne.
Słusznie. Nie ma targetu.
Z tego by wynikalo ze 'ukryte' odblokowanie przerwan na koncu funkcji (gdy destruktor zostanie wywolany przez kompilator) jest mniej niebezpieczne niz nieodblokowanie przerwan w ogole? No to powodzenia w debugowaniu kodu ktory ma 300kB bez OSa w celu znalezienia ktora funkcja za pozno wlacza przerwania.
Odwrotnie - pomaga to zamaskowac bug i zrobic go duzo trudniejszym do wykrycia.
Nie widze przydatnosci...
Boli, bo nie da sie uzaleznic od jednego dostawcy. W firmie nigdy nie uzyjemy PICa ani AVRa do niczego co wychodzi na zewnatrz, bo cena za single-source supply jest za duza.
Taaa... a te wszystkie samoloty co po swiecie lataja to w C++ pisane wg Ciebie?
To ze nie wiesz/nie slyszales/nie podano do publicznej wiadomosci, nie daje prawa nikomu mowic ze Ady sie nie uzywa. Uzywa sie w bardzo powaznych zastosowaniach.
PS: 'crap' to sie tlumaczy jako 'gowno' (z US english), a nie 'beznadzieja'. Sprawdz w slowniku.
Na koncu bloku. Jesteś *pewny* że wiedz gdzie strzela destruktor?
Obydwa przypadki sa niebezpieczne. Wole ukryte ale *pewne* niż jawne i podatne na błędy.
Wyłacza zawsze przed } kończącym dany blok lub natychmiast po opuszczeniu bloku inną metoda. W czym problem z tym "za późno" ? Możesz podać przykład?
Stosowanie techniki "scoped" jest powszechne w świecie C++, choćby boost::scoped_lock. Stosuje sie bo można. Inne języki nie mają to sie nie stosuje.
Nie zgadzam się. Moje doświadczenia sa zupełnie inne. To działa tak: implementujesz raz i wiesz że działa. Przechodzisz do dalszych spraw nie przejmując sie że zapomnisz. Po prostu nie zapomnisz. *Zawsze* zadziała. Chyba że będzie bug w kompilatorze. Ale on może być też przy 2+2 w C.
Możesz zacytować moją wypowiedź z której wynika wprost że skoro Ada spowodował bum rakiety to C++ jest używany jako język firmware samolotów? Jakieś message id?
Ktore stanowią szum statystyczny implementacji firmware na procesorach w ogóle. Co napisałem wydawalo mi się dość wyraźnie. Poza tym szumem - nie stosuje się.
Sprawdzałem. Ostatnio gówno bylo "shit". Ale ten świat idzie do przodu.
Dnia 02-05-2012 o 21:11:39 Sebastian Biały snipped-for-privacy@poczta.onet.pl> napisał(a):
Nie, bo czegoś takiego nie zrobię.
Za to:
CriticalSection critical;
... kod rzeczywiscie krytyczny
... dłuższy kod dopisany rok później
Przerwania zablokowane ciut za długo i sobie możesz szukać błędu przez nabliższy miesiąc. Tak, można ograniczyć zasięg tego obiektu, ale...
Dobrze się czegoś o sobie dowiedzieć i nawet do psychoanalityka iść nie trzeba. Jeśli już koniecznie chcesz wiedzieć, to zaczynałem od Pascala (Basica jako dzieciak nie liczę), potem C++, potem VHDL. Następnie z wielkim trudem przeszedłem z C++ do C. Faktycznie sporo fragmentów programuję w assemblerze, ale tylko tam, gdzie jest to absolutnie wymagane ze względu na wydajność. Normalnie w C, a po stronie komputera głównie w C++. Po prostu staram się używać młotka do wbijania gwoździ, a śrubokręta do wkręcania wkrętów.
Nie o to chodzi, że muszę wiedzieć co się dzieje (to że muszę wiedzieć co kompilator robi, to jest jasne), ale o to, że kod powinien wyglądać tak, że będę od jednego rzutu oka widział co się dzieje.
Jakiego sprzętowego stosu?! Sprzętowy jest w 8-bitowych PICach, a ja tu piszę o 16-bitowych. Jak już coś krytykujesz, to wypadałoby wiedzieć o tym cokolwiek.
gcc (oraz HiTech). Bardzo różne od gcc na AVR i od gcc na ARMa, tak?
Bądźże poważny. Obok PIC32 najsilniej rozwijane rodziny (szczególnie PIC24F). Najbogatsze peryferia, a do układów XLP mało co może podskoczyć w kwestii poboru mocy. ARMa w wielu aplikacjach zastępuje z powodzeniem, a cenowo zwykle łatwo wygrywa.
Niezły argument :) Ale to jednak ja jeżdzę na te szkolenia dla FAE Microchipa, a nie ci przypadkowi użytkownicy forum. Nie mówię, że _wiem_ że się pojawi, bo się tym nie interesowałem. Za 2 tygodnie jadę, mogę przy okazji spytać o oficjalne plany.
ae
Podobnie jak wstawiając return i zapominając sei. Ot, taka robota. Trzeba być uważnym.
Kiepski kompilator?
Właśnie. Dlatego używam C++ do uC zamiast wbijać gwoździe plastikowym młotkiem made in china Microchipa.
Przepraszam moja wina, zapędziłem się. PIC24 nie ma. Swoją drogą Świetnie to potwierdza tezę o slepej uliczce :D
Jest jakis gcc? To spaniałe wieści. A gdzie go mogę pobrać? Pytam serio, jeszcze kilka miesiący temu widziałem w sieci same narzekania na brak gcc @ pic.
Wiadomo. Szczególnie że masa kodu dla arma da się kompilować wprost ... oh wait... da się ?
Pytaj. PICe mnie zawsze intertesowaly ze względu na peryferia. Ale podejście do programisty jest skandaliczne.
Dnia 03-05-2012 o 10:27:33 Sebastian Biały snipped-for-privacy@poczta.onet.pl> napisał(a):
Święte słowa. Żadna sztuczka panaceum na brak uwagi nie jest.
Nie, kod odpowiadający na zdarzenia w czasie rzeczywistym. Żeby ci uświadomić o czym mowa: w kawałku, nad którym teraz pracuję jest jeden wykomentowany "nop" i 5 linijek komentarza kiedy należy go włączyć (parametry zewnętrznego układu w relacji do oscylatora). Optymalizuję tam takie rzeczy, jak wykorzystanie rejestrów roboczych w przerwaniu, skutecznie minimalizując liczbę zachowywanych na stosie i kombinując takie kodowanie stanów i dobór instrukcji, żeby nie trzeba było z tych rejestrów korzystać. Gdybym napisał ten kod w języku wyższego poziomu, natychmiast straciłbym tę kontrolę.
Skoro serio, to
ae
Dziwne. Przecież to rola kompilatora. Wręcz książkowa.
Wydaje mi się że tą kontrole musisz utrzymać z powodu kiepskiego kompilatora.
PS. Tak, też mam ciasny kod. Jednak z wyników optymalizacji gcc jestem zadowolony, w *ostateczności* biorę asm, jak każdy. Jednak nie trafia mi się to codziennie żeby warunkowało dobór kompilatora do *wszystkiego*.
full-featured ANSI compliant C. A c++ ?
Dnia 03-05-2012 o 11:19:17 Sebastian Biały snipped-for-privacy@poczta.onet.pl> napisał(a):
Uparłeś się utrzymywać, że kompilator, o którego istnieniu nie wiedziałeś jeszcze wczoraj, z całą pewnością jest do niczego. Pewnie z powodu wbudowanych wad architektury, której kompletnie nie znasz.
Przyjmij do wiadomości, że to jest przypadek w którym można albo zejść do asm, albo zająć się czym innym.
Toż zaczęliśmy od tego, że c++ nie ma. Proponuję też na tym skończyć, bo mi się już nie chce dłużej.
ae
Zgoda. EOT.
W dniu 2012-05-02 14:52, Andrzej Ekiert pisze:
Tak argumentując to można powiedzieć, że bez szukania definicji cli i sei też słabo widać co się dzieje (w szczególności: nie widać tu czy jest jakiś związek między funkcjami cli i sei).
Jeśli użytkownik (programista) tak stwierdzi, to jest to wynik braku znajomości języka czy braku znajomości projektu w którym przyszło mu pracować. Opisany mechanizm jest jasny i prosty -- nie przekonuje mnie tutaj argumentacja, że mamy do czynienia z jakąś ezoteryką (włączając w to debugowanie). Ostatecznie można opatrzyć kod odpowiednimi komentarzami.
W C lub w programowaniu C podobnym: IMO jeden diabeł. Natomiast jeśli program jest w C++, to dochodzą wyjątki... wtedy dopiero jest problem, gdy właśnie trzeba pamiętać, gdzie tu jeszcze wyjątek może polecieć i ręcznie wywoływać odpowiednie finalizacje (pamiętając o odpowiedniej kolejności i czy daną akcję sprzątania rzeczywiście należy przeprowadzić).
Pisząc w C, czyli nie mając do dyspozycji mechanizmu wyjątków i automagicznego wołania destruktorów, obsługa sytuacji nietypowych (różnych błędów itp.) jest czasami naprawdę upierdliwa. Wyjątki w C++ to IMO jedna z ważniejszych i bardziej użytecznych cech różniących ten język od C (tak, ma to swoją cenę).
pzdr mk
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.