Welcome, Guest. Please login or register.


Author Topic: HID kezelés ReLoaded (Enter the RPi) (Read 24428 times)

Offline Z80System

  • EP addict
  • *
  • Posts: 3848
  • Country: hu
Re: HID kezelés ReLoaded (Enter the RPi)
« Reply #15 on: 2018.October.14. 15:44:09 »
Quote
Ja, hogy FPGA-mikrovezérlő hibridet akarsz!

Hát, úgy első blikkre nekem úgy tűnt, hogy azokat hívják manapság FPGA -nak.

És itt most nem a PSOC -okra gondolok,
https://en.wikipedia.org/wiki/Programmable_system-on-chip

amik inkább mikrokontrollerek már mint PLD -k (PLD itt logikai értelemben akar állni),
de van PLD funkciójuk is, ami mondjuk nagyon jól jöhetett volna, ha tudom hogy létezik ilyen,
az első körben, mikor még mikrokontrollerrel csináltam sima PS/2 inputot.

Hanem olyan IC -kre, amiket nemes egyszerűséggel FPGA -nak hívnak, és korábbi tulajdonságokkal rendelkeznek.

Például:

https://tinyfpga.com

MachXO2 az non volatile:
https://www.latticesemi.com/Products/FPGAandCPLD/MachXO2#_3D24D0EEB97F430890D7AF24D20DF79A

iCE40™ LP/HX az is non volatile:
https://www.digikey.hu/product-detail/en/lattice-semiconductor-corporation/ICE40LP8K-CM81/220-1858-ND/3877704

stb ...


Quote
Azt még nem mondtad, hogy ebben hogyan is segítene az FPGA, még ha hibrid is. És azt sem, hogy miért kellene ezt mindet a billentyűzetbe vagy annak helyére kötni. Vagy megint benéztem valamit.

Jajj ... :) Remélem lesznek akik megértik ezt a koncepciót ... :)

Az FPGA nem segít ezeken.

A koncepcióm röviden a következő.

- Pici és olcsó mikrokontrollerrel nehézkes az EP igényeinek megfelelő sebességgel reagálni az EP IN/OUT jeleire.

- Pici és olcsó mikrokontrollerrel (sőt még drágával és naggyal is) marha nehéz (nagyon hosszas fejlesztés) USB és Bluetooth HID eszközöket kezelni.
PS/2 még okés, de a masik kettő az 666 nagyságrenddel nehezebb probléma (én úgy látom, szóljon aki szerint könnyű, akkor inkább arra megyek, nem barkácsolok).

- Vagyis inkább az EP -be belülre csak egy olyan fokozatot teszek, ami tökéletes sebességgel tud reagálni az EP IN/OUT jeleire,
egy 80-128 bitnyi bufferből, ami lefedi az EP billentyűzet mátrixot (és esetleg később még pár dolgot, mint pld. a reset, stb.)
és a lehető legkevesebb számú dróttal/pinnel/csatlakozóval lehet kihozni az EP -ből, egy soros interfészen.

- A mindenféle HID eszközök kezelése innentől opcionális, csinálhatod az EP -n kívülről olyan komplexitású hardverrel,
amivel csak akarod, es ki tudod vele szolgálni az előző pontban megnevezett soros interfészt.

- Ez a komplex hardver pld. lehet egy Raspberry Pi, ahol API -kat használva olvashatsz HID eszközöket, és GPIO -n pumpálhatod az EP -be a soros interfészen.


Mindezekhez azonban kell egy fokozat, hardver, az EP -be, ami 80-128 bitnyi infót bufferel,
soros interfészen engedi azt írni kívülről, és 4 cím + 8 adat párhuzamos interfészen engedi az EP -nek azt olvasni belülről.

De mi lehet ez a hardver ? Nem találtam ilyen diszkrét alkatrészt sajna eddig.

Itt jönnek a képbe a PLD -k. CPLD, FPGA, akármi, csak tudjam vele megcsinálni a fenti fokozatot.


Díl ?
« Last Edit: 2018.October.14. 16:04:43 by Z80System »
Z80 System

Offline Z80System

  • EP addict
  • *
  • Posts: 3848
  • Country: hu
Re: HID kezelés ReLoaded (Enter the RPi)
« Reply #16 on: 2018.October.14. 16:26:50 »

