Extreme Baybus: De HW is rond, nu de SW nog

[Verwijderd]

Op dinsdag 05 maart 2002 09:23 schreef SlinkingAnt het volgende:
Kun je niet iets met de geesteliljke vader van smartie regelen, dat er in smartie functies komen voor de baybus, ofdat smartie kijkt of het safe is om data te verzenden?

Ja wie weet... Smartie meet immers ook allerlei temperaturen... In principe zal het voor Smartie's vader niet zo heel complex zijn om een aantal temperaturen door te sturen via serieel voor de baybus... Configuratie enzo hoeft hij niet eens erin te maken, want wil je herconfiggen dan gooi je smartie ff uit, je runt het config proggie, je maakt aanpassingen en daarna gooi je het configproggie weer uit, smartie weer aan... klaar!

Maar inderdaad moet er wel bereidheid zijn aan de kant van Smartie's vader....

hoe dan ook, eerst die baybus maar eens aan de gang krijgen, dan is het vroeg zat om bij Smartie's pappa te gaan lobbyen

[Verwijderd]

Op dinsdag 05 maart 2002 09:37 schreef --EasY-- het volgende:

[..]

Maar inderdaad moet er wel bereidheid zijn aan de kant van Smartie's vader....

hoe dan ook, eerst die baybus maar eens aan de gang krijgen, dan is het vroeg zat om bij Smartie's pappa te gaan lobbyen

Das waar

Ik had nog ff gemaild naar iemand die meer verstand heeft van LCD'tjes dan ik (WarezHelp) en hij vond een LCD aangestuurd door een seriele poort geen goed idee.

Mailtje:
onderverstandig in 1 woord
LCD's zijn serieele zeer traag en veel electronica nodig,parallel is handiger
en directer
/Mailtje

[Verwijderd]

Op dinsdag 05 maart 2002 19:00 schreef NextGeneration het volgende:

[..]

Das waar

Ik had nog ff gemaild naar iemand die meer verstand heeft van LCD'tjes dan ik (WarezHelp) en hij vond een LCD aangestuurd door een seriele poort geen goed idee.

Mailtje:
onderverstandig in 1 woord
LCD's zijn serieele zeer traag en veel electronica nodig,parallel is handiger
en directer
/Mailtje

hahahaha sorry hoor maar die weet denk ik niet wat jij bedoeld hebt. Of heb je gezegd dat het om grafische displays gaat? Dan heeft hij nl. wel gelijk.

Want waarom is serieel traag? Vergeet niet dat het over een alfanumeriek display gaat he, dus als je 20 chars opstuurt staat je display bij 16x2 al vol. Op 9600 baud kun je 960 karakters per seconde versturen, op 115K2 baud kun je 1152 per seconde sturen. Dus reken maar uit hoe vaak per seconde je je display veranderen kan... zo snel kun jij niet lezen (niet een kijken!! )

En veel hardware... In principe JA. Maar aangezien ik toch al een AVR microcontroller met RS232 interface aan boord heb, kost het me aan extra hardware.... NIETS! Nou ja, 1 14/16 pins header voor de aansluiting van het LCD en 2 potmeters voor backlight en contrast. Als je die opties wil instelbaar wilt tenminste....

Juist daarom heb ik er ook een LCD display in bedacht, het kost alleen maar het LCD display zelf en geen andere extra electronica! anders had er nl. geeneens een display ingekomen...

Ik gebruik dergelijke displays al jaren met een eigenbouw seriele poort eraan... vandaar nu ook de keuze, de software heb ik voor 99% al liggen aangaande het display serieel aansturen...

[Verwijderd]

Vanwege alle vaagheden omrent de PWM sturing heb ik deze in een apart topic gezet: [topic=430091/1/50]

Dan kan deze draad weer on-topic: SOFTWARE FEATURES

[Verwijderd]

Kan je is heel simpel op een rijtje zetten wat er nu allemaal instelbaar is en wat er uittelezen valt.
Lijkt me makkelijk voor mij en de instappers in dit topic.

[Verwijderd]

Op dinsdag 05 maart 2002 23:19 schreef NextGeneration het volgende:
Kan je is heel simpel op een rijtje zetten wat er nu allemaal instelbaar is en wat er uittelezen valt.
Lijkt me makkelijk voor mij en de instappers in dit topic.

Uhm uit te lezen zijn fan toerentallen indien er een sensor aan de fan zit; tevens uit te lezen is de huidige PWM stand (handig bij autonome regleing van de module). Ook de tempsensoren en druktoets statussen zijn uit te lezen.

Verder kun je de gehele configuratie uitlezen en instellen. Hieronder vallen vele instellingen, onder andere minimale PWM voor elke fan, regeltype van de fan, tempertuurkrommen van de gebruikte sensoren, enz enz.

Het is nogal veelomvattend, en ik ben nog bezig om de instellingen op een rij te krijgen. Want WAT moet de software nu precies weten van een fan of sensor die aan de baybus hangt? Zowiezo moet voor elke temp sensor een serie "meetpunten" geprogrammeerd worden, zodat de unit weet bij welk gemeten voltage welke temperatuur hoort. Het configuratietool zal al een serie sensoren zelf in kunnen stellen, daarnaast moet je via custom settings eigen sensoren kunnen toevoegen.

Het is nog te vroeg om nu al een compleet beeld van ALLE instellingen te kunnen geven; op de site staat wel al het globale software document waarin al een paar registers staan (hoofdstuk 6 "configuratie in EEPROM"). Als voorbeeld de eerste:

PWM_OUTPUT_MODE: hierin bepaal je voor elke PWM uitgang wat voor soort hardware eraan hangt. Je kunt kiezen uit 0=disabled, 1=PWM output, 2=schakelcontact (b.v. relais).

Zo kun je de software in de baybus b.v. vertellen dat een output alleen mag schakelen, en niet PWM sturen. Is wel handig als je er een relais of buzzer aan vast hebt zitten

Dat is de confguratie van de hardware.

Zo zijn er ook nog instellingen, deze instellingen bepalen welke functionaliteit je wilt. Zo is er een register die bepaald wat er gebeuren moet als er alarm is. Welke uitgang moet bekrachtigd? Wat zijn de voorwaarden en temperaturen voor een alarm? Allemaal registers.

Al deze registers kunnen worden geconfigureerd. Er moet dus ook een goed config tool komen, die b.v. defaults kan instellen.

[Verwijderd]

Op woensdag 06 maart 2002 10:39 schreef --EasY-- het volgende:

[..]

Uhm uit te lezen zijn fan toerentallen indien er een sensor aan de fan zit; tevens uit te lezen is de huidige PWM stand (handig bij autonome regleing van de module). Ook de tempsensoren en druktoets statussen zijn uit te lezen.

Wat bedoel je nou precies met PWM?

Verder kun je de gehele configuratie uitlezen en instellen. Hieronder vallen vele instellingen, onder andere minimale PWM voor elke fan, regeltype van de fan, tempertuurkrommen van de gebruikte sensoren, enz enz.

Het is nogal veelomvattend, en ik ben nog bezig om de instellingen op een rij te krijgen. Want WAT moet de software nu precies weten van een fan of sensor die aan de baybus hangt? Zowiezo moet voor elke temp sensor een serie "meetpunten" geprogrammeerd worden, zodat de unit weet bij welk gemeten voltage welke temperatuur hoort. Het configuratietool zal al een serie sensoren zelf in kunnen stellen, daarnaast moet je via custom settings eigen sensoren kunnen toevoegen.

Dus gewoon het bereik v/d tempsensoren opgeven, lijkt me idd het makkelijkste (zie ook geen andere oplossing).

Het is nog te vroeg om nu al een compleet beeld van ALLE instellingen te kunnen geven; op de site staat wel al het globale software document waarin al een paar registers staan (hoofdstuk 6 "configuratie in EEPROM"). Als voorbeeld de eerste:

EEPROM is een soort CMOS dus.

PWM_OUTPUT_MODE: hierin bepaal je voor elke PWM uitgang wat voor soort hardware eraan hangt. Je kunt kiezen uit 0=disabled, 1=PWM output, 2=schakelcontact (b.v. relais).

Zo kun je de software in de baybus b.v. vertellen dat een output alleen mag schakelen, en niet PWM sturen. Is wel handig als je er een relais of buzzer aan vast hebt zitten

Dat is de confguratie van de hardware.

Zo zijn er ook nog instellingen, deze instellingen bepalen welke functionaliteit je wilt. Zo is er een register die bepaald wat er gebeuren moet als er alarm is. Welke uitgang moet bekrachtigd? Wat zijn de voorwaarden en temperaturen voor een alarm? Allemaal registers.

Al deze registers kunnen worden geconfigureerd. Er moet dus ook een goed config tool komen, die b.v. defaults kan instellen.

De defaults staan er natuurlijk al in als ie geleverd wordt, maar idd moet kunnen herstellen, en natuurlijk tot op zekere hoogte kunnen instellen.

[Verwijderd]

Op woensdag 06 maart 2002 19:33 schreef NextGeneration het volgende:

[..]

Wat bedoel je nou precies met PWM?

PWM = Pulse Width Modulation. Je stuurt hierbij de fan altijd met +12V aan, maar je schakelt heel snel (500-1000x per seconde) in en uit. Hoe langer je de ingeschakelde tijd maakt (des te korter wordt de uitgeschakelde tijd) en des te harder gaat je fan draaien. Dit noemen ze ook wel de "duty cycle": 0% = spanning altijd uit, 50% = fifty-fifty dus half vermogen, 100% = altijd aan = vol vermogen.

Dus gewoon het bereik v/d tempsensoren opgeven, lijkt me idd het makkelijkste (zie ook geen andere oplossing).

Ja, er komen ook nog enkele tussenliggende punten omdat veel sensoren een niet-lineair verloop tonen. Hierdoor kun je owel NTC als PTC sensoren gebruiken (de NTC verlaagd zijn weerstand als de temp. stijgt, de PTC juist andersom)

EEPROM is een soort CMOS dus.

PRECIES dat. Alleen voordeel is dat je geen extra batterijtje nodig hebt. Nadeel is dat je "maar" 100.000 x erin schrijven kan, en dat schrijven relatief langzaam gaat (enkele ms per byte).

De defaults staan er natuurlijk al in als ie geleverd wordt, maar idd moet kunnen herstellen, en natuurlijk tot op zekere hoogte kunnen instellen.

uhm ja zou kunnen. Het is ook heel simpel om via het config-tool ff "set defaults" te klikken

Daarna kun je modificeren wat je wil.... Er zijn zoveel opties dat ik goed moet nadenken over de indeling van alle instellingen.... Anders word het onoverzichtelijk. Sowieso een tabje met hardware config, eentje met FAN regeling, eentje voor de tempsensoren, een voor de LEDs en een voor het LCD.

[Verwijderd]

Op woensdag 06 maart 2002 20:20 schreef --EasY-- het volgende:
De NTC verlaagd zijn weerstand als de temp. stijgt, de PTC juist andersom.

Jah dat heb ik ook geleerd van m'n natuurkunde leraar .

PRECIES dat. Alleen voordeel is dat je geen extra batterijtje nodig hebt. Nadeel is dat je "maar" 100.000 x erin schrijven kan, en dat schrijven relatief langzaam gaat (enkele ms per byte).

Enkele ms per byte, lijkt me geen prob .

Daarna kun je modificeren wat je wil.... Er zijn zoveel opties dat ik goed moet nadenken over de indeling van alle instellingen.... Anders word het onoverzichtelijk. Sowieso een tabje met hardware config, eentje met FAN regeling, eentje voor de tempsensoren, een voor de LEDs en een voor het LCD.

Jah, natuurlijk, maar met 'tot op zekere hoogte kunnen instellen' bedoel ik dat je niet als streeftemperatuur 80 graden in kan stellen .

[Verwijderd]

Het is zover... Het hardware ontwerp is definitief!

