String s offset-om za svaki char?

[Chupo]

Se moze u C-u inicijalizirati array sa stringom u kojem bi ASCII svakog
character-a bio zamijenjen s ASCII+offest?

Recimo SjASMPlus (crosscompiler) ima pseudo-op:

abyte offset "neki_string"

Recimo

abyte -1 "c,d,e,f"

je isto kao

abyte "b,c,d,e"

Meni treba kad bi se tako nesta moglo s


static const unsigned char msg[] PROGMEM = "neki_text";

PROGMEM je gcc atribut koji compileru kaze da array treba biti u
programskoj memoriji (mikrokontrolera).

[Zeljko Vrba]

Post by Chupo
Se moze u C-u inicijalizirati array sa stringom u kojem bi ASCII svakog
character-a bio zamijenjen s ASCII+offest?

Ne moze i ne vidim poantu; jednostavno inicijaliziraj array da sadrzi
tocno ono sto ti treba.

[Chupo]

Post by Zeljko Vrba
Ne moze i ne vidim poantu; jednostavno inicijaliziraj array da sadrzi
tocno ono sto ti treba.

Vidim da cu ti morati odgovoriti na onaj zadnji post u : 'RAM memorija
u asembleru?' :-))

Znaci treba mi nesta sta nui svaki pristojan compiler. Evo
dokumentacije pseudo-op-a abyte u SjASMPlus-u:

ABYTE <offset> <bytes>

Defines a byte or a string of bytes. The offset is added to each of
the following bytes.

Example 5.2.

ABYTE 2 4,9 ; Same as BYTE 6,11
ABYTE 3 "ABC" ; Same as BYTE "DEF"

[Chupo]

nudi

[Zeljko Vrba]

Post by Chupo
Znaci treba mi nesta sta nui svaki pristojan compiler.

Nema toga u C-u. Uostalom, tko te tjera da koristis C, nadji si
neki "pristojan kompajler" za platformu koja ti treba.

[Chupo]

Post by Zeljko Vrba
Nema toga u C-u. Uostalom, tko te tjera da koristis C, nadji si
neki "pristojan kompajler" za platformu koja ti treba.

Naso sam. gcc je dosta dobar ali nazalost ne podrzava pseudo-op za
offset-e. Najvaznije je ipak da podrzava inline assembler :-))

Trenutno inace radim s atmega8 - covjek koji je narucio uredjaj ga je
imao pa, s obzirom da je overkill a nista nije vremenski kriticno, mogu
bez brige raditi i u C-u ;-) Ali kad radis s npr. 12c508 pa ti zbog
jedne naredbe compiler trazi neki include koji odnese 50 byte-ova (a to
je 10% od 512 byte-ova ukupne programske memorije), ili stavis jedan IF
i 2 SWITCH-a pa to odnese 6-7 byte-ova sta je cetvrtina od 25 byte-ova
ukupnog RAM-a... :-))

[Zeljko Vrba]

Post by Chupo
Naso sam. gcc je dosta dobar ali nazalost ne podrzava pseudo-op za
offset-e. Najvaznije je ipak da podrzava inline assembler :-))

Meh, odustajem. You're doing it wrong ;-p

[Mario Malenica]

Post by Chupo
Trenutno inace radim s atmega8 - covjek koji je narucio uredjaj ga je
imao pa, s obzirom da je overkill a nista nije vremenski kriticno, mogu
bez brige raditi i u C-u ;-)

Atmega8 ima 8KB programske i 1kb data memorije. Dobro, i 512 byte-a
EEPROM-a.

Standardni C nema rješenje koje trebaš, zapravo niti jedan C kompajler s
kojim sam radio (pa i ovi za mikrokontrolere) nije imao nešto takvo.

Koliko razumijem, ti planiraš podatke staviti u programsku memoriju, a
vidim nisi naveo kako bi to bilo tijekom rada (SPM instrukcija), nego u
fazi izrade SW-a. Pa bi se tu moglo odraditi s nekoliko opcija.

Prva je za slučaj da imaš puno array-a, a ne da ti se tipkati kod - uzmeš
"glavni" array i zatim napišeš mali program koji offsetira za koliko je
potrebno i zapiše sve te array-e u nekakvu header datoteku, koju zatim
ubaciš u svoj projekt.
Ako nemaš mjesta u flashu, ima tamo u čipu i nekih 512 byte-a EEPROM-a, a i
nije nešto puno sporiji od čitanja iz flash memorije, no trebati će ti
dodatni kod za pristup podacima.