Quote
Illetve egy makrocellában 1 db. tároló van, azaz 1 bit.

Ezt egyébként honnan vagy miből lehet látni ?
Z80 System

Offline Z80System

  • EP addict
  • *
  • Posts: 3848
  • Country: hu
Re: HID kezelés ReLoaded (Enter the RPi)
« Reply #17 on: 2018.October.14. 16:41:47 »
Quote
A 10 soros verzióhoz is az EPM3128 kellene, a nagyobbhoz az EPM3256, legalábbis ami a bittárolási képességet illeti.

A tutorial -okból úgy látom, hogy cégenként vannak ingyenes fejlesztőszoftverek ezekre a PLD -kre,
és azoknak beállítható egy konkrét PLD típus, amire a szoftverek fordítanak, validálnak.

Vagyis ha lenne egy konkrét logikai hálózatom tetszőleges formátumban (verilog, vhdl, schematic, akármi),
akkor elkezdhetném azt a különböző szoftverekkel fordítgatni a különböző PLD típusokra,
és így biztosat tudhatnék arról, hogy melyik típusba fér bele, melyikbe nem.

Szóval a következő lépés ezen "nyelvek" valamelyikén megfogalmazni a vágyott logikát.

Azt majd meglátjuk mennyi idő alatt jutok el odáig, hogy én azt meg tudjam csinálni,
de van egy ismerős aki azt állította, hogy ő azt seperc alatt összedobja. Meglássuk.

Addig is, ha valaki szintén úgy gondolja, hogy az neki seperc,
akkor nem tartanám vissza attól, hogy megfogalmazza ezt a hardvert ... :)

(80 bitnyi tároló, írni 2 drótos soros interfészen, olvasni 4 cím + 8 adat párhuzamos interfészen.)

Z80 System


Offline Z80System

  • EP addict
  • *
  • Posts: 3848
  • Country: hu
Re: HID kezelés ReLoaded (Enter the RPi)
« Reply #19 on: 2018.October.14. 17:55:01 »

Nézegetve pld. az Intel single port ram példáját,

hacsak nem az a helyzet, hogy az importált könyvtárakban lesz a lényeg,
és esetleg azok a könyvtárak változnak fejlesztőeszközről fejlesztőeszközre,

akkor valóban elég gyorsan mehet a munka ebben a VHDL -ben,
mert ez a ram péda csak ennyi:


Code: [Select]

library ieee;
use ieee.std_logic_1164.all;

entity single_port_ram is
port
(
data : in std_logic_vector(7 downto 0);
addr : in natural range 0 to 63;
we : in std_logic := '1';
clk : in std_logic;
q : out std_logic_vector(7 downto 0)
);

end entity;

architecture rtl of single_port_ram is

-- Build a 2-D array type for the RAM
subtype word_t is std_logic_vector(7 downto 0);
type memory_t is array(63 downto 0) of word_t;

-- Declare the RAM signal.
signal ram : memory_t;

-- Register to hold the address
signal addr_reg : natural range 0 to 63;

begin

process(clk)
begin
if(rising_edge(clk)) then
if(we = '1') then
ram(addr) <= data;
end if;

-- Register the address for reading
addr_reg <= addr;
end if;

end process;

q <= ram(addr_reg);

end rtl;


Z80 System

Offline Z80System

  • EP addict
  • *
  • Posts: 3848
  • Country: hu
Re: HID kezelés ReLoaded (Enter the RPi)
« Reply #20 on: 2018.October.14. 18:16:19 »

Ilyet találtam ennél a MAX 3000A CPLD családnál:

Quote
MAX 3000A devices use CMOS EEPROM cells to implement logic
functions. The user–configurable MAX 3000A architecture accommodates
a variety of independent combinatorial and sequential logic functions.

The devices can be reprogrammed for quick and efficient iterations
during design development and debugging cycles, and can be
programmed and erased up to 100 times.


Namost ez mi a rák ? Max 100X írhatom csak bele a logikát ? Az nagyon sovinak tűnik nekem ... :(

Ha már kész a funkció, akkor ok, de amíg fejleszti az ember ... ez sovi ...

Z80 System

Offline Z80System

  • EP addict
  • *
  • Posts: 3848
  • Country: hu
Re: HID kezelés ReLoaded (Enter the RPi)
« Reply #21 on: 2018.October.14. 19:41:40 »
Van egy újabb aprócska kis bökkenő ezzel a megakoncepcióval ... :)


