Szukam wykonawcy do modułu Ethernet dla Z80 z oprogramowaniem w Delphi i Asemblerze

Wed May 02, 2012 7:11 pm   

On 2012-05-02 14:52, Andrzej Ekiert wrote:

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. http://www.microchip.com/forums/m544964.aspx


Słusznie. Nie ma targetu.

Wed May 02, 2012 8:32 pm   

On 02/05/2012 00:28, Sebastian Biały wrote:

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.

--
Jerry1111

Wed May 02, 2012 9:53 pm   

On 2012-05-02 22:32, Jerry1111 wrote:

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.

Wed May 02, 2012 11:05 pm   

Dnia 02-05-2012 o 21:11:39 Sebastian Biały <heby@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

Fri May 04, 2012 3:53 pm   

W dniu 03.05.2012 23:32, Mario pisze:

Daleko nie trzeba szukać: avr-IAR, arm-rvds, h8-renesas. Pewnie więcej
przykładów by się znalazło.

Fri May 04, 2012 6:25 pm   

On 03/05/2012 22:34, Sebastian Biały wrote:

Mainstream gcc na dosc popularna platforme. Sorry - chcialbym wywolac te
komentarze "ale to przeciez niemozliwe", tylko nie moge.

Nie ma nic wspolnego z Intelem, tyle moge powiedziec.

--
Jerry1111

Fri May 04, 2012 6:35 pm   

On 03/05/2012 22:49, Sebastian Biały wrote:

Jak juz kod bedzie pewny i dzialajacy to idzie do biblioteki i mi wisi w
czym jest pisany. Na pewnym etapie zycia ten kod jest 'wrogi',
'niepewny' i 3x spowodowal wyciagniecie gasnicy ;-(


Oj, moze... ale moze tak samo dla C jak i dla C++.


Mysle ze design nie jest mizerny. Starczy powiedziec ze procek ma <5%
wolnego czasu, ok. 10% spedza w RTOS i reszta w przerwaniach. Ot, taki
sprytniejszy kontroler PWM do przetwornicy.


Jak wczesniej napisalem: czas wykonania programu. W taki sposob mam
bardzo ladna kontrole nad wlaczaniem/wylaczaniem z priorytetami. Wiem,
mozna inaczej zrobic ale u mnie kazda us kosztuje duzo. Poza tym
kompilator glupi i nie zawsze wypelni pipeline procka tak dobrze, jak ja
to zrobie recznie.


Ja wiem ze moge. Po prostu pokazuje ze dla roznych zastosowan sa rozne
rozwiazania. Zaczelo sie od tego ze C++ jest lepsze od C - owszem,
_czasami_ dla _niektorych_ zastosowan.


--
Jerry1111

Sat May 05, 2012 6:40 am   

On 2012-05-04 20:35, Jerry1111 wrote:

Więc kod na destruktorach gwarantuje że jest ok pod warunkiem braku
bugow w kompilatorze. *Tego* nie gwarantuje, ale nie przypominam sobie
takowego w gcc. Przypuszczam jednak że wiekszą masz szanse na dowolnego
innego buga w C który też będzie wymagał wyjęcia gaśnicy. Taki zawód, co
poradzisz.


To nijak nie tłumaczy rozłacznych punktów sekcji krytycznej.


To nijak nie tłumaczy rozłacznych punktów sekcji krytycznej.

Pokaż syntetyczny przykład w którym sekcja krytyczna *musi* być
rozwałkowana.


Bzdua. Zaczeło się od tego że Microchip dostarcza rozwiązania z lat 80
dla lemmingów. Pomimo tego że moze dostarczyć darmowe ciastko nie robi
tego. A potem już poleciała standardowa dyskusja broniąca
"wystarczającego C" jakie już wiele razy widziałem.

Sat May 05, 2012 12:45 pm   

On 05/05/2012 07:40, Sebastian Biały wrote:

Pod warunkiem ze nie zapomnisz napisac destruktora. Kod w C bedzie
dzialal tak samo dobrze jesli nie zapomnisz wlaczyc przerwan. Ale to
troche tak, jakby sie chcialo napisac "Hello, world" i zapomnialo o
printf("Hello, world"); - przed tym sie nie zabezpieczysz.


Tlumaczy - warunki sa sprawdzane w zupelnie roznych miejscach.
Stworzenie poprawnej logiki do tego wymagalo troche sprytnego myslenia
zeby 7 tranzystorow dobrze sterowac, ale bylo warto. Moglbym status
trzymac w zmiennej i miec funkcje ktora by sterowala przerwaniami na
podstawie tej zmiennej, ale robi to za mnie swiat zewnetrzny procka.

Nawet bym to w C++ se napisal, tylko kto mi da cykle zegarowe procka na
cos takiego?

Poza tym to nie jest taka ksiazkowa sekcja krytyczna, to sie dzieje w
przerwaniach i ilosc aktualnie nalozonych na siebie przerwan ma pewien
wplyw na priorytet (czyli poczatek i koniec takiej 'udawanej' sekcji
krytycznej bedzie sie wykonywal z roznymi priorytetami - logika jest
dosc zagmatwana). To wszystko narzucone przez hardware jaki musi byc
sterowany w czasie rzeczywistym. Sztuczka w tym zeby nie tracic czasu na
sprawdzanie tych warunkow bo to wszystko sie wykonuje co 10/20/100/500us
(a jest tam troche logiki i dosc duzo DSP).


Wylaczam przerwanie, cos sie robi i chce wlaczyc przerwanie. W
zaleznosci co sie stalo w miedzyczasie albo wlaczam albo nie. Z
destruktowem musialbym kombinowac i miec jakies parametry mowiace czy
destruktor ma przerwanie wlaczyc czy nie.Tak, wiem, da sie to zrobic na
rozne sposoby, tylko skad ja kuzwa wezme tyle taktow asemblera na to?
Juz pisalem - jedna mikrosekunda jest droga w tej aplikacji, wiec
powstala troche niekonwencjonalna logika.


Czyli kompilator C - nazywajmy rzeczy po imieniu.


Czyli kompilator C++.
Aha - polemizowalbym z tym 'darmowe'...

Zapominasz o jednym - na ile wycenisz koszt szkolenia typowego inzyniera
elektronika zeby umial wykorzystac C++? To sie nie oplaca - chcesz robic
sztuke (perfekcyjna i ladna, ale tylko sztuke - bo to nie zmieni sposobu
dzialania urzadzenia) dla sztuki, a tu chodzi o zarabianie kasy. Nic
dziwnego ze ludzie sie nie zgadzaja.


Czas zaakceptowac? ;-)

