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

[Anoniem: 35245]

De hardware voor de extreme multi baybus lijkt rond; de hardware specs:

- Gebaseerd op Atmel AVR microcontroller AT90S8535-8PC
- In system programmeerbaar via een tijdelijke printerpoort kabel
- EEPROM onboard t.b.v. opslag configuratie/opties
- reguliere interface via de seriele poort
- Aansturing voor 4 12V FANs via PWM
- Meting van 4 temperatuursensoren (NTC/PTC type)
- Meting van toerental van 2 FANs of 1 FAN + harddisk activity
- 3 druktoetsen
- 8 vrij bestuurbare LEDs
- LCD interface

Voor schema + PCB printscreentje zie http://www.xs4all.nl/~kruimpie

Hmm dat is het wel zo'n beetje qua hardware.Om hiervoor software te maken heb ik eisen/ideeen/kritiek nodig. Omdat het nogal een complex geheel is, wil ik de specs in stukjes hakken in de volgende items:

- configuratie. In EEPROM wil ik de complete config opslaan, die via RS232 instelbaar/opvraagbaar moet zijn. Vooral dus een lijst met items!!!
- FAN regeling. In principe wil ik kunnen regelen op toerental (closed loop), temperatuur (closed loop), of serieel (open loop te sluiten via PC software)
- LED features. Temperatuur aanduiding? Statusmelding? HDD activity meter en varianten zoals nightrider, bar, centred bar... eventueel: LEDs PWM aanstuurbaar (faden)? Het is zelfs mogelijk 2,4,6 of alle 8 LEDs te vervangen door 1,2,3 of 4 2-kleurenLEDs, die dan kunnen faden van b.v. groen naar geel naar rood! Wow wat is er eigenlijk NIET mogelijk...
- LCD features. Weergave van de module zelf, opties om er zelf teksten op te zetten via serieel...
- initialisatie: Wat moet er allemaal gebeuren tijdens initialisatie? b.v. initiele FAN snelheden, meten van eventuele RPM-PWM krommen t.b.v. regelalgoritmes...
- alarmering: wat te doen bij... watchdog indien fans via serieel worden bestuurd (en de software geeft het op)... Overschrijding van een gemeten temperatuur? enz enz

Ik PROBEER dit alles te vangen in schematische overzichten, om zo tot een volledig en mooi systeem te komen!

Dus.... kom maar op met je eisen/wensen/vragen!!!

edit:

Ik kan nu ff niet FTPen, dus het schema+PCB op de site zijn nog niet helemaal up-to-date

[Mennootje]

Voor de LED-features:

- Aanduiding duty-cycle% via LED-bar of misschien rood<-->groen fading duoledje. (eerste lijkt me mooier maar kost meer ruimte)

LCD:

- Compatible met bijv. MBM en Winamp (de apps die je bij voorkeur op je lcd wilt laten zien)
- BARS die dutycycle% laten zien van fans (niet te ingewikkelde electrostuff op je lcd, boeit niet zoveel)

Voor de rest:

- Alles via softwarescherm in te stellen/veranderen. (Bijv. schuifbalkje om fansnelheid in te stellen)
- Optie voor regeling via tempsensor of niet.
- Compatible met alle OSes (Win9x, XP, 2000 enz.)

Succes ermee, als dit alles niet te duur wordt schaf ik er zeker eentje aan.

[Harrie]

[off-topic]
Ik zie dat jij beter over weg kan met Pspice dan ik....
[/off-topic]

[Robino]

- In system programmeerbaar via een tijdelijke printerpoort kabel
- EEPROM onboard t.b.v. opslag configuratie/opties

Hier bedoel je dan toch mee dat je instellingen opslaat door tijdelijk een kabel vanaf je printerpoort erop aan te sluiten? Dit lijkt mij zeer taktisch.

Wat je naar mijn mening wel kan doen.
Afwisselend de temp., fan-speed, en je eigen dingen zoals WinAmp/Seti@home op het schermpie kunnen laten zien.

Of dat je kan kiezen:
Knop 1: Fan speed auto
Knop 2: Fan speed hoog
Knop 3: Fan speed middelmatig
Knop 4: Fan speed laag

Als je het allemaal af heb wil ik wel het printplaatje bestellen zodat ik het zelf kan maken, lijkt me vet

Je zei dat je 3 kleuren LED's kan laten overlopen aan de hand van, volgens mij, de snelheid/temp. dat lijkt me er vet gaaf uitzien

[Anoniem: 35245]

Op woensdag 27 februari 2002 16:22 schreef philippi14 het volgende:
[off-topic]
Ik zie dat jij beter over weg kan met Pspice dan ik....
[/off-topic]

oefenen

[Anoniem: 35245]

Op woensdag 27 februari 2002 16:24 schreef Rave17 het volgende:

[..]

Hier bedoel je dan toch mee dat je instellingen opslaat door tijdelijk een kabel vanaf je printerpoort erop aan te sluiten? Dit lijkt mij zeer taktisch.

Het configureren gaat via een continu aangesloten kabel op een seriele poort (die je overigens ook loshalen kan ja )

dat printerpoortverhaal slaat op het programmeren van de microcontroller, de code dus die in dat processortje te draaien komt.

Wat je naar mijn mening wel kan doen.
Afwisselend de temp., fan-speed, en je eigen dingen zoals WinAmp/Seti@home op het schermpie kunnen laten zien.

Of dat je kan kiezen:
Knop 1: Fan speed auto
Knop 2: Fan speed hoog
Knop 3: Fan speed middelmatig
Knop 4: Fan speed laag

Als je het allemaal af heb wil ik wel het printplaatje bestellen zodat ik het zelf kan maken, lijkt me vet

Ik heb maar 3 knoppen

Bovendien kun je 4 fans sturen, dus voor zoiets als je beschrijft moet je OFWEL op je PC een progje hebben die via serieel dit doet OF er moet via de 3 knoppen een menutje op het LCD display getoverd worden (a la monitor menu)

Zijn er nog mensen die overwegen ZONDER LCD display te gaan bouwen? Want dat kan ook natuurlijk... zelfs ook zonder LEDs als je wilt! Moet wel in software voorzien worden dan...

[Anoniem: 44042]

kun je die niet op de markt brengen kben wel geïnteresseerd, met een flashy uitvoering die je extern kan op je case zetten

[Chimera]

Wat word ongeveer de prijs?

[Anoniem: 44042]

vergeten de mrijs de vragen goeie opmerking , voor mij zal dat wel gratis zijn omdat ik hem op het idee bracht omhet te gaan verkopen, en ik krijg er bovendien een luxe uitvoering bovenop en extra frontjes voor de baybus met verschillende kleuren van leds

[Chimera]

Op woensdag 27 februari 2002 17:15 schreef Molshoop het volgende:
vergeten de mrijs de vragen goeie opmerking , voor mij zal dat wel gratis zijn omdat ik hem op het idee bracht omhet te gaan verkopen, en ik krijg er bovendien een luxe uitvoering bovenop en extra frontjes voor de baybus met verschillende kleuren van leds

Ik denk dat ie toch al van plan was het te gaan verkopen, zeker eerst iedereen lekker maken en dan niet verkopen (maar ja ik moet eerst sparen voor een nieuwe comp, een mooie Hammer, ik moet nl. van deze PIII 450MHz af )

[hightower]

Kan de communicatie niet via de SMBus ???
OF de USB. Dan kun je mooi de draadjes binnenboord houden

[H@rry]

Op woensdag 27 februari 2002 16:05 schreef --EasY-- het volgende:

- Meting van toerental van 2 FANs of 1 FAN + harddisk activity

kan je het niet voor mekaar krijgen om gewoon alle 4 de fans te meten?
en waarom niet? (ik ben nieuwsgierig want deze baybus staat me wel aan )

[SlinkingAnt]

Wensen:
Ook te gebruiken zonder lcd scherm
Makkelijke instelbaarheid rpm fans dmv percentages of
schuifbalkjes

Led's:
Keuze tussen diverse lichtschema's 2 kleuren, en bv als alarm een knipperfuchtie ofzow. (misschien nog een zoemertje erbij? zou wel ideaal zijn)

Verder kan ik niet iets bedenken dat wel handig zou zijn en hier nog niet bijstaat!

perfect plan zo!

[Chimera]

Waarin wilde je de SW gaan proggen?

<font size="1">En ga je de source ook vrijgeven? :9~</font>

[off-topic]
In Dreamweaver werkt het zo, en hier ?¿ (de kleine text)
[/off-topic]

[Anoniem: 35245]

Op woensdag 27 februari 2002 17:06 schreef Molshoop het volgende:
kun je die niet op de markt brengen kben wel geïnteresseerd, met een flashy uitvoering die je extern kan op je case zetten

Humm extern op je kast zetten? Dat is een leuke.... Dan kun je er beter 2 bouwen, eentje met alle MMI features (LCD,LED,knoppen), en een "kale" met alleen de hardware I/O, en die verbinden via de RS232 als null modem...

Ook nog een leuk ID..!!

edit:

Kost geeneens zoveel meer... alleen de PCB, de microcontroller en RS232 is dubbel...!! En een kastje natuurlijk met wat stekkerwerk, de "desktop variant" kan af met alleen +5V, wat je misschien uit je gamepoort kan trekken....

[Anoniem: 35245]

Op woensdag 27 februari 2002 17:13 schreef Chimera2k2 het volgende:
Wat word ongeveer de prijs?

Tja en moeilijk punt... Afhankelijk van de optie hoe je hem bouwt (vergelijk maar eens geen LCD rode LEDs met een 20x4 backlight LCD met blauwe LEDs) kun je een "no-budget" versie hebben voor een euro of 40 (misschien zelfs minder), oplopend tot zo'n 150 euro voor de "super-duper-deluxe"

[Anoniem: 35245]

Op woensdag 27 februari 2002 17:26 schreef hightower het volgende:
Kan de communicatie niet via de SMBus ???
OF de USB. Dan kun je mooi de draadjes binnenboord houden

SMbus? Is dat een standaard?

USB zou kunnen, ik zie niet zoveel voordeel. Weer een extra USB controller nodig enzo. Serieel is inderdaad wel vervelend als je geen headers ervoor op je mobo hebt, dan krij je idd een kabeltje uit je pc die direct teruglust naar een seriele poort

[Anoniem: 35245]

Op woensdag 27 februari 2002 17:27 schreef 007BigHarry het volgende:

[..]