Ha az RPi -t az EP -ről tápolom, akkor az EP kikapcsolásnál az OS nem lesz boldog az RPi -n ... :)

Valamint egy EP kikapcs után az RPi olyan 30 másodperces nagyságrendig boot -ol, és addig nem lenne billentyűzet ... :)


Persze mondhatjuk, hogy akkor adunk külön tápot az RPi -nek, de akkor meg megborul a szinkron a soros kommunikációnál.


Szóval mondjuk azt a zsinórt, amin az EP tápolta volna az RPi -t, azt nem tápoltatásra kell használni,
hanem mondjuk arra, hogy jelezzük az RPi felé, hogy egy újraindulás történt, és ezért az első bittől kezdje inkább újra a kommunikációt ...


Semmi se 1cerű ... :)
Z80 System

Offline Z80System

  • EP addict
  • *
  • Posts: 3848
  • Country: hu
Re: HID kezelés ReLoaded (Enter the RPi)
« Reply #22 on: 2018.October.14. 21:50:00 »

Oksa, újabb orbitális benézés ... :)

Az RPi szintén nem 5V toleráns.

Mondjuk bemenetként nem is nagyon kellene használni a GPIO -kat,

az RPi csak "írná" a soros interfészt,

de az simán lehet, hogy ilyen "felhúzott" típusú input lábat kellene lehúzogasson ... és akkor az 5V -ra lenne felhúzva az EP oldalon nyilván ...


Szóval ezt az egész jel illesztgetést úgy látszik nem lehet elkerülni ...


Persze még mindíg egyszerűbb lehet az RPi oldalán illeszteni 2 vagy 3 drótot,
mint a billentyű mátrix buffer fokozat EP felőli oldalán 12 -t ...

Persze valójában ott is lehet hogy csak a 4 cím vonalat kéne visszafogni 3.3V -ra,
mert a 8 data vonal meghajtaná az EP TTL -t ...

Z80 System

Offline Z80System

  • EP addict
  • *
  • Posts: 3848
  • Country: hu
Re: HID kezelés ReLoaded (Enter the RPi)
« Reply #23 on: 2018.October.14. 21:58:34 »
Ha az előbbi viszont igaz, akkor nem kéne annyira ragaszkodjak az 5V toleráns komponensekhez,
és szabaddá válhatna az út a 3.3V -os FPGA -k felé, mint pld. ez:

https://store.tinyfpga.com/products/tinyfpga-a1


Tehát az RPi GPIO 3.3V -on, illesztés nélkül kommunikálna egy 3.3V -os CPLD/FPGA -val,
a CPLD/FPGA pedig 3.3V -al adná az adatvezetékeket az EP -nek (ahol ez már jó lenne TTL magasnak),

csak az EP 4 cím vezetékét kéne illeszteni (visszavenni 3.3V -ra) a CPLD/FPGA -hoz ...

Z80 System

Offline balagesz

  • EP user
  • *
  • Posts: 277
  • Country: hu
Re: HID kezelés ReLoaded (Enter the RPi)
« Reply #24 on: 2018.October.14. 22:25:46 »
Ejj, mennyi olvasnivaló... :) De sorban.

Igen, ez lenne a terv. Max. még lehet hogy bele kell kombinálni a címzésnél a 4 sorkiválasztó drót mellé azt az 5. trigger drótot a lefutó éllel ...

A trigger ehhez "by design" nem kell, ha csak nem akarod magát a 4 bitet is saját magad tárolni a gépben levő U25/74LS273 helyett.

Lehet tényleg inkább az FPGA -k között kéne keresgéljek, ott a "kis kapacitású" is sokkal nagyobb mint itt a CPLD -knél a "nagy kapacitású" ...

Valóban, de ezt egy kissé "ágyúval verébre" megoldásnak érzem, ráadásul a jelszintekkel ott is bajban leszel. (Ha csak nem valami obsolote FPGA-t választasz.)

Inkább érdemes lenne átgondolni, hogy nem lehetséges-e mégis AVR-rel összehozni.

Én is inkább ezt tippelném, ez a legegyszerűbb (-nek hangzó) verzió. Egy hasonlót csináltam én is, akartam is róla írni, majd előszedem a témát.

