Via LPT AT24C64 EEprom uitlezen, USB-LPT of PCI-e LPT kaart ?

Op 12 februari 2017 11:44:34 schreef Arco:
Dat is dramatisch slecht; bijna een kwartier om zo'n mini-geheugentje uit te lezen...

Aan de delay_time zal het niet liggen:

int delay_time=0.5;

;-)

8000 bytes in 800 seconden is ongeveer 10 bytes per seconde.

Met binaire output, heb je zo'n 10 bytes nodig op de ascii link, voor iedere byte uit het geheugen. Met 9600 baud kan je ongeveer 1000 bytes per seconde sturen. Hmmmm.... Dan mist er inderdaad nog een factor tien aan performance.

Over i2c een geheugen uitlezen, dan gebruik je de "block read" mode. Je stuurt maar zelden een adres, en leest dan vele bytes achtereen uit.

Dan duurt 1 byte met ack ongeveer 0.1 ms.

Je hoeft het adres maar 1x in te stellen, daarna kun je de hele chip uitlezen. Op 400kHz zelfs nog sneller als 0.1mS. 8kB moet binnen een seconde wel lukken.
Mijn programmer is een Galep 4.

Ik ken niet ALLE datasheets uit m'n hoofd, maar bij mijn weten zou het kunnen dat sommige eeprom chips niet van "page" naar "page" overschakelen als je blijft lezen. Dus dat als je op adres 0x150 begint, je dan na 0xaf waardes na locatie 0x1ff de waarde van 0x100 krijgt en niet 0x200. Maar het zou best kunnen dat DIE chips uitgestorven zijn. Vandaar dat ik de mogelijkheid open hield om "zo nu en dan" een nieuw adres te moeten sturen. Dat zou ongeveer 1% van de performance kunnen schelen.

edit: Datasheet van de at24c64 bekeken. Die doet dit binnen-page-rollover alleen bij writes. (en een page is 0x20 bytes, dus die zou je op 0x15f-> 0x140 al tegen komen).

[Bericht gewijzigd door rew op (15%)]

Uit de atmel datasheet:

"As long as the EEPROM receives an acknowledge, it will continue to increment the data word address and serially clock out sequential data words.
When the memory address limit is reached, the data word address will “roll over” and the sequential read will continue."

Ja, dat zeg ik. Het huidige exemplaar kan je sequentieel helemaal uitlezen. Maar het princiepe van: "alleen de onderste X bits incrementeren, er is geen carry naar de hogere Y bits" bestaat wel. Een voorbeeld heb je in DEZE chip bij het schrijven. Zoals ik al zei, ken ik niet ALLE datasheets uit m'n hoofd, maar als ik zo'n seriele eeprom moet uitlezen weet ik genoeg dat ik het datasheet van het exemplaar waar ik mee bezig ben er bij zal pakken om zeker te weten dat DAT exemplaar niet toch wel zo'n onderbroken carry chain heeft.

Die page rollover is inderdaad iets wat kan verschillen, ook bij reads. Vaak komt die overeen met de interne row size van de eeprom cellen, bijvoorbeeld 16 of 32 bytes. Dus het is altijd oppassen.

Een los byte kun je intern namelijk niet schrijven, dat lijkt aan de buitenkant wel zo maar intern wordt een hele row gelezen, update gedaan en de hele row(aka page) weer terug geschreven.
Wil je een eeprom efficient updaten met meerdere bytes is het altijd verstandig alle bytes binnen een page gelijktijdig weg te schrijven. Dat geeft de minste wearout en duurt net zolang als EEN losse byte write op die pagina.
Misschien dat de technology wat veranderd is dat het nu niet meer zo is, maar bij de oudere generaties was dat wel zo.

Als het verandert is dan is het DOORGETROKKEN in de richting die je aangeeft. Grotere pages en zo.

Op 12 februari 2017 11:36:59 schreef henri62:
P.S. Hoe ben je aan dat password tooltje gekomen? Vaak zit in dat soort spul een virus en ben ik er huiverig voor om dat zomaar ergens vandaan te plukken.

Dat soort dingen draai ik om die reden altijd in Sandboxie.