Luciferhoutjes nodig, dus heel in het kort. En geen enkele garantie op correctheid
Ik blijf nog wat onwennig met dat multiplex en bus gebeuren.
Tsja, pootjes waren duur. Dus men heeft wat afgekl**t in het verleden. Dit is nog lang niet het ergste
- PSEN: active low read strobe voor extern program memory, dus alleen voor het Flash ?
Nou ja, kort door de bocht: je hebt 16 address lijnen (na de latch). Daarmee kun je 64k adresseren. Nou wil je diezelfde address lijnen gebruiken voor 'ROM' ('program store') en XRAM. Dan moet je dus wel vertellen waar het betrekking op heeft. Dat doet de nPSEN.
ff een open deur waarvan ik botweg aangenomen heb dat Fred die kende (en waarschijnlijk is dat ook zo): een n (kleine letter) voor een signaal naam is een manier van noteren dat dat ding 'actief laag' is. Ofwel geïnverteerd, zo je wilt 'negated' (daar komt die n ook vandaan denk ik). Een nPSEN is dus net zoiets als een PSEN, maar dan nagated. Ofwel: het ding is laag als de 'program store enable' bedoeld wordt. Ofwel: laag als er in ROM (in jouw geval flash) gelezen wordt.
- ALE: bedient een externe latch voor de 8 LSB lijnen van port 0. Alleen de LSB bits gaan daar blijkbaar door.
Volgens de datasheet: Poort0 is AD0-AD7, (data en adres)
Poort2 is AD8-AD15 Dat zijn er toch 16 adresbussen ? Ze lijken ook tristate.
De databits gaan blijkbaar ook door poort0. Daarom kon ik geen aparte databus vinden.
Ik vrees dat ik je een beetje op het verkeerde been gezet heb. Het is lang geleden... Nu je dit zo schrijft... Het zou zomaar kunnen dat P0 de gemultiplexte data & addresbus is.
Ofwel: er staat een deel van het address op als er iets met ALE gebeurt. En anders is het de data bus. Dus als ik dit zo lees niet zoals ik eerst schreef (nl. 'hoge' en 'lage' bit op 1 poort...). Excuses. Bijna goed (en daarmee toch fout ).
Even voor de terminologie: een bus is een set signalen. De complete bus bevat dus address, data en control. De address bus is dus feitelijk het deel wat het address bevat. Na de latch dus eigenlijk 16 bits, A0 t/m A15 (en, met een beetje goede wil kun je er soms ook de nPSEN nog bij rekenen, maar laat dat maar ff zitten, in de context van dit verhaal niet relevant en maakt de boel voor nu alleen maar complexer.)
Is die latch dan voor de data en niet voor een adres ?
Neen. Op die port zet je een stuk address. Dan clock je dat in de latch. Daarmee bepaal je een deel van het address - en dat staat nu 'fixed' in de latch. De actie om dus een byte uit XRAM te lezen is dus: deel van address op P0, nALE pulsen, 2de deel address op P2, P0 in 'tri state' zetten, nRD laag, P0 lezen, nRD hoog. En dat gebeurt allemaal 'vanzelf' zonder dat de programmeur er wat mee te maken heeft. De volgorde is door mijzelf verzonnen - functioneel kun je ook prima eerst A8-A15 op P2 setten en dan pas P0 en nALE doen. Je zou ook nog het hele address op P0 en P2 kunnen zetten, dan nALE pulsen, P0 tri state maken en dan lezen. Geen idee hoe de hardware het precies doet - en feitelijk ook eigenlijk nooit relevant.
Het SRAM heeft 8 data en 8 adreslijnen.
Ik denk dat die meer address lines heeft. Anders kun je maar 256 bytes in dat ding kwijt. Immers, 28=256....
Als die latch kapot is, alleen voor data bedoeld is en alleen voor het SRAM werkt dan zou dat de fout verklaren. Of niet ? Adres komt wel aan maar data niet ?
Neen, die latch maakt deel uit van de adressering. Dus dan gaat er vele meer 'stuk' (in de zin van 'bits die omvallen').
Aan de andere kant, als de data van het flash ook door die latch gaat dan kan de latch niet fout zijn. Het defect moet iets zijn wat alleen maar door het SRAM wordt gebruikt. Dat kan lezen en schrijven zijn.
Bijna goed. De adressering voor de ROM (flash) gaat ook door die latch. Vandaar dat ik zeg: aangenomen dat de firmware in die flash zit en het ding loopt, dan moet er al best veel 'bus' zijn wat werkt.
Datasheet SRAM:
- Write: CE=L, CE2=H, OE=X, WE=L
- Read: CE=L, CE2=H, OE=L, WE=H
- 8 datalijnen en 8 adreslijnen
Het moet dus iets zijn wat deze lijnen bedient. De processor zelf of een of andere logic geval er tussen.
Je hebt meer dan 8 address veters. Ik gok op minimaal 16...
Dan is de WR lijn de enige die alleen voor SRAM wordt gebruikt. Het SRAM heeft CE en CE2, CE moet altijd laag zijn en CE2 altijd hoog. Behalve in standby. Mogelijk blijft hij in standby staan. Dat kan ik testen. Dat zou de boel verklaren en ik dat zou buiten de processor om kunnen gaan.
Ja, nou, niet helemaal. Een CE is een Chip Enable. Ze hebben om interfacing makkelijk te maken een CE en een nCE veter. Als jouw ontwerp positive logic gebruikt, dan gebruik je de ene (en knoop je de andere hard vast) en als je negative logic gebruikt dan gebruik je het andersom. Idee is dat de RAM daarmee universeel voor diverse bussen is.
Verder is er ook nog een samenspel met nPSEN en eventueel address mapping.
Laat je niet in de luren leggen door het woordje 'stand by'. Het betekent niet dat het ding 'uit' gaat ofzo. Het betekent alleen dat het chippie ff nergens op reageert, niks doet.
In het kort: op de address bus kun jij niet het verschil zien tussen een READ uit XRAM en een read uit ROM (flash). Het enige wat daar verschil in maakt is de nPSEN veter. Het is niet ongebruikelijk om die - al dan niet via wat logic - aan een CE te knopen.
Verder zou je met bijvoorbeeld (niet betrekking hebbend op jouw apparaat, maar generiek) 2 32k chippies kunnen hebben die samen 64k doen. Het trucje is dat A15 (bijvoorbeeld) aan de CE van de ene chip geknoopt wordt en aan de nCE van de andere: voor de 'onderste' 32k wordt de ene gebruikt, voor de 'bovenste' 32k de andere. De firmware merkt er niks van: het is gewoon 64k.
Kortom: met die CE lijnen kun je van alles aan adresserings trucen uithalen.
Vandaar mijn opmerking van enige tijd geleden: gebeurt er uberhaupt wat op de CE lijnen? Zo nee, dan zit er rottigheid in de logic ervoor (als die er al is hoor, zoals in het voorbeeld hierboven kun je het rechtstreeks uit de controller halen.
Blijven over OE en WR van het SRAM. Ik denk dat de processor RD lijn dan aan OE zit
Daar zou je zomaar wel eens gelijk in kunnen hebben
en de WR lijn aan WR van het SRAM. Daar hoeft niets tussen want er is maar SRAM IC. Maar er is wel de footprint voor een tweede dus er zou iets tussen kunnen zitten
Neen. Dat wordt opgelost met CE en nCE (of CE en CE2 bij jou). Het is erg ongebruikelijk om in nWR en nRD te knoeien met logic - maar er is ook geen wet die het verbeidt. Dat is aan de hardware ontwerper.
Als je gaat meten: het kan prima zo zijn als rew zegt of zoals ik al eerder geopperd heb: het ding kijk bij startup ff naar RAM en als dat niet aan de verwachting voldoet, dan zou het kunnen dat de software er helemaal niks meer mee doet. Als je dus met een lopend device niks ziet gebeuren, dan is dat nog geen garantie voor 'het is stuk'.
Aan de andere kant is het ook prima mogelijk dat er pas wat met RAM gaat gebeuren als dat nodig is. Daar is weinig van te zeggen zonder dat je de firmware kent.
In het kort: als je dus op zoek gaat naar 'leven' op die lijnen, dan moet je dat dus eigenlijk zowel bij een boot als bij een meting doen.
Bij een 'dump' van de RAM (het uitlezen via RS232 ofzo) is er gene garantie dat die ook gebruikt wordt. Het zou theoretisch zo kunnen zijn dat bij boot (om welke reden dan ook) bepaald is dat RAM niet gebruikt wordt, en dat was het dan.
Waarschijnlijk vind ik dat niet. Want dat zou impliceren dat het ding volledig op z'n interne RAM (je weet wel, die 256 bytes) zou werken. Wellicht kan dat, maar het is niet erg gebruikelijk...
Verder min of meer wat guidob ook beschrijft.
Overigens verwacht ik dat die latch wel werkt. Immers, het ding zou ROMless moeten zijn. Dan komt de firmware uit de flash. Deel van die adressering MOET door die latch veroorzaakt worden, en het zijn nog de 8 'lage' bits ook. Als daar ellende in zit, dan kan het bijna niet anders dan dat het struikelt - die software is vast wel groter dan 128 bytes...
Tenslotte is mijn inschatting dat de configuratie (zo je wilt kalibratie) parameters in flash staan. Zoals gezegd: als je de spullen ervoor hebt, is het lood om oud ijzer of je er alleen een paar parameters of de complete firmware met parameters opnieuw in frut.
Zou het wellicht zo kunnen zijn dat 'memory' een optie is die 'uit' staat? Ik ken die apparaten dus niet, maar Fred heeft er meer mee gespeeld en kan daar wellicht wat meer over zeggen. In dat geval hoeft er helemaal niks stuk te zijn zeg maar .
De reden dat ik denk dat de calibratie in flash staat, is dat - als ik het goed begrepen heb - Fred wel eens een backup batterij vervangen heeft en die 'deed het nog'. Ofwel: de RAM moet haast wel 'leeg' geweest zijn, en de calibratie data was er blijkbaar nog.
Dan nog ff een hint over die adressering: het hoeft helemaal niet zo te zijn dat wat na de latch A0 heet ook aan A0 van de RAM zit. De address lijnen kun je in willekeurige volgorde aan de RAM hangen. Immers, als je een bepaald address wilt lezen, dan zal het patroon op de address lijnen hetzelfde zijn als toen je 'm schreef. Zolagn dat uniek is, maakt het feitelijk niet uit hoe het in elkaar zit. Kortom: als het voor PCB-routering handiger uit komt om wat lijnen te husselen naar de RAM... waarom niet?
Voor de flash ligt dat iets anders. Die wordt meestal extern geprogrammeerd (maar dus weer niet in het voorbeeld hieronder ), en dan heeft het voordelen als dat 1-op-1 mapped. Het MOET niet. Je kunt prima een stukkie software bakken wat ook daar de boel aanpast aan de PCB routering en het aangepaste image de flash in frut. Maar het is geloof ik niet zo gebruikelijk.
[off topic]Om Fred ff helemaal gek te maken met trucen met memory : ik heb development voor een ASIC waar een (oa.) 8051 core in zit gedaan (met alle ellende die een ASIC met zich mee brengt in de zin van 'hardware bug' in de chip zelf). Daarom weet ik per ongeluk iets meer van die 8051. Maar goed... We hadden daar 64k ROM (EPROM in dit geval) en 128k RAM, waarvan natuurlijk 64k adresseerbaar. Daarnaast nog een stuk SPI flash. Het trucje van dit geheel was om zonder nog bij de EPROM te kunnen toch firmware updates te kunnen doen.
In het kort: als je het ding resette (zo je wilt aan zette), dan werd er gestart uit EPROM. Daarin zit een klein stukje firmware wat gaat bepalen of we gaan updaten of normaal gaan runnen. Als we normaal gaan runnen, dan wordt de inhoud van de SPI flash naar RAM gecopieerd - daarvoor was bijna 64k beschikbaar. Een klein stukje werd als XRAM gebruikt voor laten we het de bootloader noemen. De laatste hand vol bytes - 1 byte was beschikbaar voor een routine die uit de EPROM gecopieerd werd en die een memory mapped SR latch kon omzetten (die zat dus op die laatste ene byte). Op het moment dat dat gebeurde, werd de EPROM overbodig, de 64k RAM die nu RAM was gemapped op wat net EPROM was en de 64k RAM die niet gebruikt werd, werd nu opeens gemapped als RAM. Daarna wel een jump naar 0x0000 gedaan - het address wat de core normaal gesproken start na een hardware reset. Gevolg was dus dat een deel van de RAM nu als ROM gezien werd en een andere deel als XRAM. En dat alles door slim met nCE lijnen en 1 adres lijn van de RAM te spelen.
Het copietje van de laatste bytes van die routine van EPROM naar RAM was nodig omdat niet gespecificeerd is hoeveel pre-fetch die core deed. Een normale 8051 doet dat volgens mij helemaal niet, maar bij die ASIC implementatie bleek het nergens uit. Op deze manier maakte het allemaal niet uit: voor en na de 'swap' stond er hetzelfde.
Vanzelfsprekend was het wel ff een rondje 'compiler temmen' om ervoor te zorgen dat dat goed ging qua memory indeling.[/offtopic]