Másrészt - ezt majd balagesz pontosítja - elég jól túlhajthatóak. Emlékeim szerint a SwinSID egy 16 MHz-es jószágon lett megvalósítva kétszeres órajel mellett.

Pontosítok: a SwinSID-ben egy 20 MHz-es AVR (ATmega88) van, és az megy 32 MHz-en, ez "csak" 1.6×-os túlhajtás. :-D

Harmadrészt azért még egy 10 MHz-en hajtott Z80 sem tud mikroszekundumonként billentyűt olvasni, arról nem is szólva, hogy értelme sincs.

Ez így van, Az OUT utasítás utántól az IN végéig van idő, ezt célszerű kiszámolni, hogy mennyi. Annyi alatt kell odaérni.

Hát ezért akartam keresni diszkrét alkatrészt, de nem találok ... összerakni sem akarok IC -ből ... sőt ha csak 1etlen módot találok rá, nyákot sem akarok tervezni, gyártatni, forrasztani ...

Ez így azért nehéz lesz ám! ;) Eléggé speciális a feladat, erre kész eszköz nem nagyon lesz.

Hacsak... Jut eszembe! Itt van az alkatrészed!. Kérdés, hogy beszerezhető-e? Mondjuk ehhez is kell némi körítés, de a lényeget megoldja. :-D

Korábbi topikokban megállapítottuk(ták), hogy ha kitolsz Z80 -on egymás után egy OUT és IN utasítást, akkor a kettő között (4 MHz Z80 esetén) kb. 3 mikroszekundum lehet,
mire a bill. sornak a helyen kell lennie. Persze ha a kód nem közvetlenül olvas az OUT után, akármennyi is lehet, de működnie kell nyilván minden körülmények között.

Na, itt is van az idő. Ha a 3 µSec az mondjuk csak 1, az akkor is 1000 nSec. Egy 20MHz-es mikrovezérlőnek az 20 órajelciklus, de egy 50 MHz-esnek már 50! Azzal azért elég sok helyre oda lehet érni.

Valamint egy mikrón USB és Bluetooth billentyűzet, egér, jatékvezérlő (és franctudja mit találok még ki) támogatásokat lekódolni ...

Az szép feladat, igaz.

Ha ilyen pár bit sem fér bele, akkor minek az a rengeteg láb a tokozáson, meg mi végre ez a nagy hűhó ?

A rengeteg láb mondjuk rengeteg bemenetnek jó ám! ;)

A neve az, hogy CPLD. Ami a "Complex programmable logic device" rövidítése.
Mondom COMPLEX !!!
Hát kérdem én, mi ezen a complex akkor ? Attól complex, hogy tudnak írni egy 666 oldalas .pdf -et róla ?

Nem, ez attól CPLD, hogy több SPLD (Simplex :-D Programmable Logic Device) blokk van benne, legalábbis nagy vonalakban.

- Pici és olcsó mikrokontrollerrel nehézkes az EP igényeinek megfelelő sebességgel reagálni az EP IN/OUT jeleire.

Szerintem pici és olcsó mikrokontrollerrel lehet ilyet csinálni, csak azzal megint az lesz a gond, hogy nem akarod majd se programozni, sőt: beforrasztani se. :-D Sajnos ezek az "új-hullámos" cuccok fura tokozásban vannak.

- Pici és olcsó mikrokontrollerrel (sőt még drágával és naggyal is) marha nehéz (nagyon hosszas fejlesztés) USB és Bluetooth HID eszközöket kezelni.

Ez viszont igaz.

- Vagyis inkább az EP -be belülre csak egy olyan fokozatot teszek, ami tökéletes sebességgel tud reagálni az EP IN/OUT jeleire,
egy 80-128 bitnyi bufferből, ami lefedi az EP billentyűzet mátrixot (és esetleg később még pár dolgot, mint pld. a reset, stb.)
és a lehető legkevesebb számú dróttal/pinnel/csatlakozóval lehet kihozni az EP -ből, egy soros interfészen.

Ez világos.

- A mindenféle HID eszközök kezelése innentől opcionális, csinálhatod az EP -n kívülről olyan komplexitású hardverrel,
amivel csak akarod, es ki tudod vele szolgálni az előző pontban megnevezett soros interfészt.
- Ez a komplex hardver pld. lehet egy Raspberry Pi, ahol API -kat használva olvashatsz HID eszközöket, és GPIO -n pumpálhatod az EP -be a soros interfészen.

