De EL-kroeg - Deel 3

[LED-Maniak]

ThinkPadd schreef op donderdag 27 mei 2010 @ 20:08:
Heb een HD44780 LCDtje gekocht om aan m'n Atom servertje hangen via LPT, maar het lukt me voor geen meter.

Eerste LCD wat ik had heb ik gesloopt perongeluk, door + en - om te draaien. Njaa Dick was zo aardig om een nieuwe op te sturen, maar daarmee lukt het ook niet.

Als ik alleen de voeding + contrast potmeter aansluit zie ik dit:
[afbeelding]

Als potmeter gebruik ik een 4K potmeter, had zo snel geen andere liggen. Moet kunnen toch die potmeter? Heb ook al geprobeerd de contrast draad rechtstreeks aan + of - te hangen maar dat helpt ook niks.

Aan de computer doet hij helemaal niks, maar volgens mij klopt dit al niet

Die is stuk ja .
je hoort bovenaan een balk te zien en onderaan niets.

[mux]

Neehoor, die werkt gewoon. Je initialisatie gaat goed maar daarna ben je verkeerde dingen naar het scherm aan het schrijven. Grote kans dat je datapins verkeerd hebt gewired.

Ik had laatst EXACT hetzelfde op mijn dc/dc converterprojectje - ik had het bijna op GoT gepost toen ik erachter kwam wat het probleem was.

[Sprite_tm]

ssj3gohan: Volgens de post is dat plaatje gemaakt zonder dat er ook maar iets heengeschreven is. Stuk dusch.

[mux]

oh...

[almightyarjen]

ThinkPadd schreef op donderdag 27 mei 2010 @ 20:08:
HD44780 LCDtje

[afbeelding]

Maar, hangt er niet een draadje te weinig aan? Ik tel 5 draadjes, dit zouden er toch minimaal 6 moeten zijn?
D4 t/m D7
En
RS

[Verwijderd]

Dat plaatje is gemaakt van een lcd waar welliswaar wel 5 draadjes aan hangen maar op slechts drie pinnen ... er wordt geen enkele data gestuurd, geen initialisatie whatever. Volgens mij zegt het plaatje dus geen fl*kker ... Als ik benzine in een auto gooi gaat 'ie (gelukkig) ook niet vanzelf rijden, daar zijn wat meer handelingen voor nodig.

[ThinkPad]

Ik heb niks qua data er aan hangen, alleen spanning (5V), GND en contrast, meer niet.

En volgens mij zou hij dan al moeten initialiseren (rij met zwarte blokjes)

[almightyarjen]

ThinkPadd schreef op vrijdag 28 mei 2010 @ 08:55:
Ik heb niks qua data er aan hangen, alleen spanning (5V), GND en contrast, meer niet.

En volgens mij zou hij dan al moeten initialiseren (rij met zwarte blokjes)

Volgens mij moet je dan nog iets doen met RS voordat hij die blokjes aangeeft...

[Sprite_tm]

Nope, dat doen de LCDs vaak meteen al. Wat ze in ieder geval nooit doen als ze niet stuk zijn is dat rare streepjespatroon geven: het enige werkende alternatief is namelijk dat het LCD helemaal blank blijft.

[mux]

Nou, die streepjes zijn bij hd44780 de bargraph mode. Het komt wel eens voor dat er troep op de E-lijn zit waardoor hij noise (bijv. buttons) als data ziet en plots in die mode schiet. Alle karakters die je daarna verstuurt worden rare streepjespatronen precies zoals dat daar.

Je kunt dus nog overwegen om alle andere pinnen aan GND te hangen en dan voeding+contrast eraan hangen...

[Sprite_tm]

De wat-mode? Ik heb in mijn leven de datasheet van die chip al vaak gezien, maar ik heb nog geen bargraph-mode gezien. Kan je vertellen op welke pagina van de specs van 't ding dat staat?

Verder zou het aan de ground hangen van de E genoeg moeten zijn om wat voor troep dan ook op het display te voorkomen. Ik blijf er echter bij: dit display is met 99.999% zekerheid dood te verklaren.

[ Voor 35% gewijzigd door Sprite_tm op 28-05-2010 10:54 ]

[mux]

ah, dat is blijkbaar unieke functionaliteit van mijn hd44780-compatible-maar-toch-niet-helemaal-scherm... Die heeft een ingebouwde bargraph mode...

Daar schiet je automagisch in als je verkeerd initialiseert (bij mij gebeurde het doordat ik na het zeggen dat ik in 4-bit mode zat, vergat om een keer een word te verzenden). Maargoed, het probleem van TP lijkt er zo erg op dat ik eraan moest denken.

[LED-Maniak]

Omdat ik graag uitdagingen zoek, hier weer een projectje van mij:




Dit is een ontvanger voor de philips living colors zodat je gewone LED-Strips ook samen kan aansturen met de philips afstandsbediening en de lampen zelf.

Het bevat 0402 weerstanden en condensatoren.
Nuttig? Nee. Leuk, leerzaam? Zeer zeker!

[Megamind]

Zijn er mensen die al een Chronos 433Mhz watch hebben van TI? Ik had 'm 1 december 2009 besteld, kreeg nu weer een bericht dat het op zijn vroegst eind augustus verstuurd zou worden!

[almightyarjen]

LED-Maniak schreef op vrijdag 28 mei 2010 @ 17:18:
Omdat ik graag uitdagingen zoek, hier weer een projectje van mij:

[afbeelding]
[afbeelding]

Dit is een ontvanger voor de philips living colors zodat je gewone LED-Strips ook samen kan aansturen met de philips afstandsbediening en de lampen zelf.

Het bevat 0402 weerstanden en condensatoren.
Nuttig? Nee. Leuk, leerzaam? Zeer zeker!

Leuk! Ik probeer dat gepriegel met SMD's altijd te vermijden...

[mux]

Oeh, dat wil ik ook! 1206 en 0402 naast elkaar

[0fbe]

Ik heb nu toch iets raars

Ik heb een PIC18F4520 die vrij vol zit met C18 gecompileerde C-code. Hij compileert zonder enige problemen. Alleen als ik hem run doen de PORTB poorten heel iets anders dan hij zou moeten doen. Hoe in godsnaam kan zoiets?

[DaWaN]

simplendi schreef op zaterdag 29 mei 2010 @ 23:07:
Ik heb nu toch iets raars

Ik heb een PIC18F4520 die vrij vol zit met C18 gecompileerde C-code. Hij compileert zonder enige problemen. Alleen als ik hem run doen de PORTB poorten heel iets anders dan hij zou moeten doen. Hoe in godsnaam kan zoiets?

Stack overflow ? Ik weet niet of zo'n PIC18 veel verschilt van een PIC16 maar een PIC16 heeft maar 16 stackposities en daar ga je retesnel overheen

[almightyarjen]

simplendi schreef op zaterdag 29 mei 2010 @ 23:07:
Ik heb nu toch iets raars

Ik heb een PIC18F4520 die vrij vol zit met C18 gecompileerde C-code. Hij compileert zonder enige problemen. Alleen als ik hem run doen de PORTB poorten heel iets anders dan hij zou moeten doen. Hoe in godsnaam kan zoiets?

Instelling van je programmer? Een soort gelijk probleem heb ik ook een keer gehad: compileren en uploaden naar een 18F ging goed, vervolgens deed het programma niet wat het moest doen (ook met portA en portB). Het bleek dat de programmer niet geschikt was voor 18F-controllers. Maar er was geen warning hierover gegenereerd...

[LED-Maniak]

ssj3gohan schreef op vrijdag 28 mei 2010 @ 17:54:
Oeh, dat wil ik ook! 1206 en 0402 naast elkaar

Jaja, erg leuk! Totdat je natuurlijk 10Volt rated tantaal op de plek zet waar hij 12Volt voor de kiezen krijgt(wie gebruikt er nog tantaal tegenwoordig...).

Het resultaat was vonken, een knal en nog meer brand. Hopelijk doet de rest het nog:

[mux]