Drugi način je funkcija koja inkrementira vrijednost, a to može odraditi
tako da joj kao parametar daješ člana array-a i offset. Stack ti ne bi
trebao biti problem, prepostavljam da imaš tih 30 i nešto byte-a RAM-a
slobodno. Čini mi se kako se inline poziv ovakve funkcije ne bi isplatio,
jer bi pojeo više prostora u programskoj memoriji od jednostavnog
deklariranja array-a.

Ili ako imaš dovoljno RAM-a, napravi funkciju koja odradi alociranje
prostora za array, pa onda kopiranje i inkrementiranje. Kao rezultat vratiš
pointer na array. :)
Nakon korištenja naravno oslobađaš alociranu memoriju.
No, u ovom slučaju treba i obavezno raditi provjere je li zbog nekog
razloga crklo alociranje memorije.

[Chupo]

Post by Mario Malenica

Post by Chupo
Trenutno inace radim s atmega8 - covjek koji je narucio uredjaj ga je
imao pa, s obzirom da je overkill a nista nije vremenski kriticno, mogu
bez brige raditi i u C-u ;-)

Atmega8 ima 8KB programske i 1kb data memorije. Dobro, i 512 byte-a
EEPROM-a.

Znam, zato i kazem da je overkill za ovo sta radim i da bez brige mogu
koristiti C (ne moram nista napraviti u assembler-u)

Post by Mario Malenica
Standardni C nema rješenje koje trebaš, zapravo niti jedan C kompajler s
kojim sam radio (pa i ovi za mikrokontrolere) nije imao nešto takvo.
Koliko razumijem, ti planiraš podatke staviti u programsku memoriju, a
vidim nisi naveo kako bi to bilo tijekom rada (SPM instrukcija), nego u
fazi izrade SW-a. Pa bi se tu moglo odraditi s nekoliko opcija.
Prva je za slučaj da imaš puno array-a, a ne da ti se tipkati kod - uzmeš
"glavni" array i zatim napišeš mali program koji offsetira za koliko je
potrebno i zapiše sve te array-e u nekakvu header datoteku, koju zatim
ubaciš u svoj projekt.
Ako nemaš mjesta u flashu, ima tamo u čipu i nekih 512 byte-a EEPROM-a, a i
nije nešto puno sporiji od čitanja iz flash memorije, no trebati će ti
dodatni kod za pristup podacima.
Drugi način je funkcija koja inkrementira vrijednost, a to može odraditi
tako da joj kao parametar daješ člana array-a i offset. Stack ti ne bi
trebao biti problem, prepostavljam da imaš tih 30 i nešto byte-a RAM-a
slobodno.

Ovo za 25 byte-ova koliko imaju 12c508 i 12f508 sam spomenuo kao
nastavak na nedavnu raspravu s Zeljkom na comp.programiranje (da li
ima/nema smisla raditi u assembleru, zasto ima/nema, ...).

Post by Mario Malenica
Čini mi se kako se inline poziv ovakve funkcije ne bi isplatio,
jer bi pojeo više prostora u programskoj memoriji od jednostavnog
deklariranja array-a.
Ili ako imaš dovoljno RAM-a, napravi funkciju koja odradi alociranje
prostora za array, pa onda kopiranje i inkrementiranje. Kao rezultat vratiš
pointer na array. :)
Nakon korištenja naravno oslobađaš alociranu memoriju.
No, u ovom slučaju treba i obavezno raditi provjere je li zbog nekog
razloga crklo alociranje memorije.

Sve sam napravio ali bi mi u fazi testiranja dobro doso spomenuti
pseudo-op. Evo jednog nedavnog primjera gdje sam (na Z80) koristio
takvu mogucnost. S obzirom da rutina radi u interrupt-u a generirace
sliku i na border-u (ovo je testna faza), krajnji program ce morati
prilikom prolaska kroz vise grana uvijek trajati tocno isti broj
taktova. Na nekim mjestima mogu uz drukciju organizaciju podataka od
standardne smanjiti broj instrukcija. U ovoj konkretnoj rutini sam bez
offset-a na ASCII kodove mogo isto postici da sam pointer HL na 15616
inicijalizirao na tu adresu umanjenu za 256 ali planiram dodati jos
stvari i to mi ne bi odgovaralo jer mi treba da mi HL pokazuje na 8
praznih byte-ova (definicija space character-a). Izmedju ta dva stanja
bi se mogo prebacivati s INC H i natrag s DEC H ali mi vise odgovara da
su offset-i vec u 'ASCII'-ima. Rutina jos ni izdaleka nije
optimizirana:

;26.06.2012. by Chupo
;IM2 mode
;stari trik za ustediti 256 byte-ova za tabelu interrupt vectora
;character set addr u ROM-u: 15616 (#3D00)
;ako se izbace naredbe oznacene sa strelicama i otkomentira RET,
;onda se umjesto okomite linije ne generira nista nego se samo
;ostavlja jedan prazan stupac
;text je definiran s ASCII kodovima umanjenim za 32 (SPACE = 0)
;legalni kodovi su od 0 do 95
;oznaka za kraj texta je #FF
;definicije karaktera se uzimaju iz ROM-a (addr 15616 = #3D00)
;program je samomodificijajuc (*)
;OUT (#FE),A unutar interrupt-a mijenjaju BORDER tako da se
;moze vidjeti koliko rutina trosi vremena
;snapshot entry point je #52, na toj adresi u ROM-u je #C9 (RET)

device zxspectrum48

org #c000 ;49152
pocetak di ;iskljuci interrupte za vrijeme promjene mode-a
ld a,#39 ;visi byte pokazuje na vise od 256 #FF-ova u
ROM-u
ld i,a ;podesi interrupt vector
im 2 ;interrupt mode 2
ei ;ponovo omoguci interrupt-e
ret ;vrati se (u Basic)

int_addr di
push af ;spremi registre na stack
push hl
push de
push bc

ld a,5
out (254),a

ld hl,16384+6144 ;HL = adresa prvog atributa
push hl
pop de ;DE = adresa prvog atributa
inc hl ;HL = adresa drugog atributa
ld a,8 ;8 redova
scroll_l ld bc,31 ;brojac prebacivanja za LDIR
ldir ;scroll jednog reda atributa ulijevo
push af ;spremi registre
push hl
push de
push bc
call crtaj ;nacrtaj kvadratic
pop bc ;vrati registre
pop de
pop hl
pop af ;vrati A
inc hl ;slijedeci red
inc de
dec a ;brojac redova
jr nz,scroll_l

ld a,7
out (254),a

pop bc ;vrati registre sa stack-a
pop de
pop hl
pop af
jp #38 ;pozovi interrupt rutinu iz ROM-a

;crtanje kvadratica u 32. stupcu
;input: A = 8..1 (broj stupca)
;row = 8 - A
;8 --> 0, 7 --> 1, ..., 1 --> 7
crtaj neg
add a,8 ;A = 8 - A
ld (row),a ;spremi izracunatu vrijednost
ld hl,15616 ;HL = adresa definicije charactera u ROM-u
ld de,msg ;DE = adresa poruke
ld a,(pos) ;procitaj offset
add a,e
ld e,a ;DE pokazuje na trenutni character
jr nc,skip4
inc d
skip4 ld a,(de) ;A = ASCII trenutnog character-a
cp #ff ;da li je oznaka za kraj texta?
jr nz,skip3 ;ako nije onda je ASCII, preskoci
ld a,%00100000 ;PAPER = GREEN
<--------------------------------
ld (atr+1),a ;plava okomita crta (*)
|
ld a,(row) ;procitaj row offset |
cp 7 ;da li je bio zadnji red? |
jr nz,b_line ;ako nije, preskoci resetiranje offset-a
<------
xor a ;kraj text-a i zadnji red, A = 0
ld (pos),a ;resetiraj string offset
;ret ;vrati se na scroll (jedan stupac ce biti prazan)
ld a,(col) ; <---------------------------------------------
dec a ; |
ld (col),a ;korekcija kad se ne crta iz ROM-a |
jr b_line ; <---------------------------------------------
skip3 ld b,#00 ;nije bila oznaka za kraj texta
ld c,a
sla c
rl b
sla c
rl b
sla c
rl b ;BC = 8*ASCII
add hl,bc ;HL pokazuje na prvi byte charactera
ld a,(row) ;procitaj row offset
add a,l
ld l,a
jr nc,skip1
inc h ;HL = HL + A
skip1 ld a,(col) ;procitaj column offset
ld b,a ;B je brojac za rotaciju
ld a,(hl) ;procitaj definiciju reda character-a
rot_row rla ;najvisi bit u carry
djnz rot_row ;nakon petlje je u carry bit koji trazimo
ld a,%00111000 ;PAPER = WHITE
jr nc,skip2 ;ako je pixel 0 preskoci
ld a,%00101000 ;PAPER = CYAN
skip2 ld (atr+1),a ;modificira instrukciju LD A,#00 (*)
b_line ld hl,22528+31 ;HL = adresa zadnjeg atributa u prvom
redu
ld a,(row) ;ponovo procitaj row offset
sla a
sla a
sla a
sla a
sla a ;A = A*32
add a,l
ld l,a ;HL pokazuje na zadnji atribut u row redu
atr=$ ld a,#00 ;parametar se modificira (*)
ld (hl),a ;nacrtaj kvadratic
ld a,(row) ;procitaj row offset
cp 7 ;da li je bio zadnji red?
ret nz ;ako nije bio zadnji, vrati se
ld a,(col) ;bio je zadnji red, procitaj column offset
cp 8 ;da li je bio zadnji stupac u character-u?
jr z,last_row ;ako je bio i zadnji stupac, preskoci
inc a ;povecaj brojac stupaca
ld (col),a ;spremi ga
ret ;vrati se
last_row ld a,1 ;bio je zadnji stupac a nacrtan je i
zadnji red
ld (col),a ;resetiraj brojac za stupce
ld a,(pos) ;procitaj string offset
inc a ;povecaj offset
ld (pos),a ;spremi ga za slijedeci put
ret ;povratak

msg abyte -32 " IM2 ATTRIBUTE SCROLLER by Chupo. MADE IN A FEW
HOURS, CAN STILL BE IMPROVED."
abyte -32 " READS CHAR DEFINITIONS FROM THE ROM AT ADDR 15616
"
abyte -32 #7f ;ASCII za ?
abyte -32 " Chupo 22.06.2012. "
defb #ff ;znak za kraj
pos defb 0 ;string offset
row defb 0 ;row offset
col defb 1 ;column offset (1 - 8)

;interrupt stuff
org #ffff ;tu ce biti interrupt vector bez obzira na podatak na
data BUS-u
defb #18 ;OP code instrukcije JR,e
;kao parametar ce se uzeti byte 0 u ROM-u (#FE -->
DI)
;to ce biti JR,$-13 i program ce se nastaviti na
65524

org 65524 ;#fff4
jp int_addr ;skok na interrupt rutinu
kraj
display " "
display "GRESAKA : ", /d, _ERRORS
display "UPOZORENJA : ", /d, _WARNINGS
display "DUZINA PROGRAMA: ", /a, kraj - pocetak, " bytes"
display " "
savesna "im2_attrText.sna", #52

[Chupo]

Ispravno formatirano i highlight-ano:

http://z80.paste.to/NjM3MTg1

[Chupo]

Ako se neko slucajno pita zasto su sa strelicama oznacene petlje u
komentarima, to je zato jer ce tu doci proracun potrosenih T stanja,
slicno ko u ovoj rutini za generiranje zvuka od *tocno* 440 Hz:

http://z80.paste.to/NjM3MjE0

Naravno, tocno koliko dozvoljava hardware.

[stylex]

Post by Chupo
Naso sam. gcc je dosta dobar ali nazalost ne podrzava pseudo-op za
offset-e. Najvaznije je ipak da podrzava inline assembler :-))

"Our sources are readily and freely available via SVN and weekly snapshots."
Izvor: gcc.gnu.org

Koliko vidim GCC je open source free software. Dakle, apsolutno nikakvih
prepreka da malo upristojis compiler i dodas trivijalnost tipa pseudo-opa po
zelji. :)