Azért az nem semmi, hogy egy 8 bites gép billentyűzetét kiváltandó egy komplett, GHz-es sebességű számítógép lesz használva. :) Ekkor minek egyáltalán az eredeti gép? Az árpin futhatna egy EP emulátor, aztán kész is vagy. :-D

Mindezekhez azonban kell egy fokozat, hardver, az EP -be, ami 80-128 bitnyi infót bufferel,
soros interfészen engedi azt írni kívülről, és 4 cím + 8 adat párhuzamos interfészen engedi az EP -nek azt olvasni belülről.

De mi lehet ez a hardver ? Nem találtam ilyen diszkrét alkatrészt sajna eddig.

Itt jönnek a képbe a PLD -k. CPLD, FPGA, akármi, csak tudjam vele megcsinálni a fenti fokozatot.

A fent linkelt MT8812 ennek a jelentős részét megcsinálja. Ahhoz, hogy kevés jellel, "sorosan" tudj bele adatot tolni, kelleni fog mellé legalább egy shift-regiszter.

Makrocellába 1 tároló:

Ezt egyébként honnan vagy miből lehet látni ?

Az általad is linkelt doksi 6. oldalán a Figure 2. pont erről szól.

Namost ez mi a rák ? Max 100X írhatom csak bele a logikát ? Az nagyon sovinak tűnik nekem ... :(

Itt inkább ilyen 1000 szokott lenni, de legalább nem hazudnak. :-D

Offline Z80System

  • EP addict
  • *
  • Posts: 3848
  • Country: hu
Re: HID kezelés ReLoaded (Enter the RPi)
« Reply #25 on: 2018.October.14. 23:19:50 »
Quote
A trigger ehhez "by design" nem kell

Hurra-hurra. Annál jobb.


Quote
ha csak nem akarod magát a 4 bitet is saját magad tárolni a gépben levő U25/74LS273 helyett.

Dehogy akarom. Minek az nekem. Csak legegyszerűbben. Szolgálja ki az EP -t annyi a lényeg.


Quote
Valóban, de ezt egy kissé "ágyúval verébre" megoldásnak érzem,

Hát ez már akkor is az volt, mikor 16 MHz -es 32 bites mikrót használtam PS/2 illesztéshez ... :) (Oszt mégse elég gyors ugye ...)

A CPLD/FPGA kérdés meg az én oldalamról nézve ugyanaz.
Venni akarok egy lehető legkisebb méretű (ilyen 30 mm X 20 mm, linkeltem már őket) breakout board -ot egy valami programozható logikai elemmel.
Amire lehetőleg nem is akarok malacozni már semmit. Azzal akarom megoldani ezt a fokozatot.

A logika, ami benne lesz, az ugyanaz, akármi is az a programozható alkatrész.

Nem mindegy akkor nekem, hogy azt az elemet a lapon, amit nem is én tettem oda, ugy hívják hogy CPLD vagy FPGA ?


Quote
Egy 20MHz-es mikrovezérlőnek az 20 órajelciklus, de egy 50 MHz-esnek már 50! Azzal azért elég sok helyre oda lehet érni.

Még az 50 Mhz -nél se olyan triviális, hogy mire kiváltódik az a megszak, mindenféle mechanizmusokon keresztül,
meg le push -olja azt a 2 regisztert, amit muszály, és kiírja végre a billentyűzet sor bájtját, addig nem csúszik ki az 1 mikroszekundumból.
Assembly megszakításkezelőre gondolok. Márpedig nincs több mint 1 mikroszekundum.
És az nem segít semmit, hogy ezt relatíve csak ritkán kell csinálnia, és nem visz CPU időt.
Amikor kell, ritkán, akkor a működés múlik rajta, ha 10 MHz Z80 kódban egymás után van az OUT és az IN.


Quote
Azért az nem semmi, hogy egy 8 bites gép billentyűzetét kiváltandó egy komplett, GHz-es sebességű számítógép lesz használva. :) Ekkor minek egyáltalán az eredeti gép? Az árpin futhatna egy EP emulátor, aztán kész is vagy. :-D

Na, ez egy komplex kérdés ... :)

