Domme Batterijen - Accupologie

Door Infant op woensdag 19 december 2012 22:17 - Reacties (16)
Categorie: Gemod / Gefix, Views: 3.095

In mijn vorige post heb ik een accu open gepeuterd, en hem aan mijn notebook gehangen.
Tot mijn grote verbazing laad mijn notebook, die normaal alleen met 3-cells accu's om kan gaan, ook doodleuk accu's uit andere modellen notebooks.

Ik heb een 2730p, en de accu's die hij vrolijk oplaad komen uit een nx7400, een 8510W, een 6715b , 6730s.... de lijst telt op het moment zo'n 60 regels.

Ik heb een beetje uitgelegd wat er zoal in zit, en een klein beetje bekeken waarom alle accu's die ik heb, van mening zijn dat ze stuk zijn.

In deze post ga ik wat verder: Ik ga uit leggen hoe ze met de PC communiceren, en ga ik er eentje snuiven.... ?

Hier volgt een waarschuwing: Het wordt een lang verhaal. Er gaat code zijn, maar gelukkig ook plaatjes. De samenvatting niet staat aan het eind, want het hele artikel is al de samenvatting.

Waarom? Omdat accu's geweldige dingen zijn, en ik me er aan stoor dat ze op elke notebook die ik tot nu toe gehad heb (modellen uit 1998 tm nu) ze niet fatsoenlijk werken.
Deze lap tekst is voor mijzelf een stuk documentatie, want ik merk als ik het een weekje laat liggen, ik alle listige dingetjes kwijt raak en vergeet. En wellicht heeft iemand anders er ook wat aan.

Links
Ter referentie, een lijstje datasheets die ik aanhaal in dit artikel:

SMBus v1.1 Specification
Smart Battery Data Specification v1.1
BQ2084 Datasheet
Atmega16U4 Datasheet
Elitebook 2730p Schema (Mediafire)

Die laatste is geloof ik niet helemaal de bedoeling dat we die kunnen zien, gezien er groot CONFIDENTIAL op staat... maar ach... het helpt wel enorm.

Overzicht
Hoe het, een notebook, in zijn geheel werkt... is te veel om uit te leggen. Als je alles in grote blokken opdeelt, wordt het steeds beter te behappen:

Hieronder heb ik een schema getekend hoe het vermogen in mijn notebook ongeveer loopt:

Schema Elitebook

Het bestaat uit vier hoofd delen (grijs omringd):
  • De notebook
  • De adapter
  • 2 batterijen
Alles wat energie verbruikt, wordt gevoed door een grote bak DC/DC converters, en die heb ik allemaal in het blok rechtsonder weg gewerkt.

Naar dat blok gaan twee rode lijnen, met twee schakelaars.

De rode lijn stelt de plus van een voedings spanning voor, en de schakelaar zijn in dit geval meestal twee stuks PFETs met de drains aan elkaar geknoopt.
Maar, in essentie worden ze gebruikt als aan/uit schakelaar. Vandaar dat ik ze zo in het schema heb gezet.

Als ik de 19V adapter in mijn notebook prik, duurt het even voordat het power lampje aan gaat. Dit is omdat hij dit schakelaartje dus eerst op 'aan' moet zetten. (Er zit een RC op de gate)

Links daarvan zit de lader. Zijn enige doel in het leven is de batterij in mijn notebook opladen. Die kan dus ook aan en uit worden gezet met een schakelaar.

Omdat de lader maar één batterij tegelijk kan opladen....
Er is voor gekozen om de lader maar één batterij tegelijk op te laten laden.

Hiervoor is er een 'battery selector' in het leven geroepen. Deze knoopt een van de twee batterijen aan de lader vast.

Als we niet aan het laden zijn, maar vanaf de batterij werken kiest de battery selector een batterij uit, en knoopt hij die via het aan/uit knopje aan de DC/DC converter... en alles in de notebook krijgt prik.

Verder valt het op dat er in de batterij ook een aan/uit schakelaar zit. De batterij kan zichzelf namelijk ook uit zetten, als hij denkt dat dat nodig is.

Accupologie
Iemand die zich bezig houd met het gedrag van accu's. (Of met hun polen...?)

Er worden twee type's accu bij deze notebook verkocht, en die noemt HP de hoofd batterij, en de reis batterij.
Laatst genoemde klik je onder de notebook, en de naam suggereert dat je daarna op reis gaat.