kan je het niet voor mekaar krijgen om gewoon alle 4 de fans te meten?
en waarom niet? (ik ben nieuwsgierig want deze baybus staat me wel aan )

Misschien is het mogelijk. Helaas is het meten van het toerental nog een heet hangijzer, het is nog niet helemaal duidelijk hoe dit goed te meten is. Voorlopig zijn er 2 toeren-inputs voorzien op de twee timer-ingangen van de AVR microcontroller, daarmee heb je maximale flexibiliteit en kun je altijd wel iets meten.

Wellicht blijkt het redelijk eenvoudig, dan kan er misschien via een modificatie alsnog 4 kanalen gemeten worden. Gelukkig is het meten niet echt nodig om toch netjes toeren te kunnen sturen, alleen stuur je dan dutycycle (0-100%) in plaats van een doel toerental (wat netter is en beter controleerbaar)

edit:

Nog een ID wat ik had: Zet PWM op 100%, meet de tijd tussen 2 RPM pulsen en schakel de PWM terug. Als je dit 1x per 1 of 5 seconde doet ofzo dan zie je dit nauwelijks terug in de toeren van de fan, maar de meting is wel superdeluxe!

Via deze truuk is het misschien mogelijk om 4 inputs te meten... Of hier nog hardwareaanpassingen voor nodig zijn weet ik nog niet 1-2-3

[Anoniem: 35245]

Op woensdag 27 februari 2002 17:37 schreef SlinkingAnt het volgende:
Wensen:
Ook te gebruiken zonder lcd scherm
Makkelijke instelbaarheid rpm fans dmv percentages of
schuifbalkjes

Led's:
Keuze tussen diverse lichtschema's 2 kleuren, en bv als alarm een knipperfuchtie ofzow. (misschien nog een zoemertje erbij? zou wel ideaal zijn)

Verder kan ik niet iets bedenken dat wel handig zou zijn en hier nog niet bijstaat!

perfect plan zo!

Aha, een stem voor gebruik zonder LCD. In principe geen probleem, via de seriele poort kun je alles instellen en teruglezen...

De LED balk krijgt sowieso een aantal modi waarin hij kan werken. incl. knipperen etc. Een buzzer is eenvoudig toe te voegen, die kan op b.v. de plaats van de 8e LED worden aangesloten, of b..v. op een temperatuur-ingang die je niet gebruikt. Ik zal er in SW rekenng mee houden dat deze pinnen geconfigureerd kunnen worden als buzzer output.

[Anoniem: 35245]

Op woensdag 27 februari 2002 17:49 schreef Chimera2k2 het volgende:
Waarin wilde je de SW gaan proggen?

<font size="1">En ga je de source ook vrijgeven? :9~</font>

[off-topic]
In Dreamweaver werkt het zo, en hier ?¿ (de kleine text)
[/off-topic]

Uhm ik denk in "c". Ik zelf heb beschikking over de IAR C-compiler voor de AVR, maar die is niet gratis. Indien mogelijk wellicht via de gnu C-compiler, die is gratis en dan kan iedereen mee hacken

Ik moet nog maar ff zien. In ider geval wordt het GEEN assemly, dit ding wordt redelijk complex en dan is assembly maar slecht onderhoudbaar (en nu aub geen diskussie over voors en tegens assembly vs. "c" want deze draad is al druk genoeg!)

[snars]

Op woensdag 27 februari 2002 18:03 schreef --EasY-- het volgende:

[..]

SMbus? Is dat een standaard?

USB zou kunnen, ik zie niet zoveel voordeel. Weer een extra USB controller nodig enzo. Serieel is inderdaad wel vervelend als je geen headers ervoor op je mobo hebt, dan krij je idd een kabeltje uit je pc die direct teruglust naar een seriele poort

http://www.smbus.org/
Smbus is een databus met twee lijnen: een klokfrequentiedinges en een datalijn. Asus-boards hebben standaard een header hiervoor (tenminste, van Asus weet ik het), en bij alle andere mobo's kan je em van pin x en y ( weet nog niet precies welke ) van de DIMM-sloten aftappen. Ik ga een maxim 6957 IC gebruiken om de ondie-tempsensor van m'n XP uit te lezen via SMbus (Motherboard Monitor ondersteunt dit standaard). Zie [topic=376439/1/25]

[snars]

Weet je wat ik zou willen zien op zo'n baybus? Een mogelijkheid om een relais [b]direct[b] aan te sturen. Gewoon: als de cpu-temp te hoog wordt, OVERAL (dus comp, waterpomp en peltiervoeding) de stroom eraf.
Owjah en dus een ingang voor de ondie-tempsensor van de XP.

[Anoniem: 35245]

Op woensdag 27 februari 2002 18:13 schreef _sNaRs_ het volgende:

[..]

http://www.smbus.org/
Smbus is een databus met twee lijnen: een klokfrequentiedinges en een datalijn. Asus-boards hebben standaard een header hiervoor (tenminste, van Asus weet ik het), en bij alle andere mobo's kan je em van pin x en y ( weet nog niet precies welke ) van de DIMM-sloten aftappen. Ik ga een maxim 6957 IC gebruiken om de ondie-tempsensor van m'n XP uit te lezen via SMbus (Motherboard Monitor ondersteunt dit standaard). Zie [topic=376439/1/25]

Aha ik snap het. Een synchroon serieel protocolletje. Het kan zonder meer, de software krijgt een rs232 drivertje die gebruik maakt van de UART onbaord van de AVR, je zou deze driver kunnen vervangen voor een SMbus drivertje, waarbij de RXD b.v. clock wordt en de TXD bidirectionele data. Ik ga het NIET maken (in eerste instantie in ieder geval); de seriele poort is zeer standaard, vrijwel ongebruikt en de AVR heeft een hardware UART hiervoor ingebakken.

[Anoniem: 35245]

Op woensdag 27 februari 2002 18:17 schreef _sNaRs_ het volgende:
Weet je wat ik zou willen zien op zo'n baybus? Een mogelijkheid om een relais [b]direct[b] aan te sturen. Gewoon: als de cpu-temp te hoog wordt, OVERAL (dus comp, waterpomp en peltiervoeding) de stroom eraf.
Owjah en dus een ingang voor de ondie-tempsensor van de XP.

Een relais-optie is reeds voorzien; de mode van een FAN output omhelst onder andere een botte aan/uit mode waarmee je relais kunt sturen.

Die ondie sensor moet ik eens induiken... als hij NTC/PTC gebaseerd is kan het zondr meer. Is hij "digitaal" via een synchroon protocolletje dan kan die uitleesbaar worden gemaakt door 2 temp sensor inputs öp te offeren" warbij 1 de clockpulsen gaat genereren en de 2e data gaat inlezen... Ik ga daar toch eens induiken!

[hightower]

Op woensdag 27 februari 2002 18:03 schreef --EasY-- het volgende:

[..]

SMbus? Is dat een standaard?

USB zou kunnen, ik zie niet zoveel voordeel. Weer een extra USB controller nodig enzo. Serieel is inderdaad wel vervelend als je geen headers ervoor op je mobo hebt, dan krij je idd een kabeltje uit je pc die direct teruglust naar een seriele poort

SMBus is idd een standaard, tref je zeker op asus mobo's aan.

En wat betreft die USB, in mijn geval heb ik die wel over. Heb ruimte voor 6 usb poorten.

[Anoniem: 35245]

Op woensdag 27 februari 2002 18:41 schreef hightower het volgende:

[..]

SMBus is idd een standaard, tref je zeker op asus mobo's aan.

En wat betreft die USB, in mijn geval heb ik die wel over. Heb ruimte voor 6 usb poorten.

De SMbus is dus zeker niet te vinden op alle mobo's zonder mod. Daarom ga ik in ieder geval als eerste een seriele variant maken. Dit is echter meer een software aangelegenheid, de hardware kan waarschijnlijk ook wel voor de SMbus gebruikt worden (ik denk 3 draadbruggen en de max232 seriele tranceiver eraf)

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. De grotere bandbreedte van USB is in deze applicatie ook van geen belang. Al met al, zeg neeeee tegen usbeeee

*LOL*

[snars]

Ja...wat je kan doen (kheb ff de pics niet klaar liggen) is een 'dummy'-DIMM-stick maken...die dan contact maakt met de juiste pins..maar genoeg over die SMbus

Wat ik weet van die ondie-tempsensor van de Athlon XP is dat het een 'diode-connected transistor' is....kan je daar iets mee?

[Anoniem: 35245]

Op woensdag 27 februari 2002 19:49 schreef _sNaRs_ het volgende:
Ja...wat je kan doen (kheb ff de pics niet klaar liggen) is een 'dummy'-DIMM-stick maken...die dan contact maakt met de juiste pins..maar genoeg over die SMbus

Wat ik weet van die ondie-tempsensor van de Athlon XP is dat het een 'diode-connected transistor' is....kan je daar iets mee?

Ik zal de specs er wel eens op nalopen... Ik hoop niet dat ik daarvoor de XP datasheet hoef te downloaden

Er zal best wel documentatie zijn van het geheel... Morgen zoek ik dat wel ff op....

[Anoniem: 35245]

Op woensdag 27 februari 2002 19:49 schreef _sNaRs_ het volgende:
Ja...wat je kan doen (kheb ff de pics niet klaar liggen) is een 'dummy'-DIMM-stick maken...die dan contact maakt met de juiste pins..maar genoeg over die SMbus

*KNIP*

AHA nu gaat het me dagen over die SMbus... Dat is gewoon de seriele bus waarmee ze die 8 pins EEPROM chippies uitlezen op de DIMM.... duuuh dat is een supersimpel serieel truukje... clocklijn/datalijn.... Een soort I[super]2[/super]C maar volgens mij dan nog simpeler... een SPI busje ofzo.... Goh kun je die ook zelf aansturen... Als de tijd rijp is ga ik daar misschien wel een stukje software voor schrijven... dat zou dan de slave-kant moeten zijn, die is net weer iets lastiger dan de masterkant...

[Anoniem: 7787]

hoe meer ik hiervan lees, hoe meer ik hoop dat jij die spullen laat etsen en gaat verkopen

[Anoniem: 35245]

Op woensdag 27 februari 2002 22:48 schreef westcoastleader het volgende:
hoe meer ik hiervan lees, hoe meer ik hoop dat jij die spullen laat etsen en gaat verkopen