- Először is, ennek az egésznek nincs semmi értelme ... :)
Az az értelme, hogy mikor olyanom van, akkor a legmodernebb (fém) Apple Bluetooth billentyűzettel fogom kattogtatni az EP -t ... a VAS EP -t ... :)
És gondolok azokra az időkre, mikor törött billentyűfóliával kellett vergődni ... :)

Ha emulátor, akkor mér mennék az RPi -re ? Elfut az a desktop gépeimen is tökjól ... :)

Nézd másképp ! Az RPi az csak egy shortcut itt ...

Az EP -be kerülő fokozat ugye egy logikailag igen egyszerű fokozat, hozzáértő gondolom fél nap alatt hekkelné össze, csak én bénázok vele ennyit.
666 nagyságrenddel egyszerűbb fokozat, mint a PS/2, USB, Bluetooth HID eszközök kezelése.
Egyszerűsége miatt kis mérete lesz, be lehet rakni EP házba is. És csak 4 drót jön ki.

Felfoghatjuk ezt egyfajta "EP keyboard" csatlakozásnak is.

És kívülre nem kötelező atomreaktort, szuperkompjútert, modern PC -t vagy akár még RPi -t sem kötni, hogy meghajtsd ezt az új "EP keyboard" bemenetet.

Ha valaki olyan frankó csávó (pld. múltkor óta már én is képes vagyok erre),
akkor fog egy kis mikrót, ami csinál egy PS/2 -> "EP keyboard" átalakítást,
amihez mostmár nem kell többé az 50 MHz,
hanem lassú, pici, olcsó, kevés GPIO lábú (4, mert mindkét oldalon soros) mikró is megteszi,

és azt az átalakítót egy kis lengő adapterré szerelve bedugja a PS/2 eszköze és az "EP keyboard" csatlakozója közé.

Tápot kap az "EP keyboard" csatlakozóról.

Ha valaki még faszább gyerek,
ugyanezt eljatszhatja USB vagy Bluetooth esetén is.
Lehet pár év múlva olyan kompakt cuccok lesznek, hogy még én is meg fogom tudni csinálni azt is.

Lehet csinálni HUB eszközt is, amire dughatunk 2 PS/2 és 2 USB eszközt is ... :)


Most viszont egy huszárvágással RPi, amivel alkalmazás szintű API -kkal pikkpakk kezelek minden fajta csatlakozót,
és minden típusú eszközt. (pld. game kontrollert bemappolok billentyűkre. billentyűre meg van írva minden játék. stb.)

De nem kell mindenki ilyen igénytelen és lusta legyen,
ha valakinek kell a kompaktabb megoldás,
mint a (mostmár nagyon úgy tűnik) külön tápról működő RPi,
akkor azt is meg tudja valósítani egy relatíve lassú, olcsó, kicsi eszközzel.
« Last Edit: 2018.October.14. 23:48:57 by Z80System »
Z80 System

Offline Z80System

  • EP addict
  • *
  • Posts: 3848
  • Country: hu
Re: HID kezelés ReLoaded (Enter the RPi)
« Reply #26 on: 2018.October.14. 23:45:19 »
Quote
Hacsak... Jut eszembe! Itt van az alkatrészed!. Kérdés, hogy beszerezhető-e? Mondjuk ehhez is kell némi körítés, de a lényeget megoldja. :-D

Azt írja, hogy 40 -es DIP -be rakják. (Breakout board -ot valszeg nem fogok találni az SMD verziójából ...)

A 40 -es dip 52 mm X 15 mm, és azt írod még kellene valami mellé ...


A CPLD/FPGA breakout board -ok, amiket linkeltem olyan 30 X 18 -asok. És remélem hogy 4 vonalnak az 5V -> 3.3V -ra illesztésén kívül semmi más nem kell majd hozzájuk.
Z80 System

Offline Z80System

  • EP addict
  • *
  • Posts: 3848
  • Country: hu
Re: HID kezelés ReLoaded (Enter the RPi)
« Reply #27 on: 2018.October.15. 00:18:42 »
Mondjuk 1 valami miatt folyamatosan gondokodok azon, hogy mégse csupán az 1 db programozható logikai áramkört tegyem belülre a géphaz alá.


Ugyanis ebben az esetben, alapból csak egy billentyűzet mátrix kivezetésem van.
A többi amit írtam mind igaz, de csak az EP billentyűzet mátrix -át tudom kívülről módosítani.