--
Jerry1111

Sat May 05, 2012 2:18 pm   

On 2012-05-05 14:45, Jerry1111 wrote:

Nie widzisz róznicy pomiędzy "zapomniałem raz napisac destruktora" a
"zapomniałem napisać pierdyliard miejsc z sei()"? Przeciez oto tu
chodzi. Żeby nie zapomnieć, to kompilator ma zajmować się duperelami
tego typu.


Dlaczego uważasz że C++ zabiera jakies cykle zegarowe?


OK, w więc na *typowy* problem blokowania przerwań masz *szczególny*
przykład gdzie to się nie nada. Jakie to częste w dyskusjach o C++ na uC ...


Typowy pustak argumentowy polega na tym że "muszisz szkolić z C++". Nie
musisz. Zaleta C++ jest to że możesz pisać w C i *powoli* uzywać za
darmo ficzerów. To mogą byc maultkie piedoły typu destruktory i już
podnosisz jakośc kodu za darmo - zarówno jest to łatwiejsze w utrzymaniu
jak i też nie generuje jednego bajtu kodu maszynowego a jest pewne.


Bierz BASCOma. Niektórym jednak zależy na tym żeby kod utrzymywac,
dodawać ficzery, poprawiać bugi i refaktoryzować. Z pierdyliardem cli()
/ sei() miałbym, z każdym z tych spory kłopot co przekłada się na tą
Twoją ekonomie.


Gdybym postulował przejście na haskela to bym się nie dziwił. Ale ja
mówie o darmowym ciastku. Kompilator/składnia identyczna. Większośc kodu
przekompiluje się na tyle gładko, że jak nawet lemmingowi podstawić g++
zamiast gcc to nie zauważy. To bezbolesne. Opór ma źródło w psychice a
nie merytorycznych argumentach.

Sat May 05, 2012 3:17 pm   

Dnia 05-05-2012 o 16:18:33 Sebastian Biały <heby@poczta.onet.pl>
napisał(a):