De eerste ga ik zelf etsen, testen, debuggen en gebruiken als development platform voor de software. Zodra ik weet dat de hardware 100% in orde is, en ik in ieder geval basis software heb, ga ik o.a. via GOT pollen hoeveel mensen interesse hebben. Zodra ik voldoende interesse heb, vraag ik de mensen vooruit te betalen (ja ik heb ervaring helaas), dan worden de printen besteld, en afhankelijk wat de mensen willen de kale PCB / bouwpakket/ volledig gebouwd opsturen... Ik zal daarvoor te zijner tijd een aantal basis modellen op de site zetten... een "no budget", een middenklasser er natuurlijk de super-duper-deluxe...

Daarnaast kunnen mensen PCB's kaal bestellen of bouwpakketten... ik probeer in 1 klap zo groot mogelijk te bestellen, want grote aantallen = meer voordeel. Minder dan 25 PCB's moet je sowieso niet bestellen, dan zijn de aanloopkosten veel te groot. Dan is zelf etsen nog een oplossing, maar 25 PCB's etsen daar wordt je ook niet vrolijk van... Bovendien is het moeilijk om een goede kwaliteit te halen.

Deze manier van werken lijkt me de enige werkende optie, ik zie toch de gemiddelde tweaker niet eerst een lichtbak bouwen en met etsmiddel aan de slag gaan....

[SlinkingAnt]

school?

Maar zou wel mooi zijn als je ook alleen de onderdelen kunt bestellen Verder heb ik wel interresse in een bouwpakker anders.

[C@SP]

Ik ben erg benieuwd naar de het resultaat, en ik zie zo'n bouwpakketje wel zitten

[Anoniem: 35245]

Op donderdag 28 februari 2002 12:01 schreef I_Love_Heineken het volgende:
Ik ben erg benieuwd naar de het resultaat, en ik zie zo'n bouwpakketje wel zitten

Toch zul je nog ff geduld moeten hebben; de ontwikkeling kost toch wel even tijd...

[im_ik]

* im_ik heeft ook een idee

de chip:
http://www.wiznet.co.kr/e_i2chip/e_pro_ass.htm
extra info:
http://www.chipcenter.com/circuitcellar/october01/c1001su4.htm

Dit is een netwerk chip met een tcp/ip layer erin, en een simple 8bit interface.
Hij kan 4 connecties tegelijkertijd aan.
En als je er now een deamon op laat draaien.
Dan kan idereen een progje maken
en verschillede projes voor verschillende doeleinden

[Skef]

Misschien kun je hier eens kijken...

Wij zijn er dus ook mee bezig, alleen nog iets uitgebreider (denk ik)..

Misschien wat voor jou om ook met ons mee te denken?

[Anoniem: 35245]

Op donderdag 28 februari 2002 14:22 schreef im_ik het volgende:
* im_ik heeft ook een idee

de chip:
http://www.wiznet.co.kr/e_i2chip/e_pro_ass.htm
extra info:
http://www.chipcenter.com/circuitcellar/october01/c1001su4.htm

Dit is een netwerk chip met een tcp/ip layer erin, en een simple 8bit interface.
Hij kan 4 connecties tegelijkertijd aan.
En als je er now een deamon op laat draaien.
Dan kan idereen een progje maken
en verschillede projes voor verschillende doeleinden

Dit is een heeeel ander project... Ik zou zeggen... knoop deze chip aan mijn microcontroller en schrijf je eigen I/O driver... dan kun je je FANs regelen over ethernet.... uhmmmm kun je me precies het nut/voordelen uitleggen?

Volgens mij sleep je zo alleen een berg ellende, kosten en een niet of nauwelijks verkrijgbare dure chip het project in....

[im_ik]

Op donderdag 28 februari 2002 14:40 schreef --EasY-- het volgende:

[..]

Dit is een heeeel ander project... Ik zou zeggen... knoop deze chip aan mijn microcontroller en schrijf je eigen I/O driver... dan kun je je FANs regelen over ethernet.... uhmmmm kun je me precies het nut/voordelen uitleggen?

Volgens mij sleep je zo alleen een berg ellende, kosten en een niet of nauwelijks verkrijgbare dure chip het project in....

Was maar een ideetje
maar ik ga wel proberen een aantal van die chipjes zelf te krijgen..

[Anoniem: 35245]

Op donderdag 28 februari 2002 14:23 schreef Skef het volgende:
Misschien kun je hier eens kijken...

Wij zijn er dus ook mee bezig, alleen nog iets uitgebreider (denk ik)..

Misschien wat voor jou om ook met ons mee te denken?

Ja hier heb ik al eens gekeken... Fijn dat de development sectie gesloten is

Ik zie alleen maar "natte dromen" (hahaha waterforum )van allerlei gebruikers. Nergens echte specs, keuzes, afwegingen, haalbaarheden of iets dergelijks? Ik zou wel eens MCU keuze, verdeling I/O poorten enzo willen zien?

Wel wat losse termen, zoals insteekkaarten... Dat maakt het geheel mijns inzien veel te complex, maar ik denk wel dat beide systemen met gratie naast elkaar kunnen bestaan

Ik zit duidelijk aan de meer "eenvoud=kracht" kant dan aan de "dit ding kan ALLES" kant. Ik maak zelf afwegingen aan de hand van wat mensen zoal wensen, maar hou voor mezelf wel voor ogen dat het betaalbaar, bouwbaar en KISS moet zijn.

Het is erg belangrijk in dit soort projecten een duidelijke lijn uit te zetten, anders verzand je in eeuwige extra opties die iedereen "wel leuk" zou vinden maar die uiteindelijk niemand (op een enkeling na) gebruiken gaat.
Resultaat: Het project loopt lang, het uiteindelijke ding is stervensduur, en de software blijkt vrijwel onmogelijk te ontwikkelen (vooral aan de embedded kant).

Ik weet niet hoe jullie ontwikkeling verloopt, maar ik hoop dat jullie ook een duidelijke lijn aanhouden. Ik wil met mijn project in ieder geval richten op de "gemiddelde tweaker" (bestaan die eigenlijk wel??? ). Oftewel niet de meer extreme zaken zoals 8 kanaals FAN sturingen. 4 kanaals is voor de meesten genoeg: 1=CPU, 2=mobo, 3=voeding en 4=casefan(s) bijvoorbeeld. Mensen die toch meer willen moeten het (voorlopig althans) niet in mijn project zoeken. Misschien in die van jullie

Mijn aanpak is dat de PCB simpel, goedkoop en toch veelzijdig moet zijn. Geen last van "I/O vergroters" zoals allerlei shifter IC's enzo, insteekkaarten zoek ik al helemaaaaal niet.

Wel leuk trouwens om zo twee aparte projecten naast elkaar te zien opgroeien en ook uit elkaar te zien groeien

Natuurlijk alle suc6 met die van jullie!!!!

ow ja hebben jullie het RPM meetprobleem al opgelost bij een PWM gestuurde fan?

[Anoniem: 35245]

Op donderdag 28 februari 2002 14:44 schreef im_ik het volgende:

[..]

Was maar een ideetje
maar ik ga wel proberen een aantal van die chipjes zelf te krijgen..

Ja het kan erg leuke applicaties vormen.... Kun je van alles via internet besturen enzo. Want een TCP/IP stack in een 8051... daar word je niet happy van nee . Dan is dit wel een leuke oplossing. Weet je al wat ze kosten?

[Bazer]

Sommige mensen hebben een fanbus, andere een lcd om informatie van netwerk/winamp/mbm/hardware e.d. te tonen. Kan je dat niet combineren? Heb je namelijk maar 1 LCD nodig en toch alle functionaliteit van je fanbus én je ziet alles op je LCD. Maar dat was ook het plan geloof ik.

edit:

typo's

[Anoniem: 35245]

Op donderdag 28 februari 2002 15:24 schreef Bazer het volgende:
Sommige mensen hebben een fanbus, andere een lcd om informatie van netwerk/winamp/mbm/hardware e.d. te tonen. Kan je dat niet combineren? Heb je namelijk maar 1 LCD nodig en toch alle functionaliteit van je fanbus én je ziet alles op je LCD. Maar dat was ook het plan geloof ik.

edit:

typo's

Ja dat was inderdaad het plan. Kan iemand mij uitleggen wat dat nou is met winamp en mbm op LCD enzo? Is dat een plugin voor winamp of mbm die een LCD aanstuurt over de paralelle of seriele poort ofzo?

[Mennootje]

Met dat Winamp/MBM gedeelte bedoel ik dat je op je LCD de Winamp/MBM info ziet. Dus huidige titel liedje, duur vh liedje, temp mobo, voltages mobo enz.

[Anoniem: 35245]

Op donderdag 28 februari 2002 16:26 schreef Mennootje het volgende:
Met dat Winamp/MBM gedeelte bedoel ik dat je op je LCD de Winamp/MBM info ziet. Dus huidige titel liedje, duur vh liedje, temp mobo, voltages mobo enz.

aha... en die gegevens haal je die via een apart progje uit winamp en stuur je die naar je display, of hebben die progs daar zelf ondersteuning voor?

Want om dat allemal zelf te gaan maken in software... dan kun je beter een bestaand proggie hebben die een lcd serieel kan aansturen. Dan kijk ik wel of ik de commandoset van he serieele display kan nabouwen. Wel een goede tip in dit geval, want ik was al bezig met een eigen seriele commandoset (die ik nog heb liggen)

[Anoniem: 42166]

Op woensdag 27 februari 2002 18:06 schreef --EasY-- het volgende:

[..]
Wellicht blijkt het redelijk eenvoudig, dan kan er misschien via een modificatie alsnog 4 kanalen gemeten worden. Gelukkig is het meten niet echt nodig om toch netjes toeren te kunnen sturen, alleen stuur je dan dutycycle (0-100%) in plaats van een doel toerental (wat netter is en beter controleerbaar)

Ik heb PWM/RPM metingen gedaan aan 7 verschillende fans. Van 40mm tot 120mm en er is niet echt een pijl op te trekken hoe een willekeurige fan reageert op een bepaalde dutycycle. Dus feedback vie RPM is eigenlijk wel een vereiste. Plus dat het koelend vermogen ook nog afhankelijk is van de grootte van de fan.

[edit]
Nog een ID wat ik had: Zet PWM op 100%, meet de tijd tussen 2 RPM pulsen en schakel de PWM terug. Als je dit 1x per 1 of 5 seconde doet ofzo dan zie je dit nauwelijks terug in de toeren van de fan, maar de meting is wel superdeluxe!

