Koodi ja dissassemblerin käyttö

[PetriK]

Jos saan ehdottaa niin mieluummin motorola S-recordina voisi tehdä tuollaisen tarkistussumman. S-record on tiedostomuoto jota FDT lukee suoraan sisään ja mahdollistaa myös sen että kaikkia tietueita (0xFFFFFFFF) ei tarvitse kirjoittaa ja siten lataaminen nopeutuu.

Tietuerakenne on tosi helppo:
S509xxxxxxxxyyyyyyyytt
x=osoite
y=muistipaikan sisältö
tt=tarkistussumma (9xxxxxxxxyyyyyyyy)

Lopussa on sitten vielä erillinen tietue jossa on kirjoitettujen rivien määrä.

Tuo saadaan binääriksi mot2bin ohjelmalla ja päinvastoin bin2mot.



Edited By PetriK on 1196434853

[timo3]

laitappas esimerkkiä miten tarkistesumma lasketaan siihen.

Samahan on se on mihinkä heksaan sen tekee vaikka S-recordina.

Ei jaksa alkaa suoraan bin muotoon vääntämään.

[PetriK]

Tässäpä nämä pari funktiota vähän yksinkertaistettuna... eli s3 on tuo kukin osoite+arvo eri rivinä ja s5 on rivien lukumäärä. Jos softassa olisi ominaisuus että se tarkistaa kunkin rivin ja pyytää aloittamaan alusta virhetilanteessa esim lähettämällä z merkin niin voisi yrittää nostaa nopeutta com portissa. Nyt mulla on vain 19.2k. No eipä näitä kovin usein toivottavasti tarvitse ladata.


---------------------------------------

S3record(address, data)
{
text_write("S309");

// tämä kirjoittaa suoraan merkkeinä osoitteen xxxxxxxx
ptr_address=IntToHexStr(address);
text_write(ptr_address);

// tämä kirjoittaa suoraan merkkeinä arvon yyyyyyyy
ptr_data=IntToHexStr(data);
text_write(ptr_data);

// aloita tarkistussumman laskeminen ysistä
result=9;
// sitten lisää yksi byte kerrallaan osoite
for (counter=0;counter<4;counter++) {
// lisää kaksi viimeistä merkkiä byteistä toisiinsa
result= result + (data&0xFF);
// ja valmistaudu käsittelemään
// seuraavat kaksi merkkiä jonossa shiftaamalla jonoa
data>>=8;
}
// sitten lisää yksi byte kerrallaan arvo
for (counter=0;counter<4;counter++) {
// tässä sama kuin yllä mutta aitona c koodina
result+=(address&0xFF);
address>>=8;
}

// laske tarkistussumma
// huomioi vain viimeinen byte
result=result&0xFF;
// viimeisen byten negaatio (eli käännetty arvo, taitaa tulla muistaakseni myös *-1 laskukaavalla)
result=~result;

// ja kirjoita tarkistussumma
text_write(IntToHexByte(result));

counter=counter+1;
// uusi rivi
text_write("
");
}


Tässä S5 kirjoittamisessa ei taideta huolia kuin maksimissaan FFFF riviä (nyt mulla on max FFFFFFFF riviä tuossa omassa c koodissa), muutin funktiota tähän niin että nyt tuo rivimäärä on maksimissaan FFFF eli ei ole testattu.

S5record(unsigned int records)
{
// write the S5 recort to the com port
text_write("S503");
text_write(IntToHexStr(records));

// calculate and write the checksum
// aloita kolmosesta joka on bytejen määrä
result=3;
// lisääs kaikki byte toisiinsa eli zz+zz
for (counter=0;counter<2;counter++) {
result+=(records&0xFF);
records>>=8;
}
// huomoi kaksi viimeistä ja niistä negaatio
result&=0xFF;
result=~result;
text_write(IntToHexByte2(result));
text_write("
");
}

[PetriK]

Tätä erilaista interface kirjoa löytyy täältä:

http://www.activeboard.com/forum.s....tPage=1

Timo3, jos vaan sulle sopii niin mä laitan noihin merkinnän että by Timo3. Nyt olen vaan laittanut että "paikallinen hakkeri".

[timo3]

lähetäppäs mulle se busan tiedosto johon ei olis vielä laskettu noita osotetta ja tarkistus-summaa, niin testaan, että tulee oikeanlainen motorlan s hex tiedosto.

[PetriK]

Mä lähetän suoraan CPU:lta tuossa muodossa sarjaporttiin, eli ei ole dataa välimuodossa.

Mutta sen sijaan tässä linkki exceliin jolla itse testailin että tehty data on oikean muotoista:

http://macmadigan.no-ip.com/BusaECU/S-record/

ja tässä linkki internettiin sivulle jossa näkyy myös esimerkki.

http://www.monroeccc.edu/ckelly/easy68ksrecord.htm

Ainoastaan S3 tietue on pakollinen ja S5 tietue kannattaa laitta loppuun että näkee että kaikki tietueet tuli perille.

[timo3]

Täytyy vielä ajaa yks tarkistuluku ecu:sta lähetän sulle sit lukuohjelman joka tekee myös sen motorlan s - records mot tiedosto.


Miten tuo sun busan mot tiedosto hyppää tossa kohdin, vai mikä siinä on juonena.

S309000156A40003FFF405
S309000156A80003FFF500
S309000156AC0003FFF6FB
S309000156B00003FFF7F6____<<
S30900028000091100005A
S309000280040002899C49
S30900028008000289BE23
S3090002800C0000000068
S309000280100928000033
S30900028014000289D005

[PetriK]

Joo - en lähetä 0xFFFFFFFF ollenkaan koska nehän tehdään valmiiksi silloin kun Flash PROM alustetaan kirjoitusta varten.
Tuo nopeuttaa jonkin verran tiedonsiirtoa Flash:ltä PC:lle kun osa longwordeista voidaan ohittaa. Ainakin mun tapauksessa sarjaliikenne on hitaampaa kuin FLASH:n lukeminen.

...

Jos tulos kääntyy vielä MOT2BIN:llä niin sitten on kunnossa. Mä en (ainakaan vielä) saanut sitä viimeisen rivin tarkistussummaa menemään tuosta softasta lävitse mutta poistan sen editorilla ja näen että yhteenlaskettu rivien määrä täsmää. Lisäksi rivitason tarkistussummat täsmäävät nätisti ja lisäävät oleellisesti luottamusta datan oikeellisuuteen.

[timo3]

Kyllä mulla kääntyy se hex2mot:lla täytyy ajaa tosiaan vielä lapi tuo ecu:luku ja katsoa kun se on päättynyt onko se osannut tehdä sen heks tiedoston oikein.


Tein sen tarkistuksen laskun laskemalla

S3090000000000000400F2

tarkisteluku = FF - ((09+00+00+00+ 00+00+00+04+00) mod 100)

ja sihen loppuun

S5050000902545
tarkisteluku = FF - ((05+00+00+90+25) mod 100) (tuo 100 on heksaluku des 256)

Tolla systeemillä se ainakin käänty

Mulla menee reilu 2 tuntia tossa luku operaatiossa kääntämättömällä versiolla, keskustelunopeus pic ja PC välillä
38400, eli ei mikään lukuhirmu heh..

varmaan kun alkais tutkimaan mitkä käskyt vie aikaa ja alkais
muuttamaan sitä, saattais nopeutua, mutta kun tuo ainakin lukee kerta kerran jälkeen samanlailla ei taida olla vaivaa alkaa muuttelemaan.



Edited By timo3 on 1196461556