(Mondjuk, ha belegondoltok, már így is lehetne az RPi -ről távvezérelni az EP -t ... :))

De pld. alapból reszetelni nem tudnám a gépet.

Az már a korábbi PS/2 -s, mikrokontrolleres esetben is meg volt csinálva, hogy a mikrokontroller felismer különböző billentyűket,
és azok hatására mindenféle reszeteket hajt végre ( meleg, hideg, rohadt hideg (C + reset) :) )

Namost ez itt nem működne, mert a beszerelt elektronika már csak EP billentyűzet mátrixot kap, abban meg nincs reset.

Bonyolultabb dolgokat meg nem hinném hogy bele kéne rakjak a CPLD/FPGA -ba.
Egy esetleges protokoll értelmezést, vagy ilyesmit, amibe belefér a bill. mátrix, a reset, és még később akármi más is ...


Szóval, talán mégis inkább a mikrokontroller + dual port ram kombo volna jó.

Dual port ramot már linkeltem, és AVR mikrokontrollereket is lehet fillérekért kapni 24-28 láb körüli DIP tokban !


És akkor a dolog annyiban változna meg, hogy kívülről a soros vonalon bejövö anyagot először a mikrokontroller kapná meg,
vele kommunikálna a külső eszközkezelő elektronika,
a mikrokontroller először megrághatná a bejött anyagot,
és annak protokollja tartalmazhatná, hogy most a bill. mátrixot küldtük, vagy pedig egy reset command -ot.

A bill. mátrixot a mikrokontroller átpasszolná a dual port ram -nak,
a reset -et vagy egyéb kommandokat pedig végrehajtaná.


És akkor ebben az esetben, lehet hogy megválhatnánk a GPIO -n keresztül lebonyolított soros kommunikációtól,
és megkövetelhetnénk a soros kivezetésünkhöz valami szabványos HW protokollt,
mint az I2C, SPI, satöbbi ... :)


Persze még egyiket sem ismerem, és ki kéne választani hogy melyik legyen, mert többfélét támogatni nem lenne jó ...

Konfigurálgatni kéne az egységeket a két oldalon ...
« Last Edit: 2018.October.15. 22:32:52 by Z80System »
Z80 System

Offline Z80System

  • EP addict
  • *
  • Posts: 3848
  • Country: hu
Re: HID kezelés ReLoaded (Enter the RPi)
« Reply #28 on: 2018.October.15. 00:27:52 »

Persze az is lehet, hogy nem kell ennyire messze menni,

hanem csak az üres felső 48 bit egyikét ki kell jelöljem reset bitnek,
és a CPLD/FPGA (hiszen ő tárolja a teljes mátrix -ot) csak azt az egy bitet kell figyelje,

és annak hatására reset -elnie.


Nade hogy tudok logikai áramkörökkel időzítve mondjuk dupla resetet kiváltani ? Valami számlálókkal ? De akkor kell órajel is ...

És hogy tudom elérni hogy beálljon a C gomb bitje a mátrixban reset előtt ...


Lehet hogy a mikrokontrolleres (+ dual port ram) verzió a jobb ...


Sok sok kérdés ... :)

Z80 System

Offline Z80System

  • EP addict
  • *
  • Posts: 3848
  • Country: hu
Re: HID kezelés ReLoaded (Enter the RPi)
« Reply #29 on: 2018.October.15. 21:22:57 »
Beszéltem ma egy ismerősömmel, és volt pár jó ötlete.

Ennek hatására egyenlőre úgy tűnik, hogy ebben az iterációban talán nem kell még visszalépjek
a mikrokontroller + dual port memory működésre. Amíg persze ez meg nem borul valahol ... :)

A működést a következőképp terveztük.


Az EP -be épített egységnek lesz ugye valahány bitnyi memóriája. Ezt nevezzük mondjuk "frame" -nek.

Egy két drótos, 1 clock + 1 data soros vonalon engedi ezt a frame -et felülírni,
valamint a 12 drótos, 4 cím + 8 data vonalon engedi a frame első 128 bitjét olvasni.

A frame lehet nagyobb is akár, mint 128 bit.
Első körben valószínűleg egyetlen bittel lesz több, az lesz a reset bit.
(Hely szűke esetén az is lehet hogy a 128 bit csak 80 bit lesz, ez majd elválik.)
A lényeg hogy a frame különböző területekből állhat,
amit addicionálisan, bővíteni is lehet a jövőben.