Als je beide batterijen aan de notebook hangt, wordt de reis batterij als eerste leeg gezogen. Als die 0% aangeeft, wordt de interne batterij leeg gezogen.

Als ik twee batterijen in mijn notebook heb, die beide half vol zijn, en ik prik de lader er in... wordt de reis batterij als eerste opgeladen. En dat vind ik vreemd gedrag. Ik wil de interne batterij als eerst opgeladen hebben. Die gebruik ik het meest.

Ten tweede kwam ik er dus achter, dat ik ook prima een batterij van een andere notebook eraan kan hangen, en die wordt dan gewoon opgeladen en ontladen. Vreemd? Nee.

DO NOT TRY THIS AT HOME! (Unless you know what you're doing.)

Als ik alleen de hoofd accu installeer, en een 12V accu op de pinnen van de externe batterij connector zet en het battery-detect pinnetje aan de min vast maak, ontlaad de hoofd batterij, en als die op is... valt de notebook niet uit?

Er wordt nu stroom uit de externe connector getrokken terwijl het lijkt alsof er geen accu aan hangt. ....MADNESS!

Accu's op, stroom weg...

Begin je je al af te vragen waarom je een 12V naar 19V car adapter gekocht hebt voor het luttele bedrag van 100 ballen? Mooi. Leest u verder.

SMBus
De wiki zegt er verrassend weinig boeiends over, en dat is waarschijnlijk omdat het dat ook niet is.

Kort samengevat is de SMBus specificatie een definitie hoe data over een bus uitgewisseld moet worden. Als je daar vervolgens de Smart Battery Data Specification naast legt, wordt het duidelijk dat er een standaard bestaat die, wanneer je een willekeurige lader aan een willekeurige accu vast maakt, deze twee met elkaar laat praten en uitvogelen wat er moet gebeuren. (Ultimately: De accu opladen.)

Dit willen we weten, omdat je in het schema twee SMBussen ziet zitten, die gaan ieder naar een accu, en doen ogenschijnlijk iets belangrijks.

De SMBus specificatie stelt eigenlijk alleen eisen aan hoe de communicatie er fysiek uit moet zien, d.w.z het aantal lijnen gebruikt om over te communiceren. De voltages die gebruikt worden, alle staten waarin de bus zich kan bevinden en het protocol om data uit te wisselen.

En dit komt in grote lijnen overeen met het I2C protocol.

Er zijn bergen met software die 'iets' met SMBus-sen kunnen:

HWMonitor is een vrij bekend stukje software, die heeft een mooie "Save SMBus data"-knop. Die slaat vervolgens wat meuk op, en die meuk heeft totaal niks met een van m'n twee batterijen te maken.
Zowiezo klopt er geen reedt van dit programma: hij denk namelijk dat er maar één batterij aan hangt. De minimum waarden zijn van de batterij met de laagste waarden, en maximum van degene met de hoogste waarden. Dit gooit ie door elkaar in een tabel en tadaa, alsjeblieft! Zo is het!

Verder geeft hij temperatuur aan die meer dan voldoende zou moeten zijn om stabiel kernfusie op gang te helpen, en gezien ik nog geen paddestoel wolk gezien heb, twijfel ik daar ook wat aan.

Speedfan vind een hele lijst met Adressen op de SMBus, waaronder een Accelerometer en een Fancontroller, maar de rest kan hij niet van vertellen wat het is.
Dit klopt verder allemaal, het schema zegt ook dat deze dingen er zijn, en dat ze inderdaad aan de SMBus van de ICH9M zitten.

Het probleem is dat de batterij daar niet aan zit, maar die zitten ieder op een aparte bus vast aan een IC genaamd KBC1091-NU van SMSC. (Pagina 32 v.h. 2730p cchema) En laat daar nou eens helemaal geen datasheet van bestaan. Grrrr.

Ik heb zelfs de fabrikant gemailt, zonder verder al te hoge verwachtingen op een respons. Toch kwam die, en kijk eens wat ze zeggen:

Hi,
Data supporting this device is only shared via NDA with approved customers.
Greetings.


En approved customers moeten om te beginnen er eerst 100.000 afnemen. 100.000!

BatteryMon is een van de vele tools die net iets meer informatie over je accu kunnen weergeven. Maar deze haalt hij niet direct uit de SMBus, maar wordt uit een Windows API gezogen. En dat is vervelend, want alle software geeft de accu informatie fout weer.

Het is hoog tijd om eens een hartig woordje met de accu te gaan houden, en uit te vinden wat hij allemaal voor een onzin aan mijn notebook verteld. Daarvoor moeten wij gaan:

Bus Snuiven
Als we niet op een makkelijke manier via software met de batterij kunnen babbelen, wil ik wel eens zien wat de batterij überhaupt allemaal te vertellen heeft als hij aan de pc hangt.

De BQ2084 datasheet is vrij uitgebreid, en geeft eigenlijk al genoeg informatie om mee aan de gang te kunnen: (Pagina 20)

"The processor then sends the bq2084-V143 device address of 0001011 (bits 7-1) plus a R/W bit (bit 0) followed by an SMBus command code. The R/W bit (LSB) and the command code instruct the bq2084-V143 to either store the forthcoming data to a register specified by the SMBus command code or output the data from the specified register."

Kortom: 00010110 = 0x16 is het commando om een register te lezen, 0x17 om te schrijven.

"In some instances, the bq2084-V143 acts as the bus master. This occurs when the bq2084-V143 broadcasts charging requirements and alarm conditions to device addresses 0x12 (SBS Smart Charger) and 0x10 (SBS Host Controller.)"

Okee. Dus alles heeft een vast adres?

Op pagina 39 van de SMBus specificatie staat inderdaad een 7-bit adres: Smart Battery: 0001 011

Dat betekend dus, als je twee batterijen hebt, zoals deze notebook, heb je twee bussen nodig om er mee te kunnen praten. Er kan namelijk maar een adres per bus hetzelfde zijn. Dit verklaart waarom er ook twee bussen naar het SMSC IC gaan. Maar waarom gaan we dan een bus gebruiken als we er maar een ding aan kunnen hangen? Whatever.

In hetzelfde document staan de signalen nogmaals beschreven, en die komen overeen met de TWI signalen zoals die in een Atmel Atmel datasheet staat. En gezien er daar eentje van voor mijn neus ligt, vraagt hij er om, om ingezet te worden als snuiver.

TWI op een Atmel
De Atmega die ik toevallig nog had liggen, een Atmega16U4, heeft net als vele andere een Hardware TWI interface. TWI staat voor two-wire interface, en die is ook eigenlijk weer hetzelfde als een I2C interface en die op zijn beurt weer hetzelfde als de SMBus interface is. Semantics.

Belangrijk nu is dat alle data wordt voorafgegaan aan een START signaal, daarna vind er communicatie plaats, en vervolgens een STOP signaal.

We gaan dus een bus-snuiver maken. (Ik houd van Engels letterlijk vertalen.) Dan kunnen we namelijk al het verkeer tussen de PC en batterij afluisteren, zonder in Linux kernels te moeten gaan rond wroeten, god forbid, een Windows driver schrijven of op dubieuze websites naar niet bestaande datasheets graven.

Ruik en Snuiver

En ik weet nu dat er op de bus in ieder geval een batterij gaat zitten, en die gaat data ontvangen en terug schreeuwen naar op z'n minst een lader.

Het vervelende aan de TWI interface is dat om data te kunnen ontvangen, je bij deze Atmega een vast adres moet opgeven. En ik wil eigenlijk gewoon alles zien.

Om het dit te doen, en om het hele communicatie proces verder zo min mogelijk in de weg te zitten, gebruik ik niet de TWI interface, maar pak ik het anders aan:

De SDA en de SCL (Data resp. Clock) hangen we beiden aan een interrupt, de Atmega16U4 heeft er een paar, ik ga INT0 en INT1 gebruiken.

Elke keer als een van deze pinnen van 0 naar 1, of van 1 naar 0 gaat, wordt de Interrupt aangeroepen. Met de beschrijving van de signalen kunnen we dan zelf de START en STOP condities eruit vissen, en alles daartussen was data. (Er is ook nog zoiets als een REPEATED START, maar die is exact hetzelfde als gewoon START).

Er draait verder op de Atmel een USB driver op die zich als seriële poort aanmeld (wat onder Windows vet klote is, maar het werkt) waar we alle dingen die we willen weten over naar buiten gaan poepen.

Omdat de micro ook nog USB interrupts moet afhandelen, wordt het tricky. Gelukkig hoeft dit niet al te snel, maar moet zo uit mijn hoofd wel binnen iets van 100ms gebeuren.

Dus, we gaan eerst gewoon steeds 50ms kijken of de interrupt pinnen heen en weer gewiebeld worden, en hoe vaak. Daarvoor zet je gewoon de interrupts aan, en wacht je een tijdje.
C: Main.c
1
2
3
4
5
6
7
sei();
sda_change = 0;
scl_change = 0;
_delay_ms(50);
cli();
...
msglen = sprintf(msgbuff,"%3u %3u",sda_change,scl_change);

C: Interrupts
1
2
3
4
5
6
7
ISR(INT0_vect) {
    scl_change++;
}

ISR(INT1_vect) {
    sda_change++;    
}

Dat was de meest kort interrupt code ooit. Bij elke wisseling wordt er gewoon 1 bij een getal opgeteld, en dat wordt vervolgens in een buffertje geprint. Verderop wordt die door een stukje USB code naar de PC geduwd. Hoe dat verder allemaal werkt is niet zo belangrijk, wat belangrijk is, is dat er geteld wordt, en de output dit geeft:

termite: Interrupt Output
1
2
3
4
5
6
7
 52 188 
 0  0  
 0  0
 0  0  
 22  94 
 0  0
 0  0

In werkelijkheid zaten er nog veel meer 0-en tussen. Er gebeurt dus voornamelijk niks, maar af en toe komt er wat gewiebel voorbij.

Het enige wat er verder hoeft te gebeuren, is de START en STOP condities herkennen. Alles daartussen is data, en dat willen we zien.

C: Interrupts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
// SCL Interrupt State Change
ISR(INT0_vect) {
    // Read value of SCL into scl
    bitSCL = PIND & SCL;        
    if (bitSCL){ //On positive going edge.
        if (bit_cnt>0){
            if (bitSDA)
                byte_val |= (1<<(bit_cnt-1));            
        }else{
            bit_cnt = 9;
            if (chars >= SMBUS_BUFF)
                chars = 0;            
            smbus_data[chars] = byte_val;
            byte_val = 0;
            chars++;
        }
        bit_cnt--;
    }    
    scl_change++;
    return;
}

// SDA Interrupt State Change
ISR(INT1_vect) {
    // Readit!
    bitSDA = PIND & SDA;    
    if (bitSDA && bitSCL){
        cond = COND_STOP;    
        stop_cnt++;
        bit_cnt = 8;
        byte_val = 0;        
    }else if (bitSCL){
        cond = COND_START;
        bit_cnt = 8;
        byte_val = 0;        
        start_cnt++;
    }else{
        cond = COND_DATA;
    }
    sda_change++;    
    return;
}

Dit is eigenlijk een vrij kort stukje code geworden. Het moet ook zo kort mogelijk zijn, want als het te lang duurt, zijn we niet klaar voordat de volgende interrupt afgaat, en missen we stukjes data.

De smbus_data array bevat nu een aantal characters. Verder wordt het aantal SDA changes, het aantal SCL changes, aantal START, aantal STOP condities geteld. En die gooit ie vererop naar de PC toe. Alle regels waar niks op gebeurt heb ik er tussenuit gevist:
En dat geeft:

termite: Beeld
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
 52 188   4   2 16  9 17 8C 40 16  A 17  0  0 
 52 188   4   2 16  9 17 8C 40 16  A 17  0  0 
 22  94   2   1 16  B 17  0  0 
 51 188   4   2 16  9 17 8C 40 16  A 17  0  0 
 52 188   4   2 16  9 17 8C 40 16  A 17  0  0 
 24  94   2   1 16  A 17  0  0 
 53 188   4   2 16  9 17 8D 40 16  A 17  0  0 
 55 188   4   2 16  9 17 8D 40 16  A 17  0  0 
 27  94   2   1 16 10 17 46  6 
 50 188   4   2 16  9 17 8C 40 16  A 17  0  0 
 28  94   2   1 16  D 17 4B  0 
 52 188   4   2 16  9 17 8C 40 16  A 17  0  0 
 53 188   4   2 16  9 17 8C 40 16  A 17  0  0 
 31  94   2   1 16  8 17 96  B 
 51 188   4   2 16  9 17 8C 40 16  A 17  0  0 
 53 188   4   2 16  9 17 8D 40 16  A 17  0  0 
 22  94   2   1 16  B 17  0  0 
 52 188   4   2 16  9 17 8C 40 16  A 17  0  0 
 50 188   4   2 16  9 17 8C 40 16  A 17  0  0 
 24  94   2   1 16  A 17  0  0 
 52 188   4   2 16  9 17 8C 40 16  A 17  0  0


Op de eerste regel, is het eerste getal het aantal SDA changes, de volgende SCL changes, dan het aantal START condities, en het aantal STOP condities. De rest is data.

Dit is dus wat er in de huidige toestand zo'n beetje voorbij komt vliegen, en begint al goed ergens op te lijken. Ter vergelijking wordt de HP Tool weer tot leven geroepen:
Okee, en nu?

De tweede batterij is degene die ik aan het afluisteren ben, en die heeft bijvoorbeeld als status code C0. De BQ2084 datasheet geeft bij BatteryStatus() (0x16) een lijstje met bitwaardes en hun beschrijving. (Pagina 43).
De regel die we opgevangen hebben die daar bij hoort:

termite: Status code regel
1
16 16 17 C0  0


Het eerste getal, was het batterij adres met de R/W bit op 0. De lader vraagt dus een register uit de batterij op. Het tweede getal is het commando, weer 0x16. Hij vraagt dus de BatteryStatus op.
0x17 is weer zijn eigen adres, met de R/W bit op 1 (Bij elkaar dus 0x17).
En de twee bytes antwoord C0 en 00 zouden vertalen naar de volgende twee statussen:

0x0080 - Initialised
0x0040 - DISCHARGING

Voor de hoofd batterij zal dat dus betekenen:

0x4000 - TERMINATE_CHARGE_ALARM
0x0080 - Initialised
0x0040 - DISCHARGING
0x0020 - FULLY_CHARGED

De hoofd batterij heeft een alarm afgegeven aan de lader, om te nokken met laden. En verder zegt ie: Ik ben volledig opgeladen!

Maar lieve batterij. Ik weet dat je niet vol bent. Waarom laad je niet op? Doorladen kreng!

De tweede batterij is om onduidelijk reden ook gewoon lekker niet aan het opladen.

On another side note, begrijp ik nu waarom de HP Tool er zo onnozel lang over doet om de batterij informatie op te vragen. Als je op de refresh knop drukt, gebeurt er namelijk niks in het dataverkeer. Kennelijk verzameld hij dus gewoon alle informatie die maar wat willekeurig voorbij komt vliegen.

Verder valt op, dat wat er nogal vaak voorbij komt het volgende is:

termite: Status code regel
1
16  9 17 8C 40 16  A 17  0  0


0x16 is weer naar de batterij toe, en 0x17 is nog steeds het antwoord terug.

Tabel 3 op pagina 14 geeft de hele lijst met commandos die naar de BQ2084 geschoten kunnen worden, en verderop wordt per commando uitgelegd hoe de data geïnterpreteerd moet worden.

Hier wordt achter elkaar command 0x09 en 0x0A verstuurd. Voltage en Current

Het antwoord is in Little-Endian en leest in Big-Endian dus resp. 0x408C en 0x0000.

0x408C is in decimale getallen 16524, en laat dat nou exact het getal zijn wat bij Terminal Voltage in de HP Tool staat. En de current is inderdaad 0 mA.

Woepie, het is altijd fijn als dingen blijken te kloppen. Ik kan dus nu fijn al het verkeer tussen de batterij en de lader volgen en analyseren.

Ennu?
Nu is het artikel afgelopen... want het wordt te lang. Gelukkig volgt er meer, veel meer.

Het schema wat ik aan het begin geplakt heb, gaat voor een heleboel fabrikanten op. Iedereen bouwt maar wat aan, gebaseerd op een losjes gedefinieerde standaard. Bij elke nieuwe notebook mag je als consument een nieuwe accu kopen, een nieuwe lader met een ander stekkertje. Plugje hier, plastic-je daar... en bam. Weer een maand eten verder.

Elektrisch gezien is het allemaal niet nodig, maar marketing technisch....

Volgende: Domme Batterijen - Verkeer(de)informatie 12-'12 Domme Batterijen - Verkeer(de)informatie
Volgende: Domme Batterijen 12-'12 Domme Batterijen

Reacties


Door Tweakers user Zerfox, woensdag 19 december 2012 23:13

Pfoe, lang maar boeiend en vooral leerzame blog!
Jammer dat je op het allerleukste moment stopt: datasniffing en analyseren!

Kan niet wachten op de volgende blogpost!

Door Tweakers user leenm, woensdag 19 december 2012 23:27

Mooie blogpost, ben benieuwd naar de rest van de serie. Ga zo door!

Door Tweakers user Infant, woensdag 19 december 2012 23:29

Zerfox schreef op woensdag 19 december 2012 @ 23:13:
Pfoe, lang maar boeiend en vooral leerzame blog!
Jammer dat je op het allerleukste moment stopt: datasniffing en analyseren!

Kan niet wachten op de volgende blogpost!
Ja, het moet wel spannend blijven he? :)