Tantaal is eigenlijk zonde om nog te gebruiken, het enige voordeel boven keramisch is dat het net iets meer capaciteit heeft in dezelfde case style, en niet nog maar 20-50% van z'n capaciteit over heeft op rated voltage. Maar de nadelen zijn veel groter: weinig marge, kan niet tegen hoge dV/dt (dus automagisch ongeschikt voor langzame of high-current dc/dc converters), heeft polariteit maar niet de bijbehorende echt hoge capaciteit van elektrolytisch spul, faalt katastrofaal...

Met het huidige aanbod van cheap X7R keramisch en low-ESR low-profile aluminium elektrolytisch, conductive polymer en proadlizers voor het echte high-performancegebied is tantaal echt iets van het verleden.

[M a r c o]

Heb pas anders nog tantaal gebruikt in een dc/dc voedingontwerp met een LM2673.
als je 2x 100u/10V nodig hebt is tantaal toch wat makkelijker te vinden, en goedkoper dan keramisch.
Bovendien was het zelfs de aanbevole keuze in de design guidelines van National Semiconductor.

Denk trouwens niet dat ze in dit ontwerp problemen zullen leveren.
Het zijn 10V uitvoeringen op de uitgang van een 12V->5V voeding waar secundair < 1A loopt.
Voeding heeft een ook een slowstart van enkele ms en een inrushcurrent limiter.

[mux]

Vaak raden ze tantaal aan omdat die een wat hogere impedantie hebben en dus makkelijker stabiel te houden zijn dan keramisch. Dat heeft dan helaas ook als effect dat je veel meer capaciteit nodig hebt, en nog beter moet ontkoppelen aan de applicatiezijde (hoewel dat altijd good practice is). Ik kies het liefst zowel LDOs als dc/dc convertertjes uit die goed met low-esr elektrolytisch danwel keramisch af kunnen.

Maarja, NI is wel een van de bedrijven die nog een hoop tantaal aanraadt, ook met hun PFM en hysteretische controllers. Tantaal is ook echt nog wel significant goedkoper dan bijvoorbeeld Taiyo Yuden high-capacitance X7R keramisch spul. Damn, je betaalt voor die 22/33/47uF keramische caps meer dan een euro per stuk!

[maikel]

maikel schreef op donderdag 27 mei 2010 @ 21:00:
[...]


Ik heb nu ook pin 10 van de ULN2803 maar aangesloten. Deze hangt nu aan +12V.

Het scheelt al een hoop: rood en groen gaan wel helemaal uit, alleen blauw blijft nog een klein beetje branden. Ik heb de scoop eraan gehangen en de uitgangen van de microcontroller lijken gewoon goed te functioneren. Het gaat dus mis na de ULN2803, lijkt het. Ik heb daarvan drie ingangen op de microcontroller aangesloten, de rest van de ingangen hangt aan GND. Blauw hangt aan pin 18. Volgens de scoop is die uitgang op geen enkel moment 12V, ik zie daar altijd iets wat op een opgaande flank lijkt. Daar komt ook verstoring in als ik een andere kleur ophoog.

Moeten overigens de GNDs allemaal aan elkaar hangen? De microcontroller krijgt zijn voeding uit de
USB->RS485-converter en dus uit een USB-poort, terwijl de LED-strip en ULN2803 hun voeding krijgen uit een labvoeding. Lijkt me haast wel, aangezien het anders niet lekker werkt. Maar ik blijf het toch spannend vinden om m'n labvoeding zomaar op een USB-poort aan te sluiten, ook al is het alleen de GND.

Iemand die hier nog antwoord op kan/wil geven?

[goeievraag]

Je hebt de grounds dus niet doorverbonden? Dan kan het idd gek gaan doen. Als je het te eng vindt om ze aan je usb-poort te hangen, kun je het ook gewoon ergens aan je kast doen, of de min van een molex-stekker, één pot nat .

Heb je ondertussen wél de massa aangesloten en nog steeds het probleem? Haal dan eens de µ-controller los van de ULN, en hang de ULN-input hard aan de min van de ULN. Licht er dan nog steeds iets op, dan heb je of iets verkeerd aangesloten, of je ziet een minieme lekstroom. In dit geval zou een weerstand parallel aan de led het probleem moeten oplossen. Probeer het eens met iets van 4.7k-10k, komt niet zo nauw.

[maikel]

Ik heb de GNDs inmiddels wel doorverbonden ja.

Zojuist heb ik even de uitgang van de PWM-timer los gehaald en toen ging blauw ook uit. Nu heb ik even in de datasheet zitten lezen en mogelijk is dit het probleem:
If the OCR2 is set equal to BOTTOM, the output will be a narrow spike for each MAX+1 timer clock cycle.

Dat treedt dus op in 'Fast PWM mode'. Misschien toch bij '0' de pin gewoon op 'input' zetten, dan moet het volgens mij opgelost zijn.

[edit]
Dat werkt dus wel, maar ik vind het wel een beetje een hack. Is er een nettere manier?

[ Voor 9% gewijzigd door maikel op 31-05-2010 23:27 ]

[Zjosh]

Meestal kan je dat probleem oplossen door de timer anders in te stellen. BOTTOM kan vast ook wel iets als UPPER zijn ofzo...

[Sibylle]

omfg, net f op breadbord deze schakeling gebouwd: http://www.deadbugprojects.com/project/moodlight (met 3 20mA ledjes).
Zie ik dat met handmatig door de kleurencirkel heengaan, de rode led niet wil faden maar gewoon aan/uit gaat. ff potmeter omdraaien: zelfde...hmmm
Rode led verwisselen met groene: zelfde, maar nu krijg ik de rode led niet meer uit?!!

rood = 1.8v
groen = 3.3v
rood+100Ohm+5v > 40mA....ATtiny2313 pinnetje naar de kloten

Hopelijk alleen dat pinnetje, de rest van de port lijkt het nog te doen. Morgen maar ff de code aanpassen en een aantekening maken, FU!

[maikel]

Ik ben nu weer iets verder, maar zit wederom met een probleempje.

C:

#define F_CPU 3686400
#include <stdlib.h>
#include <avr/io.h>
#include <avr/interrupt.h>
#include <inttypes.h>
#include <util/delay.h>
#include <string.h>

void blink(unsigned char c)
{
    PORTC = ((c != 'r') << PC0 | (c != 'g') << PC1 | (c != 'b') << PC2 | 0 << PC5);
    _delay_ms(100);
    PORTC = (1 << PC0 | 1 << PC1 | 1 << PC2 | 0 << PC5);
}

void SetR( int value )
{
    OCR1A = (2.55 * value);
}

void SetG( int value )
{
    OCR1B = (2.55 * value);
}

void SetB( int value )
{
    if (value > 0)
    {
        DDRB = (1 << PINB1) | (1 << PINB2) | (1 << PINB3);
        OCR2 = (2.55 * value);
    }
    else
    {
        DDRB = (1 << PINB1) | (1 << PINB2) | (0 << PINB3);
    }
}

int r;
int g;
int b;

void setColor(unsigned char c)
{
    PORTC = ((c != 'r') << PC0 | (c != 'g') << PC1 | (c != 'b') << PC2 | 0 << PC5);
}

/************************************************************************* 
    Initialise PWM-timers
**************************************************************************/ 
void PWM_Init()
{
    DDRB = (1 << PINB1) | (1 << PINB2) | (1 << PINB3);
    TCNT1 = 0x00;

    TCCR1A = (1 << FOC1A) | 
             (1 << FOC1B) | 
             (1 << COM1A1) | 
             (1 << COM1B1) | 
//           (1 << COM1A0) | 
//           (1 << COM1B0) | 
             (1 << WGM12) | 
             (1 << WGM10);
    TCCR1B = (1 << CS10);

    TCCR2 = (1 << FOC2) | (1 << COM21) | (1 << WGM20) | (1 << WGM21) | (1 << CS00);
}

/************************************************************************* 
    Enable RS485 transmissionin 
**************************************************************************/ 
inline void RS485_TE() 
{ 
    PORTD |= _BV(PD2); 
} 

/************************************************************************* 
    Enable RS485 reception 
**************************************************************************/ 
inline void RS485_RE() 
{ 
    PORTD &= ~_BV(PD2); 
} 


/************************************************************************* 
    Initialise serial port
**************************************************************************/ 