Nonsens, i to ciężkiego kalibru. Na początku tej dyskusji pisałem, że w
C++ musisz uważać czego nie używać. Weź typowego elektronika, który C
używa jak makroasemblera, a w C++ nie pisał i każ mu cokolwiek napisać.
Ręczę ci, że efektem będzie przerośnęty kod, korzystający z rzeczy, o
których gdzieś na szybko przeczyta i postanowi użyć nie mając pojęcia
jakie z tym wiążą się konsekwencje (np. metody wirtualne, wielokrotne
dziedziczenie). Większość z tych rzeczy będzie napisana bez sensu: np.
cały kod napisany w konstruktorach, nieświadomość jak i kiedy się
uruchamiają konstruktory i destruktory, przeciążone operatory, gdy to
niczemu nie służy, wyjątki, w dodatku źle użyte, itp. A o cechach C++,
które dla ciebie są tak cenne, mogą się nawet nigdy nie dowiedzieć.

Takie narzędzie jak C++ to możesz dać wyłącznie dobrze wyszkolonym
programistom. Więcej trzeba zrozumieć i dużo łatwiej coś spieprzyć.


Taaa, darmowym. Trzeba utrzymać grupę programistów, którzy zrobią port i
będą o niego dbać. Trzeba wyszkolić CAE/FAE, aby byli w stanie to
wspierać. A naprawdę skorzysta z tego (w przypadku małych uC, nie piszę tu
o 32-bit!), jak to pisałeś? - "szum statystyczny". A zmiana poziomu
sprzedaży będzie poniżej tego szumu.

ae

Sat May 05, 2012 5:25 pm   

On 2012-05-05 17:17, Andrzej Ekiert wrote:

Powstawia sei/cli po całym kodzie i będzie narzekać że programowanie to
ciężki zawód bo nie da się tego debugować i naczej nie da rady. Wiem,
bom widział już kilku miszczuf. Faktem jest że kod pisany przez
elektronika zazwyczaj jest gołym asm przerobionym na C ze milionem makr
bez grama wiedzy o programowaniu na jakimkolwiek poziomie abstrakcji.


Będa o tym pamiętać. Podobnie jak nie sprawia problemu pamiętanie o tym
że nie nalezy uzywać sprintf czy conio na uC. Wiedza jak każda inna.
Zawsze ja mogę wrzucić argument że programista po dowolnym kursie C też
będzie na uC pisał gigantyczne bzdury. Ten argument ma dwa końce.

Ilu znasz programistów którzy po wpisanu a/2.5 zdziwili się czemu kod
zrobil się 10x wiekszy? To ten sam problem.


Dlatego nie twierdze że C++ jest dla każdego. Microchip skreslił na
starcie wszystkich ktorzy chciali się rozwinąć. Dlatego unikam jak ognia
pomimo kuszącej oferty hardware tych prockow.


Ta grupa programistów, jesli da się im sensowną architekturę, utrzymuje
się sama albo z mizernych datków. Widocznie MC zauwazył że odstaje od
świata i wsadził MIPSa co rokuje nadzieje że da się na tym coś
współczesnego skompilować a grupa pryszczatych nastolatków będzie mu
utrzymywała gcc.

Sat May 05, 2012 5:29 pm   

no pochwal się, Ktoś się zdecydował?

Sat May 05, 2012 5:47 pm   

On 05/05/2012 15:18, Sebastian Biały wrote:

Ale u mnie co projekt to pisanie _wszystkiego_ od nowa. Wisi mi czy mam
debugowac konstruktor, makro czy funkcje.


A bedziesz laskawy spowrotem wstawic caly kontekst?


U mnie typowy. Od 10 lat nie napisalem ani jednego kodu embedded w
sposob *typowy* dla wiekszych maszyn. Tego sie nie da oderwac od warstwy
sprzetu jesli sie chce zarobic.


Taaa... a kto zaplaci za pierwsze 2 miesiace zonkow podczas takiej
transformacji? To ma sens gdzies na uczelni gdzie przy pomocy fajki
mozna myslec o roznych rzeczach przez tydzien. W mojej okolicy za dzien
myslenia jednego inteligentnego idzie faktura w walucie.
Po kilku latach pracownik sie nauczy i co? Odejdzie i bedzie problem -
szukaj drugiego takiego...


Nie jest za darmo, jesli wstawi gdzies ciag znakow "virtual" (bo nie wie
ze nie wolno) i 3 dni bedzie szukal czemu "Hello world" nie miesci sie
do flasha.