[Chupo]

Post by Zeljko Vrba
Nema toga u C-u.

U ANSI C sigurno ne. Ali to ne znaci da neki C compiler ne bi smio
imati pseudo-ope koji olaksavaju rad.

ANSI C ne podrzava niti range-ove u CASE-ovima ali npr. gcc podrzava:

http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Case-Ranges.html

[Goran Mitrovic]

Post by Chupo
static const unsigned char msg[] PROGMEM = "neki_text";
PROGMEM je gcc atribut koji compileru kaze da array treba biti u
programskoj memoriji (mikrokontrolera).

Nije li bilo jednostavnije obrisati taj PROGMEM nego pisati objasnjenje?
:)

[Zeljko Vrba]

Post by Goran Mitrovic
Nije li bilo jednostavnije obrisati taj PROGMEM nego pisati objasnjenje?
:)

E ali on je "pravi programer", ne moze to samo tako ;P

[Zeljko Vrba]

Post by Zeljko Vrba
E ali on je "pravi programer", ne moze to samo tako ;P

Cemu to? Niti sam se deklarirao ko programer, niti se podrazumijeva da

Cemu to? Vise razloga:

1. Dio sa PROGMEM nema nikakve veze sa tvojim problemom.
2. Unatoc 1), isao si objasnjavat sto PROGMEM radi.
3. Pitas o C-u, a (zbog 2)) istovremeno pretpostavljas da C programeri nisu
u stanju uvidjeti da PROGMEM nema veze s tvojim pitanjem.
4. Izgleda da ne zelis shvatiti da je C standardizirani jezik, a ne
Z80 assembler.