void USART_Init(int baudrate) 
{ 
    // Set baud rate 
    int rate = F_CPU/16/baudrate - 1;

    // Set baud rate
    UBRRH = (unsigned char)(rate>>8);
    UBRRL = (unsigned char)rate;

    // Set frame format to 8 data bits, no parity, 1 stop bit 
    UCSRC = (1 << URSEL) | (1 << UCSZ0) | (1 << UCSZ1);

    // Enable receiver and transmitter 
    UCSRB=(1<<RXCIE)|(1<<TXCIE)|(1<<RXEN)|(1<<TXEN);

    RS485_RE();
} 

void USART_Transmit( unsigned char data )
{
    //Wait for empty transmit buffer
    while ( !( UCSRA & (1<<UDRE)) )
    {
    }

    RS485_TE();

    // Put data into buffer, sends the data
    UDR = data;
}


void USART_SendString( char str[255] )
{
    int i = 0;
    while (i < 255 && str[i] != '\0')
    {
        USART_Transmit(str[i++]);
    }
}

/************************************************************************* 
    Serial interrupt, whenever we receive a byte we get an interrupt  
**************************************************************************/ 
ISR(USART_RXC_vect) 
{ 
    unsigned char color;
    color = UDR; // Fetch the recieved byte value into the variable "ByteReceived" 
    USART_Transmit( color ); // Echo back the received byte back to the computer 

    if (color == 'R' && r < 100)
    {
        r += 10;
    }
    if (color == 'r' && r > 0)
    {
        r -= 10;
    }

    if (color == 'G' && g < 100)
    {
        g += 10;
    }
    if (color == 'g' && g > 0)
    {
        g -= 10;
    }
    
    if (color == 'B' && b < 100)
    {
        b += 10;
    }
    if (color == 'b' && b > 0)
    {
        b -= 10;
    }
}

ISR(USART_TXC_vect)
{
        RS485_RE();
}

int rnd( int max )
{
    return rand() / (RAND_MAX / max + 1);
}

int main()
{
    r = 0;
    g = 0;
    b = 0;

    DDRC=0xff; // output port
    PORTC = (1 << PC0 | 1 << PC1 | 1 << PC2 | 0 << PC5);

    DDRD = (1<<PD0);

    PWM_Init();

    SetR(0);
    SetG(0);
    SetB(0);

    USART_Init(9600);

    //activate interrupts 
    sei();

    while (1)
    {
        SetR(r);
        SetG(g);
        SetB(b);
        _delay_ms(100);
    }
}

Het is dus de bedoeling dat ik vanaf de PC een teken stuur, waarmee een van de drie kleuren feller/minder fel wordt. Dat werkte nagenoeg perfect voordat ik de echo had toegevoegd. Nu de echo erin zit, lijkt het alsof niet elk teken dat ik stuur, goed aan komt: de RGB-LED reageert maar af en toe en ook de echo komt maar af en toe terug (dat gebeurt dan wel tegelijk).
Wat me opvalt is dat ik, naast de echo, ook heel vaak nullen binnen krijg op de PC. Wat zou hier de oorzaak van kunnen zijn? Het lijkt me dat het versturen van die nullen de ontvangst blokkeert of zo.

[LED-Maniak]

Shit, dat living colors is dus duidelijk tweewegscommunicatie. Ik heb een ontvanger gemaakt die op de kleuren van de afstandsbediening reageert. Instellen van de kleuren gaat op zich goed maar niet alle functies werken. Wat blijkt? Pas als ik een andere livingcolors lamp samen met de ontvanger aan zet kan ik gebruik maken van de verzadiging en dimfunctie .

Nu nog uitvogelen wat hij dan precies terug stuurt..

[mux]

maikel schreef op dinsdag 01 juni 2010 @ 01:39:

code:

void USART_Transmit( unsigned char data )
{
    //Wait for empty transmit buffer
    while ( !( UCSRA & (1<<UDRE)) )
    {
    }

    RS485_TE();

    // Put data into buffer, sends the data
    UDR = data;
}


void USART_SendString( char str[255] )
{
    int i = 0;
    while (i < 255 && str[i] != '\0')
    {
        USART_Transmit(str[i++]);
    }
}

/************************************************************************* 
    Serial interrupt, whenever we receive a byte we get an interrupt  
**************************************************************************/ 
ISR(USART_RXC_vect) 
{ 
    unsigned char color;
    color = UDR; // Fetch the recieved byte value into the variable "ByteReceived" 
    USART_Transmit( color ); // Echo back the received byte back to the computer 

    if (color == 'R' && r < 100)
    {
        r += 10;
    }
    if (color == 'r' && r > 0)
    {
        r -= 10;
    }

    if (color == 'G' && g < 100)
    {
        g += 10;
    }
    if (color == 'g' && g > 0)
    {
        g -= 10;
    }
    
    if (color == 'B' && b < 100)
    {
        b += 10;
    }
    if (color == 'b' && b > 0)
    {
        b -= 10;
    }
}

Raar, op het eerste gezicht zie ik niks mis. Een paar kleine dingetjes:
- je zou kunnen proberen in USART_Transmit nog een keer te forceren dat hij wacht tot de transmit buffer leeg is (zelfde while-loopje). Maar ik weet eigenlijk wel zeker dat dit geen zin heeft.
- SendString is een beetje vaag, dat zou ik met een pointer oplossen want nu dimension je in de stack een mega-super-duper-array die al je geheugen opslokt. Het kan veel makkelijker. lolcode:

code:

gooiallesweg StuurOnderbroek(persoonlijkheid * Onderbroek){
  terwijl(*Onderbroek) universeleserieleasynchroneontvangverzend_verzend(*Onderbroek++);
}

- Je ontvangt en verzendt direct achter elkaar in je receive-interrupt. Daar kan nog best eens de fout zitten. Je USART_TXC_vect is concurrent met USART_RXC_vect. AVRs hebben volgens mij (kijk het even na) maar één interrupt pointer, dus alles wat aangeroepen wordt tijdens interrupt A wordt gewoon niet uitgevoerd.
- Het is overzichtelijker om je ontvangen karakters in een switch statement te gooien. lolcode:

code:

  schakel(ontvangenPersoonlijkheid){
    zaak 'b': als(meuk) meuk; gakapot;
    zaak 'g': etc...
  }

[mace]

Als je echt epic wilt zijn schrijf je een compiler voor die lolcode van je.

[maikel]

Dat eerste puntje snap ik niet helemaal. In de USART_Transmit nogmaals hetzelfde while-loopje zetten? Of bedoel je dat die na de regel 'UDR = data;' moet komen of zo?

De 'SendString' gebruik ik op dit moment niet. BIj het opschonen van de code was ik die vergeten weg te halen en zoals jij 'm geeft, heb ik 'm inderdaad al vaker gezien. (maar dan wat minder leuk ) Dat C is toch weer even omschakelen als je normaal gesproken hele dagen in C# schrijft. Is er niet ergens een C# -> AVR-compiler?

En zou je je punt over die interrupt-pointers nog iets eenvoudiger kunnen uitleggen? Ik lees het nu als: als USART_TXC_vect wordt uitgevoerd, wordt USART_RXC_vest genegeerd.

Die switch zal ik inderdaad nog toevoegen.

[mux]

Volgens mij begrijp je het prima, alles wat je zegt is de correcte interpretatie. En nee, volgens mij is er geen gc#-implementatie voor AVRs... Zo erg is het niet om ook C en/of C++ te leren

Die interrupts: als één interrupt wordt gecalled, bezig is, en ondertussen een andere wordt gecalled negeert hij die tweede volgens mij, althans, ik kan me zoiets herinneren. Dat is een fundamenteel verschil met bijv. ARM7 die een vectored interrupt controller heeft, die interrupts achter elkaar zet in volgorde van prioriteit als er eentje wordt aangeroepen terwijl een andere nog loopt.

[maikel]

Ok, dat is inderdaad duidelijk. Iets dergelijk had ik volgens mij inderdaad ook al eens gelezen. Maar als ik dan de code even bekijk, lijkt het me sterk dat die 'TXC' al voorkomt als ie nog met 'RCX' bezig is. De echo is namelijk het laatste commando, dus zodra dat klaar is, is ie ook klaar met de interrupt-handler.

