Linux a elektronika (ciut dlugie)

Witam,

Poniewaz od pewnego czasu uzytkuje linuksa, a starego windowsa juz sie pozbylem bylem pozbawiony mozliwosci zabawy z elektronika - konkretnie chodzi o assemblacje, kompilacje programow, obsluge programatorow, programow do projektowania plytek i schematow..etc ,etc. Ostatnio jednak troche przysiadlem przy necie, poszperalem i okazalo sie ze jest sporo linuksowych odpowiednikow programow dla elektronikow.

Mnie osobiscie interesowaly mikrokontrolery z rodziny '51 i PIC. Poniewaz programuje w assemblerze poszukiwalem assemblerow pod te rodziny, kompatybilnych z oryginalnymi programami producentow (zeby moc wykorzystac swoje stare biblioteki programow) I tak pod '51'ke mamy programik o nazwie ASEM51, który w/g tworcow jest odpowiednikiem ASM51. Sprawdzilem - owszem kompiluje sie, tworzy kod wynikowy - zauwazylem tylko jedna roznice - wielkosc pliku hex jest troche rozna od oryginalnego hex'a skompilowanego pod WIN. Ciekawe czy mimo to, ten kod bedzie funkcjonalnie identyczny jak ten spod WIN? Czy rozne kompilatory, mimo identycznego kodu zrodlowego generuja troche rozne kody wynikowe, ktore jednak funkcjonalnie sa identyczne? Pamietajmy, ze mowimy o assemblerze gdzie instrukcja tlumaczy sie 1 do 1. Niestety poniewaz moja programatorka pod linuksem jeszcze nie dziala, nie moge sprawdzic w dzialaniu tej tezy. Moze ktos ma doswiadczenia w tym wzgledzie?

Pod PIC'e znalazlem programik gpasm, ktory jest odpowiednikiem Microchipowego mpasm'a. Wydaje sie ze dziala rowniez dobrze - probna kompilacja dosc duzego programu zrodlowego przebiegla tylko z jednym bledem

- assembler zinterpretowal wyrazenie '"' (cudzyslow w dwoch apostrofach) blednie - jako "otwarty cudzyslow bez zakonczenia", nie uwzgledniajac tego ze znak cudzyslowu jest w dwoch apostrofach i powinien byc potraktowany jako wartosc ASCII cudzyslowu... Ale - mozna to obejsc podajac bezposrednio liczbe ASCII odpowiadajaca znakowi ".

Do programowania PIC'ow jest dosc sympatycznie wygladajacy programik o nazwie flP5, ktory mozna latwo dostosowac do posiadanego programatora rownoleglego - wystarczy przypisac sygnaly sterujace do odp. pinow i gotowe :-) Do programowania innych mikrokontrolerow jest PonyProg - wersja linuksowa.

Do plytek drukowanych znalazlem Eagle'a - linuksowa wersja tego znanego w swiecie WIN edytora.

Tak wiec - nie jest tak zle, jak mi sie na poczatku wydawalo :-)) Argument, ze "Windows jest mi potrzebny bo korzystam z programow dla elektroniki, ktore dzialaja tylko pod WIN", wydaje sie tracic na wartosci. A co ciekawe - opisane prze mnie assemblery charakteryzuja sie jeszcze natychmiastowa szybkoscia dzialania - wciskam enter i juz mam kod wynikowy. Pod WIN jednak ta kompilacja trwala ciut dluzej (bylo widac jak program "mieli" troche)

Ktos ma jeszcze jakies doswiadczenia z linuksem i elektronika?

Reply to
Jado
Loading thread data ...
Reply to
Grzegorz Kurczyk

w przypadku 8051 instrukcja JMP może być przetłumaczona na SJMP, AJMP albo LJMP. zależy od tego, jak optymalizuje asembler. niektóre na przykład w ogóle nie biorą pod uwagę SJMP i AJMP, tylko idą na łatwiznę i wstawiają LJMP. inne wstawiają SJMP dla skoków -128/+127 i LJMP dla reszty. podobnie jest z instrukcją CALL.

w.

Reply to
Wojtek Kaniewski