2 minds 1 thought. Maar ik denk dat het RPM perikel te maken heeft met de tijd dat een fan aan staat en niet zozeer met de dutycycle. Dus als je een te hoge PWM-freqentie aan houdt blijft het probleem bestaan. Ook al las je een 'leespauze' in.
Bewijs uit het ongerijmde:

Stel dat je een PWM frequentie hebt van .001Hz dan kun je de fan (theoretisch) met 1% PWM aansturen. Want je aan-tijd is dan een halve seconde. Wedden dat je RPM kan uitlezen bij 1% dutycycle.

Via deze truuk is het misschien mogelijk om 4 inputs te meten... Of hier nog hardwareaanpassingen voor nodig zijn weet ik nog niet 1-2-3

Jep, of je moet intern I/O pinnen naar de T0/T1 'poorten' kunnen routen, maar dan weet jij meer dan ik.
Zal dan wel multiplexertje worden denk ik.

[Anoniem: 35245]

Op donderdag 28 februari 2002 19:28 schreef Maxim het volgende:

[..]

Ik heb PWM/RPM metingen gedaan aan 7 verschillende fans. Van 40mm tot 120mm en er is niet echt een pijl op te trekken hoe een willekeurige fan reageert op een bepaalde dutycycle. Dus feedback vie RPM is eigenlijk wel een vereiste. Plus dat het koelend vermogen ook nog afhankelijk is van de grootte van de fan.

ZO da's breed

Zoiets dacht ik al, je kunt fans wel zonder rpm goed aansturen, maar dan moet je toerenkrommen weten (hoeveel % dutycycle levert hoeveel toeren). Ook niet echt makkelijk te configgen

Aan de ander kant kun je wel je fan opregelen totdat de temp is zoals gewenst. Deze regeling komt in de hardware te zitten, kan ook zonder rpm. Alleen dat is wel een trage regeling, omdat de responsetijd van het systeem (fan harder--> temperatuur omlaag) ook heel traag is.

de regeling die ik in gedachte had:

Als de temp > 10 graden boven de streeftemp, dan fan "volgas". temp >10 graden onder de streektemp, FAN op 25% RPM ("stationair"). Binnen dit window (ook configureerbaar jaah ) zal de fan PWM regelen. Ook zonder RPM meting zou de regeling zichzelf moeten settlen op een bepaalde duty-cycle (en dus een bepaald koelend vermogen van de fan).

2 minds 1 thought. Maar ik denk dat het RPM perikel te maken heeft met de tijd dat een fan aan staat en niet zozeer met de dutycycle. Dus als je een te hoge PWM-freqentie aan houdt blijft het probleem bestaan. Ook al las je een 'leespauze' in.
*KNIP het brede*

Hmmm ik dacht eraan dat als het tijd was om rpm te meten, dan wordt de fan op 100% dutycycle geschakeld. Dit wordt volgehouden totdat de RPM input 2 opgaande (of neergaande) flanken heeft gezien. De tijd hiertussen is een maat voor het toerental. Daarna wordt de dutycycle in ere hersteld.

Dit zal uitmonden in een iets hoger toerental tijdens de meting. Bij b.v. 600rpm duurt de meting 1/10 seconde! Bij hogere toerentallen verkleind het probleem. Of ik hiervoor dan ook weer in software moet corrigeren weet ik nog niet...

Jep, of je moet intern I/O pinnen naar de T0/T1 'poorten' kunnen routen, maar dan weet jij meer dan ik. Zal dan wel multiplexertje worden denk ik.

hmmm. Bij het meten van 4x rpm wel ja, als ik T0 of T1 echt nodig heb moet ik muxen, tenzij ik in software kan meten met polling, dan kan ik elke I/O pin nemen.... ALS ik 4 rpm inputs ga maken, want ik verw8 dat een fan zonder rpm sensor ook goed te regelen is via de regeling die ik hierboven beschreef...

[Anoniem: 42166]

Op donderdag 28 februari 2002 19:41 schreef --EasY-- het volgende:

[..]

ZO da's breed

Nu niet meer

Zoiets dacht ik al, je kunt fans wel zonder rpm goed aansturen, maar dan moet je toerenkrommen weten (hoeveel % dutycycle levert hoeveel toeren). Ook niet echt makkelijk te configgen

Aan de ander kant kun je wel je fan opregelen totdat de temp is zoals gewenst. Deze regeling komt in de hardware te zitten, kan ook zonder rpm. Alleen dat is wel een trage regeling, omdat de responsetijd van het systeem (fan harder--> temperatuur omlaag) ook heel traag is.

de regeling die ik in gedachte had:

Als de temp > 10 graden boven de streeftemp, dan fan "volgas". temp >10 graden onder de streektemp, FAN op 25% RPM ("stationair"). Binnen dit window (ook configureerbaar jaah ) zal de fan PWM regelen. Ook zonder RPM meting zou de regeling zichzelf moeten settlen op een bepaalde duty-cycle (en dus een bepaald koelend vermogen van de fan).
[..]

Goeie temp regeling bedenken wordt nog wel wat. Feit blijft dat je met RPM de meetlus een stuk strakker kan maken.

Hmmm ik dacht eraan dat als het tijd was om rpm te meten, dan wordt de fan op 100% dutycycle geschakeld. Dit wordt volgehouden totdat de RPM input 2 opgaande (of neergaande) flanken heeft gezien. De tijd hiertussen is een maat voor het toerental. Daarna wordt de dutycycle in ere hersteld.

dus toch weer op pulsbreedte meten dus.

Dit zal uitmonden in een iets hoger toerental tijdens de meting. Bij b.v. 600rpm duurt de meting 1/10 seconde! Bij hogere toerentallen verkleind het probleem. Of ik hiervoor dan ook weer in software moet corrigeren weet ik nog niet...
[..]

Uhmm, 1/20ste seconde dus(edit: je zei 2 perioden 1/10s dus), wel een nette oplossing. Is dus nog wel te overzien.

hmmm. Bij het meten van 4x rpm wel ja, tenzij ik in software kan meten met polling, dan kan ik elke I/O pin nemen....

Pollen, haha dat ga je niet leuk vinden. Zeker niet als je in C programmeerd.

[Anoniem: 35245]

Op donderdag 28 februari 2002 19:58 schreef Maxim het volgende:

Goeie temp regeling bedenken wordt nog wel wat. Feit blijft dat je met RPM de meetlus een stuk strakker kan maken.

Ja daar ligt nog wel een uitdaging.... Alhoewel... eventueel "zelflerend" maken

dus toch weer op pulsbreedte meten dus.

Ja lijkt mij de enige manier om degelijk te meten... Tenzij er nog andere ideeen bij mensen leven??

Uhmm, 1/20ste seconde dus(edit: je zei 2 perioden 1/10s dus), wel een nette oplossing. Is dus nog wel te overzien.

Ja hoop ik ook. Wel 1/10 ik meet een hele puls rising-->rising of falling-->falling. rising-->falling of andersom is geen goede meting (al is het waarschijnlijk wel een lineaire rpm gerelateerde)

Pollen, haha dat ga je niet leuk vinden. Zeker niet als je in C programmeerd.

Uhm C doet daar weinig aan af hoor. Polling is idd niet leuk en door de vele interrupt-driven zaken ook erg (lees: te) onnauwkeurig denk ik. Vrijwel alle metingen en sturingen lopen geheel in H/W op interrupt basis. De PWM routine stuurt tevens de LEDs in PWM en de PWM routine maakt ook de tijdbasis voor alle software timers. De backrgound laat ik denk ik b.v. 100x per seconde lopen, zodat ik daar de niet-realtime dingen kan afhandelen (zoals b.v. strings naar het LCD pompen en de toerenkromme hocuspokus)

En geen nood... Waar nodig prop ik heus wel assembly in de c code

Alleen baal ik een btje als ik nu nog 2 extra rpm inputs op de T0 en T1 lijnen moet frommelen.... De PCB ligt er al zowat

[Anoniem: 35245]

Nog minder leuk: Als rpm sowieso gemeten moet worden met de fan heel kort op een dutycylce van 100%, dan had ik net zo goed de ground kunnen schakelen met een NPN of N-channel mosFET

De mosFET heeft vooral voorkeur, omdat hij minder warm wordt en een veel kleinere verliesspanning heeft waardoor de fan "echt" 12V kan krijgen in plaats van 12V - V_CE

BAH

[Anoniem: 42166]

Op donderdag 28 februari 2002 20:08 schreef --EasY-- het volgende:

... eventueel "zelflerend" maken

Dat bedoel ik dus

Ja lijkt mij de enige manier om degelijk te meten... Tenzij er nog andere ideeen bij mensen leven??

Pulsen tellen, maar dat is zeker met 4 RPM-ingangen een no-go.

Uhm C doet daar weinig aan af hoor.

Als je tijd gedefinieerde programmalussen moet maken wel. Maar dat doet er hier ook niet echt toe.

Polling is idd niet leuk en door de vele interrupt-driven zaken ook erg (lees: te) onnauwkeurig denk ik. Vrijwel alle metingen en sturingen lopen geheel in H/W op interrupt basis.
[knip]

Gewoon not done eigenlijk. Als je van max 6000 toeren uitgaat. Dan zit je met 200 Hz op je RPM uitgang. Moet je met tenminste 400Hz pollen.

En geen nood... Waar nodig prop ik heus wel assembly in de c code

Jouw feestje, alhoewel ik ook wel assembly wil schrijven als het nodig blijkt te zijn

Alleen baal ik een btje als ik nu nog 2 extra rpm inputs op de T0 en T1 lijnen moet frommelen.... De PCB ligt er al zowat

Plannen zijn er om verandert te worden.

[Anoniem: 42166]

Op donderdag 28 februari 2002 20:25 schreef --EasY-- het volgende:
Nog minder leuk: Als rpm sowieso gemeten moet worden met de fan heel kort op een dutycylce van 100%, dan had ik net zo goed de ground kunnen schakelen met een NPN of N-channel mosFET

Dat maakt helemaal niet uit.
Shit, maar wat was dan het probleem ook alweer

[Anoniem: 35245]

Op donderdag 28 februari 2002 20:33 schreef Maxim het volgende:

[..]

Dat maakt helemaal niet uit.
Shit, maar wat was dan het probleem ook alweer

Het probleem was dat de rpm input het niet doet met de 7V truuk. Dit is natuurlijk omdat de ground vam de fan dan +5v is...

Daarom koos ik toen voor pnp torren in de +12V kant, om zo de rpm schakeling werkend te houden.

[Anoniem: 42166]