Een beetje C/C++ is wel te doen ja, maar straks wil ik wat meer data gaan sturen en moet ik met strings gaan werken. En pointers zijn eng!
Toch eens proberen of ik Visual C++ aan de praat krijg voor mijn code. C++ is al wat makkelijker dan C en al helemaal met Visual Studio.

[mace]

IMHO is C++ totale overkill voor zo'n klein embedded projectje.

[maikel]

Weet ik, maar het is wel gemakkelijk. En aangezien ik toch alleen maar AtMega8's heb liggen, is eventuele overhead ook niet zo'n punt.
En dit is slechts een beginnetje he, wie weet hoe gigantisch dit project uiteindelijk gaat worden.

[mux]

Wat is er makkelijker aan C++ dan C eigenlijk? IMO is C++ een heel pak moeilijker om volledig te begrijpen, C is lekker simpel... En er is helemaal niks wat VS toevoegt, het duurt alleen oneindig lang om op te starten. En C++ voegt voor MCUs eigenlijk geen bal toe...

Maar over je interrupts: in de RXC ga je wat transmitten, en daarna ga je nog zitten te klooien met een hoop (moeilijk!) branches. In de tijd dat de MCU dat aan het doen is, kan hij best de TXC interrupt willen afvuren, terwijl hij nog bezig is met RXC.

[maikel]

In Visual Studio gaat het mij voornamelijk om de IntelliSense, code completion, etc. Dat mis ik in AVR Studio.
En het objectgeorienteerde van C++ vind ik wel prettig, aangezien ik zo in C# ook werk. Zeker als het project groter gaat worden.

Ah, nu snap ik 't inderdaad van die RXC. Eigenlijk moet ik dus alleen die variabele vullen en daar in de main-loop iets mee doen in plaats van in de interrupt-handler. Ik zal dat vanavond eens gaan proberen.

[M a r c o]

zulke code moet je ook niet in een interupt handler uitvoeren.
Je kunt beter in een interupt handler een statusbit activeren,
waarmee in de mainloop een functie wordt uitgevoerd.

Edit: zoals je zelf nu zegt inderdaad.

Het is altijd beter om te voorkomen dat er uitgebreide code in een interupt komt te staan.

[ Voor 7% gewijzigd door M a r c o op 01-06-2010 10:36 ]

[maikel]

Ja, inderdaad. Maar dat is ook even wennen als je normaal gesproken webapplicatie bouwt. Dan is een regel code meer of minder geen probleem. Maar in dit geval kan het dus al teveel tijd kosten.

[mace]

Misschien dus juist goed om het een keer bare bones te houden en niet alles door je IDE laten voorkauwen.

[Verwijderd]

maikel schreef op dinsdag 01 juni 2010 @ 10:35:
In Visual Studio gaat het mij voornamelijk om de IntelliSense, code completion, etc. Dat mis ik in AVR Studio.

Gebruik dan Eclipse met avr-eclipse. VS

[Stoney3K]

M a r c o schreef op dinsdag 01 juni 2010 @ 10:35:
Het is altijd beter om te voorkomen dat er uitgebreide code in een interupt komt te staan.

Bekend probleem als je van de PC af komt en dus gewend bent om callbacks (in feite softwaregestuurde interrupts) te schrijven. Vooral Windows-programmeurs hebben er een handje in om hele lappen code in callbacks/interrupt-handlers te gooien.

Op een PC met een onderliggend OS en een kernel die dat weer netjes indeelt is dat meestal niet zo'n probleem, maar op een embedded platform waar elke CPU-cycle telt moet je daar wel op letten. Met lange interrupt-handlers krijg je ook bijvoorbeeld het probleem van re-entrantie, d.w.z. dat de interrupt opnieuw wordt aangeroepen terwijl de afhandeling nog bezig is.

Tip: Probeer voor je eerste projecten op AVR niet alles asynchroon te willen doen. De Windows API doet daar IMO in verhouding té makkelijk over, waardoor je erg slordig gaat programmeren.

[LED-Maniak]

Woohoo

De codes voor de afstandsbediening van een livingcolors lamp zijn natuurlijk al breeduit bekend. De codes van de lamp zelf zijn echter nergens te vinden en zonder die codes zijn de helft van de functies niet beschikbaar. Dus wat doe je? Lamp slopen!

Ik heb de codes gevonden die de afstandsbediening terug verwacht van de living colors lamp en nu kan ik dus ook mijn eigen led-strips laten reageren op de afstandsbediening waarbij 98% van de functies nu werken ipv <50% voorheen

[maikel]

Ik heb de code nu aangepast, maar het wil nog steeds niet echt werken.

C:

#define F_CPU 3686400
#include <stdlib.h>
#include <avr/io.h>
#include <avr/interrupt.h>
#include <inttypes.h>
#include <util/delay.h>
#include <string.h>


/************************************************************************* 
    Global variables
**************************************************************************/ 
char receivedByte;
int r;
int g;
int b;


/************************************************************************* 
    Functions
**************************************************************************/ 
void SetR( int value )
{
    OCR1A = (2.55 * value);
}

void SetG( int value )
{
    OCR1B = (2.55 * value);
}

void SetB( int value )
{
    if (value > 0)
    {
        DDRB = (1 << PINB1) | (1 << PINB2) | (1 << PINB3);
        OCR2 = (2.55 * value);
    }
    else
    {
        DDRB = (1 << PINB1) | (1 << PINB2) | (0 << PINB3);
    }
}

/************************************************************************* 
    Initialise PWM-timers
**************************************************************************/ 
void PWM_Init()
{
    DDRB = (1 << PINB1) | (1 << PINB2) | (1 << PINB3);
    TCNT1 = 0x00;

    TCCR1A = (1 << FOC1A) | 
             (1 << FOC1B) | 
             (1 << COM1A1) | 
             (1 << COM1B1) | 
//           (1 << COM1A0) | 
//           (1 << COM1B0) | 
             (1 << WGM12) | 
             (1 << WGM10);
    TCCR1B = (1 << CS10);

    TCCR2 = (1 << FOC2) | (1 << COM21) | (1 << WGM20) | (1 << WGM21) | (1 << CS00);
}

/************************************************************************* 
    Enable RS485 transmissionin 
**************************************************************************/ 
inline void RS485_TE() 
{ 
    PORTD |= _BV(PD2); 
} 

/************************************************************************* 
    Enable RS485 reception 
**************************************************************************/ 
inline void RS485_RE() 
{ 
    PORTD &= ~_BV(PD2); 
} 


/************************************************************************* 
    Initialise serial port
**************************************************************************/ 
void USART_Init(int baudrate) 
{ 
    // Set baud rate 
    int rate = F_CPU/16/baudrate - 1;

    // Set baud rate
    UBRRH = (unsigned char)(rate>>8);
    UBRRL = (unsigned char)rate;

    // Set frame format to 8 data bits, no parity, 1 stop bit 
    UCSRC = (1 << URSEL) | (1 << UCSZ0) | (1 << UCSZ1);

    // Enable receiver and transmitter 
    UCSRB=(1<<RXCIE)|(1<<TXCIE)|(1<<RXEN)|(1<<TXEN);

    RS485_RE();
} 

void USART_Transmit( unsigned char data )
{
    //Wait for empty transmit buffer
    while ( !( UCSRA & (1<<UDRE)) )
    {
    }

    RS485_TE();

    // Put data into buffer, sends the data
    UDR = data;
}

void SendString(char *str)
{
    while(*str)
    {
        USART_Transmit(*str++);
    }
}



/************************************************************************* 
    Interupts
**************************************************************************/ 
// Receive complete
ISR(USART_RXC_vect) 
{ 
    receivedByte = UDR; // Fetch the recieved byte value into the variable "receivedByte" 
}

// Transmit complete
ISR(USART_TXC_vect)
{
    RS485_RE();
}