Kao sto ti je Goran vec rekao, nepotrebno kompliciras. Ako hoces imati
mogucnosti assemblera, pisi u assembleru umjesto da trazis C kompajler
koji podrzava feature assemblera. [Takav C kompajler ne bus nasao.]

Ako bas hoces C, nauci se kako pisati programe koji su dio C, dio ASM,
kako ih kompajlirati, linkati skupa i kako sve to automatizirati sa
shell skriptom ili Makefileom. Pa si sam slozi u poseban fajl u ASM-u
i slozi si tamo poruke sa ABYTE.

E i da,

5. Tvoji postovi odisu tonom tipa "Ja sam cool jer radim cuda u ASM-u,
znam Bresenhamov algoritam [itd], a vi koji koristite high-level
jezike samo slazete lego kockice i zapravo nemate pojma o tome kaj
je pravo programiranje."

E pa kad dodjes s takvim stavom onda ocekuj i odgovor kakav si dobio. Ja bih
ti sad mogao utrljati u nos brdo stvari koje sam ja isprogramirao u relativno
kratkom roku, a sve PUNO kompliciranije od jednog Bresenhamovog algoritma ili
zbrajanja vremena izvrsavanja instrukcija da postignes zeljeni efekt.

PS: bas me zanima po cemu sljedecem ces kenjati kad/ako otkrijes da ni
*assembleri* za AVR ne podrzavaju sve pseudo-opove na koje si navikao
na SLJBLAHasm-u.

PPS: I ja sam se davno malo bavio elektronikom, ali ne umisljam si zato da ja
znam nesto vrijedno spomena o elektronici i nikad mi nije palo na pamet zalit
se profesionalnim elektronicarima o... ne znam, recimo zakaj ne mogu kupit 74xx
IC sa 5 invertera jer mi tocno tolko treba pa ga bude jednostavnije zalemit na
plocicu -- a otprilike na tom nivou su tvoji postovi.

[Chupo]

Post by Zeljko Vrba
1. Dio sa PROGMEM nema nikakve veze sa tvojim problemom.

Nekog mozda zanima, lako preskocis.

Post by Zeljko Vrba
2. Unatoc 1), isao si objasnjavat sto PROGMEM radi.

A to je protivno pravilima grupe?

Post by Zeljko Vrba
3. Pitas o C-u, a (zbog 2)) istovremeno pretpostavljas da C programeri nisu
u stanju uvidjeti da PROGMEM nema veze s tvojim pitanjem.

??

Post by Zeljko Vrba
4. Izgleda da ne zelis shvatiti da je C standardizirani jezik, a ne
Z80 assembler.

Nisam trazio ANSI compiler nego neki koji to podrzava. Dao sam i
primjer GCC-a koji podrzava nestandardne stvari.

Post by Zeljko Vrba
Kao sto ti je Goran vec rekao, nepotrebno kompliciras. Ako hoces imati
mogucnosti assemblera, pisi u assembleru umjesto da trazis C kompajler
koji podrzava feature assemblera. [Takav C kompajler ne bus nasao.]

Taj sam odgovor trazio - znaci, ne postoji C compiler koji podrzava to
sta sam trazio - tnx.

Post by Zeljko Vrba
Ako bas hoces C, nauci se kako pisati programe koji su dio C, dio ASM,
kako ih kompajlirati, linkati skupa i kako sve to automatizirati sa
shell skriptom ili Makefileom. Pa si sam slozi u poseban fajl u ASM-u
i slozi si tamo poruke sa ABYTE.

Program u kojem sam trebao ABYTE s offset-om je kompletan u C-u, u
njemu nema potrebe za inline assembler-om. Radi se o tome da sklop
poruke prikazuje na 7 segmentnom LED-u koji sluzi i ko debug output a
podaci su mi u prikazanom znaku i ukljucenoj/iskljucenoj tockici, sve
skupa je spojeno na jedan port mikrokontrolera i podatke na ekran
saljem ovako:

SCREEN_PORT = (pgm_read_byte(&(charTable[znak+offset_01])) | dot_bit) ^
jumper_LED;

XOR s jumper_LED je zato jer ekran moze biti s zajednickom anodom (onda
se radi XOR s 0xff) ili sa zajednickom katodom (jumper_LED je onda 0).