Wielkosc pliku HEX ma sie nijak do wielkosci kodu w nim zawartego, porownaj pliki bin - powinny byc takie same.

Teoretycznie powinny byc jak piszes, poniewaz to programista decyduje o kazdym rozkazie. Moze natomiast tak sie przytrafic, ze kompilator uzupelni kod jakimis nieistotnymi wartosciami, jesli np: programista pozostawi wolne przestrzenie w _kodzie_ ;-) Nawet konwertery hex->bin czasami takie dziury roznie traktuja i roznie wypelniaja.

__ Pzd, Irek.N.

Reply to
Ireneusz Niemczyk

Qrcze - myslalem o jednym a pisalem o drugim - oczywiscie chodzilo mi o pliki bin - byly ciut inne w wielkosci.

Reply to
Jado

Faktycznie - masz racje...z rozpedu zapomnialem o tym... Teraz wlasnie testowo zrobilem jeszcze raz probe i uzylem konwertera hexbin pod linuxa - stary (windowsowy) i nowy (linuksowy) plik bin maja te sama identyczna wielkosc :-) mimo, ze oba byly assmblowane pod roznymi systemami. No to super :-)

Reply to
Jado

Moze to nie jest politycznie poprawne - ale pod linuxem dziala przeciez dosemu.

Powinien byc tez jakis port z gcc - tzn assemblera z pakietu.

Rozmiar kodu czy rozmiar pliku ? Bo wystarczy tylko dac LF zamiast CR+LF na koncu linii i bedzie inaczej. Albo inna ilosc bajtow zakodowac w linii Hex

Chyba ze kompilator pisal Microsoft :-) O jmp juz wspomniano.

J.

Reply to
J.F.

On Fri, 09 Jan 2004 23:19:55 +0100, Jado snipped-for-privacy@chello.pl wrote: [.....]

Prawdopodobnie chodzi o znaki końca lini: pod Win jest używana para CR/LF a pod uniksami LF. Przerób sobie hex-a wygenerowanego pod Win programikiem fromdos i porównaj cmp lub diff-em. Nie powinno być różnic.

[.....]

To może być błąd. Wysłałeś bugreport-a autorom?

[.....]

Eagle jest niezły, chociaż nie ma różnych przydatnych ficzerów. Trochę odstaje od mainstream-owych aplikacji jak np. PCAD.

Źle nie jest, bo pracować jakoś się da. Ale o ile Linuks jest praktycznie nie do pobicia jako serwer wszelakiej maści usług "internetowych", nieźle sprawdza się jako platforma dla DBMS-ów, to niestety, brakuje dobrego softu inżynierskiego. Do PCB praktycznie jest tylko Eagle, nie ma żadnego (tzn. ja nie znam) CAM procesora, do rysunku technicznego jest "tylko" Microstation i QCad. Generalnie jest klopot z softem, który ze swojej natury wymaga GUI. Bo już np. z symulacją (Spice, Xspice), matematyką (Octave, Scilab, komercyjna Mathematica) czy też kompilatorami/assemblerami jest dobrze. Za jakiś czas będę chciał pobawić trochę w PLD/FPGA i zauważyłem że w tej działce też zaczyna robić się dobrze. Jest trochę darmowego softu, a Xilinx (i zdaje się że Altera również) wypuściły linuksowe wersje swojego softu.

Mimo wszystko należy się cieszyć że idzie ku lepszemu - widać to dosyć wyraźnie, gdy spojrzę na to z perspektywy 5 lat, tzn. od czasu, gdy na poważnie zacząłem używać Linuksa.

A co powiesz o, za przeproszeniem, Płaczniku. :-) No ale to jest soft "nieelektroniczny." :-) No i nie każy musi go używać. :-)

[.....]

Regards, /J.D.

Reply to
Jan Dubiec

formatting link

Reply to
Adam Dybkowski

On Sat, 10 Jan 2004 01:21:21 +0100, Adam Dybkowski snipped-for-privacy@amwaw.edu.pl> wrote: [.....]

BTW. No to w górę "serca" jak pisze Jerry. ;-)))

Regards, /J.D.

Reply to
Jan Dubiec

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.