De 4053 test goed maar ik heb ze op voorraad dus uitwisselen is zo gebeurd. Als ik nu de tijd niet had en genoeg wist van digitaal foutzoeken had ik gewoon alle ICs kunnen omwisselen. Daar ben ik altijd wat huiverig voor bij oudere apparatuur ivm timing maar deze is uit 2009 en smd dus ik denk niet dat het hier speelt.
Je zou ff moeten kijken hoe hard dat ding loopt - Xtal. Dan ff in de datasheet kijken hoe veel cycles voor een instructie (let op: het is een 8051 kloon, geen originele... dus je moet het echt van deze weten). Dan heb je enig idee van wat er op de bus gebeurt. Immers... elke instructie is 1x fetch uit ROM en dus 1x wat op de bus doen. Daarmee heb je dus ook een idee over frequenties die je daar tegen komt. Als je propagatie tijden daar niet in de buurt komen, gaat het eigenlijk altijd wel goed. Tot er iemand met timing heeft lopen kl**ten waardoor dingen per ongeluk werken natuurlijk .
Het ding is volgens mij meer dan 20 jaar geproduceerd dus qua ongelukkig ontwerp en bugs zal het ook wel meevallen.
Ja... nou... het kan ook prima zijn dat men er gewoon niet tegen aan loopt (bugs) en een ongelukkig ontwerp z'n werk gewoon doet (dus we laten het zo). Ik mag je er geen details van verraden, maar ik heb ooit eens een audit gedaan van een apparaat wat toen elke Nederlander wel kende. Het was al 10 jaar in gebruik en deze l*l vindt er toch 2 bugs in. Minor weliswaar, stonden het normaal functioneren nauwelijks in de weg. Maar het was net niet helemaal goed... Je kent het gezegde: als architecten huizen zouden bouwen zoals programmeurs software maken, dan kan een enkele specht een hele stad verwoesten.
Ook programmeurs hebben vaak erg veel last van functioneel denken - 'het doet het toch'? Ja, die Chinese LED rechtstreeks op een CR2032 doet het ook... Je snapt waar ik heen wil (been there, done is, bought the t-shirt en in de loop der jaren heel veel bijgeleerd!)
Hoewel "upgrades" niet altijd een verbetering zijn. Je ziet hier ook wazige dingen. Ik heb er een met een niet verlichte display gezien. De display was wel uitgerust met backlight maar dat was niet aangesloten. Het driver circuit was er wel maar niet bestukt.
Prototype? Het moest ff goedkoper? Zeg het maar...
Ik zal eens kijken wat ze met A16 doen. Bankswitching zou niet onlogisch zijn. Ze hebben bij het ontwerp blijkbaar rekening gehouden met 2 sram ic's. (misschien was dat eerst voor 2x64 bedoeld) Maar zelfs dan meer dan 64k, dus altijd bankswitching.
Ja, nou... zoals gezegd: ik verwacht het niet, maar het zou kunnen dat het ding gewoon 64k nodig heeft. Punt. Vroeger opgebouwd uit 2x32 (dat was toen financieel de beste oplossing), later wellicht 1x 64 en toen deze gemaakt werd was 1x 128 goedkoper 0- en die doet het tenslotte ook. Memory is raar spul met dagprijzen. Op een PCBtje van een oud-werkgever ook rare trucen met footprints over elkaar heen. Reden? Meer keus aan RAM chippies, pak diegene die deze week de goedkoopste is...
Staar je ook niet blind op A16. Er is een address lijn die 'ergens anders' heen gaat. Zoals gezegd: je kunt die lijnen at random aansluiten. Dus als het bij routeren anders beter uit kwam, nou ja, dan doen we het zo. Zolang elk address maar uniek is, gaat dat volkomen goed komen.
En dan zou het best kunnen dat in dat pad een foutje zit.Het moet in ieder geval iets zijn wat de hele functie de mist in laat gaan want anders was het corrupte data geweest en niet geen data. En als ze iets met een checksom doen verwacht ik een andere foutmelding dan geen data (maar wie weet, de programmeur beslist dat)
Ja en nee. Ik weet niet hoe hun interne 'boekhouding' in elkaar zit. Het is mogelijk dat in de eerste 2 bytes van het daarvoor bedoelde stuk memory botweg het aantal records staat. Als daar wat fout gaat en er komt toevallig '0x0000' of '0xffff' terug, dan zou het zomaar kunnen dat de firmware dan zegt 'niet zinnig, we doen niks'. Zeker bij embedded is het moeilijk om exception handling 'naar buiten' te doen. Het is niet ongebruikelijk dat als je bij een 'dump' functie parameter checking doet (kijken of je input parameters überhaupt zinnig zijn ipv. er blind mee aan de gang te gaan), je gewoon besluit 'niks' te doen als ze dat niet zijn. Wellicht in debugging mode (al dan niet een vlag bij compilen) nog ergens een error heen brullen, maar in productie... tsja... wat zou je willen doen??
Er kunnen best foutjes in het schematje staan. Het is 4 layer board daarnaast is een vergissing bij tekenen en het daarna weer duidelijk/leesbaar opnieuw tekenen ook zo gemaakt.
Sterker nog... het zou me verbazen als het helemaal zou kloppen . Maar aangezien jij blijkbaar ook aan het documenteren bent, trigger ik ook even op inconsistenties tussen je verhaal en je plaatje. Aan jou om er iets of niets mee te doen...
Ik heb net een 40pin boxconnector van 20 dunne teflon draadjes voorzien. Daar kan ik zo de LA inprikken zonder gedoe met losschietende klemmetjes.
Een userfout verwacht ik niet. De unit heeft altijd gewerkt en de eigenaar heeft veel ervaring met deze units. Ik heb zelf nog nooit iets in de setup hoeven wijzigen en ben daar ook niet geweest. Ik zal eens kijken wat de klok-tijd doet. Zou de boel werken zonder de klok ?
Daar kan alleen de programmeur iets zinnigs over zeggen.
[off topic][ouwe doos]Ik ben met een 8051 eens vreselijk op n'm snufferd gegaan met parameter checking. Ik ben daar vrij scherp op, dus als je een pointer krijgt, dan check ik die wel even op null zijn. Null heeft doorgaans als waarde 0x0000 op een 16-bit address.
Goed, een stuk code, liep prima. Is al enige tijd in gebruik en min of meer 'af'. Ergens heel anders in dat project aan het knoeien en het stuk code wat al 'af' is doet het opeens niet meer. Snap er geen snars van. Ik ben er toch niet aan geweest? Hmz... nieuwe stuk code er ff uit... ja, loopt weer. Nieuwe stuk code er weer in... werkt niet meer.
Afijn, eerste idee is dat die nieuwe code ergens een misser maakt en wat plat schrijft (over data heen schrijft waar-ie vanaf moet blijven). Nee, dat deed het echt niet.
Nou ja, lang verhaal kort: het bleek dat het stuk memory waar die pointer naar wees... op 0x0000 zat. Dat kan gewoon bij een 8051. Je kunt aan de linker opgeven waar memory zit - welke addressen (je hoeft niet de volle 64k vol te hebben en je hoeft ook niet op 0 te beginnen, niemand die je dat verplicht). En daar braaf op 0x0001 begonnen. Tot er iemand bezig is geweest om make files op te schonen... ergens gelezen heeft dat de default 0x0000 is. Nou, daar hebben we memory, dus dit kan weg.
Zonder de 'nieuwe' code maakte de linker een memory map waarbij het 'goed' ging. Met die 'nieuwe' code ging het 'fout'.
Make file 'Bijna goed'. En toch een dag naar gezocht...[/ouwe doos][/off topic]