Op donderdag 28 februari 2002 20:39 schreef --EasY-- het volgende:

[..]

Het probleem was dat de rpm input het niet doet met de 7V truuk. Dit is natuurlijk omdat de ground vam de fan dan +5v is...

Daarom koos ik toen voor pnp torren in de +12V kant, om zo de rpm schakeling werkend te houden.

Haha, stom eigenlijk. Probleem blijft wel dat als je een NPN-tor gebruikt. Je aan de RPM-uitgang 2 torren in "serie" hebt staan da's 2 x 0,2..0.3V. Gaat de atmel niet als 0 herkennen volgens de specs.

[Mennootje]

Op donderdag 28 februari 2002 19:02 schreef --EasY-- het volgende:

[..]

aha... en die gegevens haal je die via een apart progje uit winamp en stuur je die naar je display, of hebben die progs daar zelf ondersteuning voor?

Want om dat allemal zelf te gaan maken in software... dan kun je beter een bestaand proggie hebben die een lcd serieel kan aansturen. Dan kijk ik wel of ik de commandoset van he serieele display kan nabouwen. Wel een goede tip in dit geval, want ik was al bezig met een eigen seriele commandoset (die ik nog heb liggen)

Misschien handig om wat code te lenen van iemand?

http://www.markuszehnder.ch/projects/lcdplugin/index.html

Deze jongen heeft een heel mooi progje voor seriele displays en paralle displays. Sourcecode zit er ook bij enz.

MBM is ook helemaal niet moeilijk. Werkt via shared memory oid: http://mbm.livewiredev.com

Hoop dat ut lukt

[Anoniem: 42166]

[blaat..knip]

Hmmz, dat shared memory is wel interessant, alleen kun voor zover ik het zie bij elke versie van MBM je code aanpassen. Da's minder.

[Anoniem: 35245]

Op donderdag 28 februari 2002 20:48 schreef Maxim het volgende:

[..]

Haha, stom eigenlijk. Probleem blijft wel dat als je een NPN-tor gebruikt. Je aan de RPM-uitgang 2 torren in "serie" hebt staan da's 2 x 0,2..0.3V. Gaat de atmel niet als 0 herkennen volgens de specs.

TTL spec voor logisch '0' is 0 - 0,7V ... dus zal wel lukken, of heeft de atmel een ander level? nou ja hoe dan ook, ik denk dat ik het zo maar hou met de pnp's. Ik hoop ergens nog op een idee te komen om toeren te meten zonder omwegen

[Anoniem: 35245]

Op donderdag 28 februari 2002 20:53 schreef Mennootje het volgende:

[..]

Misschien handig om wat code te lenen van iemand?

http://www.markuszehnder.ch/projects/lcdplugin/index.html

Deze jongen heeft een heel mooi progje voor seriele displays en paralle displays. Sourcecode zit er ook bij enz.

MBM is ook helemaal niet moeilijk. Werkt via shared memory oid: http://mbm.livewiredev.com

Hoop dat ut lukt

Wat ik er zo van zie, is dat ik de baybus maar gewoon "transparant" maak, zodat dergelijke software "denkt" een serieel display te zien en voila... nix zelf te hacken (op het seriele commandosetje na dan)

[Anoniem: 45185]

Is het mogelijk om de voltages voor de fans te regelen via die chip, dus dat je elke fan apart kan regelen.
Als je erdan vanuit gaat dat voltage en toerental een linear verband is kan je dat ook allemaal uitrekenen.

NB: ik weet niet zo heel veel van elektronica, maar ik probeer toch maar een ideetje in te brengen .

[Anoniem: 42166]

Op donderdag 28 februari 2002 21:27 schreef --EasY-- het volgende:

TTL spec voor logisch '0' is 0 - 0,7V ... dus zal wel lukken, of heeft de atmel een ander level? nou ja hoe dan ook, ik denk dat ik het zo maar hou met de pnp's. Ik hoop ergens nog op een idee te komen om toeren te meten zonder omwegen

Dacht ik ook, maar bij V_IL 'Input Low Voltage' staat bij max 0,3*. *the highest value where the pin is guaranteed to be read as low. (Bijna)letterlijk uit de datasheet.

Wat ik er zo van zie, is dat ik de baybus maar gewoon "transparant" maak, zodat dergelijke software "denkt" een serieel display te zien en voila... nix zelf te hacken (op het seriele commandosetje na dan)

Maar dan heb je dus 2 programma's die van 1 com-poort gebruiken. Denk niet dat Windows dat tof vindt. En aangezien je vanuit je eigen programma nooit de poort kan overnemen van WinAmp ofzo, verlies al snel contact met je Extreme Baybus.

[Anoniem: 35245]

Op donderdag 28 februari 2002 21:32 schreef Maxim het volgende:

[..]

Dacht ik ook, maar bij V_IL 'Input Low Voltage' staat bij max 0,3*. *the highest value where the pin is guaranteed to be read as low. (Bijna)letterlijk uit de datasheet.

Een goede reden om de PNP's te houden in ieder geval... Een groter probleem vind ik 2 rpm inputs bijklussen

Maar dan heb je dus 2 programma's die van 1 com-poort gebruiken. Denk niet dat Windows dat tof vindt. En aangezien je vanuit je eigen programma nooit de poort kan overnemen van WinAmp ofzo, verlies al snel contact met je Extreme Baybus.

Tja dat is inderdaad niet zo prettig nee. alweer

[Anoniem: 45185]

Op donderdag 28 februari 2002 21:32 schreef Maxim het volgende:
Maar dan heb je dus 2 programma's die van 1 com-poort gebruiken. Denk niet dat Windows dat tof vindt. En aangezien je vanuit je eigen programma nooit de poort kan overnemen van WinAmp ofzo, verlies al snel contact met je Extreme Baybus.

Idd, dus zal je moeten zorgen als je overschakeld dat het 'hoofdprogramma', de een uitschakeld en de andere daarna aanzet.

[Anoniem: 42166]

Op donderdag 28 februari 2002 22:01 schreef --EasY-- het volgende:

Een goede reden om de PNP's te houden in ieder geval... Een groter probleem vind ik 2 rpm inputs bijklussen

De hardware oplossing :

* http://www-us9.semiconductors.com/acrobat/datasheets/74HC_HCT157_CNV_2.pdf

Kost je wel een IO.

De software oplossing :

* Pollen in een door een timer geinitieerde ISR.

Verder zal ik het ook niet weten.

[Anoniem: 35245]

Op donderdag 28 februari 2002 22:06 schreef NextGeneration het volgende:

[..]

Idd, dus zal je moeten zorgen als je overschakeld dat het 'hoofdprogramma', de een uitschakeld en de andere daarna uitzet.

Uhm op zich is contact verliezen met de baybus al voorzien... Als een fan in "seriele"regeling staat dan zal de baybus bij het uitblijven van seriele commando's na x seconde overgaan in alarm en de FANs op full power schakelen

Maar netjes is anders idd... Misschien kan ik met een windows prog wel een virtuele seriele poort maken

[Anoniem: 45185]

Op donderdag 28 februari 2002 22:22 schreef --EasY-- het volgende:

[..]

Uhm op zich is contact verliezen met de baybus al voorzien... Als een fan in "seriele"regeling staat dan zal de baybus bij het uitblijven van seriele commando's na x seconde overgaan in alarm en de FANs op full power schakelen

Maar netjes is anders idd... Misschien kan ik met een windows prog wel een virtuele seriele poort maken

Jah, zou mogelijk moeten zijn (eens rondkijken op sw fora).
Heb je trouwens al een definitieve keuze gemaakt wat betreft programmeertaal?

[Anoniem: 45185]

Kijk eens: Virtual Serial Port device driver.
Of: Virtual Serial Port.

[Anoniem: 42166]

Op donderdag 28 februari 2002 22:34 schreef NextGeneration het volgende:
Kijk eens: Virtual Serial Port device driver.

Is helaas commercieel.

Of: [url="http://Virtual Serial Port device driver"]Virtual Serial Port[/url].

Check ff 't linkie doet 't nie
[url="http://Virtual Serial Port device driver"]= zoekopdracht

* Anoniem: 42166 gaat

[Anoniem: 45185]

Alles wat ik op dit moment vind is commercieel, ik denk dat voor Windows iig niets bruikbaars te vinden is.
Misschien dan toch maar voor de niet nette oplossing, of zelf iets bouwen natuurlijk.

[Anoniem: 35245]

Op donderdag 28 februari 2002 22:27 schreef NextGeneration het volgende:

[..]

Jah, zou mogelijk moeten zijn (eens rondkijken op sw fora).
Heb je trouwens al een definitieve keuze gemaakt wat betreft programmeertaal?

Uhm... Er zijn twee programmeertalen... De embedded taal word sowieso c. Of het IAR C of Gnu C wordt weet ik nog niet, het hangt er ook van af of ik de embedded code ga vrijgeven. De IAR c-compiler is nl. onverslaanbaar, maar niet bepaald gratis. Hoe goed de Gnu C compiler is weet ik eerlijk gezegd niet!

De andere code wordt de code die op je PC loopt. Deze code is qua basis niets meer dan een progje om instellingen te maken en die door te kletsen via je seriele poort. Borland C++ builder lijkt me snel en handig hiervoor. Het verdergaande werk (zoals het aansturen van het display etc) zal ik wat meer overlaten aan de rest van de wereld

Zolang de embedded core maar stabiel is, kun je zelf via de seriele poort heerlijk programmeren, of dat nou visual basic, delphi, MS C++ of Borland C++ is, maakt niets uit.

[Anoniem: 35245]

Op donderdag 28 februari 2002 22:10 schreef Maxim het volgende:

[..]

De hardware oplossing :

* http://www-us9.semiconductors.com/acrobat/datasheets/74HC_HCT157_CNV_2.pdf

Kost je wel een IO.

Waarom zo moeilijk bedacht ik me... Een fan rpm is niets meer dan een open collector output. Dus waarom niet gewoon 2 rpm lijnen aan elkaar en dan een timerinput in? Nu zie ik de 2 rpm signalen geORred. Als ik nu rpm ga meten moet ik de te meten fan tijdelijk op dutycycle=100% zetten. Als ik dan de andere fan op dutycycle=0% zet, dan zie ik altijd pulsen van de "goeie" fan!!! tataaaah weer een chip en een I/O bespaart . Nu hoef ik alleen maar ff twee extra rpm-touwtjes bij te trekken in CAD

De software oplossing :

* Pollen in een door een timer geinitieerde ISR.

