De EL-kroeg - Deel 3

[Ibex]

	Heuh, wat is dit dan? Het komt vaak genoeg voor dan mensen een slimme constructie gebouwd hebben om iets gedaan te krijgen, even snel willen weten welke tor nou beter werkt voor een bepaald iets, truukjes willen uitwisselen om een soldeerpunt schoon te krijgen, noem maar op. In EL is daar normaliter niet echt plek voor, vandaar dat we dit maar eens proberen: een topic waar de ELlers informeel kunnen kletsen over wat ze bezighoudt. Ok, dus... Nou, pak een pilsje en gooi die geniale truuks, irritante hebbelijkheden of leuke features van chippies op tafel, of begin te klagen over de brandblaren aan je vingers als je nog niet zo ver bent. IRC Wens je gewoon lekker te babbelen tegen een snelheid vele malen groter dan slowchat, dan kan je vele stamgasten en andere gasten vinden op IRC. icr.tweakers.net in #elektro. Vorige delen... 01 02 03 De vaste spammers stamgasten... • ThinkPad • DaWaN • wacco • Atlas • bobo1on1 • rreal_FireFly • Boudewijn • mace • Sprite_tm • ssj3gohan Geef ze een pint! En als laatste: Dit is een iets wat groter experimentje geïnspireerd door de NOS-kroeg. Ik hoop dat jullie het kunnen waarderen en het gezellig kunnen houden, zodat er nog vele delen kunnen volgen. Met dank aan: • Sprite_tm voor de originele TS en de stats • madwizard voor het plaatje

[Voor 9% gewijzigd door Ibex op 19-05-2009 07:14]

[Ibex]

Sow, eventjes nog wat stats in de TS gezet. Toffe ideen zijn altijd welkom.

Ik zit overigens nu te prutsen met data in het programmageheugen opgeslagen. Op een of andere manier lijk ik enkel troep uit te lezen in plaats van de data die ik zou verwachten. Morgen maar eens met een frisse(re) kop opnieuw proberen .

[Ibex]

Sprite_tm schreef op maandag 18 mei 2009 @ 23:27:
Je progde toch in assembly voor de AVR? Houd je er dan rekening mee dat je labels tellen in instructies (=16bit) terwijl lpm een byte-adres nodig heeft? Zo moet 't:

code:

ldi zlo,low(mijn_data*2)
ldi zhi,high(mijn_data*2)
lpm ;r0 bevat nu 0xa5

mijn_data: .db 0xa5

Het probleem:

Er staat "HeloWrld" in een stukje program memory. Ik wil dit simpelweg letter per letter tonen op het display, tot ik 0 vind, dan weet ik dat de string gedaan is. Momenteel ga ik ervan uit dat ik steeds maximaal 8 karakters heb, later ga ik trachten een "scroll" functionaliteit te schrijven.

Wat verwacht ik op het scherm:

[norml][H][e][l][o][W][r][l][d][/norml]

Wat krijg ik:

code:

[$][@][7][&][#][(][D][>] ; gedurende 1 seconde, de tekens zijn iets anders in werkelijkheid
[!][a][,][?][-][^][_]["] ; nogmaals 1 seconde
[r][l][d][H][e][l][o][W] ; deze verkapte string gedurende 2 seconden
[#][#][#][#][#][#][#][#] ; een fractie van een seconde
[!][%][,][=][@][l][z][~] ; 1 seconde
; en dan gaat het terug naar lijn 3 om zo de hele tijd deze laatste drie lijnen te herhalen.

Je moet weten dat de functie displaytekst hieronder elke seconde aangeroepen word door een timer.

Mijn code is nu ongeveer zo:

code:

;...
.def temp = r16
.def character = r17
.def position = r18
.def argument = r19
.def registerselect = r20
.def databyte = r24
.def addressbyte = r25
.def working1 = r26
;...
displaytekst:
    ldi ZH, high(message << 1)
    ldi ZL, low(message << 1)
    clr working1
    
    startdisplay:
        lpm character, Z+
        tst character
        breq messagewritten
        mov position, working1
        rcall writechar
        inc working1
        rjmp startdisplay
    
    messagewritten:
ret

writechar:
    mov temp, position      ; 0b?????xxx
    andi temp, 0b00000111   ; 0b00000xxx
    ori temp, 0b00011000    ; 0b00011xxx -> add A4 and A3
    ori temp, 0b11100000    ; 0b11111xxx -> set nCE, nWR and nRD
    
    andi character, 0b01111111
    
    mov addressbyte, temp   
    mov databyte, character
    rcall writedata
ret

writedata:
    mov temp, addressbyte
    
    mov argument, addressbyte
    ldi registerselect, 0b00000000
    rcall loadbyte

    mov argument, databyte
    ldi registerselect, 0b00000001
    rcall loadbyte
    
    andi temp, 0b01111111   ; lower nCE
    mov argument, temp
    ldi registerselect, 0b00000000
    rcall loadbyte
    
    andi temp, 0b10111111   ; lower nWR
    mov argument, temp
    ldi registerselect, 0b00000000
    rcall loadbyte
    
    ori temp, 0b01000000    ; set nWR
    mov argument, temp
    ldi registerselect, 0b00000000
    rcall loadbyte
    
    ori temp, 0b10000000    ; set nCE
    mov argument, temp
    ldi registerselect, 0b00000000
    rcall loadbyte
ret

loadbyte:
    rcall loadbit ;bit 7
    lsl argument
    rcall loadbit ;bit 6
    lsl argument
    rcall loadbit ;bit 5
    lsl argument
    rcall loadbit ;bit 4
    lsl argument
    rcall loadbit ;bit 3
    lsl argument
    rcall loadbit ;bit 2
    lsl argument
    rcall loadbit ;bit 1
    lsl argument
    rcall loadbit ;bit 0
    
    rcall strobeSTCP
ret

loadbit:
    sbrs argument, 7
    rjmp clearDS
    setDS:
        sbi PORTB, 0
        rjmp endloadbit
    clearDS:
        cbi PORTB, 0
    endloadbit:
    rcall strobeSHCP
    cbi PORTB, 0
ret
;...
message:
.db "HeloWrld",0,0

Een hele lap, maar misschien ligt het probleem totaal ergens anders.

Als ik de code in displaytekst vervang naar volgende code, werkt alles prima:

code:

    ldi character, 'H'
    ldi position, 0b00000000
    rcall writechar
    ldi character, 'e'
    ldi position, 0b00000001
    rcall writechar
    ldi character, 'l'
    ldi position, 0b00000010
    rcall writechar
    ldi character, 'o'
    ldi position, 0b00000011
    rcall writechar

DaWaN schreef op maandag 18 mei 2009 @ 23:28:
[...]

Wat ga je nu eigenlijk bouwen dan ?

Voorlopig nog niets concreet. Maar het was alweer een twee jaar geleden (ongeveer) dat ik nog eens serieus geknutseld had met electronica. Maar nu ik een nieuw appartement heb met een huge bureau, kan ik terug lekker aan de slag gaan, zonder 's avonds alles te moeten opruimen .

Er zijn een aantal dingen die ik momenteel onder de knie wil krijgen:
- ATtiny2313 (ik had voorheen enkel ervaring met een ATmega8583)
- Schuifregisters
- Een nieuw schermpje: HDSP-2110 (prachtig en leuk ding!)

Ik had al ervaring met timers e.d. maar je vergeet snel kleine dingen waardoor je wel eventjes zoet bent.

Volgende stappen zijn:
- Het tonen van tekst die ik intyp in een console en via seriele poort verstuur, afhankelijk van wanneer mijn laatste onderdeeltjes toekomen.
- Het uitlezen en verwerken van GPS signaal uit mijn receivertje
- Schrijven (en lezen) van (en naar) een SD kaartje
- Alles combineren en een soort van GPS-logger maken .

[Voor 36% gewijzigd door Ibex op 19-05-2009 07:58]

[Ibex]

Ik trek me de haren uit mijn hoofd. Ik slaag er gewoonweg niet in om een reeks bytes uit het program memory te lezen .

Ondertussen maar een beetje gespeeld met het sram door dit te gebruiken inplaats van talloze rXX registers. En dat lukt dan wel zonder problemen.

[Ibex]

Nop, ik gebruik r16 t.e.m. r24. Ik kan me echt niet meer inbeelden wat er mis is.

Iemand zin om eventjes mijn code na te lezen aub? Je kan ze vinden op http://pastebin.com/m2ed84ed8. Er staat een hele zwik in commentaar in de displaytekst methode. Het stuk in commentaar is gewoon manueel de tekst zetten, de code eronder niet in commentaar is via het program memory.

Ik begin te vrezen dat ik gewoon die HDSP-2110 niet correct aanstuur.

[Voor 8% gewijzigd door Ibex op 21-05-2009 11:18]

[Ibex]

Ik heb even een routine bijgeschreven die een ledje laat knipperen op het ritme van de seconde, zodat ik zie wanneer er telkens een update zou moeten komen.

Bovendien heb ik de code in de displaytekst methode vervangen door volgende code:

code:

    mov position, temp2
    mov character, temp3
    rcall writechar
    inc temp2
    sbrc temp2, 3
    ldi temp2, 0b00000000
    inc temp3
    sbrc temp3, 7
    ldi temp3, 0b00000000

Dit zou normaalgezien telkens het volgende karakter moeten laten tonen in het volgende veld, eventueel terugspringend naar het eerste veld / teken indien alle velden / tekens zijn doorlopen. Vanzelfsprekend worden temp2 en temp3 nergens anders voor gebruikt.

Het vreemde is dat de microcontroller na 3 seconden gewoon stopt (crashed I guess), waardoor er maar twee tekens verschijnen.

[Voor 4% gewijzigd door Ibex op 21-05-2009 12:53]

[Ibex]

Ok, het probleem dat de microcontroller lijkt te crashen is opgelost. Ik overschreef *ergens* een waarde . Nu nog proberen om die string uit het @#$% programmemory te halen .

[Voor 94% gewijzigd door Ibex op 21-05-2009 15:26]

[Ibex]

. Het moet een bug zijn in gavrasm. Ik heb nu eventjes AVR studio 4 op mijn oude windowslaptop geinstalleerd (damnnn, dat ding is traag) en dan met remote desktop eventjes mijn .asm gebuild en naar mijn microcontroller geflashed, en het ding werkt gewoon perfect...

Nu vraag ik me toch echt af waar die bug zit...

---

@madwizard: He, dat wist ik nog niet. Ook wel handig in feite, heb je ook geen speciale functies en dergelijke meer nodig.

---

Zozo, eens ik die bug in gavrasm had ontdekt en ik nu met AVR studio compileer, gaat het lekker vlot .

Ondertussen heb ik de code iets opgeruimt en werk ik nu zo veel mogelijk in het sram. Voorlopig copier ik de te tonen string in een buffer in het sram en vervolgens copier ik deze naar een andere plaats in het sram. Van daaruit toon ik deze op het scherm. Is de string langer dan 8 karakters, dan begin ik na een halve seconde de tekst te scrollen, toon deze weer een halve seconde vast op het scherm en scroll weer, ... Is de string korter of gelijk aan 8 karakters, dan scroll ik niet .

Als volgende stap (maar daarvoor is het nog even wachten op onderdeeltjes) ga ik connectie maken via seriele poort naar de computer en via een hyperterminal achtig iets tekst verzenden naar de microcontroller. Deze zal dan de karakters in de buffer opslaan, tot ik een enter typ, waarna de buffer zal verplaatst worden naar het andere gedeelte in het sram van waaruit gedisplayt wordt. Op die manier kan ik naar wens typen zonder dat de weergave op het schermpje in de soep draait.

[Voor 55% gewijzigd door Ibex op 21-05-2009 23:43]

[Ibex]

Ibex schreef op donderdag 21 mei 2009 @ 15:27:
. Het moet een bug zijn in gavrasm. Ik heb nu eventjes AVR studio 4 op mijn oude windowslaptop geinstalleerd (damnnn, dat ding is traag) en dan met remote desktop eventjes mijn .asm gebuild en naar mijn microcontroller geflashed, en het ding werkt gewoon perfect...

Nu vraag ik me toch echt af waar die bug zit...

Hehe .

Hello.

Please be aware that a new version of the AVR command line assembler gavrasm
has been released. This version corrects two serious errors, so please use
this newer version.

In de releasenotes:

May 2009: Version 2.3
- Corrected: Serious error when addressing register ZL (R30).
- Corrected: Error when using the -x option (only external def.inc)

En inderdaad, de .hex files zijn nu identiek tussen AVR studio en gavrasm.

Hopelijk mailt hij mij terug wat nu juist de exacte fout was, ben wel benieuwd .

[Ibex]

Lijkt me heerlijk toch?

Je moet een eindje rijden met de trein. Stapt op, gaat zitten in een gedeelte met een tafeltje. Je legt heel "cool" een harde schijf op de tafel, je neemt een kleine loodaccu uit je tas, je neemt het printplaatje, sluit alles netjes aan met gewone kabeltjes en leunt lekker achterover terwijl je geniet van heerlijke muziek.

Het gezicht van de mensen maakt het imho alleen maar leuker .

[Ibex]

Ik heb een usb-serieel breakout bordje van micro4you gekocht. De micrcontroller spuugt elke seconde een '.' uit naar de seriele lijn tegen 38400 8N1. Minicom (=hyperterminal) ontvangt mooi elke seconde een '.'

Wat ik echter totaal iet aan de praat krijg is de andere richting. Wat ik ook in minicom intik, het rode ledje "TX" gaat maar niet branden, en de microcontroller krijgt geen signaal binnen. Wanneer ik de RX en TX van het breakout bordje aan elkaar knoop zou ik verwachten dat ik elke letter die ik in minicom intik, zie verschijnen, maar ook dit is niet het geval.

Als ik het breakout bordje in de USB poort prik, herkent mijn pc deze direct als een virtuele compoort, en zowel het RX als TX lichtje gaan enkele keren knipperen (wellicht een power-on-self-test oid)

Mensen die weten wat ik zou misdoen, en hoe ik eventueel kan testen of het verzenden van karakters naar de microcontroller nu werkt of niet, of waar juist de fout liggen?

[Ibex]

Sprite_tm schreef op zondag 14 juni 2009 @ 19:02:
Heb je hardware en software flow control (ctrl-a o 'serial port setup') wel uitstaan? Die kunnen namelijk ervoor zorgen dat een te verzenden byte in een queue komt te staan inplaats van daadwerkelijk verzonden te worden.

. Hardware flow control stond nog aan.

Nu zie ik effectief de TX-led oplichten, de microcontroller lijkt nog niets te ontvangen, maar dat is wellicht software. Nu lekker verder knutselen .

[Ibex]

Verdorie zeg.

In mijn gang heb ik een kastje waar onderandere router, modem en de NAS in geplaatst zijn. Bovendien heb ik voor mijn digitale TV een powerline adapter insteken, dus het werd een overload aan adapters. Ik heb dan maar een flinke 12V voeding gekocht en alle apparaten die volgens de adapter 12V moeten hebben hierop aangesloten. Werkt uitstekend .

De enige adapter die ik nog over had was een 6V voor het laadstation van de telefoon. Bovendien moest ik mijn ventilator in de kast (om wat airflow te genereren) ook nog van een electronensapje voorzien, dus ik bouwde dan maar een 12V > 6V voedingkje. De ventilatoren draaien netjes en ook de het basisstation van de telefoon leek netjes te werken; de handset kon het basisstation vinden, het basisstation kon de handset laten "opbiepen" en ook de handset werd keurig opgeladen eens op het station geplaatst. Toch was er 1 ding wat niet werkte; het bellen en gebeld worden, er was simpelweg geen kiestoon te vinden.

Dan maar terug de originele adapter aangesloten werkt alles terug prima. Toch maar eens het basisstation open gevezen en nagemeten wat er nu juist aan spanning binnenkwam; 9V. WTF zeg, waarom een 6V adapter voorzien als je dan toch 9V gebruikt. Ik weet dat een adapter meestal onbelast een hogere spanning geeft, maar van zodra er enige belasting is, dat de spanning inzakt naar het uiteindelijke niveau, maar dat het basistation uiteindelijk 9V gebruikt vind ik toch een beetje ranzig...

[Ibex]

goeievraag schreef op zaterdag 05 september 2009 @ 16:34:
@Ibex: Als die telefoon aan je modem hangt, en beide hangen aan de zelfde voeding, zou het kunnen dat het telefoonsignaal naar de massa getrokken wordt:

Stel dat het modem ader1 van de telefoonkabel aan de massa heeft, en het signaal op ader2. Als je telefoon het net andersom heeft, wordt het telefoonsignaal kortgesloten op het moment dat je de massa's doorverbindt. Als je gewoon nog 'klassiek' belt is het onwaarschijnlijker, het hangt allemaal af van hoe de signalen in je modem/splitter lopen.

De telefoon loopt inderdaad direct naar de modem, en ze zitten inderdaad beiden op dezelfde 12V voeding (waarbij voor de telefoon de 12V nog even naar 6V gebracht word door een LM2575). Maar daar alle twee de toestellen DC input hebben (waarbij de + en de - dus duidelijk zijn, niet zoals bij een stopcontact, waar 1 draad de lijn is en de andere neutraal terwijl je niet weet welke wat is), zou ik verwachten dat ze beiden dezelfde kabel nemen. Bovendien zou dit probleem zich dan toch ook voordoen wanneer ze op hun "normale" adapter zitten?

Toch maar mijn labovoeding richting daar sleuren en kijken wat er gebeurd als ik 6V input geef, en wat als ik richting de 9V ga.

edit; verhip, als de telefoon aan mijn labvoeding hangt met 6V werkt hij. Als de telefoon aan zijn eigen 6V adapter hangt (waarover ik 9V meet) werkt hij. Hang ik hem via mijn LM2575 12V > 6V convertor aan mijn 12V voeding waarop ook de modem is aangesloten, werkt het bellen zelf niet meer. Ik zou dus gokken dat het iets te maken heeft met het galvanisch gescheiden zijn van beiden?

[Voor 12% gewijzigd door Ibex op 05-09-2009 16:54]

[Ibex]

Ik heb sinds kort de Openbench Logic Sniffer. Heerlijk om op de computer de data te bekijken die je naar een of ander component stuurt.

Nu ben ik bezig 8 van de ongeveer 16 ingangen van een display aan het "sniffen" waar ik data insteek met een attiny2313 via 2 schuifregisters. Nu sample ik data tegen 100MHz, en zie stukjes waarbij de rise en fall van een datalijn slechts 20ns uit elkaar liggen (ofte, 50MHz). Hoe is dit mogelijk wanneer de microcontroller zelf maar een kristal heeft van 20MHz?

[Ibex]

ssj3gohan schreef op dinsdag 26 oktober 2010 @ 21:11:
[...]
Als je een SIPO schuifregister zou hebben worden 8 opeenvolgende samples op de datalijn in 1 attiny-cycle verwerkt, dus zou je 8 keer zo snel als het kristal moeten kunnen samplen. Dat is de enige manier waarop hij sneller kan samplen dan zijn kloksnelheid. Er zit geen PLL in die dingen ofzo.

Dit snap ik nog niet volledig. Mijn microcontroller kan maximaal tegen 20MHz data serieel naar het (idd) SIPO schuifregister klokken. Het heeft minimaal 2 kloktikken nodig per bit om deze in het schuifregister te laden, plus dan nog eens minimaal 1 om de 8 bits op de uitgang te plaatsen. Dit dus een 17 kloktikken in totaal. En dan geen rekening gehouden met zaken die de microcontroller tussentijds moet doen. En eer een uitgang op het schuifregister van staat veranderd, moeten opnieuw alles serieel in het schuifregister geschoven worden, en weer alles op de uitgangen geplaatst worden. Dus een rise en fall op een uitgang van het schuifregister zou toch minimaal 34 kloktikken moeten duren, ofte < 1MHz.

Kan je dit verklaren/uitleggen? Wellicht zie ik iets over het hoofd, maar het is wel leuk om te snappen waarom ik iets zie .

Glitches aan de kant van de microcontroller zouden misschien kunnen, maar die zou ik dan toch niet zien aan de uitgang van mijn schuifregister?

Schuifregister is een 74HC595 btw .

---

Nevermind, ik moet gewoon mijn ground aansluiten. Het clipje was losgeschoten, waardoor de sniffer inderdaad allerlei dingen zag die er niet waren. Damnit .

Nu kan ik wel begrijpen wat ik zie .

[Voor 6% gewijzigd door Ibex op 27-10-2010 07:49]

[Ibex]

code:

void latch()
{
    PORTB &= ~(1 << PB2);
    PORTB |= (1 << PB2);
    PORTB &= ~(1 << PB2);
}
void strobe_clock()
{
    PORTB &= ~(1 << PB1);
    PORTB |= (1 << PB1);
    PORTB &= ~(1 << PB1);
}

void shift_byte(uint8_t byte)
{
    uint8_t tempbyte = byte;
    for (uint8_t i = 0; i < 8; i++)
    {
        tempbyte = byte;
        tempbyte = tempbyte >> i;
    
        tempbyte &= 1;
        if (tempbyte == 1)
        {
            PORTB |= (1 << PB0);
        }
        else
        {
            PORTB &= ~(1 << PB0);
        }
        strobe_clock();
    }
}

Hiermee kan ik een byte op een sipo schuifregister plaatsen. Het probleem met deze functie is dat de byte verkeerd om op het schuifregister terecht komt. Ik plaats ze nu namelijk van LSB naar MSB op het schuifregister, wat erop neertkomt dat de LSB op de MSB van de uitgangen terecht komt, en omgekeerd.

Ik gokte dat ik

code:

for (uint8_t i = 0; i < 8; i++)

zou moeten vervangen door

code:

for (uint8_t i = 7; i >= 0; i--)

. maar dat werkt helaas niet. Iemand?

[Ibex]

DaWaN schreef op zondag 14 november 2010 @ 20:33:
[...]


Misschien iets met de initialisatie van i ? Bij de meeste compilers mag je i niet declareren in de for loop zelf.
Ik zou de code zelf trouwens alsvolgt schrijven:

code:

void shift_byte(uint8_t byte)
{
    uint8_t i;
    for (i = 0; i < 8; i++)
    {
        if (byte & (1 << i))
        {
            PORTB |= (1 << PB0);
        }
        else
        {
            PORTB &= ~(1 << PB0);
        }
        strobe_clock();
    }
}

Deze code werkt wel, maar heeft nog steeds het probleem dat het de volgorde van de bits omdraait. De for aanpassen helpt ook hier niet. Deze code is overigens wel iets netter .

LED-Maniak schreef op zondag 14 november 2010 @ 20:35:
[...]
Declareren van i mag prima in de for loop. Zelf hou ik niet zo van de compiler specific uint8_t. Liever gebruik ik gewoon "unsigned char i".

Daar heb je een punt. Het is inderdaad netter om "standaard" types te gebruiken. Als ik me niet vergis zijn dit de standaard types:
• char (= 8bit integer)
• int (= 16bit integer)
• long int (= 32bit integer)
• long long int (= 64bit integer)

Klopt dit?

---

Edit; het is ondertussen gelukt. Blijkbaar kan ik gewoon in de for lus niet (of althans niet op die manier) aftellen. Ik heb dus gewoon in plaats van 1 << i, 1 << (7 - i) gedaan .

[Voor 34% gewijzigd door Ibex op 14-11-2010 21:07]

[Ibex]

Interessant om weten allemaal .

[Ibex]

base_ schreef op maandag 15 november 2010 @ 16:11:
[...]
Moet je eens met je hiel in een DIP16 gaan staan! Had toen ook een schroevedraaier nodig...

[Ibex]

Ik zou een schakeling nodig hebben om met 1 pin van een micocontroller te kunnen schakelen tussen 3.3V en 12V. Ik heb beide spanningen voorhanden op mijn schakeling, en mijn microcontroller werkt op 3.3V. Het is om een led te schakelen tussen zwak en fel branden. In feite is het met een van de uitgangen van een SIPO schuifregister.

Iemand een idee?

[Voor 8% gewijzigd door Ibex op 16-11-2010 20:00]

[Ibex]

Het zit zo, de led zit in een wandschakelaar. De leds heben allemaal common "min", en hebben een vaste voorschakelweerstand van 10k. Ik moet dus aan de "plus" van de led 12V of 3.3V kunnen geven. De schakelingen van hierboven werken op zich perfect, maar werken niet in een situatie van common "min".

[Ibex]

Zou het ook gaan met een PNP of NPN transistor?

Edit; Als ik het goed begrijp zou ik de mosfet ook kunnen vervangen door een PNP transistor zoals de BC557, door de emitter aan de 12V te hangen, de collector aan de 10k ingebouwde weerstand, en de basis met een weerstandje aan de microcontroller.

[Voor 72% gewijzigd door Ibex op 18-11-2010 22:15]

[Ibex]

ssj3gohan schreef op donderdag 18 november 2010 @ 22:40:
[...]
Specifieke reden waarom je dat wilt doen?

Als je hem direct aan de microcontroller hangt kan er een hoge spanning op je uitgangspin komen te staan. Dan kun je het beste de basis van de PNP weer aan de collector van een NPN hangen, de emitter van die NPN aan ground hangen en de basis van de NPN aan je micro knopen. Zowel voor de basis van de NPN als PNP een weerstandje hangen en you're good to go.

Hetzelfde verhaal, maar dan NPN=N-channel en PNP=p-channel kun je uitvoeren met MOSFETs.

Dit was inderdaad de oplossing. Ik heb me ondertussen even goed ingelezen in het gedrag van PNP en NPN transistors, zodat ik ook echt begrijp wat er gebeurd. Dat maakt het allemaal een pak logischer.

[Ibex]

Enige tijd geleden maakte ik met hulp van jullie, twee transistoren en een handvol weerstanden een schakelingetje om met behulp van een 3.3V microcontroller / schuifregister uitgang 12V te verbinden met de 12V ingang van een common (-) led. Dit was dan eigenlijk een kortsluiting van een met de led in serie staande weerstand die de led zacht liet branden, waardoor een logische 1 op de uitgang van de microcontroller / schuifregister de led feller zou branden

code:

     (+)
      |
   +--+--+
   |     |
---X     W
   |     |
   +--+--+
      |
================
      |
      W
      |
    (led)
      |
     (-)

Het gegeven onder de ==== is vast, en kan ik niet aanpassen. Alle leds (+ hun weerstanden) hangen aan eenzelfde ground. Dus de "X" kan ik oplossen met transistoren, maar ik moet dit 8 keer doen, en heb geen zin in 16 weerstanden en een berg weerstanden op mijn printplaat.

Bestaat er een IC die X kan vervangen? En dan liefst 8 keer X in 1 package.

[Ibex]

Die jumperwires ben ik ook wel in geinteresseerd. Vooral dan goedkope, want helaas durft men soms belachelijk hoge prijzen vragen voor zulke zaken.

[Ibex]

Ik ben op zoek naar een N-type en een P-type FET geschikt voor schakelen met de microcontroller (logic-level?) die voor de meeste breadboard toepassingen geschikt zijn, een beetje zoals de BC547 en BC557 dat zijn voor de gewone transistoren. Ik wil een beetje experimenteren met FETs en hoe ze werken en hoe ik ze juist kan/moet gebruiken. Iemand die een paar types uit de mouw kan schudden (al dan niet samen met wat achtergrondinformatie erover)?

[Ibex]

Super, bedankt

[Ibex]

Bah, twee uur aan het kutten geweest en wat blijkt, ik had een aantal pennetjes van mijn schuifregisters niet goed aangesloten. No shit dat ik rare resultaten kreeg...

Soms werkt het nog steeds het beste om gefrustreerd alle draadjes van het breadboard te rukken en opnieuw te beginnen. En dan kom je aan een bepaalde pin "he, die had ik daarnet anders zitten, even nakijken" (...) *facepalm*

Edit; en zonet ontdekte ik twee LMC7660's in de bus. Met deze lieverd is het toch een pak gemakkelijker om een negatieve spanning te krijgen voor het contrast van mijn lcd .

[Voor 58% gewijzigd door Ibex op 30-12-2010 21:27]

[Ibex]

CyBeR schreef op donderdag 22 september 2011 @ 02:10:
[...]


Een beetje laat bij dit feestje, maar nee, ze zetten er geen twee mensen op. Beduidend meer Voor m'n werk laat ik pcb's door hen maken (inderdaad, als er iets mis is sturen ze screenshots en weetikveel wat op; ze hebben zelfs een open circuit die ik over het hoofd gezien heb gespot) en de vorige keer dat ik iets bestelde zag ik dat ze filmpjes gemaakt hebben over hoe ze dat nou daadwerkelijk doen: http://www.eurocircuits.c...g-a-pcb-eductional-movies

(Dat 't geen miljoen euro kost voor 10 stuks verbaast me.)

Overigens heb ik bij hen ook wel extra gekregen hoor. Vorige keer had ik 3x een panel besteld (met daarop 10x 2 losse bordjes). Het duurde forever dat ik erachter kwam want ik vergeet altijd wat ik bestel, maar ik bemerkte opeens dat na er drie gebruikt te hebben, er nog drie in m'n handen had

Ik vraag me dan af hoe chineese producenten dit zoveel goedkoper kunnen krijgen. Wellicht een combinatie van een meer geautomatiseerd process, mindere kwaliteit en goedkopere werkkrachten?

[Ibex]

Ik heb sinds kort een nieuwe multimeter in huis. Een erfstuk van mijn opa van toen hij nog bij Electrabel werkte. Het ding zou naar het schijnt erg goed zijn, maar ik kan in de verste verte geen informatie of handleiding meer vinden.

Het gaat om de normameter mp14.

Norma zou lang geleden overgenomen zijn door LEM wat op zijn beurt weer gedeeltelijk is overgenomen door Fluke. Fluke zelf bevestigde dit, maar kon geen handleiding meer leveren, aangezien de MP14 al buiten gebruik was voordat LEM was overgekocht. Fluke gaf de suggestie op het internet te zoeken .

Mijn vraag is dan ook of iemand van jullie meer over deze meter weet. Een handleiding zou super zijn, maar misschien is er iemand die al weet waar alle knopjes voor dienen.

Foto:

[Ibex]

Pfffffrt, ik kom er niet meer uit met een atmega8 projectje, en ik hoop dat iemand mij een handje op weg kan helpen. Laat ik de situatie even uitleggen:

Ik heb onderstaand stukje code die 64 bits moet inklokken vanuit 8 shiftregisters.

C:

uint8_t shift_byte_in(void)
{
    uint8_t loadedbyte = 0; 
    for (uint8_t i = 0; i < 8; i++)
    {
        IN_PORT &= ~(1 << IN_CLK);
        IN_PORT |= (1 << IN_CLK);
        if (IN_PIN & (1 << IN_SER))
        {
            loadedbyte |= (1 << i);
        }       
        IN_PORT &= ~(1 << IN_CLK);
    }
    return loadedbyte;
}
uint64_t shift_int64_in(void)
{
    uint64_t byte;
    uint64_t int64 = 0;
    for (uint8_t i = 0; i < 8; i++)
    {
        byte = 0 | shift_byte_in();
        int64 |= byte << (i * 8);
    }
    return int64;
}

Daarna krijg ik een waarde terug (normaal de 64 bit vanuit de shiftregisters). Van dit getal zou er eentje op "1" moeten staan, de rest op "0". Ik bereken de positie van deze "1" met volgende code:

C:

uint8_t calculate_button_address(uint64_t button)
{
    uint8_t buttonaddress = 0;
    for (uint8_t i = 0; i < 64; i++)
    {
        if (button & (1 << i))
        {
            break;
        }
        buttonaddress++;
    }
    return buttonaddress;
}

Aan elkaar geknoopt door volgende code (snippet):

C:

uint64_t inputs = shift_int64_in();
if (inputs)
{
    uint8_t buttonaddress = calculate_button_address(inputs);

Het probleem is echter dat dit adres perfect werkt voor de eerste 16 locaties (0x00 t.e.m. 0x0F), maar bij de volgende 48 loopt het mis; er blijft dan 0x0F uit de calculate_button_address komen. Iemand een idee waarom?

Edit; hardwaregewijs lijkt alles in orde; als ik bijvoorbeeld input 0x13 indruk, is ook enkel zijn input op het shiftregister hoog, en zeker niet die op locatie 0x0F.

[Voor 5% gewijzigd door Ibex op 17-12-2011 22:55]

[Ibex]

Sprite_tm schreef op zondag 18 december 2011 @ 10:20:
Mijn gok is dat je (1<<i) geinterpreteerd word als een int, waardoor de 1 er bij waardes boven 16 uitvalt. Je zou ((uint64_t)1<<i) oid kunnen proberen. Ik kan daar niet meteen mee verklaren waarom er 0xf uit blijft komen en niet 0x40 tho'.

Ik zie ook niet direct een verklaring waarom dit de oorzaak zou zijn, maar het is wel een potentiele bug. Even testen dus .

Wirf schreef op zondag 18 december 2011 @ 11:48:
[...]

code:

    for (uint8_t i = 0; i < 8; i++)
    {
        IN_PORT &= ~(1 << IN_CLK);
[...]
        IN_PORT &= ~(1 << IN_CLK);
[...]
      }

Misschien is dat hierom? Dat je in de loop, die 8 keer uitgevoerd wordt, twee keer "IN_PORT &= ~(1 << IN_CLK);" doet?
edit: Wat doen IN_PORT, IN_CLK, IN_PIN en IN_SER eigenlijk?

IN_PORT is gewoon een alias van PORTD, IN_PIN van PIND. IN_CLK en IN_SER zijn alias voor resp.PD6 en PIND5 waarop de shiftregisters zijn aangesloten. Ik doe het twee keer aan het begin en het einde om ervoor te zorgen dat het steeds juist staat.

[Ibex]

Sprite_tm schreef op zondag 18 december 2011 @ 10:20:
Mijn gok is dat je (1<<i) geinterpreteerd word als een int, waardoor de 1 er bij waardes boven 16 uitvalt. Je zou ((uint64_t)1<<i) oid kunnen proberen. Ik kan daar niet meteen mee verklaren waarom er 0xf uit blijft komen en niet 0x40 tho'.

Dit was het dus effectief. Thanks