Ik heb voor het prototype een combinatie gemaakt van 2 PWM fanregelingen: fan1 t/m fan3 worden "hard" PWM gestuurd via een mosFET in de grondlijn. Toerenmeting verloopt via het "1 fan op PWM 100%, rest op PWM 0%" oftewel het "RPM sensor sharing for PWM regulated fans" ofwel RPMSSFPWMRF-systeem(c) . De 4e fan heeft een p-channel mosFET in de +12V lijn en wordt via een LC netwerk tot een "echte" DC spanning omgezet die naar de fan gaat. Nadeel is dat als ik deze in viervoud heb, dat ik een multiplexer moet toevoegen voor de toerensensor selectie, en moet ik andere I/O opofferen (b.v. 6 LEDs ipv. of dubbel gaan gebruiken (b.v. LCD datalijnen ook gebruiken voor multiplexer selectie = wel vies )

Qua hardware kan ik beide aanpakken van fans besturen zo testen. De toerensensor van fan4 meet ik door fan1-3 op 0% PWM te schakelen tijdens de meting (volgens het RPMSSFPWMRF-systeem(c) ). De beste aanpak komt in viervoud op de definiteve PCB!

Omdat de MAX232 chips toch betaalbaar blijken als je goed zoekt, is de dicrete RS232 interface van de PCB verdwenen, en moet het MAX232 IC gebruikt worden (kost zo'n 2.70 euro ex btw). Voor de echte "no budget" freaks zit er nog wel een discreet gedeelte op voor "RX only" oftewel zonder MAX232 kun je daarmee wel serieel sturen maar niets terug ontvangen.

Voor verdere wensen op het hardwarevlak is het voor nu even te laat: Hopelijk ga ik dit weekend etsen...!!

[Verwijderd]

Op vrijdag 08 maart 2002 10:25 schreef --EasY-- het volgende:
Het is zover... Het hardware ontwerp is definitief!

Ik heb voor het prototype een combinatie gemaakt van 2 PWM fanregelingen: fan1 t/m fan3 worden "hard" PWM gestuurd via een mosFET in de grondlijn. Toerenmeting verloopt via het "1 fan op PWM 100%, rest op PWM 0%" oftewel het "RPM sensor sharing for PWM regulated fans" ofwel RPMSSFPWMRF-systeem(c) . De 4e fan heeft een p-channel mosFET in de +12V lijn en wordt via een LC netwerk tot een "echte" DC spanning omgezet die naar de fan gaat. Nadeel is dat als ik deze in viervoud heb, dat ik een multiplexer moet toevoegen voor de toerensensor selectie, en moet ik andere I/O opofferen (b.v. 6 LEDs ipv. of dubbel gaan gebruiken (b.v. LCD datalijnen ook gebruiken voor multiplexer selectie = wel vies )

Hmm, dat snap ik niet helemaal.
Er zijn dus nog wat probs met de toeren meten. Lijkt me de beste keuze om wat I/O'tjes op te offeren.

Qua hardware kan ik beide aanpakken van fans besturen zo testen. De toerensensor van fan4 meet ik door fan1-3 op 0% PWM te schakelen tijdens de meting (volgens het RPMSSFPWMRF-systeem(c) ). De beste aanpak komt in viervoud op de definiteve PCB!

Omdat de MAX232 chips toch betaalbaar blijken als je goed zoekt, is de dicrete RS232 interface van de PCB verdwenen, en moet het MAX232 IC gebruikt worden (kost zo'n 2.70 euro ex btw). Voor de echte "no budget" freaks zit er nog wel een discreet gedeelte op voor "RX only" oftewel zonder MAX232 kun je daarmee wel serieel sturen maar niets terug ontvangen.

Heb je al een grove schatting van de kosten?

[Verwijderd]

Op vrijdag 08 maart 2002 19:19 schreef NextGeneration het volgende:

Hmm, dat snap ik niet helemaal.
Er zijn dus nog wat probs met de toeren meten. Lijkt me de beste keuze om wat I/O'tjes op te offeren.

Weet ik niet... Beide systemen hebben voor en nadelen. De "mooie" DC gestuurde variant betekent een extra IC t.b.v toerenmeting nodig, en bovendien duurdere en "slechtere" p-channel FETs. Daarnast is er per kanaal een grote elco en een zeer zware spoel nodig. Kost allemaal geld, printformaat enz enz. EN I/O, de chip zit nu al "vol". Dus moeten er in dat geval features af of gaan delen. B.v. je mag de datalijnen op het LCD display veranderen zolang je niet clocked. Dus kun je die dubbel gebruiken, dus ook om de toereninput te selecteren die je meten wil. Maar dan moet de LCD module in sw dus geen data naar het LCD sturen als er toeren gemeten worden. Al met al ook geen fijne optie.

De 1e optie met de "koude" sturing bespaart al deze onderdelen. Mogelijke nadelen zijn "zoemende" fans wat wellicht te verhelpen is door de pwm frequentie aan te passen, en het toerenmeten is moeizamer in software te maken (maar daar voelt de tweaker nix van). Of het meten van toeren met deze optie nog effect voor het toerental van de fan zelf heeft (er moet immers getruukt worden met de PWM) moet ff bekeken worden.

Heb je al een grove schatting van de kosten?

uhm moeilijk. Ik denk:

Aan grut 5 euro
Aan max 232 een euro of 6 (met condensatoren eromheen)
Aan Atmel AVR controller een euro of 15
Aan PCB een euro of 10
Aan connectoren een euro of 12 (rs232 en printerpoort connector zijn de duurste)
Aan FETs zo'n 6 euro (4 stuks)
aan molexen en 3pins fan headers zo'n 18 euro (als je alles bestuckt)

totaal zo'n 72 euro, dit is excl. LCD display maar wel met alle opties er verder op.

Als je beknibbelen wil dan kun je denk ik ook wel voor 50 euro klaar zijn met een "slanke" versie.....

Als ik via een bedrijf kan kopen of een bedrijf die ik ken het kan regelen kan ik denk ik alle spullenvoor de helft krijgen, vooral bij grote aantallen!!! Maar dat is nog ff afw88....

Ik heb hier b.v. de Atmellen AT90S8535-8PC liggen die bij afname 100 stuks voor €6,02 per stuk de deur uitgaan
(bij Conrad kosten ze 12 euro ofzo)

[SlinkingAnt]

Wanneer denk je dat je klaar bent met de hardware en softwareontwikkeling? en voor welk OS wordt het gemaakt? XP lijkt me het beste omdat het denk het meest gebruikt gaat worden als het al niet zo is dan.

[Verwijderd]

Op vrijdag 08 maart 2002 20:16 schreef SlinkingAnt het volgende:
Wanneer denk je dat je klaar bent met de hardware en softwareontwikkeling? en voor welk OS wordt het gemaakt? XP lijkt me het beste omdat het denk het meest gebruikt gaat worden als het al niet zo is dan.

Uhm PCB wil ik met 1-2 weken wel up and running hebben. Voor de eerste (basis) versie embedded software moet je ook nog wel een week of 3 rekenenen. Dan nog een configtool... 1 week ofzo... De echte superdeluxe embedded software met volledige crystalfontz emulatie enz enz moet je rekenen op maanden programmeerwerk. Daarom eerst een "slanke" versie.

OS is windows, welke windows doet er niet echt toe, want dat is nou het mooie, de seriele poort is al superstandaard sinds windows 1.0

Dat werkt gewoon altijd wel

Ook op linux en dergelijke zou het geen probleem moeten zijn om config programma's te maken, omdat de seriele poort altijd simpel ondersteund wordt. Een bergje chars een seriele poort uitgooien als je een knopje drukt lukt altijd wel.

[Verwijderd]

Op vrijdag 08 maart 2002 20:33 schreef --EasY-- het volgende:

Uhm PCB wil ik met 1-2 weken wel up and running hebben. Voor de eerste (basis) versie embedded software moet je ook nog wel een week of 3 rekenenen. Dan nog een configtool... 1 week ofzo... De echte superdeluxe embedded software met volledige crystalfontz emulatie enz enz moet je rekenen op maanden programmeerwerk. Daarom eerst een "slanke" versie.

OS is windows, welke windows doet er niet echt toe, want dat is nou het mooie, de seriele poort is al superstandaard sinds windows 1.0

Idd, windows is (in dit geval) windows, en dat doet er voor de rest niet zo heel veel toe.

[Raafz0r]

Ik ben wat laat aan deze thread begonnen, dus het kan zijn dat ik niet alles perfect heb gevolgd, maar je had het een tijd terug over de temperatuurregeling. Hierbij had je het over een mechanisme om de fans zo bij te stellen dat de temperatuur op de aangegeven waarde blijft.

Jouw idee was om de fan 100% aan te zetten als er meer dan 10 graden verschil is tussen gemeten en ingestelde temperatuur.

Nou deed me dat vraagstuk denken aan wat we een tijd terug bij procestechnologie behandeld hebben. Daar gaat het er ook om dat je een proces telkens zo wilt bijstellen dmv correcties op de input dat de output binnen vastgestelde grenzen van een waarde blijft.

De (algemeen) beste manier hiervoor is via een zogenaamde PID-regelaar. PID staat voor Proportionele Integrerende differentierende actie.

De vergelijking die hierbij hoort is:


De variabelen hierin zijn (hierbij voor het hele verhaal het voorbeeld van een volstromende bak nemend, waarbij de uitvoer niet te regelen is, maar de invoer met behulp van een klep wel):

u= hoever moet de klep open (deze u is altijd begrensd, afhankelijk van de apparatuur)

u0 = verstelling van nulpunt: hoever moet de klep openstaan om het vloeistof niveau te krijgen en te houden(zonder storingen)

K = proportionele versterking, een constante waarde die ingesteld kan worden en bepaald hoe snel een storing gecorrigeerd wordt (denk ik, moet dit hele verhaal weer een beetje opdiepen)

e = verschil tussen gewenste waarde en meting (kan dus negatief zijn)

Ti= integratietijd (over welke tijd wordt er geintegreerd)

Td= differentiatietijd (over welke tijd wordt er gedifferentieerd)

Wat is nu het belang van deze drie factoren in de regeling?
Zou er alleen een proportionele regeling zijn dan krijg je last van overshoot en zal de afwijking e nooit nul worden. Zie het onderstaande plaatje:


Om dit op te lossen wordt de integrerende functie toegevoegd. Hiermee kan de afwijking e wel nul worden.

Het differentierende deel van de formule zorgt ervoor dat de regelaar snel kan reageren op ontstane afwijkingen. Dit zorgt voor een snellere regeling, en voor een betere stabiliteit.

Hopelijk is dit niet te uitgebreid voor je en kun je het volgen (ikzelf blijf het lastig vinden, maarja, daarom ga ik ook liever gifmengen dan procestechnologie volgen ).

Hieronder nog wat links naar de eerste de beste google resultaten

http://www.jashaw.com/pid/tutorial/pid3.html
http://wwwhome.cs.utwente.nl/~schoute/213014/sheets_college3.pdfp

[Verwijderd]

Heey een specificatie van de regelmodule

Mooi werk, inderdaad is dit een strakke manier van regelen. De regeling die ik als simpel "AVR compatible" algoritme in gedachte had, was inderdaad om volledig uit te sturen bij meer dan 10 graden afwijking, en daarbinnen te regelen. Een variable voor het % van PWM om de doeltemperatuur te halen zorgt ervoor dat je geen doorschot hebt. Als blijkt dat de temperatuur niet bereikt wordt terwijl de fan toch op "doel PWM %" draait, dan wordt de doelvariabele bijgesteld.

Wel grappig om nu dit zo eens naast een "echte" PID regeling te houden, de variabele waarin ink het "doel PWM" bijhou is niets anders dan jouw integrator!

De regeling lijkt dus wel een beetje op een "self-made" PID regelaar! Ik zal toch eens kijken of ik dit stukje wiskunde niet in de AVR kan proppen (zonder floats te gebruiken).

Nu denken mensen misschien dat een dergelijke regeling veel te zwaar is om in viervoud in een AVR te stoppen, maar dat valt erg mee. De regeling op zich is namelijk niet realtime, het kan best zo zijn dat de regeling maar 1x rekent terwijl de PWM al 10x een "rondje" heeft gemaakt; realtime is in het design al losgekoppeld van niet-realtime, zodat dit zeker moet kunnen!

Tanx voor de reply, dit scheelt mij zeker weer uit- en opzoekwerk

[Verwijderd]

Ik heb de PID functie nog eens goed bekeken.

Het eerste deel is duidelijk: U en U0. Alhoewel U0 eigenlijk de fansnelheid is die de gewenste temperatuur oplevert, en die is dus nog altijd moeilijk.

De rest is de eigenlijke regeling. Met K kun je de gehele regeling feller of relaxter maken (strakker of losser). De integratie heeft een dt in zich, wat volgens mij betekent dat de waarde van e tussen 2 samples in gelijk wordt verondersteld, oftewel er worden "bars" geintegreerd met breedte t_sample. Bij mij zal deze tijd constant zijn, dus mag ik volgens mij puur e integreren (zolang ik de tijd maar schaal in de constante T_i). De integrator introduceert duidelijk "kennis uit het verleden", en geeft de regeling een soort "variabel instelpunt" volgens mij. In de AVR makkelijk te maken door simpelweg elke volgende gemeten temperatuur minus de doeltemperatuur bij een integratievariabele op te tellen. Als e=0 (temperatuur is op doelwaarde), dan blijft de integrator staan. Wat trouwens niet betkent dat de fan niet meer versnelt; deze stopt pas met versnellen als de integrator 0 is.

De differentiator is inderdaad overduidelijk verantwoordelijk voor snelle respons op snelle veranderingen. Hoe groter het temperatuursverschil tussen de metingen, des te groter wordt deze factor, en dus zal de regeling dan des te sneller reageren. Oftewel: hoe sneller de temp stijgt hoe sneller de fan zal versnellen. Dit is in de AVR wel te bouwen via een ringbuffer. elke gemeten temperatuur wordt opgeslagen in dit buffer (tot een bepaald aantal samples toe). Nu kan de diff. factor altijd gevonden worden uit het verschil tussen de laatst gemeten temperatuur en die van x samples terug (te vinden in het ringbuffer). Hierbij is x de dt/T_sample

Klopt mijn verhaal een beetje?

WOW dit wordt nog wel wat... Als de hardware loopt zal ik zeker een aparte draad openen op het forum om specifiek deze regling goed te krijgen!

[Brothar]

Is het mogelijkom je PCB-onywerp ook te voorzien van de diverse connectoren ?

Ikzelf heb meegedaan met een LED aanschaf-aktie, en had ook het idee om met de seriële poort de informat op het LED te laten bepalen door een keuze met druktoetsen.
Het lijkt erop dat jouw ontwerp daartoe de mogelijkheid geeft, en daarnaast nog wat extra's kent.

Mijn kennis van electronica is net niet nul, progrsammeren gaat me beter af.

Mag ik voorstellen dat dit een samenwerkingsproject wordt ?
't Lijkt me leuk met een stel tweakers iets te ontwikkelen.

[Verwijderd]

Op zaterdag 09 maart 2002 21:24 schreef Brothar het volgende:
Is het mogelijkom je PCB-onywerp ook te voorzien van de diverse connectoren ?

Jazeker, voeding verloopt via een Molex (5 1/4" harddisk power connector); elke fan uitgang heeft een molex 4pins, 3pin header (met toerensensor) en een 2 pins header (minifans). Verder is er een 2x4 pins header voor de 4 temp. sensoren, een 14/16 pins header voor een LCD, enz enz.

Ikzelf heb meegedaan met een LED aanschaf-aktie, en had ook het idee om met de seriële poort de informat op het LED te laten bepalen door een keuze met druktoetsen.

Dat kan zeker, ik heb 3 druktoetsen voorzien en 8 LEDs. Ook nog een LCD. Dit alles kan zeker via de seriele poort worden bediend; als het alleen om de LEDs besturen gaat kun je de PCB gebruiken maar hoef je heel veel niet van onderdelen te voorzien. Voor alleen RS232, toetsen en LEDs: 1 microcontroller, 1 kristal, 9 condensatoren, 1 MAX232 ICtje, 1-3 drukknopjes, 1-8 LEDs met 1-8 weerstanden, 1 molex voor voeding. 1 programmeerkabeltje en 1 serieel kabeltje. That's it really!

Het lijkt erop dat jouw ontwerp daartoe de mogelijkheid geeft, en daarnaast nog wat extra's kent.

Ja het is de bedoeling dat dit project voor elk wat wils is.

Mijn kennis van electronica is net niet nul, progrsammeren gaat me beter af.

Mag ik voorstellen dat dit een samenwerkingsproject wordt ?
't Lijkt me leuk met een stel tweakers iets te ontwikkelen.

Dat is het leuke: De embedded software is nogal complex maar zit geukkig verborgen in de micro

Verder verloopt alles via de seriele poort, zodat echt iedereen in welke taal en op welk operating system dan ook kan programmeren voor het ding! Ik ga alleen een configuratie programma maken, zodat je allerlei instellingen aan het ding kan maken. Alle seriele I/O commando's worden gedocumenteerd en dus kan iedereen naar hartelust "sturen", of je nu complexe dingen wil doen zoals eigen regelingen voor de fans, of simpele dingen zoals de ledjes aansturen, ook dit is voor elk wat wils.

[Raafz0r]

Yep, volgens mij heb je het wel te pakken. Ik heb geen idee wat nou zo'n AVR precies is en wat je er mee kunt, maar je snapt wat ik bedoel .

Daarnaast schijnt het zo te zijn dat zo'n PID-regeling best leuk is, maar dat hij valt of staat met de juiste tuning (althans, voor procestechnologische zaken, waarbij een rendementsverschil van 1% duizenden euro's kan schelen). Misschien hiervoor wat overbodig, maar dat zal ik eens nazoeken.

[Verwijderd]

Op zaterdag 09 maart 2002 22:19 schreef as4Raven het volgende:
Yep, volgens mij heb je het wel te pakken. Ik heb geen idee wat nou zo'n AVR precies is en wat je er mee kunt, maar je snapt wat ik bedoel .

Daarnaast schijnt het zo te zijn dat zo'n PID-regeling best leuk is, maar dat hij valt of staat met de juiste tuning (althans, voor procestechnologische zaken, waarbij een rendementsverschil van 1% duizenden euro's kan schelen). Misschien hiervoor wat overbodig, maar dat zal ik eens nazoeken.

Een AVR is dus de embedded microcontroller; een 8bits risc processortje met 8Kb flashrom aan boord

De afregeling van de PID kun je serieel configureren, dus bouwen is simpel; het tunen daarna zal wel iets moeiljiker worden

[Verwijderd]

Op zaterdag 09 maart 2002 21:24 schreef Brothar het volgende:
Mijn kennis van electronica is net niet nul, progrsammeren gaat me beter af.

Aah, ben ik toch niet de enige

Mag ik voorstellen dat dit een samenwerkingsproject wordt ?
't Lijkt me leuk met een stel tweakers iets te ontwikkelen.

Lijkt mij ook een goed plan!

[Mithrandir]

Op zondag 10 maart 2002 15:23 schreef NextGeneration het volgende:

[..]

Aah, ben ik toch niet de enige
[..]

Lijkt mij ook een goed plan!

Tsja, wat zou je samen kunnen werken? 't coden? Tsjah...
Ik ken wel wat PHP, dus als je via internet je fans wil kunnen regelen....

Nee, das niets

[Verwijderd]

als je object georienteerd werkt is er prima samen te werken hoor,
/me heeft al eens in projectgroepvorm aan software gewerkt (AVR-Assembler)

[Verwijderd]

Op zondag 10 maart 2002 15:26 schreef DinoRaptor het volgende:

[..]

Tsja, wat zou je samen kunnen werken? 't coden? Tsjah...
Ik ken wel wat PHP, dus als je via internet je fans wil kunnen regelen....

Nee, das niets

Hmm, PHP ken ik ook, maar niet OO.
Ik ben bezig met Delphi, en dat leek mij wel een goed plan hiervoor.

[Verwijderd]

Een draad op PW: [topic=435075].

[Verwijderd]

Op zondag 10 maart 2002 15:32 schreef _AscII_ het volgende:
als je object georienteerd werkt is er prima samen te werken hoor,
/me heeft al eens in projectgroepvorm aan software gewerkt (AVR-Assembler)

idd, is mogelijk. Maar daar is object oriented niet noodzakelijk voor hoor; alleen een goed design. Zie de software modules op http://www.xs4all.nl/~kruimpie . Deze zijn op hoog niveau gesplitst, als de dataflows tussen de modules duidelijk zijn kom je een heel eind.

Echter voorlopig hou ik het coden van he embedded stuk nog ff "binnen", ik denk nl. dat het moeilijk is om anders een goed ontwerp neer te leggen (tenzij er goede specs zijn, wat ook weer veel tijd kost)

[Verwijderd]

Op zondag 10 maart 2002 15:50 schreef NextGeneration het volgende:
Een draad op PW: [topic=435075].

Tanx voor de draad

Hopelijk levert het iets op

[SimplyMe]

Even over de verbinding naar de PCB

Op de meeste moederborden zit een Ir connector
hier gaat als het goed is ook rs232 over heen.
Dus is het misschien mogelijk om deze connector
er voor te gebruiken inplaats van met een kabel buiten
je pc te gaan zitten.

[Verwijderd]

Op maandag 11 maart 2002 15:08 schreef SimpleMe het volgende:
Even over de verbinding naar de PCB

Op de meeste moederborden zit een Ir connector
hier gaat als het goed is ook rs232 over heen.
Dus is het misschien mogelijk om deze connector
er voor te gebruiken inplaats van met een kabel buiten
je pc te gaan zitten.

Ja klopt, sowieso bestaan er meerdere connectoren die serieel kunne bevatten... Er is ook een 10 pins dubbele header soms aanwezig... De connector op het PCB is 3 pins, RXD-GN-TXD, voor ieder mobo zou een aparte oplossing kunnen bestaan, de IR connector is wel een goeie kans tanx

[SlinkingAnt]

oh, ff iets anders, als je nog alpha/beta testers zoekt ? Ik hou me aanbevolen!

[Verwijderd]

Op maandag 11 maart 2002 15:38 schreef SlinkingAnt het volgende:
oh, ff iets anders, als je nog alpha/beta testers zoekt ? Ik hou me aanbevolen!

Ik denk niet dat jij de enige ben .

[SlinkingAnt]

oh, toch nie

[Verwijderd]

Hahahaha LOL

Ik hoop idd wel op wat animo, dan kunnen er misschien wel "echte" PCB gemaakt worden ipv. al dat ge-ets. De PCB's worden sowieso niet ge alfa of beta test, die test ik zelf of ze een beetje kloppen emn that's it. Vanaf dat moment kan er in principe gebouwd gaan worden. De embedded software is een ander verhaal, omdat die door iedereen immers kan worden "geflashed" als je een programmeerkabel hebt.

[SlinkingAnt]

Heb je het definitieve ontwerp van de pcb al af?

[Verwijderd]

Op dinsdag 12 maart 2002 09:25 schreef SlinkingAnt het volgende:
Heb je het definitieve ontwerp van de pcb al af?

lijkt me datie dat pas af heeft als hij de software werkend heeft (op die manier zou ik het doen iig

[Verwijderd]

Op dinsdag 12 maart 2002 10:04 schreef _AscII_ het volgende:

[..]

lijkt me datie dat pas af heeft als hij de software werkend heeft (op die manier zou ik het doen iig

uhm?? Ik maak toch eerst hardware, en dan pas de software erop hoor.... andersom lijkt me erg moeilijk.

De PCB is in zoverre af, ik heb hier een sheet liggen met de BOTTOM erop... nu moet ik ff tijd vrijmaken om het ding te belichten en etsen. Daarna bouwen... De atmellen heb ik al liggen, de max232 en dergelijke heb ik nog wel op voorraad. Alleen ff een probleempje om de molexen te vinden voor PCB montage... Acht wat ik kan ook een oud verlengkabeltje verknippen en die eraan solderen...

Weet ook niet of ik nog fotoprint heb liggen... Het past niet op een 100x160mm PCBtje, maar ik heb het wel zo gekregen dat er 2 op een 160x233mm passen

Deze PCB heeft 3 fans via een "harde" n-channel mosFET sturing lopen, en fan4 heeft een p-channel mosFET sturing met een LC kring erbij... Dit om te kunnen zien welke sturing lekkerder loopt.

De echte definitieve PCB krijgt dan dus OFWEL 4x de harde n-channel sturing OFWEL 4x de LCkring gekoppelde.

Nadeel van de LC gekoppelde is wel dat ik een mux ICtje moet toevoegen om 4x toeren te meten, en dat ik een grotere PCB nodig heb om 4x een grote elko maar erger nog 4x een loei van een spoel moet huisvesten

Voordeel is dat ik geen piepende FANs heb, en geen "rare toeren" hoef uit te halen om toeren te meten

Voordeel van de "harde" sturing is dus eenvoud in hardware...

Ff afwachten wat het worden gaat, nu eerst fotoprint en tijd regelen

[Verwijderd]

Nog een last-second aanpassing op de hardware uitgevoerd: Ik had het over het hoofd gezien, maar de INT0 en INT1 pinnen had ik nog over

Hier zitten nu 2 headers op waarmee 2 aparte HDD-activity monitors mogelijk zijn. De originele activity monitor (op pin T0) ga ik tijdelijk niet gebruiken, wellicht komt hier een 3e monitor op (ook bruikbaar voor b.v. netwerk activity)

Ik ben nu de specs van de LED controller aan het opstellen, tot nu toe ben ik zover dat ik elke LED afzonderlijk een configuratie opgeef. De software zal daarna zelf voor elke led de intensiteit berekenen.

Ik maak nog geen ondersteuning voor bicolor en all-color LEDs, voorlopig kun je alleen LEDs configureren met daarnaast een optie om de LED te inverteren. Opdie manier kun je dus een bicolor LED aansturen door beide LED uitgangen b.v. op FAN1 RPM-2-INTENSITY te programmeren, en een van beide te inverteren. Op die manier zal een bicolor LED die eraan hangt van b.v. groen naar rood faden afhankelijk van een temperatuur of fan toerental.

Nog leuker wordt het met een "all-color" LED. Deze LEDs hebben 3 leds intern, rood, groen en blauw en kunnen zo alle kleuren van de regenboog krijgen. Door deze slim te configureren kun je b.v. op de rode tak de CPU temperatuur zetten, op de groene tak het fan toerental en op de blauwe tak de geinverteerde temperatuur

Nu heb je dus een LED die rood wordt bij hoge CPU temperatuur, geel wordt bij hoge CPU temperatuur met hoog FAN toerental, en blauw wordt bij lage CPU temperatuur en alle kleuren daartussenin

Tot nu toe heb ik al 28 configuraties waarin een LED kan werken

Onder andere:

LED is part op RPM / TEMP / HDDACT. bar
LED monitors RPM /TEMP / HDDACT (intensity)
LED is used as ALARM output (cq buzzer)

Voor 4 temp sensoren, 4 fans en 2 hdd activity kanalen pakt dat uit tot pakweg 28 combinaties

Mist iemand nog iets in deze LED configuratie?

[Xplosive]

Nog een opmerking over het hardware ontwerp waarom heb je geen standaard isp header gebruikt dus 3*2 of 5*2, het voordeel daarvan is, is dat hiervoor veel dongle's bestaan en dat deze makkelijk te maken zijn.

[Verwijderd]

Op woensdag 13 maart 2002 10:04 schreef Xplosive het volgende:
Nog een opmerking over het hardware ontwerp waarom heb je geen standaard isp header gebruikt dus 3*2 of 5*2, het voordeel daarvan is, is dat hiervoor veel dongle's bestaan en dat deze makkelijk te maken zijn.

uhm... ik heb deze in principe "dongleloos" gemaakt, je kunt met alleen draadjes overweg. Heb je echter een pinout+schema van een (simpele en goede) dongle, post hem dan ff misschien kan ik deze nog op de PCB proppen, desnoods als 2e poort (kan men kiezen)... Kan nog net, want ik heb nog geen tijd gehad om de PCB te etsen...!!

iig tanx voor deze goede tip!

[The Lord]

Hmm. Echt snel ben ik niet met reageren en je bent al je print aan het bakken. Maar goed, ik deel het toch even.

USB is moeilijk, er moet dan een usb chip op de print, die je maar moet zien te krijgen en zien aan te sturen. Plus een extra berg software. Daarom is dit (voor nu althans) geen optie.

In de Elektuur stonden twee projectjes om met USB te experimenteren. De meest flexibele oplossing was een print waarop een (Atmel?) controller zat met alle logica erin gebakken. Tevens was er voor deze oplossing een identificatiecode aangevraagd bij het USB forum (en verkregen) en een driver geprogrammeerd.
Helaas ligt de prijs geloof ik rond de €40 voor dit ding.

Nadeel van USB is waarschijnlijk de lastige aansturing onder niet Windows OS-en. Voordeel is dat je niet afhankelijk bent van die ene seriële aansluiting waar je modem aanzit (of erger bij een legacy-free PC...)

[Xplosive]

Hier een schema waarmee simpel atmel uC isp geprogrameerd kan worden http://www.iready.org/projects/uinternet/ispdongle.pdf

[Verwijderd]

Op woensdag 13 maart 2002 11:02 schreef The Lord het volgende:

*KNIP*
Helaas ligt de prijs geloof ik rond de €40 voor dit ding.

Nadeel van USB is waarschijnlijk de lastige aansturing onder niet Windows OS-en. Voordeel is dat je niet afhankelijk bent van die ene seriële aansluiting waar je modem aanzit (of erger bij een legacy-free PC...)

Oftewel: GEEN USB. Het is gewoon te duur, te complex en voegt verder weinig tot niets nuttigs toe...

Misschien indien er veel vraag naar is in een toekomstige variant?

[Verwijderd]

Op woensdag 13 maart 2002 11:05 schreef Xplosive het volgende:
Hier een schema waarmee simpel atmel uC isp geprogrameerd kan worden http://www.iready.org/projects/uinternet/ispdongle.pdf

Kijk DAAR heb ik wat aan. De dongle is idd redelijk simpel, en werkt ook samen met programma's als ponyprog neem ik aan??

Opvallend is het feit dat je geen OSC pin nodig hebt, iets wat via mijn systeem wel benodigd is.

Ik zal zeker proberen deze header layout op PCB te krijgen! De 6-pinner lukt misschien, de 10 pinner weet ik nog niet... (lastig met zo'n lange groundbar erdoorheen).

Probleem is dat ik de max232 er vlak naast heb liggen op de PCB, misschien moet ik mijn SIL header vergeten en overgaan op de 6 of 10 pinner...??

Bij deze ook nog een vraag: Wie heeft er al zo'n dongle gemaakt, en welke header hebben jullie hierop, de 6 of de 10 pinner?

[Xplosive]

Ja deze dongle werkt ook met ponyprog ik heb thuis de 10 pins versie liggen en deze werkt goed

[Verwijderd]

Op woensdag 13 maart 2002 11:21 schreef Xplosive het volgende:
Ja deze dongle werkt ook met ponyprog ik heb thuis de 10 pins versie liggen en deze werkt goed

Ik heb geprobeerd om de 10-pins versie er "ff" in te proppen, maar ik ben bang dat ik de PCB weer grof moet wijzigen hiervoor... onder andere moet ik het max232 circuit verplaatsen... Ff kijken of ik er nog tijd voor vrijmaken kan, want ik denk dat het wel belangrijk is om deze header op de PCB te krijgen.

[Xplosive]

Op woensdag 13 maart 2002 17:55 schreef --EasY-- het volgende:

[..]

Ik heb geprobeerd om de 10-pins versie er "ff" in te proppen, maar ik ben bang dat ik de PCB weer grof moet wijzigen hiervoor... onder andere moet ik het max232 circuit verplaatsen... Ff kijken of ik er nog tijd voor vrijmaken kan, want ik denk dat het wel belangrijk is om deze header op de PCB te krijgen.

Ik denk dat de 6 pins versie ook wel werkt. Het gaat er maar om dat zo'n dongle makkelijk te maken is aangezien er nog wel wat software wijzigingen zullen volgen

Verder moet ik nog ff kwijt dat ik dit een zeer cool topic vind en dat ik hier zeker ook aan ga meedoen.

Ik heb de draad ff doorgelezen en je schema bekeken maar het is me nu nog steeds niet helemaal duidelijk hoe je het een en ander met de fans gaat doen. In het schema op je website staat dat je met van 2 fans rpm kan meten en een stukje terug in dit topic zeg je dat je van fan 1 tm fan 3 rpm kan meten
Wat is nu het definitieve schema. Ik ben zeer benieuwd

[Verwijderd]

Op woensdag 13 maart 2002 18:54 schreef Xplosive het volgende:

[..]

Ik denk dat de 6 pins versie ook wel werkt. Het gaat er maar om dat zo'n dongle makkelijk te maken is aangezien er nog wel wat software wijzigingen zullen volgen

Ja ik denk inderdaad dat 99% van de tweakers sowieso nog een dongle maken moet... Ik kijk wel of de 6pins versie er beter op past.

Ik heb de draad ff doorgelezen en je schema bekeken maar het is me nu nog steeds niet helemaal duidelijk hoe je het een en ander met de fans gaat doen. In het schema op je website staat dat je met van 2 fans rpm kan meten en een stukje terug in dit topic zeg je dat je van fan 1 tm fan 3 rpm kan meten
Wat is nu het definitieve schema. Ik ben zeer benieuwd

OEPS sorry de website moet nodig geupdate

alle fan rpms hangen nu koud aan elkaar, door alle fans op 0% PWM te schakelen en eentje op 100% pwm voor heeel korte tijd meet ik de pulstijd tussen twee RPM flanken. Direct heirna gaan alle fans weer normaal PWMmen. Zo kan ik van elke fan de RPM meten. Als experiment zit fan4 als echte DC geregelde fan erbij, als dit de btere oplissing blijkt ga ik alle fans zo sturen.

Ik zal kijken, waarschijnlijk kan ik morgen pas de site updaten.... Stay tuned!

[SlinkingAnt]

ff tussendoor, wat is een dongle?

[Verwijderd]

Op woensdag 13 maart 2002 19:53 schreef SlinkingAnt het volgende:
ff tussendoor, wat is een dongle?

Uhm eigenlijk is dit geen echt goede benaming. Een dongle is van origine een software-beveiliging die als kastje aan (meestal) de printerpoort komt te hangen. De software checkt dan met regelmaat of de dongle aanwezig is.

Deze "dongle" is ook een mini-kastje aan de printerpoort, van waaruit een isp-kabel (In System Programmable) loopt naar een header op de baybus. Via een progje kun je dan mbv deze "dongle" de AVR microcontroller op de baybus flashen (net als een bios zeg maar).

De dongle bestaat als je hem netjes maakt uit een enkel goedkoop 74LS244 ICtje. Ik heb zelfs al "minder nette" versies gezien die in plaats van de '244 een paar weerstanden hebben. De '244 regelt namelijk I/O tussen de AVR controller op de baybus en de printerpoort. Dit is de nette oplossing.

De minder nette oplossing schakelt niet tussen input/output, maar scheid de lijnen via een weerstand... simpel maar effectief!

[Verwijderd]

Op woensdag 13 maart 2002 09:38 schreef --EasY-- het volgende:
Hier zitten nu 2 headers op waarmee 2 aparte HDD-activity monitors mogelijk zijn. De originele activity monitor (op pin T0) ga ik tijdelijk niet gebruiken, wellicht komt hier een 3e monitor op (ook bruikbaar voor b.v. netwerk activity)

Toch

Maar nog even over de P&W draad ([topic=435075/1/100]), ik denk dat dit nix meer gaat worden.
De software (eigenlijk een driver) is te koop voor veel/teveel $$$, en dat is dus niet zo aantrekkelijk.

In het kort, de virtuele seriele poort is wat mij betreft een niet uit te werken idee :'(!

[Verwijderd]

Op woensdag 13 maart 2002 22:15 schreef NextGeneration het volgende:

*KNIP*
In het kort, de virtuele seriele poort is wat mij betreft een niet uit te werken idee :'(!

Jammer, misschien dat Smartie alleen de seriele poort opent, data schrijft en weer sluit...?? Dan zou een 2e programma in principe kunnen wachten tot de poort beschikbaar is en snel hetzelfde truukje uithalen.... Zou kunnen werken maar is natuurlijk wel glad ijs

Anders... vergeten. En dus zelf LCD spullen schrijven OF de maker van Smartie zover krijgen dat hij de baybus ondersteund... Helaas is geen van de opties echt lekker

[Verwijderd]

Ik heb nog eens zitten kijken naar de dongle, maar ik bedenk me nu, omdat iedereen toch nog zelf een dongle bouwen moet, dat de SIP header die ik nu in het ontwerp heb zitten toch ook alle pinnen uitvoerd die nodig zijn. Dus ik zie eigenlijk het nut niet meer helemaal van de 6 of 10 pins connector; je kunt de dongle gewoon bouwen, maar er komt dan alleen een "niet standaard" connector op te zitten.

Bovendien is dit nog maar de proto-PCB. Ik probeer de 6 pins nog wel even, anders dan komt de 6 of 10 pins connector wel op de definitieve print en hou ik voor nu de SIP header

[Xplosive]

Waar dient die xtal lijn voor???
volgens mij heb je dit nergens voor nodig.

[Verwijderd]

Op donderdag 14 maart 2002 16:27 schreef Xplosive het volgende:
Waar dient die xtal lijn voor???
volgens mij heb je dit nergens voor nodig.

Zie AVR datasheet. Volgens de datasheet moet ook deze lijn "handbestuurd" worden....

edit:

Was daar ook niet zo happy over, xtal draden die laat ik liever geen antenne zijn

[Xplosive]

Op donderdag 14 maart 2002 16:41 schreef --EasY-- het volgende:

[..]

Zie AVR datasheet. Volgens de datasheet moet ook deze lijn "handbestuurd" worden....

edit:

Was daar ook niet zo happy over, xtal draden die laat ik liever geen antenne zijn

hmm volgens mij heb je aan het crystal naast je uC genoeg. De sck-lijn is namelijk ook al een soort van klok signaal.

[Verwijderd]

Op donderdag 14 maart 2002 17:33 schreef Xplosive het volgende:

[..]

hmm volgens mij heb je aan het crystal naast je uC genoeg. De sck-lijn is namelijk ook al een soort van klok signaal.

Zo werkt de dongle blijkbaar. In de originele spec van Atmel staat de lijn wel vermeld als "te besturen"...

Omdat de dongle enzo hem niet gebruikt zal hij wel overbodig zijn lijkt mij. Ach ja, weglaten is makkelijker dan later toevoegen

Als ik de 6 of 10 pinner erop zet istie sowieso weg...!

[Verwijderd]

Op woensdag 13 maart 2002 22:25 schreef --EasY-- het volgende:

[..]

Jammer, misschien dat Smartie alleen de seriele poort opent, data schrijft en weer sluit...?? Dan zou een 2e programma in principe kunnen wachten tot de poort beschikbaar is en snel hetzelfde truukje uithalen.... Zou kunnen werken maar is natuurlijk wel glad ijs

Anders... vergeten. En dus zelf LCD spullen schrijven OF de maker van Smartie zover krijgen dat hij de baybus ondersteund... Helaas is geen van de opties echt lekker

Idd, die opties zijn ook niet alles.
Maar is het een slecht idee om de data (temps enzo) via de seriele poort te lezen, en de LCD aan te sturen via de paralelle poort?

[Xplosive]

Op donderdag 14 maart 2002 19:09 schreef --EasY-- het volgende:

[..]

Zo werkt de dongle blijkbaar. In de originele spec van Atmel staat de lijn wel vermeld als "te besturen"...

Omdat de dongle enzo hem niet gebruikt zal hij wel overbodig zijn lijkt mij. Ach ja, weglaten is makkelijker dan later toevoegen

Als ik de 6 of 10 pinner erop zet istie sowieso weg...!

Volgens mij is die kloklijn waar jij het over de sck lijn. Ik zou wel is willen weten in welke specs jij hebt gelezen dat je nog een kloksignaal moet meesturen.

[Verwijderd]

Op donderdag 14 maart 2002 19:28 schreef Xplosive het volgende:

[..]

Volgens mij is die kloklijn waar jij het over de sck lijn. Ik zou wel is willen weten in welke specs jij hebt gelezen dat je nog een kloksignaal moet meesturen.

De XTAL1 lijn is nodig bij Parrallel Programming. Bij Serial Programming is deze niet nodig.

[Xplosive]

Op donderdag 14 maart 2002 19:31 schreef Maxim het volgende:

[..]

De XTAL1 lijn is nodig bij Parrallel Programming. Bij Serial Programming is deze niet nodig.

Wat bedoel je precies met parrallel programeren
Houdt dit in dat je nog een extra print moet maken met een klokgenerator erop, voor die xtal lijn??

[Xplosive]

Easy, ik heb nog is naar je pcb ontwerp gekeken en ik heb nog wat tips. Ik neem aan dat die rode laag die over de print ligt met de ground is verbonden?? Als dat zo is dan zou je de spoke width bij thermal relief settings wat ruimer kunnen nemen. Dit heeft als voordeel dat je dan de ground lijnen niet zelf meer hoeft te trekken want die zitten dan meteen met de ground laag verbonden.
Dat scheelt weer met routen

[Verwijderd]

Op donderdag 14 maart 2002 19:38 schreef Xplosive het volgende:

[..]

Wat bedoel je precies met parrallel programeren
Houdt dit in dat je nog een extra print moet maken met een klokgenerator erop, voor die xtal lijn??

Parrallel Programming :

De Parrallel Programming Mode(PPM) is de snelste manier. PPM gebruikt acht datalijnen plus zes control-lijnen. En is dus niet zo geschikt voor ISP. De PPM wordt geinitieerd door kort +12 V op de RESET-lijn te zetten en daarom ook wel High Voltage Programming genoemd.
De data wordt met een puls op de XTAL-lijn naar binnen gehaald.

Serial Programming Mode :

Is niet snel maar heeft maar 3 lijnen nodig (SCK,MOSI en MISO) is dus uitermate goed geschikt voor ISP. De SPM wordt geinitieerd door de RESET-lijn laag te houden tijdens de powerup. Dit is dus Low Voltage Programming. De data wordt serieel door SCK naar binnen 'geklokt'.



edit: De XTAL1-lijn is hier dus niet nodig !

[Verwijderd]

voor de mensen die usb toch wel intressant vinden:
[topic=423931]

inkoop actie voor ubs chipjes (wel voor de mensen met wat meer knutsel ervaring)

deze usb chipjes zijn zo in het huidige hardwareontwerp te plakken.

[Verwijderd]

--EASY--, aangezien je de MOSI-,MISO- en SCK-lijnen ook als output gebruikt kom je niet onder een 74HC244 (zoals gebruikt in de dongle) uit. Zoals je je schema nu hebt kun je kortsluiting maken met de printerpoort.

/edit:
Een printerpoort is dan misschien wel tegen kortsluiting beveiligd, maar netjes is anders.

[Verwijderd]

Op donderdag 14 maart 2002 19:28 schreef Xplosive het volgende:

[..]

Volgens mij is die kloklijn waar jij het over de sck lijn. Ik zou wel is willen weten in welke specs jij hebt gelezen dat je nog een kloksignaal moet meesturen.

Staat toch echt in http://www.atmel.com/atmel/acrobat/doc1041.pdf

DE specs.

[Verwijderd]

Op donderdag 14 maart 2002 19:46 schreef Xplosive het volgende:
Easy, ik heb nog is naar je pcb ontwerp gekeken en ik heb nog wat tips. Ik neem aan dat die rode laag die over de print ligt met de ground is verbonden?? Als dat zo is dan zou je de spoke width bij thermal relief settings wat ruimer kunnen nemen. Dit heeft als voordeel dat je dan de ground lijnen niet zelf meer hoeft te trekken want die zitten dan meteen met de ground laag verbonden.
Dat scheelt weer met routen

Nee ik route altijd eerst gnd met iets hogere prio dan de overige lijnen. anders komt die er later nooit strak in, ik zit niet te wachten op grounds die via via via bij hun doel komen.... De ground layer is gewoon een copper pour die connected met GND is.

[Verwijderd]

Op donderdag 14 maart 2002 19:53 schreef Maxim het volgende:

[..]

*KNIP*
edit: De XTAL1-lijn is hier dus niet nodig !

Heb weer half gekeken

[Verwijderd]

Op donderdag 14 maart 2002 20:25 schreef Maxim het volgende:
--EASY--, aangezien je de MOSI-,MISO- en SCK-lijnen ook als output gebruikt kom je niet onder een 74HC244 (zoals gebruikt in de dongle) uit. Zoals je je schema nu hebt kun je kortsluiting maken met de printerpoort.

/edit:
Een printerpoort is dan misschien wel tegen kortsluiting beveiligd, maar netjes is anders.

Ik zag een schema met scheidingsweerstanden naar de printerpoort ipv een nette '244... Wel errug grof maar werkt ook wel denk ik. De stroom wordt gewoon begrennst door de serieweerstanden als output output tegen komt

[Verwijderd]

Op donderdag 14 maart 2002 20:52 schreef --EasY-- het volgende:

Heb weer half gekeken

LOL, ik heb dubbel gekeken, parallel schrijf je met maar één r.

Ik zag een schema met scheidingsweerstanden naar de printerpoort ipv een nette '244... Wel errug grof maar werkt ook wel denk ik. De stroom wordt gewoon begrennst door de serieweerstanden als output output tegen komt

Kan ook.

[Vastloper]

Op donderdag 14 maart 2002 20:49 schreef --EasY-- het volgende:

[..]

Nee ik route altijd eerst gnd met iets hogere prio dan de overige lijnen. anders komt die er later nooit strak in, ik zit niet te wachten op grounds die via via via bij hun doel komen.... De ground layer is gewoon een copper pour die connected met GND is.

Hoezo via via via? de stroom kan nog steeds exact hetzelfde lopen met die copper pour. Nu lopen de sporen toch volledig in je copper pour dus het kan er iig nooit op achteruit gaan. Overigens is het sowieso niet onverstandig je spoke width wat hoger te zetten want je ziet nu dus nog wel 4 miezerige spoortjes bij elke ground pin dat is slecht te etsen en heeft nu geen effect als je dat op 10 mil zet of zelfs 20 mil dan heb je echt die sporen ook niet meer nodig. Als je je dan zorgen maakt om je statistics enzo dat het niet 100% routed aangeeft moet je in user preferences use pours for connectivity aanvinken. Persoonlijk doe ik ground altijd als laatste juist om het zo veel mogelijk via een copper pour te doen.

[Verwijderd]

Op donderdag 14 maart 2002 20:57 schreef Maxim het volgende:

[..]

LOL, ik heb dubbel gekeken, parallel schrijf je met maar één r.

Wist je dat geenneens tssss

[Verwijderd]

Op donderdag 14 maart 2002 20:58 schreef Vastloper het volgende:

[..]

Hoezo via via via? de stroom kan nog steeds exact hetzelfde lopen met die copper pour. Nu lopen de sporen toch volledig in je copper pour dus het kan er iig nooit op achteruit gaan.

Inderdaad, de copperpour ligt over de sporen. maar als ik route zonder gnd, en die pour ik er later overheen dan kan ik je nu al zeggen dat er vele kleine groundplanes ontstaan die onderling geisoleerd zijn door tracks... Het is en blijft een single layer PCB!

Overigens is het sowieso niet onverstandig je spoke width wat hoger te zetten want je ziet nu dus nog wel 4 miezerige spoortjes bij elke ground pin dat is slecht te etsen en heeft nu geen effect als je dat op 10 mil zet of zelfs 20 mil dan heb je echt die sporen ook niet meer nodig. Als je je dan zorgen maakt om je statistics enzo dat het niet 100% routed aangeeft moet je in user preferences use pours for connectivity aanvinken.

Uhm ik weet niet welk CAD pakket je gebruikt, maar die ik gebruik accepteerd logscherwijs een copperpour die aan GND zit als net conencties. Ik weet niet wat je met "spoke width" bedoeld, is dat de dikte van de copper-pour naar pad verbindingen? Die 4 "miezerige" spoortjes worden speciaal aangelegd als "thermal relief" omdat je deze anders bijna niet goed gesoldeerd krijgt. En het etst altijd prima hoor... Die sporen zie je op de website nog door de copperpour enzo lopen, maar als ik eenmaal "happy" ben met de PCB dan unroute ik gewoon het hele GND net en klaar!

Persoonlijk doe ik ground altijd als laatste juist om het zo veel mogelijk via een copper pour te doen.

En DAT doe ik nu juist anders.... Ik vertrouw op de autorouter. Ik gebruik een gridless router, waarbij ik o.a. de GND en VCC hoger zet qua "cost" zodat deze altijd lekker direct verbonden worden. Als je op een single layer als laatste de gnd zet, is die altijd zo zigzag (als je hem er al op krijgt), dat je ICtjes nooit lekker directe spanning krijgen. Resultaat: Alle storing die een IC veroorzaakt uit zich in stromen over je gehele board ipv. dat ze nog een redelijk korte weg naar je voeding afleggen. Deze stroom zal altijd zo dicht mogelijk langs de VCC lijn vloeien (spoelwerking). Dus VCC moet ook direct zijn, en op een single layer PCB het liefst VCC langs een groundplane die relatief direct naar de voeding lopen!

[Verwijderd]

UPDATE

Op http://www.xs4all.nl/~kruimpie staat nu het nieuwste schema, alleen nog wel met 3 verschillende isp-connectoren, verders "af". Ook natuurlijk nog steeds de "3x hard-PWM, 1x DC converted PWM" optie om te kijken welke fansturing het lekkerst lopen zal.

Ook de nieuwe PCB staat erop, met (na wat prop en schuifwerk) een 6 pins isp-connector erop van 2x3 pins!

Ook het document dat helemaal onderaan is uitgebreidt, er staat nu een redelijk software design van de meeste modules in. Omdat het project niet zo heel groot is, is eigenlijk pakket van eisen, global en detailed design in een. Maar zolang het werkbaar is...

[SlinkingAnt]

Wat is die massa pinnetjes in die hoek?
En hoe groot is het plaatje is cm?

[Verwijderd]

Op vrijdag 15 maart 2002 11:56 schreef SlinkingAnt het volgende:
Wat is die massa pinnetjes in die hoek?
En hoe groot is het plaatje is cm?

Die massa pinnetjes zijn geen massa pinnetjes maar zwevende eilanden... Zo heb ik dus een eigen "prutsboardje" in de hoek. Ik kan er b.v. een extra IC op solderen en via draadjes doorverbinden naar de rest van de PCB mocht dat nodig zijn... Op de definitieve PCB vind je die natuurlijk niet meer trug he

het plaatje is groot uhm... 137 mm langs de fan connectoren en 111mm in de "diepte"... Past dus helaas net niet op een "enkele eurokaart" van 160x100 mm, maar er passen er wel twee op een "dubbele eurokaart" van 230 x 160mm

[SlinkingAnt]

Het ging er mij nog om dat hij in een cdrom slot paste, en dus makkelijk te plaatsen is.

[Verwijderd]

Op vrijdag 15 maart 2002 12:13 schreef SlinkingAnt het volgende:
Het ging er mij nog om dat hij in een cdrom slot paste, en dus makkelijk te plaatsen is.

Ja die had had ik al bedacht... sowieso bedoeld om in een 5 1/4" bay te proppen

[SlinkingAnt]

Kan je er ook een glowpad op 3V ofzow op aansluiten? Dus dat je kan dimmen maar ook dat het voltage begrensd wordt? Zodat je je ledjes niet opblaast

[Xplosive]

Dit zal wel een stomme vraag zijn, maar waarom gebruik je een transistor en een fet om de fan's te schakelen. Is alleen een fet niet voldoende??
Wat ik me ook nog afvraag is waarom je een condensator gebruikt bij de resetpin bij de uC.

[SlinkingAnt]

misschien om een klein lekstroompje op te vangen ofzow? Wordt namelijk meestal als ontstoring gebruikt

[Verwijderd]

Op vrijdag 15 maart 2002 17:15 schreef SlinkingAnt het volgende:
Kan je er ook een glowpad op 3V ofzow op aansluiten? Dus dat je kan dimmen maar ook dat het voltage begrensd wordt? Zodat je je ledjes niet opblaast

Uhm 3V? Als je de LEDs via een weerstand stuurt is dat geen probleem (LEDs zijn stroomgestuurd en niet spanninggestuurd!) Ook fadebaar dus.

[Verwijderd]

Op vrijdag 15 maart 2002 18:29 schreef Xplosive het volgende:
Dit zal wel een stomme vraag zijn, maar waarom gebruik je een transistor en een fet om de fan's te schakelen. Is alleen een fet niet voldoende??

Hmmmm Dat is absoluut GEEN stomme vraag... Eerder stom dat ik het over het hoofd heb gezien.... Normaal bij een TTL uitgang moet het wel via een tor, omdat de FET op zijn gate echt de volle +12V moet krijgen om geheel te sluiten... 5V is niet voldoende. Maar omdat de poorten van de AVR OC zijn (dus alleen een N-kanaal naar aarde) KAN het werken zonder transistor denk ik.... Tanx je hebt weer 4 torren plus 4 weerstanden uit het design geoptimaliseerd

edit:

Dit vergeetje komt omdat ik meer designervaring heb met de 89C2051 en dderivaten... Deze hebben een vaste pullup naar de +5V, de AVR kan deze echter afschakelen zodat ik zelf de pullups naar de +12V kan maken. Besparing is dus wel 4 torren maar helaas geen 4 weerstanden... Ik reageerde iets te ondoordacht

Als ik het slim speel dan kan ik hierdoor bovendien de diepte van de PCB naar 10cm brengen, zodat een enkele PCB ook past op een halve eurokaart van 160x100 mm

dus dubbel tanx!

Wat ik me ook nog afvraag is waarom je een condensator gebruikt bij de resetpin bij de uC.

Uhm die is WEL nodig, is namelijk de coldboot condensator. Deze houd de reset pin in reset als er spanning op de chip komt. Pas na opladen van deze condensator valt de reset af en zal de microcontroller booten. Op deze manier boot de controller pas als de spanning stabiel aanwezig is

[Vastloper]

Op donderdag 14 maart 2002 22:07 schreef --EasY-- het volgende:

[..]

Inderdaad, de copperpour ligt over de sporen. maar als ik route zonder gnd, en die pour ik er later overheen dan kan ik je nu al zeggen dat er vele kleine groundplanes ontstaan die onderling geisoleerd zijn door tracks... Het is en blijft een single layer PCB!

Daar heb je gelijk in ja het is natuurlijk lastiger met single layer pcb, ik ben double layer gewend en daar kun je zulke problemen altijd oplossen dat zal nu niet altijd kunnen.

[..]

Uhm ik weet niet welk CAD pakket je gebruikt, maar die ik gebruik accepteerd logscherwijs een copperpour die aan GND zit als net conencties. Ik weet niet wat je met "spoke width" bedoeld, is dat de dikte van de copper-pour naar pad verbindingen? Die 4 "miezerige" spoortjes worden speciaal aangelegd als "thermal relief" omdat je deze anders bijna niet goed gesoldeerd krijgt. En het etst altijd prima hoor... Die sporen zie je op de website nog door de copperpour enzo lopen, maar als ik eenmaal "happy" ben met de PCB dan unroute ik gewoon het hele GND net en klaar!

Ik gebruik net als jij ook orcad, maar je hebt een setting waarmee je copper pours als connectie uit en aan kan zetten en afhankelijk van de template die je gebruikt staat die nog weleens uit en staat er in de statistics dus dat hij niet geroute is en als je naderhand autorouter nog gebruikt dan route hij ze alsnog. Als je naderhand het ground net nog weghaald, kan ik dat goed begrijpen dat je die eerst route op een single layer pcb, en de spoke width zijn die 4 miezerige spoortjes van het thermal relief je ziet er een mooie tekening en uitleg van in de help bij thermal relief settings, deze heb ik breder om een betere verbinding te maken met de ground aangezien er bij sommige componenten toch best wat stroom kan gaan lopen. Ik begrijp alleen niet helemaal wat je bedoelt met dat je het anders niet goed gesoldeerd krijgt bedoel je dat als je die breder maakt of zonder thermal relief ofzo?

[..]

En DAT doe ik nu juist anders.... Ik vertrouw op de autorouter. Ik gebruik een gridless router, waarbij ik o.a. de GND en VCC hoger zet qua "cost" zodat deze altijd lekker direct verbonden worden. Als je op een single layer als laatste de gnd zet, is die altijd zo zigzag (als je hem er al op krijgt), dat je ICtjes nooit lekker directe spanning krijgen. Resultaat: Alle storing die een IC veroorzaakt uit zich in stromen over je gehele board ipv. dat ze nog een redelijk korte weg naar je voeding afleggen. Deze stroom zal altijd zo dicht mogelijk langs de VCC lijn vloeien (spoelwerking). Dus VCC moet ook direct zijn, en op een single layer PCB het liefst VCC langs een groundplane die relatief direct naar de voeding lopen!

Ik ben een beetje ontevreden over de autorouter, ik heb hem nog nooit gebruikt voor een single layer pcb maar mijn ervaring met double layer is dat hij vaak heel inefficient is en overal maar via's plaatst en vaak hele rare bochtjes maakt. Waar ik meestal juist op let is om mijn signaallijntjes zo kort mogelijk te houden en er een ground plane tussen te krijgen om daar crosstalk te voorkomen door parasitaire capaciteit, omdat daar juist meestal weinig stroom loopt maar toch veel wisselende spanning over staat komen daar juist veel wisselende elektrische velden af op ground en voeding staat een constante spanning en heb je dus juist geen parasitaire capaciteit ook loopt daar de meeste stroom door. En om je voeding stabiel te maken plaats ik bij elk ic dan ook een ontkoppelcondensator om de pieken ed eraf te halen. Ook loopt de voeding en ground op veel meer plekken op je bord dan een signaal lijn en is die dus makkelijker te routen meestal. Mijn voorkeur blijft toch bij handmatig routen ook dit gaat meestal sneller dan je denkt en je kunt veel beter op bepaalde sporen letten die extra aandacht vergen zoals bijvoorbeeld van een crystal.

Verder blijven het natuurlijk details en zal de print vast wel goed werken. Hoe staat het overigens met de software, want volgens mij is dat topic daar voor geopend. Waarin wil je de software maken c/assembly en wat voor interface wil je eraan geven gewoon telnet of een windows frontend? Ik wil je graag helpen bij het programeren ik heb vooral ervaring met assembly voor avr controllers heb een keer een i2c monitor gemaakt in een 1200 met 1k flash waarbij een display zat met knoppen waarop tot 7 sessie bewaard en bekeken konden worden en tevens zat er een rs232 aansluiting op waarbij alle berichten ook nog eens over de compoort met 115k2 werden verstuurd. Ook heb ik diverse programma's voor windows gemaakt dus een frontend zou ik je ook mee kunnen helpen. Het is iig eerst belangrijk dat je een goede use case hebt iig in je hoofd en dan een duidelijk objectmodel opzet. Heb je al iets daarvoor gedaan of bedacht? Als je hulpt kunt gebruiken laat het dan even weten.

Overigens had ik gehoord dat de controllers gezamelijk ingekocht zouden worden oid. Het is ook mogelijk om die controllers als sample te bestellen bij atmel zelf ik ken veel mensen die dit al eens gedaan hebben en na enkele weken een aantal ic's door de bus kregen ik geloof wel dat je niet meer dan 2 van elk type controller mag bestellen maar je wel meerdere soorten controllers ed tegelijk kan bestellen.

edit:

Ik zie nu dat je al een ontwerp van de software hebt, ik zal hem eens aandachtig bekijken en mischien commentaar leveren, denk dat je het wel goed kan omzetten in een objectmodel met duidelijke relatieomschrijving en methodes en attributen van objecten. Als je je software duidelijk en overzichtelijk wilt houden en makkelijk aan te passen. Wil wel een eerste opzet maken als je het niet erg vind anders. en het idee me helemaal duidelijk is.

Overigens had je het geloof ik ook al ergens over compatible zijn met mbm ed en volgens mij moet je dit dan via crystalfontz doen aangezien je geen paralelle poort aansluiting hebt voor je display. Ik heb ook weleens zoiets willen maken maar ik heb nog nergens het gehele protocol daarvan gevonden als je die hebt of iemand anders dan wil ik die iig ook graag hebben.

[Verwijderd]

Op vrijdag 15 maart 2002 21:17 schreef Vastloper het volgende:

[..]

Daar heb je gelijk in ja het is natuurlijk lastiger met single layer pcb, ik ben double layer gewend en daar kun je zulke problemen altijd oplossen dat zal nu niet altijd kunnen.

Ja double layer is altijd veeeel makkelijker wat dat betreft. Mar single layer is simpel en makkelijk te maken, vandaar de keuze in dit project.

Ik gebruik net als jij ook orcad, maar je hebt een setting waarmee je copper pours als connectie uit en aan kan zetten en afhankelijk van de template die je gebruikt staat die nog weleens uit en staat er in de statistics dus dat hij niet geroute is en als je naderhand autorouter nog gebruikt dan route hij ze alsnog. Als je naderhand het ground net nog weghaald, kan ik dat goed begrijpen dat je die eerst route op een single layer pcb,

Ik snap wat je bedoelt. Idd is hij bij mij zo ingesteld dat copper pour ook als "net" gezien mag worden.

en de spoke width zijn die 4 miezerige spoortjes van het thermal relief je ziet er een mooie tekening en uitleg van in de help bij thermal relief settings, deze heb ik breder om een betere verbinding te maken met de ground aangezien er bij sommige componenten toch best wat stroom kan gaan lopen. Ik begrijp alleen niet helemaal wat je bedoelt met dat je het anders niet goed gesoldeerd krijgt bedoel je dat als je die breder maakt of zonder thermal relief ofzo?

Nou optimaler zou zijn om de eilanden geheel te begraven in de copper-pour. Maar als je dat gaat solderen zul je merken dat het hele groundplane maar moeilijk warm te stoken is, zeker met een hobbyboutje. Er vloeit dan gewoon teveel warmte weg om netjes te solderen. Dat is ook de hele reden dat deze thermal reliefs bestaan! en vergis je niet, leg die 4 dunne lijntjes naast elkaat van b.v. 15 mil elk, en je hebt dus wel een track van 4x15=60mil.... En daar past erg veel stroom doorheen hoor!

Ik ben een beetje ontevreden over de autorouter, ik heb hem nog nooit gebruikt voor een single layer pcb maar mijn ervaring met double layer is dat hij vaak heel inefficient is en overal maar via's plaatst en vaak hele rare bochtjes maakt.

Gebruik je de autorouer in Layout of heb je de Smart-route gridless router ook?

Waar ik meestal juist op let is om mijn signaallijntjes zo kort mogelijk te houden

Dat is altijd verstandig.

en er een ground plane tussen te krijgen om daar crosstalk te voorkomen door parasitaire capaciteit, omdat daar juist meestal weinig stroom loopt maar toch veel wisselende spanning over staat komen daar juist veel wisselende elektrische velden af.

En dat is juist niet het geval! Onthoud als je EMC goed designed dat de sporen waar weinig stroom loopt juist "target" zijn voor storingen, terwijl sporen die veel stroom voeren juist "aggressor" zijn!

op ground en voeding staat een constante spanning en heb je dus juist geen parasitaire capaciteit ook loopt daar de meeste stroom door. En om je voeding stabiel te maken plaats ik bij elk ic dan ook een ontkoppelcondensator om de pieken ed eraf te halen.

Een ontkoppel condensator bij elk IC dient om de stroomvariaties die door het IC geproduceerd worden op te eten. Andersom redenerend zal deze ook stroomvariaties van buiten bij het IC weghouden.

Ook loopt de voeding en ground op veel meer plekken op je bord dan een signaal lijn en is die dus makkelijker te routen meestal. Mijn voorkeur blijft toch bij handmatig routen ook dit gaat meestal sneller dan je denkt en je kunt veel beter op bepaalde sporen letten die extra aandacht vergen zoals bijvoorbeeld van een crystal.

Ja onthoud altidj dat een stroom door de voeding een SPIEGEL van deze stroom onder zich zal opwekken! Een superdeluxe design zal dan ook altijd onder de voedingslijn een groundspoor hebben lopen, precies over elkaar (of een ground layer natuurlijk; al zal de stroom dan nog door het virtuele spoor onder de voeding lopen). Bij een single layer PCB is dat dus helaas pindakaas. De beste optie is dan om langs een voedingslijn altijd een ground(plane) in de buurt te hebben.

Probeer met de autorouter eens te spelen met gewichten; de kristallijnen hebben b.v. een gewicht 70, de voeding+gnd gewicht 60 en de rest gewicht 50. Nu zal de autorouter altijd de kristallijnen kort houden, ten koste van andere signalen met een lager gewicht.

Verder blijven het natuurlijk details en zal de print vast wel goed werken. Hoe staat het overigens met de software, want volgens mij is dat topic daar voor geopend. Waarin wil je de software maken c/assembly en wat voor interface wil je eraan geven gewoon telnet of een windows frontend?

Software in de AVR wordt op zeker C. Afhankelijk of ik deze code open source maak wordt het IAR C-compiler of de gratis Gnu C compiler. Om te configureren komt er een stukje windows software. Ik denk gemaakt in Borland C++ builder.

*KNIP*
Het is iig eerst belangrijk dat je een goede use case hebt iig in je hoofd en dan een duidelijk objectmodel opzet. Heb je al iets daarvoor gedaan of bedacht? Als je hulpt kunt gebruiken laat het dan even weten.

Zie http://www.xs4all.nl/~kruimpie

Helemaal onderaan zie je het voorlopige HW/SW codesign document staan. Hier vind je al een opdeling in modules, verdeling van de resources en beschrijvingen van de meeste SW modules.

Overigens had ik gehoord dat de controllers gezamelijk ingekocht zouden worden oid. Het is ook mogelijk om die controllers als sample te bestellen bij atmel zelf ik ken veel mensen die dit al eens gedaan hebben en na enkele weken een aantal ic's door de bus kregen ik geloof wel dat je niet meer dan 2 van elk type controller mag bestellen maar je wel meerdere soorten controllers ed tegelijk kan bestellen.

Ik heb hier nu 3 samples voor me liggen

Wellicht ga ik een kvk nummer aanvragen en via de groothandel bestellen. Niet alleen de AVRren maar alle componenten dan dus. Scheelt zo 50% in kosten

[Vastloper]

Bedankt voor de uitleg met routen zo leer ik ook weer wat.
Ik had je document gevonden en heb hem inmiddels snel doorgenomen ik zie dat je toch al verder gevordert bent met de software dan ik dacht, ik geloof alleen niet dat je echt uml of een andere object georienteerde ontwerpmethode hebt gebruikt.

Verder heb ik ook niks kunnen vinden over crystalfontz oid overigens draait dat op 19k2 ipv 9k6 dacht ik mischien kan dit nog een probleem leveren heb je daar ook al naar gekeken of wil je geen crystalfontz gebruiken? Dit lijkt me wel erg handig aangezien je dan in 1 keer compatible bent met vele programma's.

Ook vroeg ik me af of je handshaking gebruikt voor de seriele interface aangezien je op bepaalde momenten mischien te druk bent met andere taken en je dan mischien snel data kwijt kan raken wat is verstuurd als je een buffer overflow hebt. Het is dan natuurlijk wel belangrijk om die handshaking ook direct te gebruiken zodra je een buffer overflow interrupt krijgt ongeacht welk proces er op dat moment bezig is al wil je dat hij vlekkeloos werkt met de pc software en eventueel crystalfontz programma's.

[Verwijderd]

Op vrijdag 15 maart 2002 22:15 schreef Vastloper het volgende:
Bedankt voor de uitleg met routen zo leer ik ook weer wat.
Ik had je document gevonden en heb hem inmiddels snel doorgenomen ik zie dat je toch al verder gevordert bent met de software dan ik dacht, ik geloof alleen niet dat je echt uml of een andere object georienteerde ontwerpmethode hebt gebruikt.

WAAROM object georienteerd? daar leent dit ontwerp zich niet echt voor, zeker niet omdat veel modules erg zwaar leunen op de HW resources (timers etc). Ontwerpmethode = btje Ward/Mellor achtig...

edit:

Dit is typisch een project waarin dataflow diagrammen perfect werken... Het hele ding doet nix anders dan input, verwerken, output in essentie

Op dichter detailniveau zullen de state-transistie diagrammen nog wel komen denk ik

Verder heb ik ook niks kunnen vinden over crystalfontz oid overigens draait dat op 19k2 ipv 9k6 dacht ik mischien kan dit nog een probleem leveren heb je daar ook al naar gekeken of wil je geen crystalfontz gebruiken? Dit lijkt me wel erg handig aangezien je dan in 1 keer compatible bent met vele programma's.

Ik heb ernaar gekeken, en ik denk dat ik crystalfontz (en die andere ben ff de naam kwijt) allebei kan emuleren omdat beide een unieke commandoset hebben. 9600 of 19200.... maakt niet veel uit, de seriele poort in de AVR kan het allemaal

Ik hoopte zo ook programma's als smartie te kunnen gebruiken, alleen dat werkt alleen als de baybus "standalone" werkt, want er kan maar 1 progje tegelijk naar een seriele poort kletsen De plannen om een virtuele seriele poort te maken zijn op niets uitgelopen lijkt het.

Ook vroeg ik me af of je handshaking gebruikt voor de seriele interface aangezien je op bepaalde momenten mischien te druk bent met andere taken en je dan mischien snel data kwijt kan raken wat is verstuurd als je een buffer overflow hebt. Het is dan natuurlijk wel belangrijk om die handshaking ook direct te gebruiken zodra je een buffer overflow interrupt krijgt ongeacht welk proces er op dat moment bezig is al wil je dat hij vlekkeloos werkt met de pc software en eventueel crystalfontz programma's.

Huh handshaking? Nee totaal geen probleem met "te druk"; kwestie van een goed design. bytes worden ontvangen in een korte interrupt, verwerking geschiedt in de background dus los van alle realtime "taakjes". Een AVR kan bovendien HEEL WAT instructies uitvoeren tussen 2 seriele bytes in hoor! RTS/CTS b.v. kost gewoon te veel lijnen, word in praktijk nooit gebruikt omdat de AVR het makkelijk aan kan, XOn/XOFF zou kunnen in geval van nood, maar nogmaals, het moet makkelijk kunnen. Bovendien is overflow wel te signaleren in de UART van de AVR, dus registreren DAT het mis gegaan is kan ook nog... !!

[Xplosive]

Op vrijdag 15 maart 2002 20:09 schreef --EasY-- het volgende:

[..]

Hmmmm Dat is absoluut GEEN stomme vraag... Eerder stom dat ik het over het hoofd heb gezien.... Normaal bij een TTL uitgang moet het wel via een tor, omdat de FET op zijn gate echt de volle +12V moet krijgen om geheel te sluiten... 5V is niet voldoende. Maar omdat de poorten van de AVR OC zijn (dus alleen een N-kanaal naar aarde) KAN het werken zonder transistor denk ik.... Tanx je hebt weer 4 torren plus 4 weerstanden uit het design geoptimaliseerd

Volgens mij is een spanningsverschil van ongeveer 2V op de gate ten opzichte van de source, voldoende om de fet volledig te laten geleiden of sperren (dat ligt aan het type fet) Je zou de uitgang van je uC dus direct aankunnen sluiten op de gate ingang van je FET (zonder weerstand dus).

[Xplosive]

Op vrijdag 15 maart 2002 20:09 schreef --EasY-- het volgende:

[..]

Uhm die is WEL nodig, is namelijk de coldboot condensator. Deze houd de reset pin in reset als er spanning op de chip komt. Pas na opladen van deze condensator valt de reset af en zal de microcontroller booten. Op deze manier boot de controller pas als de spanning stabiel aanwezig is

Ja ik begrijp dat die nodig is maar zoals die nu in je schema staat (in serie met je vcc) zal condensator zich razend snel opladen maar voor de rest gebeurt er niks (er zal nog steeds een spanningsverschil van 5V zijn tussen de nReset en de VCC) zo zal de uC altijd in de reset toestand blijven staan. je kan het beter als volgt doen:



Op deze manier kan je precies berekenen hoelang de het duurt voordat de uC uit de reset toestand komt.

[Verwijderd]

Op zaterdag 16 maart 2002 13:59 schreef Xplosive het volgende:

[..]

Volgens mij is een spanningsverschil van ongeveer 2V op de gate ten opzichte van de source, voldoende om de fet volledig te laten geleiden of sperren (dat ligt aan het type fet) Je zou de uitgang van je uC dus direct aankunnen sluiten op de gate ingang van je FET (zonder weerstand dus).

Ja klopt toch, de FET gaat nooit volledig dicht als de V_gate 5V wordt, terwijl de voedingsspanning hoger is! Vergeet niet dat de fan op 12V loopt!

Dus ik heb de pullup weerstand naar +12V zeker wel nodig. Maar omdat de AVR een open collector output heeft met afschakelbarepullup naar +5V kan ik deze trap dus al direct gebruiken als stuurtrap. Als de open collector open is, zal de V_gate dan immers wel +12V worden.

[Verwijderd]

Op zaterdag 16 maart 2002 14:18 schreef Xplosive het volgende:

[..]

Ja ik begrijp dat die nodig is maar zoals die nu in je schema staat (in serie met je vcc) zal condensator zich razend snel opladen maar voor de rest gebeurt er niks (er zal nog steeds een spanningsverschil van 5V zijn tussen de nReset en de VCC) zo zal de uC altijd in de reset toestand blijven staan. je kan het beter als volgt doen:

[afbeelding]

Op deze manier kan je precies berekenen hoelang de het duurt voordat de uC uit de reset toestand komt.

Nee dat berekenen kun je totaal niet. Het inwendige circuit heeft nogal een grote onprecisie. Ja, met zo'n superkleine weerstand als jij hebt staan kun je het inwendige van de AVR wel weglaten, die is een dikke factor groter. Maar je hebt dan ook weer een heel dikke 1uF C nodig (je hebt er zelf een gepolariseerde inzitten???). Waarom zo moeilijk doen? Zoals ik het heb staan is standaard volgens de AVR spec, en klein en handig, dus waarom zou ik een extra weerstand nemen? In jouw schema krijgt een programmer het ook erg zwaar om die 390 ohm weerstand om te trekken.

[Vastloper]

Op zaterdag 16 maart 2002 14:29 schreef --EasY-- het volgende:

[..]

Ja klopt toch, de FET gaat nooit volledig dicht als de V_gate 5V wordt, terwijl de voedingsspanning hoger is! Vergeet niet dat de fan op 12V loopt!

KNIP

Het gaat toch alleen om de gate-drain spanning? niet de gate-source spanning? gate-drain kan dan gewoon 0 of 5V worden de gate-source is dan 7V of gaat er dan soms een stroom van de source naar de gate lopen? dan zou je dan toch doormiddel van high-z op de pin en eventueel een pull down weerstand je microcontroller beschermen of gaat dan de fan alsnog draaien. Ik dacht iig dat de gate-source spanning niet van belang is en kun je het anders niet met behulp van een extra diode tegengaan?

edit:

Ik heb nog eens gelezen wat je allemaal zegt en ik heb je geloof ik niet helemaal goed begrepen, maar wat je zegt heb ik iig nog niet eerder van gehoord. ik kan me voorstellen dat je kanaal idd verder open gaat met meer spanning maar gaat het dan niet om de stroom die je erodoorheen kan krijgen of iig het vermogen? Meer spanning heeft toch geen breder kanaal nodig, maar meer stroom wel toch?

[Xplosive]

Op zaterdag 16 maart 2002 14:36 schreef --EasY-- het volgende:

[..]

Nee dat berekenen kun je totaal niet. Het inwendige circuit heeft nogal een grote onprecisie. Ja, met zo'n superkleine weerstand als jij hebt staan kun je het inwendige van de AVR wel weglaten, die is een dikke factor groter. Maar je hebt dan ook weer een heel dikke 1uF C nodig (je hebt er zelf een gepolariseerde inzitten???). Waarom zo moeilijk doen? Zoals ik het heb staan is standaard volgens de AVR spec, en klein en handig, dus waarom zou ik een extra weerstand nemen? In jouw schema krijgt een programmer het ook erg zwaar om die 390 ohm weerstand om te trekken.

In mijn schema staat een 390K ohm weerstand, mischien niet helemaal duidelijk maar toch.

[Vastloper]

Op zaterdag 16 maart 2002 14:36 schreef --EasY-- het volgende:

[..]

Nee dat berekenen kun je totaal niet. Het inwendige circuit heeft nogal een grote onprecisie. Ja, met zo'n superkleine weerstand als jij hebt staan kun je het inwendige van de AVR wel weglaten, die is een dikke factor groter. Maar je hebt dan ook weer een heel dikke 1uF C nodig (je hebt er zelf een gepolariseerde inzitten???). Waarom zo moeilijk doen? Zoals ik het heb staan is standaard volgens de AVR spec, en klein en handig, dus waarom zou ik een extra weerstand nemen? In jouw schema krijgt een programmer het ook erg zwaar om die 390 ohm weerstand om te trekken.

Kun je mischien aangeven waar in de spec (paginanummer) jij een condensator in serie op de nRESET ziet staan want dit heb ik echt nergens gezien en zoals Xplosive ook zegt een condensator in een gelijksspanningsnetwerk is in feite een isolator op een kleine lekstroom na. Het spanningsniveau tussen de nRESET en de Vcc zal zover ik weet gehandhaafd blijven en er zal nooit 5V op de nRESET komen en zal hij dus altijd in de reset blijven hangen op deze manier. Overigens word er in bijvoorbeeld een STK200 voor de atmel, die van atmel zelf is, een RC netwerk van 43K en 100nF gebruikt voor coldstart vervolgd door een 1M ohm weerstand naar de nRESET dit zou volgens mij berekening ongeveer een tijd van 0,01s opleveren asl coldstart en de 1M weerstand heeft als gevolg dat het inwendige circuit van de van de nRESET nog nauwelijks effect kan hebben.

[Vastloper]

Ik las trouwens nog dat je mischien de interne diode van een athlon wilde inlezen, maar nog niet precies wist hoe. Ik had een tijdje terug een PDF'je gezien waarin alles hierover staat uitgelegd en hoe je het met behulp van 2 verschillende soorten ic's kunt doen. Via zo'n IC is waarschijnlijk geen optie meer maar hieruit kun je mischien wel een andere methode achterhalen. Mischien kun je het anders gewoon via de SMbus ophalen bij bepaalde moederborden maar dit zal denk ik ook afhankelijk zijn van het moederbord. Het document is iig hier te vinden:
http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/24228.pdf

[Verwijderd]

Op zaterdag 16 maart 2002 14:42 schreef Vastloper het volgende:

[..]

Het gaat toch alleen om de gate-drain spanning? niet de gate-source spanning? gate-drain kan dan gewoon 0 of 5V worden de gate-source is dan 7V of gaat er dan soms een stroom van de source naar de gate lopen? dan zou je dan toch doormiddel van high-z op de pin en eventueel een pull down weerstand je microcontroller beschermen of gaat dan de fan alsnog draaien. Ik dacht iig dat de gate-source spanning niet van belang is en kun je het anders niet met behulp van een extra diode tegengaan?

edit:

Ik heb nog eens gelezen wat je allemaal zegt en ik heb je geloof ik niet helemaal goed begrepen, maar wat je zegt heb ik iig nog niet eerder van gehoord. ik kan me voorstellen dat je kanaal idd verder open gaat met meer spanning maar gaat het dan niet om de stroom die je erodoorheen kan krijgen of iig het vermogen? Meer spanning heeft toch geen breder kanaal nodig, maar meer stroom wel toch?

Uhm.... om zo'n FET echt goed open te krijgen werkt +12V sowieso beter. Alleen al omdat de schakelflank steiler wordt. De gate is volledig spanningsgestuurd, hierdoor loopt dus nooit een hoge stroom (tenzij je net schakelt omdat een FET een grote C_{gate,parasitair} heeft.

Ik kan eens simuleren met +5v, wat het nu echt scheelt... Of de flank vlakker wordt, en of de FET lekker goed dicht wil. Ik weet in ieder geval dat echte n-channel FET drivers wel degelijk de volle +12V erop zetten voor het beste resultaat

[Verwijderd]

Op zaterdag 16 maart 2002 14:52 schreef Vastloper het volgende:

[..]

Kun je mischien aangeven waar in de spec (paginanummer) jij een condensator in serie op de nRESET ziet staan want dit heb ik echt nergens gezien en zoals Xplosive ook zegt een condensator in een gelijksspanningsnetwerk is in feite een isolator op een kleine lekstroom na.

Pagina 106 van de complete datasheet van de AT90S8535 daar staat de resetpin's interne pullupweerstand: tussen 100K en 500K. Dus geen externe weerstand benodigd

Alleen ook ik heb niet goed gelezen, de AT89Cxxxx serie waar ik veel ervaring mee heb heeft een RESET lijn, de AVR een nRESET lijn

Dus wederom bedankt, ik moet mijn C naar ground leggen ipv 5V zoals bij de 89C serie

Het spanningsniveau tussen de nRESET en de Vcc zal zover ik weet gehandhaafd blijven en er zal nooit 5V op de nRESET komen en zal hij dus altijd in de reset blijven hangen op deze manier. Overigens word er in bijvoorbeeld een STK200 voor de atmel, die van atmel zelf is, een RC netwerk van 43K en 100nF gebruikt voor coldstart vervolgd door een 1M ohm weerstand naar de nRESET dit zou volgens mij berekening ongeveer een tijd van 0,01s opleveren asl coldstart en de 1M weerstand heeft als gevolg dat het inwendige circuit van de van de nRESET nog nauwelijks effect kan hebben.

Dit is een vreemd circuit aangenomen dat de AVR een interne pullup heeft...?? Die 43K/100nF snap ik nog wel, dan gebruik je effectief de interne (onprecieze) pullup niet. Die 1M ohm naar de reset snap ik dan niet, hoe krijgen ze die lijn ooit laag getrokken als de interne pullup 100K-500K is? Vaag.....

Conclusie: NEE een externe weerstand is niet nodig, en NEE ik had niet opgelet... De reset-C moet naar GND

[Verwijderd]

Op zaterdag 16 maart 2002 15:22 schreef Vastloper het volgende:
Ik las trouwens nog dat je mischien de interne diode van een athlon wilde inlezen, maar nog niet precies wist hoe.

Ja ik heb me wel eens gewaagd aan een bezoekje aan www.amd.com maar dat was niet echt snel te vinden... en ja tijd tijd tijd he

Ik had een tijdje terug een PDF'je gezien waarin alles hierover staat uitgelegd en hoe je het met behulp van 2 verschillende soorten ic's kunt doen. Via zo'n IC is waarschijnlijk geen optie meer maar hieruit kun je mischien wel een andere methode achterhalen.

ICtjes op zich is geen optie nee. Misschien in V2.... Maar het uitlezen... ja dat zou goed kunnen, ook met deze baybus al misschien. Ik heb wel op amd.com gezien dat ze ergens op de ZIF voet van de Athlon XP 2 draadjes soldeerder waaraan dan de interne thermal diode zat. Dus dat is in ieder geval deel 1

Ik denk dat die ICtjes nix meer dan opampjes zijn? Zo ff kijken....

Mischien kun je het anders gewoon via de SMbus ophalen bij bepaalde moederborden maar dit zal denk ik ook afhankelijk zijn van het moederbord. Het document is iig hier te vinden:
[..]

Via de SMbus ophalen... ik heb erover nagedacht, maar dat gaat niet lukken denk ik, zelfs al heb je een mobo die het lezen kan. Ik begreep dat de SMbus een I²C bus is. Deze is single master multi-slave. Ik kan hier dus geen data venaf halen, hoogstens de bus "snoopen" en hopen dat de meetwaarde een x voorbij komt.

Alternatief is via een windows programma die de SMbus leest en het daarna via de seriele poort naar de baybus stuurt. Maar die optie had ik al bedacht, ook voor de overige tempsensoren op mobo's. Wellicht kunnen we de maker van Smartie overtuigen om deze waarden serieel over te pompen via zijn applicatie

iig tanx voor de link.... scheelt mij weer veel zoekwerk. Ik zal wel kijken of de ingang van de baybus compatible is met deze sensor... Dan gaan we eindelijk eens ECHT tempmeten

[edit]
Was idd hetzelfde bestandje wat ik gevonden had... De XP diode blijkt inderdaad niets meer dan een PN junctie die verloopt met de temperatur... dat moet wel te meten zijn, ik denk zelf zonder extra hardware buiten de baybus zoals deze er nu ligt. Als ik hem aan de praat heb ga ik er wel mee experimenteren...

Dan kan ik zelfs b.v. als de delta-t tussen 2 samples groter is dan x graden (chip wamrt te snel op) een relais bekrachtigen die het mobo "droog" zet

Zou nog wel eens een XPtje kunnen redden die zijn koeler verliest

[Verwijderd]

Pfff dit SOFTWARE draadje staat wederom VOL met hardware-items.... Vandaar dat ik dit draadje wil splitsen in 2 draadjes:

De hardware: [topic=441366/1/50]

De software: [topic=441370/1/50]

Hopelijk kan iedereen nu beter zijn of haar ei kwijt