Door Tweakers user wheez50, donderdag 20 december 2012 00:16

same here - doet me denken aan de blogs van ene mux ...

[Reactie gewijzigd op donderdag 20 december 2012 00:17]


Door Tweakers user Felyrion, donderdag 20 december 2012 05:51

Opnieuw petje af voor je blog! Super om er eens zo diep in te duiken. Meer van dit :)

Door Tweakers user HenriM, donderdag 20 december 2012 10:03

Eindelijk weer een blog op Tweakers die de moeite waard is. Ga zo door!

Door Tweakers user i-chat, donderdag 20 december 2012 13:09

goed neer geplempt voor 99% snapte ik het zowaar... niet gezegd hebbende dat ik het je na zou doen, maar dat was ook neit de intentie van het beginnen te lezen ... not yet anyway

Door Tweakers user Infant, donderdag 20 december 2012 16:03

wheez50 schreef op donderdag 20 december 2012 @ 00:16:
same here - doet me denken aan de blogs van ene mux ...
mux en ik delen een 'indistinguishable brainwave pattern'... het is soms beangstigend.
i-chat schreef op donderdag 20 december 2012 @ 13:09:
goed neer geplempt voor 99% snapte ik het zowaar... niet gezegd hebbende dat ik het je na zou doen, maar dat was ook neit de intentie van het beginnen te lezen ... not yet anyway
Ik schrijf hetook, omdat ik op veel fora en weblogs alleen maar mensen vind die niet begrijpen waarom hun accu dood is, denken dat accu's invriezen goed is. Er heerst nogal wat onbegrip.