int main()
{
    receivedByte = ' ';
    r = 0;
    g = 0;
    b = 0;

    DDRC=0xff; // output port
    PORTC = (1 << PC0 | 1 << PC1 | 1 << PC2 | 0 << PC5);

    DDRD = (1<<PD0);

    PWM_Init();

    SetR(0);
    SetG(0);
    SetB(0);

    USART_Init(9600);

    //activate interrupts 
    sei();

    SendString("Ready...");
    while (1)
    {
        if (receivedByte != ' ')
        {
            switch (receivedByte)
            {
                case 'R':
                {
                    if (r < 100) r += 10;
                    break;
                }
                case 'G':
                {
                    if (g < 100) g += 10;
                    break;
                }
                case 'B':
                {
                    if (b < 100) b += 10;
                    break;
                }
                case 'r':
                {
                    if (r > 0) r -= 10;
                    break;
                }
                case 'g':
                {
                    if (g > 0) g -= 10;
                    break;
                }
                case 'b':
                {
                    if (b > 0) b -= 10;
                    break;
                }
            }

            SetR(r);
            SetG(g);
            SetB(b);

            USART_Transmit( receivedByte ); // Echo back the received byte back to the computer 
            receivedByte = ' ';
        }
    }
}

De string 'Ready...' komt netjes binnen, maar daarna lijkt de microcontroller nergens meer op te reageren. Een enkele keer is het me wel gelukt een 'R' te sturen, de LED-strip is ook op rood gegaan en ik kreeg een 'R' terug. Maar dat alles was pas na een hele tijd na het verzenden.

Zie ik nog iets over het hoofd?

[jerbro]

Je zou de char receivedByte volatile kunnen maken

C:

volatile char receivedByte;

Volatile zorgt ervoor dat de compiler weet dat de variabele door 'externe oorzaken' kan veranderen. Het is op dit moment namelijk mogelijk dat het programma dat de compiler genereerd uit dit deel:

C:

    while (1)
    {
        if (receivedByte != ' ')
        {
            switch (receivedByte)
            {
                .....
            }
        }
    } 

in de microcontroller iets wordt als:

code:

-Haal de data uit geheugenadres van 'receiveddata' naar register 16 (R16)
:vergelijk
-Kijk of R16 gelijk is aan ' '
-Zo ja, ga naar :vergelijk
-Zo nee, Ga naar een deel van de code dat de switch voor zijn rekening neemt

Als de interrupt dan een wijziging maakt naar het geheugenadres van Receivedbyte zal dit niet in R16 terecht komen, en de if in de while-lus dus nooit resultaat opleveren.

[maikel]

Het lijkt nu wel iets beter te gaan inderdaad, maar helaas nog niet feilloos. Ik krijg nog steeds regelmatig nullen binnen en ook niet alles wat ik stuur, lijkt aan te komen.

Ik heb in de main-loop en de receivedByte-check ook een stukje staan die een LED even laat knipperen, zodat ik zie wanneer dat gedeelte wordt uitgevoerd en die knippert ook steeds wanneer ik de nullen binnen krijg. Het lijkt er dus op dat receivedByte geen spatie is.

[edit]
Ik heb die spatie voor receivedByte nu vervangen door 0x0 en dat lijkt beter te werken (al snap ik niet wat dat uit zou maken). Maar nog steeds lijkt niet elk teken aan te komen. Ik moet steeds enige tijd wachten om het volgende teken te kunnen sturen.

Ik heb nu ook de cases uitgebreid met:

C:

char buf[5] = "";
case 'R':
{
    if (r < 100) r += 10;
    itoa(r, buf, 10);
    SendString(strcat("Red increased to: ", buf));
    break;
}

Nu krijg ik dus ook de status van de gewijzigde kleur terug. Dat werkt wel, alleen wordt de zin elke keer verlengd met de nieuwe waarde. Dus:
- Red increased to: 10
- Red increased to: 1020
- Red increased to: 102030

Waarom is dat? Die buffer is niet groter en die string is geen variabele. (ik vrees nu al voor alle andere string-bewerkingen die ik nodig ga hebben )

[ Voor 50% gewijzigd door maikel op 01-06-2010 22:19 ]

[jerbro]

maikel schreef op dinsdag 01 juni 2010 @ 21:48:
[edit]
Ik heb die spatie voor receivedByte nu vervangen door 0x0 en dat lijkt beter te werken (al snap ik niet wat dat uit zou maken). Maar nog steeds lijkt niet elk teken aan te komen. Ik moet steeds enige tijd wachten om het volgende teken te kunnen sturen.