Verder zal ik het ook niet weten.

edit:

Hier stond onzin

Ik ga in ieder geval niet pollen, is lelijk bah. Zeker niet als de hardware oplossing zo simpel en goedkoop is

[Anoniem: 35245]

Op donderdag 28 februari 2002 21:32 schreef Maxim het volgende:

[..]

Dacht ik ook, maar bij V_IL 'Input Low Voltage' staat bij max 0,3*. *the highest value where the pin is guaranteed to be read as low. (Bijna)letterlijk uit de datasheet.

Als ik de fans via een mosFET stuur lukt het weer wel. Een beetje mosFET heeft een R_on < 0.0125 ohm!

[Anoniem: 7477]

Voor zover ik het kan zien gaat het je veel moeite kosten om de RPM meeting goed uitgevoerd te krijgen. Maar wat ik nu niet snap is waarom je die rpm toch wilt weten?

Behalve dat het een leuk getal is heb je er niets aan. Je gaat toch sturen op temp en niet op rpm?

Bij het meten van de rpm krijg je een timings probleem, laat je het weg dan hou je geen timings critische componenten over. Oftewel even de programma flow:

code:

init
watchdog on

do
  meet temp's
  set fan's
  serial comm
  set values from serial
  lcd module
  kick watchdog
loop

int0
  watchdog off
  button afhandeling incl lcd sturing
  set values
  watchdog on
end int0

De watchdog is een feature van de amtel's. Het is een HW watchdog die je chippie reset indien ie niet binnen een (instelbare) tijd wordt gekicked.

btw in pseudo code opgeschreven, ik kan c lezen, schrijven is iets moeilijker. Heb meer verstand van bussiness logica (SAP) proggen en daar is timing zelden een probleem.

[Anoniem: 35245]

Op vrijdag 01 maart 2002 08:33 schreef ascii het volgende:
Voor zover ik het kan zien gaat het je veel moeite kosten om de RPM meeting goed uitgevoerd te krijgen. Maar wat ik nu niet snap is waarom je die rpm toch wilt weten?

Behalve dat het een leuk getal is heb je er niets aan. Je gaat toch sturen op temp en niet op rpm?

Bij het meten van de rpm krijg je een timings probleem, laat je het weg dan hou je geen timings critische componenten over. Oftewel even de programma flow:

code:

init
watchdog on

do
  meet temp's
  set fan's
  serial comm
  set values from serial
  lcd module
  kick watchdog
loop

int0
  watchdog off
  button afhandeling incl lcd sturing
  set values
  watchdog on
end int0

De watchdog is een feature van de amtel's. Het is een HW watchdog die je chippie reset indien ie niet binnen een (instelbare) tijd wordt gekicked.

btw in pseudo code opgeschreven, ik kan c lezen, schrijven is iets moeilijker. Heb meer verstand van bussiness logica (SAP) proggen en daar is timing zelden een probleem.

hahahah ik heb juist ALLEEN ervaring met tijdkritische zaken ... Het gaat iets anders in elkaar steken:

- de PWM sturingen gaan sowieso op timer2 lopen, dus volledig onder interrupt. Deze timer maakt ook gelijk de tijdbasis voor alle software timers (waarmee LED knipperfrequenties enzo worden gemaakt)
- Seriele communicatie loopt ook onder interrupt
- temperatuurmeting loopt ook al onder interrupt (A/D converters leveren interrupts en dat is tevens de "kick" voor de volgende A/D conversie)
- De meting van de toerensensoren wil ik ook meten met behulp van hardware, dus ook onder interrupt.

Dat wat overblijft is het aan elkaar plakken van deze realtime zaken. Dit gebeurt in de background, die ik met regelmaat laat lopen (b.v. op 100Hz).

De watchdog feature is inderdaad leuk, maar voegt verder niets aan timing faciliteiten toe; hij dient slechts als functie om de AVR te hard-resetten als hij vermoed dat de code niet langer lekker executeerd (de watchdog kick mag niet te lang uitblijven). Is al een lang bestaand iets, alleen de AVR heeft het nu eindelijk netjes met een eigen R/C oscilatortje, dus zelfs als de kristal oscilator stopt zal de watchdog alsnog ingrijpen.

[Anoniem: 7477]

Er zijn meer wegen die naar Rome gaan.

Maar waar ga je je amtel kopen? Bij conrad hebben ze de 8535 niet in dil40 uitvoering... Print aanpassen of maar voor de 4434 gaan?

Of natuurlijk ergens anders kopen, weet je een goede online zaak? (en anders moet ik maar even langs de gortere dorpen en steden hieromheen gaan)

[Anoniem: 35245]

Op vrijdag 01 maart 2002 11:09 schreef ascii het volgende:
Er zijn meer wegen die naar Rome gaan.

Maar waar ga je je amtel kopen? Bij conrad hebben ze de 8535 niet in dil40 uitvoering... Print aanpassen of maar voor de 4434 gaan?

Of natuurlijk ergens anders kopen, weet je een goede online zaak? (en anders moet ik maar even langs de gortere dorpen en steden hieromheen gaan)

Uhm toen ik keek had Conrad de DIL uitvoering wel hoor... Maar de wereld houd niet op bij conrad

Ik heb ze ook bij display gezien... e.v.a. denk ik.

[Anoniem: 45185]

Op vrijdag 01 maart 2002 07:53 schreef --EasY-- het volgende:

[..]

Uhm... Er zijn twee programmeertalen... De embedded taal word sowieso c. Of het IAR C of Gnu C wordt weet ik nog niet, het hangt er ook van af of ik de embedded code ga vrijgeven. De IAR c-compiler is nl. onverslaanbaar, maar niet bepaald gratis. Hoe goed de Gnu C compiler is weet ik eerlijk gezegd niet!

...

Zolang de embedded core maar stabiel is, kun je zelf via de seriele poort heerlijk programmeren, of dat nou visual basic, delphi, MS C++ of Borland C++ is, maakt niets uit.

Aha, nou die Gnu compiler is een goede hoor (linux kernel wordt er ook mee gebakken).
En Delphi lijkt me interressant, niet veel ervaring mee, maar daar is wat aan te doen

[Anoniem: 35245]

Op vrijdag 01 maart 2002 14:09 schreef NextGeneration het volgende:

[..]

Aha, nou die Gnu compiler is een goede hoor (linux kernel wordt er ook mee gebakken).
En Delphi lijkt me interressant, niet veel ervaring mee, maar daar is wat aan te doen

Ja, alleen de Gnu compiler kan misschien de code niet zo lekker optimaliseren als de IAR c-compiler dat doet. Maar ik ga deze gnu compiler zeker wel bekijken.

Delphi is op zich een leuke keuze, zelf heb ik dan echter meer gevoel bij Borland C++ builder. Dit is eigenlijk net als delphi, maar dan "c" als programmeertaal i.p.v. Pascal zoals Delphi dat heeft.

Of ik de embedded code vrijgeef weet ik nog niet, het is ERG foutgevoelig met al die realtime interrupt zaken. Wat ik zeker wel vrijgeef is de seriele communicatie standaard, op die manier kan iedereen supersimpel de unit besturen en uitlezen.

Als basis zal ik in beginsel slechts een configuratie/ logviewing utility maken, waarmee je de instellingen in de baybus kunt aanpassen en desgewenst in EEPROM opslaan. Dit stukje software is sowieso ook nodig voor het debuggen van de embedded code en het testen van de hardware I/O

[Anoniem: 45185]

Ik wacht met spanning op de pics (als ie in elkaar zit dus), en met nog meer spanning op de configuratie!! .

[Anoniem: 45185]

Ik wil dus wel een proggie bouwen, maar dat komt dan pas na de examens ().
Het wordt dan in Delphi geschreven (waarschijnlijk open-source).
Maar als iemand me voor is met een mooi programma vindt ik dat ook niet erg .

[Anoniem: 35245]

Op vrijdag 01 maart 2002 16:12 schreef NextGeneration het volgende:
Ik wacht met spanning op de pics (als ie in elkaar zit dus), en met nog meer spanning op de configuratie!! .

