inhoud ext. RAM zichtbaar maken.

het programma van arco voldoet eigenlijk niet voldoende.

Wat voldoet er niet? (het doet wat je destijds gevraagd hebt)

die puntcomma, is dat een ascii code ?

Ja, alle tekens op je toetsenbord (behalve de functietoetsen) hebben een ascii code...

puntcomma is ";"

oftewel ascii 59 (decimaal)
http://www.asciitable.com/

Op 24 februari 2021 19:22:52 schreef Arco:
[...]
Wat voldoet er niet? (het doet wat je destijds gevraagd hebt)

ik zie de "1"-en en "0"-en wel, alleen niet in op de volgorde zoals ze in werkelijkheid zitten, maar dat is nog niet zo erg. meest vervelende is dat ik niet (direkt) kan zien wat welke byte is. ik denk dat dat in excel beter te realiseren is.

Op 24 februari 2021 19:22:52 schreef Arco:
Ja, alle tekens op je toetsenbord (behalve de functietoetsen) hebben een ascii code...

enter ook ? kan hem niet vinden.

CR=13 en LF=10

had ik zien staan, maar dat is toch geen enter ?

<Enter> , als in ASCII 13, word vertaald met "Wagenterugloop" en komt nog uit het Telex tijdperk. Maar dit stuurt je cursor (wagen) naar kolom 1 (helemaal links). Maar dan sta je nog steeds op de zelfde regel. Bij een printer of typemachine/telex zou je dan alles op één regel over elkaar typen/printen.
Vandaar dat de LF er achteraan komt om het "papier" (de rol) 1 regel omhoog te schuiven zodat je op een blanco regel uitkomt.
De noodzaak van een LF achter een CR is in de loop der jaren wel wat vervaagd.
13 - 10 zijn decimale waarden, 0x0D en 0x0A in HEX

ok, je moet ze beide doen.

Carriage Return en Line Feed.
Dit staat nog steeds symbolisch op de "enter" toets... omlaag en terug naar het begin.

Zonder line feed begin je vrolijk over de zelfde regel te schrijven.

[Bericht gewijzigd door Sine op (31%)]

De noodzaak van een LF achter een CR is in de loop der jaren wel wat vervaagd.

Inderdaad. Reeds vele decennia gebruikt de Unixwereld enkel een 0x0a. Er is geen enkele reden om die extra byte 0x0d te verkwisten.

13 - 10 zijn decimale waarden, 0x0A en 0x0A in HEX

Maak daar maar van "0x0d en 0x0a".

Op 24 februari 2021 20:45:56 schreef trix:
ok, je moet ze beide doen.

Bij de meeste programma's kun je tegenwoordig opgeven of de data is afgesloten met een CrLf, of alleen met een Cr...
Bij een in te lezen CSV file kun je ook van alles instellen wat betreft delimiters, formatting, en end-of-line...

[Bericht gewijzigd door Arco op (19%)]

dat probeer ik nu ook te ontdekken, hoe je zo'n CSV file maakt.

Maak daar maar van "0x0d en 0x0a".

Staat er toch ? :+

Er is geen enkele reden om die extra byte 0x0d te verkwisten.

En dan toch programmeren als '\n' :+

Je stuurt alle waardes als ascii, gescheiden door een "," of ";", en afgesloten door een "Enter" (Cr)...

Op 24 februari 2021 22:14:29 schreef Arco:
Je stuurt alle waardes als ascii,

stel ik heb een byte: 0b11100000 (224)
verstuur ik die dan als:
32 32 34 (hex)

als ik een matrix heb van 300x300, stuur ik dan die enter na iedere regel (van 300 stuks) of helemaal aan het eind (dus 1x).

Stuur 300 regels.

Elke regel bevat 300 velden.

Achter elk veld (behalve het laatste van elke regel) een veldscheider ofte "field separator"; dat is typisch een komma, maar kan ook een tabulatie zijn of een : of wat dan ook, als het maar iets is dat zeker niet in de data kan voorkomen.

Beëindig elke regel met een regelafsluiter; zoals gezegd kan dit in Unix-achtige omgevingen een enkele 0x0a oftewel linefeed zijn, maar om het universeel te houden kan ook 0x0d 0x0a = carriage return + linefeed = CRLF.

[nakomertje] vermits de te verzenden data binair zijn, en elke waarde kunnen hebben tussen 0x00 en 0xff (als ik dat goed begrijp) is het opletten geblazen om geen enkel veld gelijk te maken aan de veldseparator, wat die dan ook weze. Dus dat idee van 32 32 34 is nog niet zo gek niet; maar vooral moet men iets maken dat enerzijds foutloos werkt en blijft werken, en anderszijds vlotjes kan verwerkt worden door de ontvangende partij.

[Bericht gewijzigd door big_fat_mama op (30%)]

nou ja idee, 32 32 34 :)
ik zie gewoon geen andere opties.

Zo moet het ook. 0x32, 0x32, 0x34 is gewoon de ascii representatie van 224 decimaal.

Of het zo "moet" is misschien teveel gezegd, er zullen vast meer opties zijn. Zoals ik reeds stelde hangt het er ook van af wie of wat die csv gaat interpreteren. Maar het is zeker werkbaar, ja, dat wel.

Toch even nadenken: hoe gaat men 0b00000011 weergeven? Als 0x03? of als 0x00 0x00 0x03 ?

als 0x00 0x00 0x03 denk ik.

maar je schreef:

Op 25 februari 2021 19:16:47 schreef big_fat_mama:
[nakomertje] vermits de te verzenden data binair zijn, en elke waarde kunnen hebben tussen 0x00 en 0xff (als ik dat goed begrijp) is het opletten geblazen om geen enkel veld gelijk te maken aan de veldseparator, wat die dan ook weze. Dus dat idee van 32 32 34 is nog niet zo gek niet;

de waarde kan inderdaad alles tussen 0x00 & 0xFF zijn.
de ascii code van zo'n veld seperator (b.v. ; (59)) kan dus ook voorkomen, en dat wil ik dus niet.
waarom is dan 32 32 34 een goed idee ?

even voor de volledigheid, ik wil de data uit eindelijk in excel laten zien.
en naar ik begepen heb kan dat via putty.

waarom is dan 32 32 34 een goed idee ?

Omdat je dat een duidelijk onderscheid hebt tussen data en separator. (data is dan altijd '0', '1',...tm '9')

die vat ik even niet :?

'32' = '2'(ascii), '34' = '4'(ascii)
Als je separators gebruikt, moet dat nu eenmaal een waarde zijn die nooit in de data kan voorkomen.

[Bericht gewijzigd door Arco op (58%)]

ah...kijk zo dus, even laten bezinken tnx.

ik had het al vermeld maar, de data hoeft maar 1 keer verzonden te worden, en dus niet continu (real time).

nu nog bedenken hoe ik van een byte naar de ascii ga :).

maar stel dat is gelukt, dan heb ik dus een CSV file, die gaat naar de PC en word ontvangen door putty. wie/wat gaat er dan voor zorgen dat dit weer een byte word waarvan ik per bit de status kan laten zien, putty of excel ?