Iets anders dat het mogelijk kan zijn, op het moment dat je tekens stuurt zet je de RS485 converter op versturen. Op dat moment verstuurt de RS485 converter geen data naar de microcontroller, maar de RX pin wordt ook niet keihard hoog of laag gemaakt. Mogelijk wordt er een beetje ruis ontvangen, waardoor de microcontroller denkt een teken ontvangen te hebben (wat weer geecho'd wordt, enz)
Je zou eens kunnen proberen om het ontvangen op de microcontroller helemaal uit te schakelen zolang er verstuurd wordt.

[maikel]

Zoiets zou 't inderdaad wel kunnen zijn. Als ik met m'n vingers de draadjes tussen de RS485 en de microcontroller aan raak, komt er ook ineens een hoop data binnen. Wellicht moet ik daar nog wat componentjes toevoegen. Ik heb nu de uitgangen van de MAX485 direct aan de microcontroller hangen.

De enable/disable-code heb ik nu aangepast naar:

C:

/************************************************************************* 
    Enable RS485 transmissionin 
**************************************************************************/ 
inline void RS485_TE() 
{ 
    PORTD |= _BV(PD2); 
    UCSRB=(0<<RXCIE)|(1<<TXCIE)|(0<<RXEN)|(1<<TXEN);
} 

/************************************************************************* 
    Enable RS485 reception 
**************************************************************************/ 
inline void RS485_RE() 
{ 
    PORTD &= ~_BV(PD2); 
    UCSRB=(1<<RXCIE)|(0<<TXCIE)|(1<<RXEN)|(0<<TXEN);
} 

Maar het probleem is nog hetzelfde.

[mux]

Het is ook eigenlijk best vies om string functions te gebruiken in een 8-bit microcontroller. Ik heb al meermalen gehad dat sprintfjes e.d. een keiharde stack overflow veroorzaakten zonder dat je dat kon weten, net als strcats. De stack in een AVR is ook maar 16 bytes ofzo he.. En erachter zit werkgeheugen geplakt, dus als je echt ongeluk hebt loopt je stack over in nuttig geheugen en crasht en verbrandt alles.

[maikel]

Maar hoe kan ik dan het best iets van een communicatieprotocol implementeren? Gewoon via een vast aantal tekens? Dan weet ik in ieder geval zeker dat de stack niet overloopt.

[mux]

Je hoeft sowieso geen strcat te doen, je kunt gewoon meermalen een stukje string sturen.

Getallen zijn irritant, maar het heeft nut (performance-wise) om daar de moeilijke route te nemen: sprintf en aanverwante constructies zijn onnoemelijk traag, en zeker als je dat in een interrupt gooit gaan er baby's dood. Je kunt beter je getal hakselen:

code:

betrouwbaar meuk = een_of_ander_getal;

persoonlijkheid a = meuk / 10000;
verstuur_persoonlijkheid(a);
meuk -= (meuk / 10000) * 10000;

a = meuk / 1000;
verstuur_persoonlijkheid(a);
meuk -= (meuk / 1000) * 1000;

a = meuk / 100;
verstuur_persoonlijkheid(a);
meuk -= (meuk / 100) * 100;

a = meuk / 10;
verstuur_persoonlijkheid(a);
meuk -= (meuk / 10) * 10;

verstuur_persoonlijkheid((persoonlijkheid) meuk);

werkt voor elke unsigned int, kan evt. in een loopje gezet worden als je dat leuk vindt. Voor signed kun je zelf wel wat bedenken. Het is lelijke code, ik weet het, maar zodra je tegen allerlei vage resource-gerelateerde problemen aanloopt heeft het nut even helemaal terug te gaan naar de meest basic code. Pas als je hele programma bestaat uit simpele assignments en statements met minder dan 4 variabelen (=8 stack-bytes, plus genoeg buffer voor een register, extra instructies of ghosts) kun je echt een stack overflow of trage standaardfuncties uitsluiten.

Ik ben er trouwens helemaal niet zeker van dat een stack overflow je probleem is, dus zoek vooral zelf ook verder. Dit is maar een methode om van printfuncties af te komen. stdio/string hebben mij meer dan eens de das omgedaan, vandaar dat ik erover begin.

[Verwijderd]

even een vraagje ik wil beginnen met c programeren en een avr controller welke raden jullie aan, ik heb al een programmer voor de avr's

[maikel]

Ik heb destijds gewoon gekeken naar wat ik goedkoop op eBay kon krijgen. Dat waren in mijn geval Atmega8's, waarvan ik er een heel stel heb besteld. Voor kleine projectjes is het overkill, maar ze waren erg goedkoop toen. En je kunt er later natuurlijk grotere projecten mee maken.

AVR heeft zelf AVR Studio ter download op de site staan. Het is best een aardige interface die ook een aantal programmers ondersteunt.

[Mr_gadget]

Ik heb hier nog een oude crt tv staan die heel erg sneeuwt. Iemand ervaring met het repareren van tv's? Ik heb wel even zitten kijken maar zaten geen bolle condensatoren e.d. op de printplaat. Is dit nog te verhelen of kan ik beter voor een externe tuner gaan (er zit een keer scart op )
Het tv signaal hier in de flat schijnt ook wel zwakt te zijn.

[Verwijderd]

Mr_gadget schreef op donderdag 03 juni 2010 @ 19:20:
Ik heb hier nog een oude crt tv staan die heel erg sneeuwt. Iemand ervaring met het repareren van tv's? Ik heb wel even zitten kijken maar zaten geen bolle condensatoren e.d. op de printplaat. Is dit nog te verhelen of kan ik beter voor een externe tuner gaan (er zit een keer scart op )
Het tv signaal hier in de flat schijnt ook wel zwakt te zijn.

Dat te zwak signaal zal waarschijnlijk wel de oorzaak van je ruis zijn. De kans bestaat dat met een andere tv hetzelfde probleem optreed. Misschien ergens een verzwakking in je kabel.

[Verwijderd]

ssj3gohan schreef op dinsdag 01 juni 2010 @ 09:41:
Die interrupts: als één interrupt wordt gecalled, bezig is, en ondertussen een andere wordt gecalled negeert hij die tweede volgens mij, althans, ik kan me zoiets herinneren. Dat is een fundamenteel verschil met bijv. ARM7 die een vectored interrupt controller heeft, die interrupts achter elkaar zet in volgorde van prioriteit als er eentje wordt aangeroepen terwijl een andere nog loopt.

SEI/ CLI, zie: https://docs.google.com/v...0jdvWOGDTA5Pd9xosPXW1Ni6A

echter, volgens mij negeer je daarmee simpelweg de interrupt lijn, op het moment dat je dan je interrupts, aan het einde van je ISR, weer aan zet....
schiet niet op, daarom moet je aan het einde van je interrupt altijd de interrupt lijn resetten (OUT naar de juiste poort), althans, zo werkt het op de Z80 (8 bit CPU van onder andere de gameboy en ti-83+/84)

[DJSmiley]

Mr_gadget schreef op donderdag 03 juni 2010 @ 19:20:
Ik heb hier nog een oude crt tv staan die heel erg sneeuwt. Iemand ervaring met het repareren van tv's? Ik heb wel even zitten kijken maar zaten geen bolle condensatoren e.d. op de printplaat. Is dit nog te verhelen of kan ik beter voor een externe tuner gaan (er zit een keer scart op )
Het tv signaal hier in de flat schijnt ook wel zwakt te zijn.

Je kabelaar bellen? Volgens mij hoor je iets van 75 dbuv op je AOP te hebben. Als je dat niet haalt moet je kabelaar het fixen, en als dat wel goed is zul je met versterkers aan de haal.

Wel eerst uitsluiten of die tv zelf niet het issue is, niet elke tv heeft dezelfde gevoeligheid op de tuner. Uiteraard kan ie ook gewoon stuk zijn. Repareren... mjah, een andere crt halen op marktplaats is sneller dan moeite stoppen in zo'n ding

[LED-Maniak]

Verwijderd schreef op donderdag 03 juni 2010 @ 20:14:
[...]


SEI/ CLI, zie: https://docs.google.com/v...0jdvWOGDTA5Pd9xosPXW1Ni6A

echter, volgens mij negeer je daarmee simpelweg de interrupt lijn, op het moment dat je dan je interrupts, aan het einde van je ISR, weer aan zet....
schiet niet op, daarom moet je aan het einde van je interrupt altijd de interrupt lijn resetten (OUT naar de juiste poort), althans, zo werkt het op de Z80 (8 bit CPU van onder andere de gameboy en ti-83+/84)

Als er bij een AVR een interrupt wordt getriggert en uitgevoerd en er komt een andere dan blijft de interrupt flag staan. Vervolgens is na het afhandelen van de huidige interrupt de volgende aan de beurt.

Dit gaat overigens niet op volgorde van binnenkomst maar op volgorde van waar de vector zit.

[Sibylle]

LED-Maniak schreef op donderdag 03 juni 2010 @ 20:35:
[...]

Als er bij een AVR een interrupt wordt getriggert en uitgevoerd en er komt een andere dan blijft de interrupt flag staan. Vervolgens is na het afhandelen van de huidige interrupt de volgende aan de beurt.

Dit gaat overigens niet op volgorde van binnenkomst maar op volgorde van waar de vector zit.

hangt f van de gebruikte code. SIGNAL() of ISR() negeren inkomende interrupts, en deze worden op volgorde van prioriteit afgehandeld nadat de macro klaar is. Bij INTERRUPT(), is het mogelijk de macro te 'interrupten'.

[LED-Maniak]

Dat kan je ook doen door(voor bijvoorbeeld timer 0): ISR(TIMER0_OVF_vect, ISR_NOBLOCK). Dan blokkeert hij geen andere interrupts.

[joopv]

Mr_gadget schreef op donderdag 03 juni 2010 @ 19:20:
Ik heb hier nog een oude crt tv staan die heel erg sneeuwt. ......Het tv signaal hier in de flat schijnt ook wel zwakt te zijn.

Als eerste test moet je de tv aansluiten direct op de wandcontactdoos waar je kabel de woning binnenkomt - het AOP Abbonnee-Overname-Punt. Met een korte en gegarandeerd goede kabel.

Hoe is het beeld dan? (controleer alle zenders).

[ThinkPad]

-

[ Voor 121% gewijzigd door ThinkPad op 05-06-2010 19:03 ]

[mux]

En gisteren hebben we weer goede voortgang geboekt met de li-ion lader/ontlader. Recap: 3-fase dc/dc converter die van 1 li-ion cel (3.6-4.25V) naar alles tussen de ~4 en 20V converteert, met een schermpje, knopjes en bluetooth.

We hebben Bluetooth werkend gekregen en mijn partner in crime heeft een VB6.0-progsel gemaakt dat laat zien wat de dc/dc converter ons vertelt. Ik ben vergeten een screenshot te maken, maar dat komt zsm wel. Het komt erop neer dat we via de computer kunnen zeggen hoeveel stroom en/of spanning hij moet gaan maken, en dan doet hij dat en geeft feedback over hoe warm hij is, wat de batterijspanning en uitgangsspanning is, uitgangsstroom en alle informatie die verder nog nodig is.

Performance is ook geweldig, uit een Kokam 8Ah 8C celletje kunnen we met gemak ~40-50W trekken, en dat met één fase (de andere fasen moeten nog gefikst worden). Zonder koeling wordt hij dan wel erg warm, dus we hebben een speciaal heatspreadertje gefreesd dat als interface voor een groter koelblok kan dienen.

Dus, nu nog de andere fasen laten werken, automatisch fasen aan- en uitschakelen, de control loop verbeteren (hij wil nog wel eens over de zeik gaan met een sterk inductieve belasting) en dan hebben we spoedig een portable 150W labvoeding die je met je computer, pda of telefoon kunt bedienen

(we hebben gemerkt dat bluetooth zodanig veel makkelijker is dan een schermpje+knopjes dat de volgende versie gewoon helemaal geen schermpje meer krijgt).

edit: en we zijn live...

[ Voor 3% gewijzigd door mux op 06-06-2010 19:53 ]

[mace]

Kent iemand nog een beetje een leuke elektronica/hacking blog? Zoals Hack a day?

Ik vind Hack a day tegenwoordig namelijk behoorlijk in kwaliteit achteruit gegaan.
(uitgezonderd als Sprite er weer eens opstaat hé! )

[ Voor 14% gewijzigd door mace op 06-06-2010 16:13 ]

[Infant]

mace schreef op zondag 06 juni 2010 @ 16:13:
Kent iemand nog een beetje een leuke elektronica/hacking blog? Zoals Hack a day?

Ik vind Hack a day tegenwoordig namelijk behoorlijk in kwaliteit achteruit gegaan.
(uitgezonderd als Sprite er weer eens opstaat hé! )

Hackedgadgets is altijd wel grappig...

[Sprite_tm]

http://www.uelectronics.info/ is ook wel leuk, maar updatet niet echt enorm vaak.

[Atlas]

Stomme vraag: ik heb volgens mij *ooit ergens* gelezen dat een LED ook als LDR ge/misbruikt kan worden. Ik kan dit nergens terug vinden. Loop ik te ijlen of kan het echt?

[LED-Maniak]

Dat kan echt
Hij word dan dacht ik als 'condensator' gebruikt en de tijd wordt gemeten dat het duurt voordat de LED opgeladen is.

[ Voor 18% gewijzigd door LED-Maniak op 08-06-2010 00:22 ]

[ThinkPad]

Heeft mister Sprite dat niet eens gedaan ?

[Sprite_tm]

Yep.
Hmm, misschien moet ik mijn site eens her-inrichten: als ik zelf ook al moeite heb met zaken terug te vinden heb ik misschien teveel artikels voor de oorspronkelijke indeling...

[LED-Maniak]

Oke, even een vraagje voor de mensen met wat ervaring betreft CE en electronica:

Stel dat ik een PWM Dimmer maak met een fet als open collector geschakeld waarbij de led's dus tussen de +12Volt zitten en de fet. Moet ik dit dan beveiligen tegen kortsluiting en overcurrent?

Wat gebeurt er bijvoorbeeld met een fet waar teveel stroom door loopt, vliegt dat spontaan in de fik(rook heb ik er al eens uit zien komen.. vuur nog niet) of kan ik er van uit gaan dat die poort dan gewoon stuk gaat en klaar?

Ik weet dat je voor de CE richtlijn je apparaat brandveilig moet maken. Maar tot hoe ver moet ik doorgaan? poly-/multifuses bij elke poort?

Een temperatuur sensor wil ik sowieso op de print plaatsen om dat in de gaten te houden.

[mux]

Het is heel simpel; je moet de CE richtlijnen doorlezen! Maar, CE heeft eigenlijk weinig nut. Het enige wat CE zegt is dat je het op de europese markt mag verkopen. Wat jij wilt is een apparaat dat aan de relevante brand- en vochteisen voldoet. Je zult zelf daarvan de ISO normen moeten opzoeken, bijvoorbeeld door de ISO normen van een 'gewone' dimmer eens op te zoeken.

Waar en hoeveel je moet zekeren en in hoeverre je brandveiligheid moet bewijzen ligt helemaal aan je ontwerp en de normen die je hanteert.

[mace]

Infant schreef op maandag 07 juni 2010 @ 11:20:
Hackedgadgets is altijd wel grappig...

Sprite_tm schreef op maandag 07 juni 2010 @ 13:24:
http://www.uelectronics.info/ is ook wel leuk, maar updatet niet echt enorm vaak.

Thanks, ik zal ze eens checken.

Hackaday vind ik echt stukken minder de laatste tijd, veel simpele dingen, en het commentaar wat ze erbij schrijven is vaak ook echt suf.

Ben ik de enige die er zo over denkt?

[mux]

Sprite_tm schreef op maandag 07 juni 2010 @ 13:24:
http://www.uelectronics.info/ is ook wel leuk, maar updatet niet echt enorm vaak.

Held! Via een link kwam ik op dit type scherm:

http://www.vandijkenelekt...ies_id=23&products_id=125

Grafisch 122x32, monochroom, SED1520, 1 euro!

Dat is weer net zo'n typische aanbieding als de Baco-led-matrices Daar worden er een paar van besteld voor de voorraad...

[Sprite_tm]

Volgens mij is dat omdat ze de kwantiteit flink opgevoerd hebben een tijdje terug. Er komt nu wel veel meer langs dan 1 post per dag, maar de spoeling is d'r ook dunner door geworden.

[mace]

Ja dat is ook wel zo, alleen vind ik het commentaar wat ze er op geven ook vaak zo duf. Van die gigantisch voor de hand liggende dingen.

[mux]

Veel projecten zijn ook redelijk 'standaard': arduino/andere devboar-frutsels en het ontzettend afgezaagde 'he laten we een microcontroller iets doen wat 40 jaar geleden ook al kon'. Maar er zitten ook leuke dingen tussen, zoals een aardige universele FAT-implementatie enzo.

[lemming_nl]

Vraagje, ik heb een elektromotor. Deze motor bevat 2 condensatoren, 20uF en 180uF. Een loop en start condensator. De 20uF condensator is gemaakt voor 400V~, de 180uF voor 120V~. Is dit gebruikelijk? Kan hier weinig informatie over vinden. Mij lijkt dat die 120V~ condensator kapot gaat. Maar deze motor heeft wel gedraait op 230V (in een apparaat welke ik niet heb). Lijkt me sterk dat er al die tijd een verkeerde condensator in heeft gezeten?

Verder vroeg ik mij af of het gebruikelijk is om voor 115V een extra winding parallel te gebruiken welke niet (elektrisch) aangesloten is op de andere windingen (en dus ook geen condensatoren bevat). De motor bevat namelijk 2 motor windingen. De ene bevat condensatoren terwijl de andere helemaal los hangt. Deze is niet elektrisch verbonden met de andere.

[ Voor 29% gewijzigd door lemming_nl op 08-06-2010 19:40 ]

[Stoney3K]

Zo, maar eens even wat tests gedaan:



Philips TL-D hoogfrequent ballastje, 4 stuks voor 1 euro gescoord op eBay ... 2 tubes op 1 ballast, en 0-10V continu dimbaar (hier met labvoedinkje)

Straks worden deze gebruikt voor verlichting van mijn verlaagd plafond boven de bank. Dan heb ik er nog 2 over, die ga ik denk ik nog ombouwen tot mobiele armaturen (gestuurd met DMX512) voor filmopnames.

[goeievraag]

lemming_nl schreef op dinsdag 08 juni 2010 @ 17:54:
Vraagje, ik heb een elektromotor. Deze motor bevat 2 condensatoren, 20uF en 180uF. Een loop en start condensator. De 20uF condensator is gemaakt voor 400V~, de 180uF voor 120V~. Is dit gebruikelijk? Kan hier weinig informatie over vinden. Mij lijkt dat die 120V~ condensator kapot gaat. Maar deze motor heeft wel gedraait op 230V (in een apparaat welke ik niet heb). Lijkt me sterk dat er al die tijd een verkeerde condensator in heeft gezeten?

Verder vroeg ik mij af of het gebruikelijk is om voor 115V een extra winding parallel te gebruiken welke niet (elektrisch) aangesloten is op de andere windingen (en dus ook geen condensatoren bevat). De motor bevat namelijk 2 motor windingen. De ene bevat condensatoren terwijl de andere helemaal los hangt. Deze is niet elektrisch verbonden met de andere.

De condensators staan in serie met de wikkelingen, ze krijgen daarom niet de volle netspanning over zich.

[Boudewijn]

Maar wat is dan de lol van een 400V C?

offtopic:
Staan die aanloop condensatoren niet vaak parallel aan een wikkeling?

[goeievraag]

Hoe groter de condensator, hij kleiner de impedantie. De kleinere condensator krijgt hier de meeste spanning, daarom heeft deze een hogere werkspanning. (En misschien een stukje veiligheid, omdat deze permanent onder spanning staat)

Over het serie/parallel
Het doel van de condensators is om een fasedraaiing in de stroom te maken tussen twee wikkelingen. Hiervoor moet de condensator wel in serie staan.
Door deze fasedraaiing krijgt het magnetisch veld binnen de motor een draaiende component. Dit is een benadering van het ideale draaiende veld in een 3-fasenmotor. Zonder deze draaiende component krijg je een magneetveld dat op en afbouwt in één richting. In stilstand wekt dit geen koppel op.

[Boudewijn]

goeievraag schreef op zondag 13 juni 2010 @ 01:02:
Hoe groter de condensator, hij kleiner de impedantie. De kleinere condensator krijgt hier de meeste spanning, daarom heeft deze een hogere werkspanning. (En misschien een stukje veiligheid, omdat deze permanent onder spanning staat)

Hmmm juist ja. Makes sense .

Over het serie/parallel
Het doel van de condensators is om een fasedraaiing in de stroom te maken tussen twee wikkelingen. Hiervoor moet de condensator wel in serie staan.

Make sense too. Die denkstap heb ik gemist.

Door deze fasedraaiing krijgt het magnetisch veld binnen de motor een draaiende component. Dit is een benadering van het ideale draaiende veld in een 3-fasenmotor. Zonder deze draaiende component krijg je een magneetveld dat op en afbouwt in één richting. In stilstand wekt dit geen koppel op.

Jep dat wist ik .


Bedankt voor de uitleg .

[Boudewijn]

Even iets heel anders:


Ik weet dat een buienversterker kan gaan oscilleren, met alle gevolgen van dien.
Nu weet ik echter niet exact waardoor dat komt (terugkoppeling via de uitgangstrafo's richting buizen?).

Daarom mij nvraag: kan je een pre-amp (dus zonder UGTs) zonder belasting laten draaien? Bij een eindversterker heb je dan forse kans op schade, maar geldt dat ook voor een preamp?

[jeronimo]

Boudewijn schreef op zondag 13 juni 2010 @ 23:05:
Even iets heel anders:


Ik weet dat een buienversterker kan gaan oscilleren, met alle gevolgen van dien.
Nu weet ik echter niet exact waardoor dat komt (terugkoppeling via de uitgangstrafo's richting buizen?).

Daarom mijn vraag: kan je een pre-amp (dus zonder UGTs) zonder belasting laten draaien? Bij een eindversterker heb je dan forse kans op schade, maar geldt dat ook voor een preamp?

Het doorslaan van een onbelaste eindversterker komt door opslingeren van de primaire spanningen
op de UGT. Een preamp zonder UGT heeft daar geen last van en kan zonder probleem onbelast aangesloten worden. Alleen even in de gaten houden dat een DC pad voor een eventuele uitgangselco wel zo prettig is. Dat voorkomt knallen als je er een eindtrap aan hangt.

[Boudewijn]

Dank je voor de info .

[oddish2211]

ik heb al weer een hele tijd geleden zelf een FM transmitter in elkaar gezet, volledig overgenomen van een schema op internet. maar ik heb eigenlijk geen idee hoe zoiets werkt. ik snap hoe FM werkt, maar bijv. oscilators en dergelijke niet.

weet iemand misschien een boek, of een webpagina waar zat info op staat om dit te leren? ik wil dan bijv. leren hoe je een oscillator maakt en dan ook een stabiele. dus wat je bijv. kan doen om een stabiele & ruisvrije FM transmitter te maken. ik wil dus de hele theorie erachter weten ipv. klakkeloos iets overnemen en niet snappen waarom het wel/niet werkt.

ik heb zometeen ~8 weken vakantie, heb ik mooi weer een projectje om aan te werken

[ Voor 6% gewijzigd door oddish2211 op 14-06-2010 10:10 ]

[SA007]

Ik vond op e-bay ultracheap deze vfdtjes:

16 char, starburst, erg leuke dingen

Prijs inclusief shipping is ~3 euro per stuk.
Heb er 25 aangeschaft (indien intresse, DM maar ofzo), als ze op zijn koop ik er wel weer meer, verkoper heeft nog een flinke voorraad (alleen per 25 te kopen overigens).

Nu ben ik van plan om de meeste hiervan door te verkopen, met controller.
Nu is dankzijn Sprite_TM het aanturen van zo'n ding vrij simpel.
Alleen nu ben ik aan het twijfelen wat voor controller ik erop moet zetten.

- I²C: Zit in bijna alles, makkelijk af te tappen, makkelijk te adsressen, maar zonder kennis moeilijk te gebruiken.
- UART: Lastig met adressering, behalve op een µC niet direct aan sluiten, kan wel met een max485 makkelijk op lange afstand bedient worden.
- Raw data/clock: Laat de koper er maar een µC aan knopen die het display aanstuurt
- USB: Makkelijk voor een leek, verder eigenlijk alleen nadelen qua prijs, componenten, aansluitbaarheid op losse controllers etc.

Aangezien ik er de nodige ga verkopen vandaar een poll:
Poll: Welke aansturing
• I2C met 3-4 address pinnen
• UART
• Raw clock/data pinnen
• USB
• Anders (geef aan wat dan)
<sup>Tussenstand:

Ook een poll maken? Klik hier</sup>

[Megamind]

Een FTDI chip is niet duur, maar wel lastig om als amateur te verwerken maar voor een batch misschien erop laten plakken?

[SA007]

Een FTDI chip is wel nogal duur hoor, kost het dubbele van het hele display...

Daarnaast heeft usb als erg groot nadeel dat het niet voor andere doeleinden gebruikt kan worden dan aan een computer koppelen.
Daarnaast is I²C ook aan een computer te knopen op een paar dozijn locaties.

[NightOwlNL]

ik zat zelf te denken aan RS232, nog steeds een vrij common interface tenslotte
2nd best zijn voor mij i2c en usb eigenlijk

[Atlas]

Ik zou ook voor rs232 gaan. Is makkelijk ompoortbaar naar USB indien nodig

[DaWaN]

Wat had je dan als idee voor een controller ?
Een goedkope AVR kan alles (USB, I2C én UART)

[SA007]

DaWaN:
Komt idd een AVR op.
Alleen meerdere protocollen in 1 chip implementeren is best lastig.

I2C en UART zou nog wel lukken, daar niet van, maar ook USB erbij wordt nogal krap.
Daarnaast is het erg lastig om een software USB implementatie goed werkend te krijgen onder Windows (USB-CDC op USB1 is een hack, Direct USB heb je.libusb nodig wat neit werkt op 64 bit, USB-HID is erg leuk maar megaveel werk om goed werkend te krijgen)

[Sprite_tm]

Waarom niet allemaal idd? Sluit iig 1 pinnetje aan op een interrupt-lijntje en je kan alles dmv reflashen zelf omkatten.

[LED-Maniak]

pak een usb avr en je hebt het allemaal. at90usb162 bijvoorbeeld. 2,85 per stuk uit mijn hoofd en weinig extra onderdelen nodig. Dan heb je usb, uart, spi, i2c. Eitje

[madwizard]

SA007 schreef op maandag 14 juni 2010 @ 22:14:
(USB-CDC op USB1 is een hack, Direct USB heb je.libusb nodig wat neit werkt op 64 bit, USB-HID is erg leuk maar megaveel werk om goed werkend te krijgen)

Op XP,Vista en 7 heb je WinUSB, soort libusb maar dan van microsoft zelf, al gesigned en wel dus werkt ook op 64-bit zonder rare trucs. Heb er een tijdje terug een .NET wrapper voor geschreven (bestaan er wel meer overigens) en werkt prima.

[Verwijderd]

Er is een USB-I2C voorbeeld van V-USB (waarvoor de driver in de linux kernel is opgenomen). Die is gebaseerd op een tiny45 en hier dus niet handig (te weinig pootjes) maar dezelfde code op een grotere AVR moet kunnen. Gooi daar wat code bij voor i2c slave en rs232 en stem de aansturing op elkaar af zodat dezelfde functies gebruikt kunnen worden vanuit de verschillende protocollen. Eventueel selecteren van je interface via een jumper ... zou moeten kunnen?