Ik probeer het dus ook zo te schrijven, dat als je nooit van plan bent aan je accu te komen, het leesbaar is.
Maar als je, zoals ik, dat ding volledig binnenstebuiten gaat keren, hoop ik dat je hier ook wat aan hebt.

Door Tweakers user addo2, donderdag 20 december 2012 19:59

Infant: Ik lees je blog nu een week en reageer bijna nooit ergens op maar ik vind je onderzoekje fantastisch om te lezen en wil je dit graag meegeven.

Bedankt voor de informatie (en de info die er vast nog gaat) komen! _/-\o_

Door Tweakers user BeefHazard, donderdag 20 december 2012 20:18

Leuk stuk, jammer alleen van de vele dt-fouten. Maar dat is slechts mijn mening. KUTGW, en let op je spelling ;)

Door Tweakers user Infant, donderdag 20 december 2012 20:58

Ja, ik heb de afgelopen jaren niet echt veel Nederlandse stukken meer geschreven. Reedt moet uiteraard met dt. Altijd.

Bedankt voor de positieve reacties.

Door Tweakers user Xessive, donderdag 20 december 2012 21:44

mooie blogpost. Kijk nu al uit naar het vervolg

Door Tweakers user Xaero, donderdag 20 december 2012 21:47

Erg leuke blog! ;-). Errug duidelijk

Door Tweakers user BeefHazard, donderdag 20 december 2012 23:54

Infant schreef op donderdag 20 december 2012 @ 20:58:
Ja, ik heb de afgelopen jaren niet echt veel Nederlandse stukken meer geschreven. Reedt moet uiteraard met dt. Altijd.

Bedankt voor de positieve reacties.
Reedt en kudt is sowieso een gogo

Door Tweakers user melcon, vrijdag 21 december 2012 11:12

Geweldige blog dit! En schijt aan de spelling, het is prima leesbaar en vooral heel goed begrijpbaar!

Door Tweakers user spone, vrijdag 21 december 2012 23:42

Ondanks dat ik er maar de helft van begrijp, vind ik het best interessant. Bij deze ook mijn waardering voor de blogposts tot nu toe!

Reageren is niet meer mogelijk