S druge strane, ako se radi o brojci a ne znaku onda byte na ekran
saljem s recimo

SCREEN_PORT = (pgm_read_byte(&(charTable[relay_num+offset_02])) |
dot_bit) ^ jumper_LED;

Ako definicije karaktera recimo pocinju od SPACE onda (za uppercase
stringove) offset_01 mora biti -32 a offset_02 +16. Drukcijom
organizacijom definicija karaktera bi ustedio odredjeni broj byte-ova
jer mi ne trebaju karakteri izmedju SPACE i '0', niti izmedju ':' i
'@', a source bi i dalje bio citljiv i s ekranom bi se u slucaju svih
znakova upravljalo s jednom te istom instrukcijom. Slijedeci razlog
zasto staviti offset cak i ako ima dovoljno memorije je zato da neko
kome se salje .hex ne bi samo tako mogo s hex editorom prije
programiranja mikrokontrolera promijeniti stringove. S obzirom da si
usput radim i library, gledam da mi podaci u source-u budu citljivi, da
se mogu lako promijeniti, i da mi se nakon pritiska na compile (bez
nekih medjufaza) generira .hex za u mikrokontroler.

Post by Zeljko Vrba
E i da,
5. Tvoji postovi odisu tonom tipa "Ja sam cool jer radim cuda u ASM-u,
znam Bresenhamov algoritam [itd], a vi koji koristite high-level
jezike samo slazete lego kockice i zapravo nemate pojma o tome kaj
je pravo programiranje."

To je bilo u vezi tvrdnji da je programirati u assembleru a peace of
cake. I dalje kazem isto - znam ljude koji znaju i vise programske
jezike i nekoliko assemblera ali im assembler ne lezi (nacin
razmisljanja koji je potreban za nesta isprogramirati u asm).

Programiranje u assembleru je nekad neophodno ne samo zbog performansi
ili ogranicenja memorije nego i zbog ogranicenja compilera, ovo je
dobar primjer:

http://tinyurl.com/cy28h3m

Post by Zeljko Vrba
E pa kad dodjes s takvim stavom onda ocekuj i odgovor kakav si dobio. Ja bih
ti sad mogao utrljati u nos brdo stvari koje sam ja isprogramirao u relativno
kratkom roku, a sve PUNO kompliciranije od jednog Bresenhamovog algoritma ili
zbrajanja vremena izvrsavanja instrukcija da postignes zeljeni efekt.

Gledam (Peek at my software projects), nije lose. Kad naletim na nesta
sta necu znati isprogramirati (a hocu), zamolicu te za pomoc. Sta se
tice kompliciranosti algoritama u assembleru, reko sam da su neki vrlo
jednostavni, dao sam primjer visekanalnog zvuka s ADSR envelopom na
1 bit output-u, medjutim u 15-20 godina je samo nekoliko programera
uspjelo na ogranicenom hardware-u te algoritme i isprogramirati.

Inace mislim da te se sjecam s faxa, vjerojatno bi se i ti po slici
sjetio mene.

Post by Zeljko Vrba
PS: bas me zanima po cemu sljedecem ces kenjati kad/ako otkrijes da ni
*assembleri* za AVR ne podrzavaju sve pseudo-opove na koje si navikao
na SLJBLAHasm-u.

Ako nisam otkrio do sad, necu nikad :-)) Ovo si napisao ko da sam tek
sad otkrio AVR - s AVR-ima se bavim vec dugo vremena a s PIC-evima ce
zacas biti 20 godina. Medjutim, s programiranjem se bavim jos 'malo'
duze - s assemblerima vec oko 30 godina a s visim programskim jezicima
jos od UCSD-a preko Turbo Pascala (gdje sam se na 5.5 i po prvi put
sreo s OOP-om) pa nadalje. Medjutim, programiranje mi je nekad alat a
nekad hobby. Vjerojatno imamo bar nekoliko zajednickih frendova koji bi
ti mogli reci vise o tome.

Post by Zeljko Vrba
PPS: I ja sam se davno malo bavio elektronikom, ali ne umisljam si zato da ja
znam nesto vrijedno spomena o elektronici i nikad mi nije palo na pamet zalit
se profesionalnim elektronicarima o... ne znam, recimo zakaj ne mogu kupit 74xx
IC sa 5 invertera jer mi tocno tolko treba pa ga bude jednostavnije zalemit na
plocicu -- a otprilike na tom nivou su tvoji postovi.

Uzmes neki Xilinx ili Lattice pa si slozis '74' kakav hoces :-)

[Goran Mitrovic]