Pld. egy esetleges scenárió:

frame = billentyűzet mátrix elso 80 bitje + 1 reset bit + billentyűzet mátrix maradék 48 bitje + 8 bit mouse X + 8 bit mouse Y + 16 bit mouse X + 16 bit mosue Y

Ez egy olyan fejlődést írna mondjuk le, hogy:
- először csak a billentyű mátrix első 80 bitje fért az FPGA -ba
- később beletettünk egy reset bitet is, és az FPGA azt a reset -re teszi
- még később lett nagyobb FPGA, és beletettük a maradék billentyűzetmatrix biteket, és rámeppeltünk valamilyen dolgokat (amit az EP ugye tud olvasni natívból)
- még később beletettünk 8 bites egér inputot, és azt valahova belepumpáljuk az EP -be ...
- még később beletettünk 16 bites egér inputot, mer a 8 az már sovány volt, és azt megintcsak valahova belepumpáljuk az EP -be ...

Csökkenni nem tud a frame mérete, mindíg csak nő, a 8 bites egér input akkor is bennemarad, ha a 16 bites már feleslegessé teszi.

És természetesen nem nőhet az egekbe, nem pumpálhatunk be vele pld. hang mintát, szerintem úgy kb. soha nem fogja meghaladni a 256 bitet ...


A mindenkori teljes frame -et másodpercenként sokszor (mondjuk úgy 100 - 1000 frame/sec) frissítjük a soros bemeneten keresztül.

Ez ugye mindent maxra téve kb. 256 KHz -es frekvenciát követelne a soros vonalon,
és már egy 16 MHz -es AVR -en is simán toltam 4 MHz -et a GPIO -ra C nyelvből, sima ciklussal,
szóval a mikrokontrollereknek sem lesz az gáz, a többszáz MHz -es RPi pedig valszeg ki se röhögi.

A frame első bitje előtt lesz egy "frame kezdete" jel. Ez a soros vonalunk mindenkori órajelének töbszörös ideéig (mondjuk 10 - 20) lehúzott clock vonal.

Ez után a külső egység belepumpálja az általa ismert frame -et a belső egységbe.
Ha előbb jön az új "frame kezdete" jel, minthogy frissülne a belső egység összes bitje (a külső egység kisebb frame -et ismer még),
akkor a fennmaradó bitek nem frissülnek a belső egységben.
Ha később jön csak a "frame kezdete" jel, mint amit a belső egység ismer (a külső egység nagyobb frame -et ismer már),
akkor a "felesleges" biteket a belső egység elnyeli, és nem tárolja el.


A belső egység a bekapcsolás után a párhuzamos (kimeneti) portján egyből működik,
de a soros (bemeneti)porton jövő adatokkal addig nem csinál semmit, míg nem kap egy "frame kezdete" jelet.

Így ha a külső egységünk nem a belső egységtől kapja a tápot
(belső egységtől pld. egy "lengőre szerelt" billentyűzet konverter kapja),
hanem saját táppal működik
(mint pld. az RPi),

akkor ha az EP -t kikapcsoljuk, és a belső egység lekapcsol ettől,
mikor visszakapcsolják az EP -t, akkor a belső egység újra szinkronba kerül a külső egységgel,
ami a kikapcsolás alatt zavartalanul tovább tolta a biteket, és a szinkronból így kilépett.


Az olyan "komplexebb" dolgokat, mint pld. makrók vagy szekvenciák (pld. hideg reset, ahol 2 reset van egymás után)
azt mindíg a külső egységeknek kell megvalósítaniuk fenti interfészt használva.

Ez rossz azért, mert mindent mindíg meg kell valósítani minden külső egységben újra,
meg azért is mert lesznek limitációk, mint pld. a frame frissítési frekvenciája,
ami egy adott szekvencia (hideg reset) belső egységgel történő implementációjánál nem lenne.
(De a reszetre jó lesz az a frekvencia is ... :))

De ez jó is azért, mert az egyes megvalósítások lehetnek testreszabva a külső egységekre.
(Persze lehet, hogy ez sovány vigasz, de akkor is ez a helyzet ... :))


Hát így állnánk most ...
« Last Edit: 2018.October.15. 22:13:45 by Z80System »
Z80 System