Hardware Data Saver (om niet loger te zeggen) voor serieele protocolen

Ik had het fijne idee om zelf een Data Loger ineen te knutselen, tot ik ontdekte dat ik dat uiteraard niet kan met mijn ondermaatse soldeerkunst.
Toch wil ik proberen mijn idee uit te werken, zodat anderen er misschien plezier van hebben, ik heb gegoogled, maar ik vondt enkel commercieele systemen!
Hoog tijd voor een selfmade project dacht ik.
Aangezien bij een com poort de 2 communicatie richtingen in aparte aders lopen met 1 ground, zou het mogelijk zijn op beide lijnen een soort zeer groot schuifregister aan te sluiten, dewelke dan apart uitgeschreven kunnen worden naar de IN zijde, zodat je een opname en een afspeelstand hebt, waarbij je voor het afspelen moet kiezen welke buffer In of Out er gefetcht wordt.
Maar gelukkig is het voor PS/2, btw ook intressanter voor Data Logging, op het eerste zicht veel simpeler.
(data)
(GND)
(+5v)
(clock)
Dan zou je data kunnen doorschuiven op het teken van clock en je schakeling kan volledig +5v-GND powered zijn.
Dan zou er gewoon een soort trage puls moeten zijn die door een knop bediend wordt om alles terug te fetchen,
dat aparaat zou dan gewoon in parallel staan op de lijnen naar bv het keyboard, nadat je info verzameld hebt kopel je het keyboard af, open je notepad(of desbetreffende Linux versie), zet je de switch op fetch en druk je op de knop, die vanaf dan het systeem van clock voorziet, totad je loslaat.

Het is maar een idee, als er iets grof fout mee zit, laat het me weten, als je toevallig een enorme google-krak bent en je hebt een schema voor dit soort rommel gevonden, give it to me!

Btw ik ben maar een simpele hobbyist, met soldeerprobleem incluis, maar ik heb me toch redelijk goed gedocumenteerd.

Thx voor het doorlezen van dit eindeloze plangelal.

HobbyAfwijking van dit forum: Levende Google-Bot worden, like me!

Op 6 januari 2004 20:35:11 schreef AmAx:Thx voor het doorlezen van dit eindeloze plangelal.

Het was me een genoegen dit literaire meesterwerk te mogen lezen (:))

ciao 4 now.....

kijk eens in de electuur van deze maand...

:)lrik

de meeste problemen los je op door er geen probleem van te maken.. de rest heeft alleen wat tijd nodig

thx alrik ik snel even door de bib, meen je het, is dit volledige project er? Dieven, idee-rippers, helden!
en veel meer goeds, I love Elektuur!!!

HobbyAfwijking van dit forum: Levende Google-Bot worden, like me!

Spijtig genoeg is het in elektuur een sensor logger, waarbij er dus sensoren, die een spanning geven, of een weerstand hebben relatief tot de temperatuur, luchtvochtigheid..., en die dus niet op een digitale maar op een analoge manier werken, voor een transfer-logger moet je parralel op een lijn die gebruikt wordt werken, bij ingang van de dalende flank van de door het keyboard opgewekte clock moet de data van de dataline gelezen worden, en dient deze opgeslagen te worden, in een digitaal gehuegen, waar er voor elk clock signaal, geasocieerd met een data signaal(1 of 0), slechts 1 bit gebruikt wordt, de tijd tussen de clocks is steeds hetzelfde.
transfer is
done with a frame of 11 bits
Start Bit (Logic 0)
followed by 8 data bits (LSB First)
one Parity Bit (Odd Parity)
and a Stop Bit (Logic 1)
Each bit should be read on the falling edge of the clock.
Als de line idle is, dus niet gebruikt is ze hoog, dus er zou na een hoog van meer dan 10 bits niet meer gestockeerd moeten worden tot op het moment van de volgende nul(next start bit).
http://beyondlogic.org/keyboard/keyboar1.gif
Spijtig genoeg zend de PC ook soms dingen naar het toetsenbord.
http://beyondlogic.org/keyboard/keyboard.gif
Dwz, de PC houdt de clock down, en brengt de dataline ook op 0, dan laat hij de clock terug los, waardoor het KBD direct terug begint te clocken, op de eerste falling edge ziet het KBD low(start Byte) en vanaf de 2e komt de data(LSB first) na de data komt de stop Byte (Idle), en dan laat de PC ook de dataline met rust, als het kbd dat ziet
stuurt hij een ACK(bevestiging)
Dit geheel terzijde over de transfers.
Samengevat: Als de clock laag gaat(on the falling edge) komt er iets, dat moet worden opgeslagen.
Nu zou het mooi zijn om de door de PC gezonden signalen niet op te slaan, omdat dit bij het weergeven problemen zou geven.
maar daar geraak ik niet uit, samen met het probleem van de opslagchips...

btw: The frequency of the clock signal typically ranges from 20 to 30 Khz.
dat is nodig om de data terug te geven, dan moet de dataloger namelijk zelf de clock maken

Nogmaals dank voor het lezen van dit KoeterWaals

HobbyAfwijking van dit forum: Levende Google-Bot worden, like me!

Ik begrijp dat je de communicatie tussen de PC en het keyboard wilt onderscheppen en de data van het keyboard op wilt slaan? Dat zou kunnen met een (snelle) uC. Daar ontkom je haast niet aan omdat je de datastroom van en naar het keyboard uit elkaar moet kunnen houden. Dat kan door de adressering van het keyboard en PC interface te laten herkennen door de uC. Een en ander hangt sterk af van het protocol dat voor de informatieuitwisseling gebruikt wordt. Zo te zien is het een pseudo I2C protocol. Je zou dan de data in kunnen lezen en na elke stop conditie deze, door de uC laten wegschrijven naar bijvoorbeeld een EEPROM of een ander snel geheugen. Ik ben echter bang dat je op gigantische timing problemen gaat stuiten....
Waarom wil je de data afkomstig van het keyboard apart loggen? Kan toch ook gewoon op de harde schijf worden gezet?

ciao 4 now.....

Wel het is leuk om er een elektronica stukje voor te maken,
en een uC is niet echt nodig want als er clock is is er data, hij moet alleen leren na die lange clock 0 even inactief te gaan

HobbyAfwijking van dit forum: Levende Google-Bot worden, like me!