Post by Chupo
Programiranje u assembleru je nekad neophodno ne samo zbog performansi
ili ogranicenja memorije nego i zbog ogranicenja compilera, ovo je
http://tinyurl.com/cy28h3m

Ovo nije specifican problem za embedded sustave, vec je itekako aktualan
npr i na x86. Svaki moderniji kompajler ima to vec nekako rijeseno (npr,
volatile na VS2005 i visim).

A to za performanse ti je dosta nategnuto danas kad mikrokontroleri rade
na stotinama MHz. Bas sam se nedavno bavio Blackfin procesorima i
optimizacijama algoritama na njima i jednostavno se ne isplati rucno
strikati asm. Osim sto bi takav kod bio neodrziv, kompajler obavlja vise
nego dobar posao. Jedino treba tu i tamo baciti pogled u ono sto generira,
pa ga malo lupiti po prstima ako slucajno ode u krivom smjeru.

[Zeljko Vrba]

Post by Chupo
Program u kojem sam trebao ABYTE s offset-om je kompletan u C-u, u
njemu nema potrebe za inline assembler-om. Radi se o tome da sklop

Ja nisam nigdje spomenuo inline assembler.

Post by Chupo
S druge strane, ako se radi o brojci a ne znaku onda byte na ekran
saljem s recimo
SCREEN_PORT = (pgm_read_byte(&(charTable[relay_num+offset_02])) |
dot_bit) ^ jumper_LED;
Ako definicije karaktera recimo pocinju od SPACE onda (za uppercase
stringove) offset_01 mora biti -32 a offset_02 +16. Drukcijom

OK, sad kuzim. I bas nemas mjesta za tih par if-ova za racunanje offseta? Ili
recimo probat komprimirati font? Npr. state machine gdje svaki bit ulaznog
znaka mijenja stanje? Numeriranje stanja bi se vjerojatno dalo zakodirati u
neki gray code tako da je prijelaz izmedju susjednih stanja +-15, sto fino
stane u jedan nybble itd itd...

Hm, vis, sad sam dobio ideju za progooglat i mozda implementirat ;)

Post by Chupo
znakova upravljalo s jednom te istom instrukcijom. Slijedeci razlog
zasto staviti offset cak i ako ima dovoljno memorije je zato da neko
kome se salje .hex ne bi samo tako mogo s hex editorom prije
programiranja mikrokontrolera promijeniti stringove. S obzirom da si

Security by obscurity. Zaboravi. Ako je nekome interesantno promijeniti
stringove, napravit ce to i sa ovakvom shemom.

Post by Chupo
Uzmes neki Xilinx ili Lattice pa si slozis '74' kakav hoces :-)

Mda, ne znam sto ce mi onda lemljenje i stampane plocice; sve strpam u
neki Xilinx na PCI kartici ;P

U labosu di sam prije bio smo imali masinu sa ugradjenim Xilinxom na maticnoj
(drugi CPU slot) i dev kit... Htio sam se malo igrati s time al, jeez, koja
tlaka je sve to upogoniti. Nikad nisam dosao dalje od pokretanja IDE-a..
Citao sam dokumentaciju i skuzio da bi mi trebalo bar tjedan dana da skuzim
kako uopce skompajlirati i uploadati sample projekt, a tada nisam imao
tolko vremena :-(

[Chupo]

ne samo u stringova

'u stringovima' sam htio napisati :-)

[Chupo]

Post by Zeljko Vrba
OK, sad kuzim. I bas nemas mjesta za tih par if-ova za racunanje offseta? Ili
recimo probat komprimirati font? Npr. state machine gdje svaki bit ulaznog
znaka mijenja stanje? Numeriranje stanja bi se vjerojatno dalo zakodirati u
neki gray code tako da je prijelaz izmedju susjednih stanja +-15, sto fino
stane u jedan nybble itd itd...
Hm, vis, sad sam dobio ideju za progooglat i mozda implementirat ;)

Covjece!!!! :-)))) Pa o tome cijelo vrijeme govorim!! :-))

Da li sad vidis? Nekoliko redundantnih recenica je uzrokovalo OT flame
war (da li je i ovo redundantan podatak - ako je flame, onda je
vjerojatno i OT? :-)) ) koji ti je, uz ne previse zivciranja, dao ideju
za napraviti nesta sta ce te, kad napravis, veseliti!! :-))

Post by Zeljko Vrba

Post by Chupo
znakova upravljalo s jednom te istom instrukcijom. Slijedeci razlog
zasto staviti offset cak i ako ima dovoljno memorije je zato da neko
kome se salje .hex ne bi samo tako mogo s hex editorom prije
programiranja mikrokontrolera promijeniti stringove. S obzirom da si