Pics moet je nog ff geduld hebben (de pcb is er nog geeneens0. De configuratie kun je al afleiden uit het schema, ik heb nu een word bestand die ik misschien nog wel vanavnd op de site ga zetten. Deze bevat hardware features en globale software features!

Ik zit een btje met de PCB in mijn maag, want er zitten toch weer wijzigingen in die ik op de PCB moet zetten. En dat duurt nou eenmaal als je het enkelzijdig EN netjes wil doen.

[hightower]

Op woensdag 27 februari 2002 22:22 schreef --EasY-- het volgende:

[..]

AHA nu gaat het me dagen over die SMbus... Dat is gewoon de seriele bus waarmee ze die 8 pins EEPROM chippies uitlezen op de DIMM.... duuuh dat is een supersimpel serieel truukje... clocklijn/datalijn.... Een soort I[super]2[/super]C maar volgens mij dan nog simpeler... een SPI busje ofzo.... Goh kun je die ook zelf aansturen... Als de tijd rijp is ga ik daar misschien wel een stukje software voor schrijven... dat zou dan de slave-kant moeten zijn, die is net weer iets lastiger dan de masterkant...

Is inderdaad een I2C

[Anoniem: 7477]

Op vrijdag 01 maart 2002 08:59 schreef --EasY-- het volgende:

[..]

hahahah ik heb juist ALLEEN ervaring met tijdkritische zaken ... Het gaat iets anders in elkaar steken:

<knip interupt verhaaltje>

Eeeuh, ik was even aan het kijken naar de interupts van de avr's maar wat ik heb gelezen is dat er geen prioritering is aan te leggen tussen alle interups en dat als 1 int wordt afgehandeld er geen andere interups worden opgepakt. Ik heb inderdaad bijna geen ervaring met realtime proggen (hoewel, binnen een minuut moet de wijziging van de vooraad toch echt in de db staan, anders komen ze echt even vragen wie die shit heeft gebouwd en dat het vroeger zonder al die comps toch altijd beter ging).

Maare, is het wel mogelijk om met zo'n beperkte int afhandeling een betrouwbare functionalteit te bouwen? Geef anders eens een redelijk functionele uitleg van wat je gaat doen.

[Anoniem: 42166]

Op zaterdag 02 maart 2002 21:25 schreef ascii het volgende:

[..]

Eeeuh, ik was even aan het kijken naar de interupts van de avr's maar wat ik heb gelezen is dat er geen prioritering is aan te leggen tussen alle interups

Klopt.

en dat als 1 int wordt afgehandeld er geen andere interups worden opgepakt.

Kan wel, de AT90S ondersteund wel geneste interrupts.
De ISR het GIE-bit (Global Interrupt Enable) laten setten.

Ik heb inderdaad bijna geen ervaring met realtime proggen (hoewel, binnen een minuut moet de wijziging van de vooraad toch echt in de db staan, anders komen ze echt even vragen wie die shit heeft gebouwd en dat het vroeger zonder al die comps toch altijd beter ging).

LOL

Maare, is het wel mogelijk om met zo'n beperkte int afhandeling een betrouwbare functionalteit te bouwen? Geef anders eens een redelijk functionele uitleg van wat je gaat doen.

Ja en nee

[Anoniem: 35245]

Op zaterdag 02 maart 2002 21:25 schreef ascii het volgende:

[..]

Eeeuh, ik was even aan het kijken naar de interupts van de avr's maar wat ik heb gelezen is dat er geen prioritering is aan te leggen tussen alle interups en dat als 1 int wordt afgehandeld er geen andere interups worden opgepakt. Ik heb inderdaad bijna geen ervaring met realtime proggen (hoewel, binnen een minuut moet de wijziging van de vooraad toch echt in de db staan, anders komen ze echt even vragen wie die shit heeft gebouwd en dat het vroeger zonder al die comps toch altijd beter ging).

Maare, is het wel mogelijk om met zo'n beperkte int afhandeling een betrouwbare functionalteit te bouwen? Geef anders eens een redelijk functionele uitleg van wat je gaat doen.

Er zijn volgens mij meerdere interrupt niveau's op de AVR. Dus het is wel degelijk mogeljik dat de ene interrupt onderbroken wordt door een 2e van een hogere prioriteit. Als je goed gebruik maakt van de hardware echter dan heb je dat eigenlijk niet echt nodig. Pulsen worden gemeten door de hardware timers, die daarna een interrupt genereren. Bij de (oudere) PIC controllers moet je dan als de wiedeweerga de registers lezen en eventueel reloaden met waardes min het aantal machineinstructies en datsoort ongein.

Bij de AVR is dat niet nodig. De timers meten een puls, en genereren een interrupt. Daarna kun je op je "gemakkie" de gemeten pulsduur uitlezen zonder dat dit nog echt tijdkritisch is. Alleen de PWM sturing vormt hierop een uitzondering: Omdat ik 12 PWM kanalen heb (4 FANs + 8 LEDs) moet ik dit in software oplossen.

Hoe doe ik dat? Eenvoudig. Als je een PWM waarde wil verstellen, wordt deze "niet realtime" aangepast in een gesorteerde tabel van alle PWM waardes. Als ik een nieuwe PWM cycle start, dan sla ik deze tabel naar een realtime schaduwgeheugentje (zo ontkoppel ik niet-realtime van realtime). Nu ga ik een timer programmeren die afgaat zodra de 1e PWM af moet vallen, en zet ik de auto-reload op de tijd van de 2e afvaller. Als die interrupt komt, dan gooi ik de bijbehorende output op 0, ik weet dat de tiemr al gereload is op de 2e puls, en dus zet ik de reload waarde nu op de delta-t tussen puls 2 en 3. De laatste puls reload totdat de pwm-tijdbasis weer compleet is.

Op die manier heb ik dus een n-kanaals PWM, die volledig stabiel is qua tijdbasis en tijden. Er zijn wel een paar uitzonderingen, b.v. PWM tijden die HEEL DICHT op elkaar liggen. Die veeg ik op een "hoop" zodat ze in dezelfde interrupt afgehandeld worden. Effectief zullen PWM's die op een percentage worden berekend nooit samenvallen (1% verschil is zat voor de AVR om dat in 2 losse interrupts af te handelen)

Pfoe genoeg sluiertips opgelicht ???

[Anoniem: 35245]

UPDATE

Check HTTP://www.xs4all.nl/~kruimpie

Hierop is nu naast een weer wat nieuwer schema nu ook de eerste 2 analysis lagen van de softyware te vinden. De eerste laag is een globaal plaatje van de baybus met alle I/O daaromheen. Het 2e plaatje is het hoogste software niveau. Hierin zie je alle software modules die tot nu toe voorzien zijn, plus de dataflows onderling!

Verdere uitleg kun je nog vinden in het global design document wat ook toegevoegd is op de wegpage!

[Anoniem: 35245]

En nog een update. Ik ben het schema toch weer aan het modificeren zodat de PWM uitgangen via n-channel FETs gestuurd worden. De simulatie (zie http://www.xs4all.nl/~kruimpie ) laat duidelijk het verschil zien tussen een pnp darlington en een n-channel mosFET: De mosFET schakelt ook zonder speciale voorschakeltrap vrijwel even steil als de PNP tor, maar je kunt duidelijk zien dat de spanning over de FAN beduidend hoger is (dus kan sneller draaien en de FET blijft duidelijk koeler)...

Dit omdat de FET origineel was ingeruild voor een pnp transistor omdat toerenmeting niet mogelijk leek. Volgens de nieuwe meetmethode is dit echter wel mogelijk!

[mr_a]

Op woensdag 27 februari 2002 22:22 schreef --EasY-- het volgende:

[..]

AHA nu gaat het me dagen over die SMbus... Dat is gewoon de seriele bus waarmee ze die 8 pins EEPROM chippies uitlezen op de DIMM.... duuuh dat is een supersimpel serieel truukje... clocklijn/datalijn.... Een soort I[super]2[/super]C maar volgens mij dan nog simpeler... een SPI busje ofzo.... Goh kun je die ook zelf aansturen... Als de tijd rijp is ga ik daar misschien wel een stukje software voor schrijven... dat zou dan de slave-kant moeten zijn, die is net weer iets lastiger dan de masterkant...

Euh, even offtopic toevoeging:

SMbus wordt wel voor meer gebruikt dan alleen voor het uitlezen van de SPD, hoor!
SMbus is een bus die opgezet is om parallel aan alle ander bussen in het hele systeem alle apparaten te combineren met het doel statusinformatie e.d. toegankelijk te maken voor software applicaties.
Als je een schema maakt van de opbouw van je PC, zou je de SMbus dus tussen alle belangrijke componenten kunnen tekenen. Alles wat MBM uitleest komt van SMbus, maar er kan waarschijnlijk nog veel meer mee.

Just my € 0.02

[SlinkingAnt]

Ik ben ff je Global_design door gelopen. Van het technische gedeelte van toerental snapte ik nie veel, zolang het maar werkt vind ik het best, maar toch ff een paar dingetjes:

Is het mogelijk om je lcd in samenwerking met Smartie ofzow te gebruiken? Of moet er een apartje plugin voor komen om de data over de seriële poort te jagen.

Wanneer de uitlezing van tempsensors op mobo goed werkt, is het dan niet beter om maar 2 externe sensors te gebruiken en 4 fans met RPM uitlezing te hebben?

Hard disk activiteit is ook leuk. Ook een knightrider functie inbouwen voor 7 en/of 8 leds (1 led wordt meestal toch zoemer denk ik) met instelbare snelheid en met fading?

En vanaf hoofdstuk 6 snap ik er de ballen niet meer van, maar dat is toch alleen het technische gedeelte

[Anoniem: 45185]

Is het misschien een idee om als optie een tweede HD-activity in te bouwen (als NIC of iets anders).

Ik heb btw je word document doorgelezen, ik moet eerlijk zeggen dat ik het errug lastig vind, maar als ik de communicatie tussen de seriele poort en de baybus maar ga snappen komt het goed.

Heb ik nog 1 vraagje waarom laat je de communicatie niet verlopen tussen de printerpoort en de baybus?

[Anoniem: 35245]

Op zondag 03 maart 2002 12:06 schreef SlinkingAnt het volgende:
Ik ben ff je Global_design door gelopen. Van het technische gedeelte van toerental snapte ik nie veel, zolang het maar werkt vind ik het best, maar toch ff een paar dingetjes:

Is het mogelijk om je lcd in samenwerking met Smartie ofzow te gebruiken? Of moet er een apartje plugin voor komen om de data over de seriële poort te jagen.

Ik weet niet in hoeverre Smartie met verschillende hardware overweg kan. Indien Smartie een LCD display serieel kan aansturen, dan lijkt het me zeker nuttig om de communicatie "doorzichtig" te maken zodat Smartie ermee overweg kan. Helaas is het wel zo dat als smartie tegen de seriele poort praat, dat het goed mogeijk is dat een 2e aplicatie dit niet meer mag. Dus je kunt in dat geval altijd maar een progje hebben wat tegen de baybus kletst.

Wanneer de uitlezing van tempsensors op mobo goed werkt, is het dan niet beter om maar 2 externe sensors te gebruiken en 4 fans met RPM uitlezing te hebben?

Mja, ik heb nu 4 toerenkanalen EN vier temperatuur sensoren En dat alles met dezelfde hardware

Hard disk activiteit is ook leuk. Ook een knightrider functie inbouwen voor 7 en/of 8 leds (1 led wordt meestal toch zoemer denk ik) met instelbare snelheid en met fading?

Iets dergelijks staat inderdaad in de specs. De module 1.3, de LED controller is verantwoordelijk voor het besturen van de LEDs en hun eventuele patronen. Dit wordt ZEKER een feature van de hardware!

En vanaf hoofdstuk 6 snap ik er de ballen niet meer van, maar dat is toch alleen het technische gedeelte

psies

[Anoniem: 35245]

Op zondag 03 maart 2002 13:08 schreef NextGeneration het volgende:
Is het misschien een idee om als optie een tweede HD-activity in te bouwen (als NIC of iets anders).

Hmmm is wel een leuk ID. Alleen ik heb geen mooie timerpoorten meer over, als ik een 2e hdd activity wil maken dan zal ik toch moeten werken in sftware met polling. Oftewel: Een 2e activity input is onder voorbehoud. Je kunt hem b.v. wel aansluiten op een temperatuursensor ingang, een druktoetsingang of zlefs op een LED uitgang (die je dan voor dat doel als ingang schakelt). Maar of de software daar ook een degelijke activity van meten kan??? Dat zal meten blijken.

Ik heb btw je word document doorgelezen, ik moet eerlijk zeggen dat ik het errug lastig vind, maar als ik de communicatie tussen de seriele poort en de baybus maar ga snappen komt het goed.

Daar komt een aparte spec voor, maar ik heb deze nog niet gemaakt omdat ik hem als het mogelijk is compatible wil maken met die van reeds bestaande seriele LCD displays.

Heb ik nog 1 vraagje waarom laat je de communicatie niet verlopen tussen de printerpoort en de baybus?

Omdat de printerpoort vaak gebruikt is, en een seriele poort nu nog nauwelijks. Bovendien kost een paralelle poort interface bergen I/O naar de microcontroller, zodat je weer minder te besturen hebt. Als laatste: de microcontroller heeft in hardware een seriele poort gebakken die bytes stuurt en ontvangt met zeer weinig overhead. Een parallele poort versie zou al gauw extra hardwarebronnen vragen die je in zo'n kleine micro toch al spaarzaam moet gebruiken.

[SlinkingAnt]

Op zondag 03 maart 2002 19:39 schreef --EasY-- het volgende:

[..]

Ik weet niet in hoeverre Smartie met verschillende hardware overweg kan. Indien Smartie een LCD display serieel kan aansturen, dan lijkt het me zeker nuttig om de communicatie "doorzichtig" te maken zodat Smartie ermee overweg kan. Helaas is het wel zo dat als smartie tegen de seriele poort praat, dat het goed mogeijk is dat een 2e aplicatie dit niet meer mag. Dus je kunt in dat geval altijd maar een progje hebben wat tegen de baybus kletst.

Is het niet mogelijk om softwarematig smartie tegen een virtuele parpoort aan te laten lullen en als de software niks doorgeeft op het scherm, omdan de smartiesignalen (geconverteerd naar seriel (pluginnetje?)) door te laten naar de lcd? Moet lijkt mij toch wel mogelijk zijn of wordt dat teveel werk?

[Anoniem: 35245]

Op zondag 03 maart 2002 22:21 schreef SlinkingAnt het volgende:

[..]

Is het niet mogelijk om softwarematig smartie tegen een virtuele parpoort aan te laten lullen en als de software niks doorgeeft op het scherm, omdan de smartiesignalen (geconverteerd naar seriel (pluginnetje?)) door te laten naar de lcd? Moet lijkt mij toch wel mogelijk zijn of wordt dat teveel werk?

Hm ik weet niet of dat zomaar kan. De parallelle communicatie naar een LCD is nogal gewaggel met bitjes. Om daar weer "droge" tekst uit te halen etc. is denk ik niet makkelijk. Kan smartie geen seriele displays aansturen?? Moet dat proggie toch es downen

[Anoniem: 35245]

Ik heb het nagezocht, en Smartie ondersteund in V5 seriele displays, van het type crystalfontz of Matrix Orbital. Nu is het leuke, dat de Matrix orbital alle commando strings naar het LCD begint met code 0xFE, en de Crystalfontz begint alle commando's met 0x00 - 0x29 of een "ESC[" sequence. Dit maakt ze beide uniek, en dus kan ik de baybus best zo maken dat beide commandosets "gesnapt" worden door de baybus. Een derde unieke sequence maak ik zelf om de baybus-specifieke dingen te regelen (instellingen en sturingen van de PWM regeling en dergelijke)

Oftewel:

Het is zeker mogelijk om via Smartie het display aan te sturen, alsmede elk ander LCD proggie wat crystalfontz of Matrix Orbital ondersteund. Het is gewopon een kwestie van tijd om alle commando's in de microcontroller te programmeren.

Het enige probleem dat nog rest, is dat ik geen 2 applicaties tegelijk naar dezelfde seriele poort kan laten sturen. Dus als b.v. Smartie 5.0 draait en het LCD display stuurt, dan kan ik niet daarnaast ook nog een serieel configuratietootlje ofzoiets draaien.

Een mogelijke oplossing zou zijn dat mijn config/stuur tooltje een virtuele seriele poort aanmaakt waar Smartie o.i.d. weet tegenaanpraat.... Maar of dat een beetje te maken is...??

Voor mensen die de unit in normale omstandigheden sowieso "standalone" willen gebruiken is het geen probleem; een kwestie van smartie ff sluiten als je wilt (her)configureren. Daarna werkt de unit zelfstandig en mag een programma als Smartie de verdere displaybesturing doen. Je kunt dan alleen NIET b.v. de door het mobo gemeten CPU temperatuur constant doorsturen naar de controller.

[SlinkingAnt]

Beterz, dan ben ik voor 90% zeker een tweaker die er zeker 1 ga maken (als mijn financien het toestaan )

[Anoniem: 45185]

Op maandag 04 maart 2002 09:12 schreef --EasY-- het volgende:

Het is zeker mogelijk om via Smartie het display aan te sturen, alsmede elk ander LCD proggie wat crystalfontz of Matrix Orbital ondersteund. Het is gewopon een kwestie van tijd om alle commando's in de microcontroller te programmeren.

Het enige probleem dat nog rest, is dat ik geen 2 applicaties tegelijk naar dezelfde seriele poort kan laten sturen. Dus als b.v. Smartie 5.0 draait en het LCD display stuurt, dan kan ik niet daarnaast ook nog een serieel configuratietootlje ofzoiets draaien.

Een mogelijke oplossing zou zijn dat mijn config/stuur tooltje een virtuele seriele poort aanmaakt waar Smartie o.i.d. weet tegenaanpraat.... Maar of dat een beetje te maken is...??

Hmm, ik denk dat een virtuele seriele poort niet zo makkelijk is (proggies zijn er wel maar voor veel $$).
Ik kan eens vragen of de maker van Smartie zijn programma niet tegen ExtremeBaybus-server (net bedacht ) kan laten praten en dan het server proggie die signalen weer door laten sturen.

Anders wordt het toch eens tijd om zelf met een LCD proggie te beginnen, maar dan kom je natuurlijk niet direct zover als Smartie en kan je ook geen andere LCD proggies op je LCD draaien (al kon dat ook niet als Smartie zelf aangepast werd).

Voor mensen die de unit in normale omstandigheden sowieso "standalone" willen gebruiken is het geen probleem; een kwestie van smartie ff sluiten als je wilt (her)configureren. Daarna werkt de unit zelfstandig en mag een programma als Smartie de verdere displaybesturing doen. Je kunt dan alleen NIET b.v. de door het mobo gemeten CPU temperatuur constant doorsturen naar de controller.

Das inderdaad jammer. Ik dacht dat bijvoorbeeld temperaturen enzo via de paralelle poort gingen (toch?).

[Anoniem: 35245]

Op maandag 04 maart 2002 17:18 schreef NextGeneration het volgende:

[..]

Hmm, ik denk dat een virtuele seriele poort niet zo makkelijk is (proggies zijn er wel maar voor veel $$).
Ik kan eens vragen of de maker van Smartie zijn programma niet tegen ExtremeBaybus-server (net bedacht ) kan laten praten en dan het server proggie die signalen weer door laten sturen.

Mja dat zal wel een probleem worden denk ik. Ik zou zo ook ff niet weten hoe ik zo'n driver moet opzetten voor een virutele seriele poort. Jammer. Misschien kan de programmeur van Smartie wel iets ja, dat programma ziet er gelikt uit

Anders wordt het toch eens tijd om zelf met een LCD proggie te beginnen, maar dan kom je natuurlijk niet direct zover als Smartie en kan je ook geen andere LCD proggies op je LCD draaien (al kon dat ook niet als Smartie zelf aangepast werd).

Tja, dat zal denk ik niet gebeuren. Het blijft altijd achter een programma als Smartie aanhobbelen, dan liever een alternatief zodat Smartie gewoon gebruikt kan worden...

Das inderdaad jammer. Ik dacht dat bijvoorbeeld temperaturen enzo via de paralelle poort gingen (toch?).

Ehm nee. Alles verloopt via de seriele poort. Alleen het programmeren van de code in de microcontroller loopt via de paralelle poort. Na het programmeren wordt deze printerpoortkabel verwijderd en vanaf dat moment werkt de baybus alleen over serieel.

[Anoniem: 45185]

Op maandag 04 maart 2002 20:19 schreef --EasY-- het volgende:

Mja dat zal wel een probleem worden denk ik. Ik zou zo ook ff niet weten hoe ik zo'n driver moet opzetten voor een virutele seriele poort. Jammer. Misschien kan de programmeur van Smartie wel iets ja, dat programma ziet er gelikt uit

Jah, ik blijf rondkijken naar die virtuele seriele poort, want dan is het ook mogelijk om andere programma's dan Smartie te draaien.

Tja, dat zal denk ik niet gebeuren. Het blijft altijd achter een programma als Smartie aanhobbelen, dan liever een alternatief zodat Smartie gewoon gebruikt kan worden...

En daar heb je helemaal gelijk in.

Ehm nee. Alles verloopt via de seriele poort. Alleen het programmeren van de code in de microcontroller loopt via de paralelle poort. Na het programmeren wordt deze printerpoortkabel verwijderd en vanaf dat moment werkt de baybus alleen over serieel.

Alles via de COM-poort gaat dat wel?? (geen ervaringen mee, daarom vraag ik het ook).

[Anoniem: 45185]

Ik heb nog eens over de ExtremeBaybus-server nagedacht.
Het moet dus eigenlijk een 3e seriele poort worden, waar Smartie of een eventueel ander programma of andere programma's tegen aan kletsen.
Op de ExtremeBaybus-server wordt ingesteld wat er weergegeven moet worden en dat wordt dan doorgepompt naar de poort waar de baybus werkelijk op aangesloten zit.

t'is eigenlijk simpel

[Anoniem: 35245]

Op maandag 04 maart 2002 22:38 schreef NextGeneration het volgende:

[..]
*KNIP*
Alles via de COM-poort gaat dat wel?? (geen ervaringen mee, daarom vraag ik het ook).

Ja.

[Anoniem: 35245]

Op maandag 04 maart 2002 23:26 schreef NextGeneration het volgende:
Ik heb nog eens over de ExtremeBaybus-server nagedacht.
Het moet dus eigenlijk een 3e seriele poort worden, waar Smartie of een eventueel ander programma of andere programma's tegen aan kletsen.
Op de ExtremeBaybus-server wordt ingesteld wat er weergegeven moet worden en dat wordt dan doorgepompt naar de poort waar de baybus werkelijk op aangesloten zit.

t'is eigenlijk simpel

Jaaaaaah simpel he

Bouw jij "ff" een prototypje virtual serial port

hahahahah LOL

Ik wou dat het zo simpel was!! Maar de beschrijving die je geeft was wel helemaal wat ik in mijn hoofd had ja...