wat voor pascal variant kan dat geweest zijn? Ik ben dat bij pascal nog niet tegen gekomen.
Dit topic is gesloten
wat voor pascal variant kan dat geweest zijn? Ik ben dat bij pascal nog niet tegen gekomen.
Vandaag een mooie paralelle 10 bits gray code rotary encoder van Marktplaats aan de praat gemaakt.
Pinout van de connector klopte niet met de datasheet, kleurtjes wel, na wat puzzelen In Arduino (Chinese pro micro / Leonardo) zou alles goed moeten zijn maar toch een puinhoop-volgorde er uit. Bits werkten allen, verwisselen maakte het niet beter en op het oog zag de output er "niet zo fout" uit. mm.
Bleek dat ik de negatieve logica over het hoofd had gezien:
En dat gaat met gray code heel anders mis als binair. Bitjes geïnverteerd en alles klopt weer
Golden Member
Op 16 oktober 2019 19:02:47 schreef maartenbakker:
En DOS op 1/1/1980.
Is (was?) 1/5/1980 (herinner ik me nog goed)...
Hoe recentere/actuele BIOS'en (laptops/desktops/servers) reageren qua datum bij een 'platte' CMOS-batterij heb ik nooit gecontroleerd.
De lithiumbatterij op de meeste moederborden is goed voor zo'n 10 jaar levensduur bij normaal gebruik.
Maanden/jarenlang niet-gebruik van de computer (zonder netspanningsaansluiting) ontlaadt de batterij het meest, continu aangesloten op netspanning wordt tevens het CMOS-geheugen gevoed door de netvoeding (+5V standby spanning).
Ik heb trouwens nog nooit een systeem langer gehad dan een 4-5 jaar (op het werk nog een aantal oude werkende computers rond de 10 jaar), ik heb dus al 20+ jaren geen datum meer verloren zien gaan ("CMOS checksum Error" ).
heb onlangs nog een pc in huis gehad die de ene dag niet meer goed doorstartte, moest in bios iets opnieuw instellen eerst, daags erop was ie alle instellingen kwijt, bios batterij dus. ook een laptop gekregen van iemand, die deed toch niks meer. was dus ook alleen de bios batterij ding was verder nog prima.
bij een pinautomaat ook gehad, die deed het prima, tot ie snachts updates kreeg, erna herstarten en dan hing ie steeds. batterij aan de oude gesoldeerd en daarna de oude eraf geknipt. toen kreeg ie dus ook updates binnen zonder vastlopen. klok en instellingen moesten goed gezet worden, en zo'n pinboer rekent gewoon 350€ voor een nieuwe terminal..
Golden Member
Op 28 november 2019 18:38:25 schreef Turbokeu:
[...]Is (was?) 1/5/1980 (herinner ik me nog goed)...
ik heb dus al 20+ jaren geen datum meer verloren zien gaan ("CMOS checksum Error" ).
Ook geen last van de millenium bug gehad?
[Bericht gewijzigd door RAAF12 op donderdag 28 november 2019 19:44:38 (39%)
Golden Member
Eind 1999 heb ik op mijn toenmalig werk een volledige inventaris gemaakt (met behulp van een utility) van de computers die niet 2K-compatibel waren.
Die zijn vòòr 2000 uit de circulatie gehaald.
Op 28 november 2019 19:19:32 schreef RAAF12:
[...]Ook geen last van de millenium bug gehad?
Ik had destijds nog een XT computer, die niet verder ging dan 1999 ofzo. Een simpel programmaatje heeft de jaren daarop de PC normaal laten functioneren. Volgens mij heette dat progje Y2K.exe ofzo.
Iedereen was in paniek wat er zou gebeuren, terwijl je heel simpel de datum had kunnen wijzigen naar de laatste dag en uur van het jaar 1999 en even later wist je dan of eventueel alles fout liep.........
Maar sukkels die niet snappen hoe eea werkt, zijn bang dat de boel permanent beschadigd kan raken van zo'n test. En dan test je zoiets minder makkelijk.
Voor dweil z'n raw->sigrok conversie programma aan het schrijven. Ik hou in gedachten wat doel-systeem is van waar ik mee bezig ben. Op een atmel atmega328 zoals gisteren voor m.bouwer z'n ESC, dan ben je voorzichtig met geheugen en stack-gebruik enz.
Maar nu voor dweil z'n conversie programma: target machine is een apparaat wat minstens 8G aan RAM heeft, dus 0.1% daarvan op de stack moet geen probleem zijn.
Wel dus. Je krijgt bij "mkdir" een segmentation fault als je 10Mbyte aan stack variabelen definieert. Zucht. Heeft wat tijd gekost om dat te vinden, omdat het sterk aan de mkdir call lijkt te liggen....
Op 28 november 2019 20:53:40 schreef buzzy:
Iedereen was in paniek wat er zou gebeuren, terwijl je heel simpel de datum had kunnen wijzigen naar de laatste dag en uur van het jaar 1999 en even later wist je dan of eventueel alles fout liep.........
ja, voor u wel makkelijk te testen. maar stel nu eens dat je een groot bedrijf bent, met een serverpark die allemaal op UTC tijd loopt.
en bij de berekening van de lonen op het einde van de maand (dat kan je pas doen de 1e van de maand erna omdat je dan pas weet wie de 31ste nog gewerkt heeft of niet) moet je rekening houden met ancienniteit, familiale situatie,....
en stel dan eens dat op 1jan 2000 één van die pc's denk dat het 1985 is.
jij bent beginnen werken in 1990, dus ancienniteit -5 (daar gaat het boekhoudprogramma al over de nek), je kinderen zijn geboren in 1996 en 1998, ineens heb je er geeneen meer op de loonbrief.
je bent getrouwd in 1991, dus volgens die pc ben je nog niet getrouwd...
die mensen kunnen ook zomaar niet alle servers van datum veranderen voor een testje. daar hangen grote databases aan.
ik werk in de luchtvaartsector, en daar gaat verschillende systemen in de soep als er maar 1 pc een paar seconden afwijkt (radardata, database van vluchtplannen, ...). dan krijg je helicopters die op de pc nog in de lucht hangen, maar in realiteit al geland zijn, dus kunnen geen andere vliegers overvliegen.
op mijn thuis pc boeit het niet of die nu op 2019 of 1989 staat, enkel mijn mailbox zal wat verkeerd gaan sorteren.
je moet je pc maar eens een jaar fout zetten, en proberen te surfen. krijg je al fouten vollop, k geloof zelf dat chrome weigert te starten
Op 8 december 2019 13:52:23 schreef rew:
Wel dus. Je krijgt bij "mkdir" een segmentation fault als je 10Mbyte aan stack variabelen definieert. Zucht. Heeft wat tijd gekost om dat te vinden, omdat het sterk aan de mkdir call lijkt te liggen....
Als ik me goed herinner zet de linker in de exe hoeveeel stack je programma nodig heeft. Ik heb even geexperimenteerd met een simpel recursief programmatje (cygwin-gcc op win7) en dat crasht als je zo'n 2MByte aan stack gebruikt.
(effe google-en) Dat klopt! met
code:
gcc -Wl,--stack,16777216 -o file.exe file.c
Krijg je 16M stack
@fcapri: je zou ook wel een volslagen idioot zijn als je zulke dingen gaat testen op operationele kritische systemen, daar heb je development en staging servers voor. Je gaat toch ook geen nieuwe software ongetest op zo'n server zetten, en hopen dat alles werkt?!?
In mijn beleving is dit weinig anders dan een release-candidate testen.
Wellicht kunnen we hieruit concluderen dat er veel bedrijven zijn die dus geen fatsoenlijke testomgevingen hebben, en "op hoop van zegen" maar nieuwe software naar productie doorzetten.
er zijn altijd dingen die je niet kan simuleren. uitbetaling van een loonprogramma bv.
in de luchtvaartsector zal je ooit wel eens moeten installeren op kritische systemen. wij hebben een volledige duplicate testomgeving, op identiek dezelfde hardware draaien. en we hebben ook al gehad dat een update daar perfect op draaide, en op het live systeem crashte.
nuja, 45min laten draaien we weer op de vorige versie.
1x stond ik er alleen voor, terwijl ik een kritische update lanceer, valt de electriciteit uit. doordat we in een updatefase zaten (geen vliegtuigen in de lucht), waren er ook andere testen aan de gang. oa ook het UPS systeem.
beetje jammer dat de electra uitvalt net op de moment dat de ups ook in test stond. alle servers uit. t heeft een hele dag geduurd om het 'oude' systeem weer aan de praat te krijgen, de update werd dan 3maand uitgesteld.
we hebben ook een nieuw radiosysteem gekregen, werkte in test perfect, we breken de oude radiozenders af, en zetten de nieuwe zenders in de plaats (IP based). blijkt er toch ergens een bug in te zitten. teruggaan naar het oude was onmogelijk
Eigenlijk is het raar dat het zo moeilijk is om een dergelijk systeem na een "vieze" shutdown weer aan de gang te krijgen; ik heb dat ook meegemaakt met database servers, die daar op papier tegen bestand zouden moeten zijn.
Je zou toch denken dat we dat inmiddels opgelost zouden hebben, met journaling filesystems, live replication, etc.
Tegelijk is het vreemd dat je een dergelijke update alleen staat te doen; je zou denken dat het risico op stomme foutjes groot genoeg is om een extra paar ogen mee te laten kijken.
Op 8 december 2019 20:54:18 schreef SparkyGSX:
Tegelijk is het vreemd dat je een dergelijke update alleen staat te doen; je zou denken dat het risico op stomme foutjes groot genoeg is om een extra paar ogen mee te laten kijken.
Zelfs dat is geen garantie dat het goed gaat.
In Tsjernobyl waren er genoeg oogjes die meekeken hoe het fout ging. En het was nota bene tijdens een test.
Die werd doorgedrukt door een omhooggevallen politiek kneusje zonder enig verstand van kernreactors terwijl alle operators zeiden dat het een slecht idee was. Het probleem was niet het aantal ogen, het probleem was één hersenloze blaaskaak, in combinatie met een heel slecht ontworpen reactor (o.a. een grote positieve void coefficient).
Alsnog is een paar extra ogen meestal een goed idee bij zulke operaties.
[Bericht gewijzigd door SparkyGSX op zondag 8 december 2019 22:10:24 (10%)
Op 8 december 2019 14:56:08 schreef blurp:
code:
gcc -Wl,--stack,16777216 -o file.exe file.c
Krijg je 16M stack
Met -Wl,--stack,16777216 krijg ik: /usr/bin/ld: unrecognized option '--stack'
Ik denk dat ik Linux gebruik en zoiets hier door het OS geregeld wordt. Ik kan geloof ik de stacksize met "limit" instellen. Compiler is best wel slim. Als ik een functie aanroep die test[0] en test[100] refereert, NA mijn main gedefinieerd is, maar daarna alleen test[SIZE-1] refereert dan wordt de call weggeoptimaliseerd. Met -O0 blijft de call staan en crasht de boel met 0x800000 als de variabele grootte, maar niet bij 0x7f0000.
@rew: Klopt, linux is slimmer met stack, en kan de stack laten groeien als een programma dat nodig heeft. (lees: Een programma krijgt een hele berg (virtuele) stack toegewezen, en pas als dat daarwerkelijk gebruikt wordt wordt er ook geheugen voor gecommit.)
Die stack optie werkt denk ik alleen op windows (al ondersteunt de GNU linker zoveel platformen dat ik daar geen definitieve uitspraak over ga doen).
Maar in plaats van met ulimit te gaan klooien kun je je variabelen ook globaal maken, dan loop je ook niet uit je stack.
Zodra je weet wat het probleem is kan je het op diverse manieren oplossen. Ik heb de variabelen van een array tot pointer gemaakt en aan het begin van main een malloc gezet. Iets eleganter vind ik dan globaal of static (binnen main).
code:
#define MAXSIZE (9*1024*1024)
char test2[MAXSIZE];
static char test3[MAXSIZE];
...
int main (int argc, char **argv)
{
static char test4[MAXSIZE];
char test0[MAXSIZE];
char *test1;
test1 = malloc (MAXSIZE);
...
test0 werkte niet, ik heb voor test1 gekozen, test2 t/m test4 zou ook werken.
Special Member
Rook een beetje een brandluchtje.
Na openen kastje trof ik dit aan
Dan maar even thermografie gedaan:
duurde ook even voor ik deze doorhad....
Wie ziet hem ook??
Hij is eignelijk redelijk obvious
en ja voor de piepers: thermografie is van een ander kastje: maar deze was ook 89 graden... Verschil nihil: de ene hangt links de andere rechts met een fan erachter.
[Bericht gewijzigd door High met Henk op donderdag 19 december 2019 15:52:11 (26%)
Golden Member
Er hadden wel eens deksels op die goten gemogen
Ik zie het probleem niet zo, of het moet een missende draad zijn aan de onderkant van de th.beveiliging..
Special Member
Door die missende draad doet het thermisch relay niets!!!!
Das dus de fail..
Gaat er geen zwarte naar 2-T1 ?
Special Member
het is een 1 fase motortje, waarbij de fase doorgelust wordt
Dit topic is gesloten