Security by obscurity. Zaboravi. Ako je nekome interesantno promijeniti
stringove, napravit ce to i sa ovakvom shemom.

Zato i kazem 'da ne bi mogo *tek tako* promijeniti stringove'. Naravno
da ce neko ko ce se bas zainatiti disassemblirati kompletan program i
napraviti izmjene, ne samo u stringova s porukama nego i dijelova
programa - u krajnjem slucaju cak i ako su sprzeni flash i EEPROM lock
fuse-ovi. Ali bas da program na kojem sam radio nocima isprucujem u
obliku u kojem ga moze promijeniti svaki klinac iz nizih razreda
osnovne koji zna otvoriti Notepad...

Post by Zeljko Vrba

Post by Chupo
Uzmes neki Xilinx ili Lattice pa si slozis '74' kakav hoces :-)

Mda, ne znam sto ce mi onda lemljenje i stampane plocice; sve strpam u
neki Xilinx na PCI kartici ;P
U labosu di sam prije bio smo imali masinu sa ugradjenim Xilinxom na maticnoj
(drugi CPU slot) i dev kit... Htio sam se malo igrati s time al, jeez, koja
tlaka je sve to upogoniti. Nikad nisam dosao dalje od pokretanja IDE-a..
Citao sam dokumentaciju i skuzio da bi mi trebalo bar tjedan dana da skuzim
kako uopce skompajlirati i uploadati sample projekt, a tada nisam imao
tolko vremena :-(

Ja se (jos) nisam bavio s CPLD-ovima, prije par godina sam se u sklopu
neceg sta sam onda planirao raditi poceo proucavati VHDL i Verilog, ali
su se desile neke stvari zbog kojih sam morao promijeniti sve tadasnje,
pa i preispitati planove za buducnost...

[Zeljko Vrba]

Post by Chupo
Covjece!!!! :-)))) Pa o tome cijelo vrijeme govorim!! :-))
Da li sad vidis? Nekoliko redundantnih recenica je uzrokovalo OT flame
war (da li je i ovo redundantan podatak - ako je flame, onda je
vjerojatno i OT? :-)) ) koji ti je, uz ne previse zivciranja, dao ideju
za napraviti nesta sta ce te, kad napravis, veseliti!! :-))

Tako je. Ta ideja je cool i nesto na sto vrijedi potrositi nesto slobodnog
vremena. Istovremeno i prilika za malo se poigrati C#-om :)

Post by Chupo
Ja se (jos) nisam bavio s CPLD-ovima, prije par godina sam se u sklopu
neceg sta sam onda planirao raditi poceo proucavati VHDL i Verilog, ali
su se desile neke stvari zbog kojih sam morao promijeniti sve tadasnje,
pa i preispitati planove za buducnost...

Sorry, nije bio Xilinx nego neko Alterino FPGA-cudoviste. Al anyway,
upogoniti to je tlaka.

[stylex]

Post by Chupo
Uzmes neki Xilinx ili Lattice pa si slozis '74' kakav hoces :-)

Mda... a zasto se ti onda sa Zilogom i AVRom zahebavas? :) Jeftileni sa 100k
gateova bi to odradili da boli glava. :) :) :) Doduse ja bih tu recimo
roknuo kakav Cortex-M3/M4 pa radio kao covjek. Jeftinija je razlika u cijeni
ocvrsja nego vrijeme potroseno na pi*darije.
E da, ocekujem jos malo o unrollanju loopova, FIR vs. IFR kod DCTa ili
waveleta i slicno. :)

[Goran Mitrovic]

Lijepo objasnjeno. Samo, cini mi se da je Goranov komentar bio u
smislu: 'Zasto mislis da nekoga ovdje zanima zbog cega taj atribut?'.

Nesto je news server stekao, pa tek sad dobio poruku..

Uglavnom, ne bas. Poanta je bila da je taj dio skroz suvisan za tvoj
problem i da se jednostavno mogao izbjeci, a sve to pak docarava kako tvoj
mozak funkcionira - nepotrebno komplicira. :P

[Chupo]

Post by Goran Mitrovic
Nesto je news server stekao, pa tek sad dobio poruku..
Uglavnom, ne bas. Poanta je bila da je taj dio skroz suvisan za tvoj
problem i da se jednostavno mogao izbjeci, a sve to pak docarava kako tvoj
mozak funkcionira - nepotrebno komplicira. :P

:-)

Desava se :-) Kasno je da ga sad mijenjam :-)