Zrozumiales co napisalem?
Moze jeszcze masz plugin Matlab->Bascom?


Prosze bardzo - czy ja nie mowie ze nie? Niektorym zalezy na zrobieniu,
wsadzeniu do produkcji i braniu sie za inny _produkt_.


Darmowe nie jest. Producent musi wydac kase zeby to zrobic, klient musi
wydac kase zeby to dobrze uzywac. IMO return on investment bedzie
ujemny. Jest 6e9 ludzi i wychodzi ze jestes jedynym adwokatem.
Statystyka mowi mi ze cos nie tak.


O!


Znaczy nie identyczna.


Opor ma zrodlo w koncie bankowym. Inaczej wszyscy by robili jak piszesz,
bo by wiecej zarabiali.

--
Jerry1111

Sat May 05, 2012 6:26 pm   

On 2012-05-05 19:47, Jerry1111 wrote:

Tym fajniej busi być debugować te same błedy za każdym razem.


Nie piszę tu o nietypowości że piszesz na uC. Mowię o tym że piszesz
nietypowo jak na uC skoro emulujesz priorytety przerwać na cli/sei
porozrzucancyh po kodzie. Na ten (mizerny) przykład u mnie są same
przypadki CriticalSection a kod jest RT jak najbardziej. Byc może mamy
rózne style pisania kodu. I nie, nie piszę firmware do migania diodą,
problemy są realne i raczej żyłują procesor na pełne osiągi.


Jakiej transformacji? ScopedWhatever masz za 30 sekund w kodzie. Już.
Działa. 0 zonków.


Pięknie ujmujesz poziom kwalifikacji przeciętnego klepacza firmware :)


Gorzej, jeśli wstawi gdzieś printf to może i 3 flaszy zabraknąć. I co,
porzucamy C i piszemy w asm? Fakt, dla wielu żadna różnica.


Ani razu w tej dyskusji nie padło słowo "matlab" o ile dobrze widzę.
Więc argumentujesz używając ukrytej wiedzy. To nie fair.


Słusznie. Dzieki takiem podejściu zawsze zaczynasz od int main() { } i
odkrywasz kwadratowe koła za każdym razem. Ekonomia, ja rozumiem. Ja tak
nie potrafie. Może z tego wynika brak porozumienia.


Oczywiście, jesli nie narobiłeś straszliwej kupy w C to skompiluje się
jako C++.


Nie, z dokładnością do kupy w kodzie. Zazwyczaj wychodzi na zdrowie jej
poprawienie.


Masz jednokierunkowe podejście do ekonomi. Faktycznie, jesli robisz małe
projekty to moje rady nie mają żadnego zastosowania. Jeśli jednak robisz
większe to nagle potrzeba refaktoringu, ponownego użycia, abstrakcji
staje sie bezpośrednio przekładalna na pieniądze. Zawodowo co prawda mam
do czynienia ze znacznie więszymi apliakcjami od strony kodu, ale zasady
są podobne - tracisz czas (i pieniądze) używając prymitywnych narzędzi,
choć pozornie wydaje się że tworzą produkt szybciej. Bez realiów cięzko
dyskutować czy Tobie taki model biznesu pasuje. Jak widze nie. To jednak
oznacza coś bardzo niefajnego: nie masz realnego przykładu na którym
możesz wykazać mizernośc C++. Bo masz tylko argument ekonomiczny i to
popraty raczej mizerną argumentacją. A taki argument jest zawsze
subiektywny, więc nie ma sensu ciągnąć dyskusji.

Mi potrzeba abstrakcji, destrutorów, traits wyszła na AVR. Dzieki temu
ostatnio firmware (specyficzny, RT) napisałem w 0.5 dnia wykorzystując
90% kodu optymalnie (tzn w C nie dało by się lepiej, musiałbym dlubac w
ASM) i 10% dopisując. Mógłbym to samo mieć w C z pomocą kilku
pokracznych makr, ale szacuje że bym się nie wydłubał przez tydzień z
ifdefów. I szacunek popieram próbą którą zarzuciłem po 3 dniach.

Byc może mi pomaga doświadczenie z duzych systemów, bo zawodowo pisuję w
C++ spore rzeczy. Myslę że to zawsze jednak ok poznać inny punkt
widzenia, nawet w ostrej dyskusji (którą to raz na jakiś czas próbuje
wzniecić). Ktoś mi tu zarzucił mesjanizm, może i racja.