Na ezaz...

Erről fingomsincs, mármint nemtudom, mert a végcél (többekközött) az h tetszőleges számú Voltmérő és ezzel egyidőben néhány Amperérő által mért adatokat kéne beolvasnom, de hogy ezt hogy tudom megoldani, azt (még) nemtudom (mármint azt e igazából tudom, hogy ezt elektronikailag hogy oldom meg azt se tudom, és gondolom most ezt kéne először kitalálni, és ezután jöhet h hogy olvasom be mindezt a gépbe.

(Javítsatok ki ha rosszul gondolom)

Köszi!

Üdv!

Barbár

Nos, a párhuzamos porttal sok lehetőséged van. Én ezek közül 1-et használtam össz-vissz. Leginkább azért, mert ez bármelyik LPT porttal működik.

Ezzel alapvetően 4 bites adatokat lehet beolvasni a státuszregiszteren keresztül. Ha nagyobb bitszélességre van szükség, akkor a bemenő adatokat pufferelni kell, és max. 4 bitenként be lehet olvasni őket.

A többi lehetőség:

- kétirányú kommunikáció az adatbuszon, 8 biten,
- EPP,
- ECP.

Utóbbi kettőről nem is tudom, hogy működnek, bár a Google nyilván tud adni 1-2 jó linket.

És egyébként 4 bit -en szerinted meg lehetne oldani, hogy több (ha a végcélt tekintjük akkor legalább 8)
voltmérő adatait kéne kezelni + legalább 1 apermérőét.
???

Üdv!

Barbár

Ez teljesen a műszereidtől függ.

Alapvetően, ha az LPT port parancskimeneteit nem használod másra, 8*2*4=64 kétállapotú bemenetet tudsz kezelni.

Ha a műszereid nem sorosan kommunikálnak, akkor 8 műszer esetén 8 bites lehet a felbontása egy-egy műszernek. Ez azt jelenti, hogy a beállított méréshatáron belül 256 különböző értéket tudsz kezelni. A felbontás rovására lehet növelni a műszerek számát, de alighanem jobb lenne valami sorosan kommunikáló műszert választani, mert ott nem lesz ennyire szűk a keresztmetszet.

Esetleg lehet javítani a módszeren, ha az adatbuszt is fel lehet használni a műszerek kezeléséhez, ekkor egy bittel kiválasztod, hogy az LPT-re kötött hardvernek küldöd a vezérlést, vagy a műszerek közül választasz egyet. Így 256*4*4=4096 kétállapotú bemenetet fogsz tudni kezelni, ami 512 8 bites felbontású, 256 16 bites felbontású, vagy 128 32 bites felbontású műszert tudsz kezelni. Ez már elég sok.

Hogyan jön ez ki: 8 adatkimenet, ezt szétosztjuk kétfelé, az elvisz 2 vezérlőbitet, marad 2, és van 4 bemeneti bitünk. Sőt, 5 bemeneti bitünk van, csak az nem 2 hatványa, ezért nem szeretjük, de ettől még használható, így 5120 adódik.

Lassan (de biztosan ) kezd felszálni a köd előttem .

Így most olvasva amit írtál, elkezdte kicsit fejben matekozni, és ha jóértem akkor elméletileg megoldható lenne pl maximum 64 darab 64 bites műszer használata is ha az adatbuszokat is felhasználnám a műszerek kezelésére.

Igazából az adatbuszokat (ha 1 mód van rá akkor mind a 8-at szeretném másra használni, ezesetben, ha jólértem akkor maximum 8 műszert tudnék kezelni, és 8 bites "felbontásban".

Javíts ki ha félreértettem, de a 8 bites felbontás pl azt jelenti h a méréshatárok között 8 különböző értéket tudnék mérni ugye? (ez nagyon kevés sajnos).
Például a Voltmérők többségénél a méréshatárnak 6 és maximum 16 V között kéne mérnie minimum 1/5-öd Voltonként kéne ""skálázva lennie"" (bocs, de nem találta igy fáradtan érthetőbb kifejezést), de inkább 1 tizedes pontossággal...

Bocs, hogyha ilyen ködösen írok, holnap, de legkésőbb hétfőre kiderítem ennél lényegesen pontosabban h minek milyen méréshatárok között kéne működnie.

Ja és az utolsó amit most írni szerette volna a hozzászólásoddal kapcsolatban:
A "műszerek" kifejezés alatt ugye nem csak boltban kapható kész műszereket értünk?


Üdv!

Barbár


Írtad h méréshatár

Megteheted. Egy adott kimenetet nem csak egy adott célra lehet használni. 10 bittel lehet 16 kimenetet előállítani úgy, hogy a 10 bitet 8 adatbitre + 2 vezérlő bitre osztjuk fel. (Utóbbiakat a vezérlőbitekből vesszük el.)

A 8 bites felbontás a méréshatárt 256 részre osztja. Ezt írtam az előbb is. Megint kezdesz fáradni.

16V-6V*100 (ha 10 millivoltos pontosságról beszélünk), az 1000 lehetséges érték. Ehhez 10 bites felbontás kell. Amihez pont illik az 5 bites bemenet.



Én nem értek rajta semmi konkrétat. Számomra most csak egy fekete doboz, aminek van valamennyi kimenete, amiket időnként le lehet olvasni.

:eek2:
Valóban kezdek fáradni...
De most imközben vacsiztam, eszebejutott valami:
Minek akarok ennyire spórolni, meg "kicentizve" használni az LTP-portot, ha simán használhatok 1 PC-ben 2 különálló LTP-portot is, így megkétszerezve minden olyan lehetőséget aminek a számát az LTP-port adottságai korlátozzák.

Tényleg bocs, de omstmár ne fog az agya, főleg ne a matekhoz, de akkor ha pl minden űszernek 6-16V között kell érnie és mindegyiknek 10 millivoltos pontossággal, akkor 1 LTP portra (az adatbuszok felhasználása nélkül) hány műszert is tudnék csatlakoztatni?

A kulcsszó a "ha". Holnap (vagyis ma ) remélhetőleg lesz PCI-os LPT kártyám. Eddig ilyet még tudtommal itt a fórumon senki nem üzemelt be. Ki fogom próbálni, megy-e Delphiből. Persze ha ISA foglalat is van a gépedben, akkor nincs ilyen gond.

Jut eszembe, notóriusan "LTP"-t írsz. Pedig a betűszó a Line PrinTer rövidítése. Tehát LPT, nem LTP.

10 bites, párhuzamos kimenetű műszerből 8-at tudsz rákötni a szabvány párhuzamos portra (az 5 státuszbemenet és 1+3 vezérlő kimenet felhasználásával).

Várom a tapasztalatokat a PIC -os LPT kártyával kapcsolatban.

Egyébként a műszerekre visszatérve: elvileg megoldható h a különböző "műszereknek" különböző legyen a felbontása ugye?

Csak mert van ahol elég pontosan kéne mérnie a dolognak, és van ahol igazából csak azt kéne tudnom, hogy 2 adott vezetéken van-e feszültségkülöbség vagy sem (illetve konkrétan h egy kapcsoló be van-e kapcsolva vagy sem)

Köszi!

Üdv!

Barbár

bocs, hogy beleszólok de én nem kavartam meg barbárt amint az utolsó mondatodban megfogalmaztad egy-két dologal nem árt ha tisztában van az ember egyébként hozzá se kezdjen. nekem az a bajom az egészel, hogy Barbár polgártárs még nagyon kezdő ha nem sértem meg ezzel de alap dolgokal nincs tisztában ezért próbáltam meg egy kicsit okítani mert ha nincs tisztában a számrendszerekkel sem akor kár hozáfogni programozni még Delphi-ben is ami ugyebár egy igen magasszintű nyelv. Szerintem egyébként kár erőltetni ezt a párhuzamos portot sokkal bonyolultab vele a kétirányú komunikáció mint a soros porton + a nyákterv is egy rémálom mert mindkét irányból kell egy puffer a portra valamint itt egy példa, a párhuzamos port data buszának a beállítására, hogy bemenet vagy kimenet legyen:
//**** Lpt port Data bus I/O beállítása *******
function TForm1.LtpIO(): integer;
var
Vagy, Data: Byte;
begin
vagy := PortIn($37A);
Data := Vagy Xor $20;
PortOut($37A,Data);
if Jelzo = 0 then
begin
Jelzo := 1;
Result := 1;
end
else if Jelzo = 1 then
begin
Jelzo := 0;
Result := 0;
end;
end;

nemtudom, hogy ezt Barbár polgártárs mikor írta volna így meg mikor még a számrendszerekkel sincs tisztában egyáltalán mi az az XOR művelet hogyan is néz ki az igazságtáblázata??? meg ilyenek.
Úgyhogy ha szerinted én csak hülyeségeket beszélek :no: akkor kiszálok a témából, jó szórakozást.

A magasszitű nyelvek előnye pont az, hogy nem kell tisztában lenned a pontos HW-SW környezettel. Kivéve, ha magasszintű nyelven HW-t kezelsz. De a SW környezet ismeretét még így is megspórol(hat)od.



Ez az "ízlések és pofonok" témakör. Számos előnye van az egyiknek is és a másiknak is. Ami egy kezdő számára fontos lehet, az a könnyű hibakeresés lehetősége, és remélem, egyetértünk benne, hogy itt a párhuzamos port nyer, azt ui. egy sima voltmérővel is lehet "debugolni".



Természetesen nem írtál hülyeségeket. A többit PÜ-ben írom.

Üdv! Ilyesmiről beszéltem, amit megcsináltam az egyetlen csatorna. Az analóg jelet az "An be " poti adja, a Vref poti a 255-höz tartozó feszültséget jelöli. A cucc az LPT-re csatlakozik (ami egyirányú). Az LPT még három kimenetével és egy léptetőregiszterrel "igen sok" AD-t meg lehet címezni a Chip Select bemenetén. A Data és Clock közös sínen, amely chip nincs engedélyezve annak nagy impedanciás az adat kimenete. A progi mellékelve, A TCL548, csak a konvertált értéket írja ki, a szkóp...magáért beszél. a képen az ujjamal érintem az analóg bemenetet. Vagyis 50Hz, kb2V. (ja a *.bas, az egyszerű .txt lesz)

A léptető regisztert valahogy igy kellene, de egy olyan típust kellene választani amely "magában számol" s egy engedélyező jel hatására egyszerre jeleníti meg a beleírt "adatot" a lábain. De ilyet még nem próbáltam.Itt az EWB fájl is ha van Electr. Worbenched. Ha nincs, akkor legyen! Igy meg lehet érteni a működését. Még egy kép a "szkópról" deszkamodell korában, és amikor egy multiméterből származó 50Hz körüli feszt tettem rá.

Sziasztok!

Csupán érdeklődési jelleggel, kérdezném elsősorban a gurukat, mint például potyo, trudnai, icseny, ATtiny, szilva, bbatka, killbill, dpeti, és sajnos biztos vagyok benne, hogy hagytam ki fontos illetőket, talán elsősorban az AVR-es topikból... szóval az lenne a kérdésem, hogy Ti miként álltok neki egy saját projektnek? Ezt amolyan beszélgetős kérdésként indítom, nem haragkeltőként, vagy vitaszítóként.

Szóval, tegyük fel, van egy nem egetrengetően irtózatosan bonyolult megoldandó feladat, de mégsem 2 db LED felváltva villogtatásáról van szó.

Ilyen esetben ti miként indultok el?

Jó, az nyilvánvaló, mindegyikőtöknek megvan a megfelelő előképzettsége a szakmában, ami a feladatok megoldásához szükséges. Ha nem így van, az ismeretlen dolgoknak utánajártok, ez is rendjén van és teljesen természetes.

Nade, mégis, a feladattal való konkrét elindulás az, ami érdekelne engem (szerintem titkon nagyon sokakat), illetve annak a módja. Sőt, igazából én személy szerint ennek a mikéntjét valamennyire tudom, illetve magaménak is érzem már, mint bizonyos módszert, és alkalmazom itthon egy ideje, inkább úgy kérdezném ezeket, mintha sok-sok kezdő pártfogójaként működnék és a kezdő pályafutási kérdéseiket tolmácsolnám az irányotokba.

Mert az addig oké, hogy valaki olvasgatja, megérti és megtanulja az utasításokat, megismeri az adatlap használatát és még angol tudása is van valamennyi. Aztán elkezdi nézegetni a mintaprogramokat, szépen sorjában azokat is megemészti és megérti a delikvens.

Nade, ezzel még nem lehet valakinek a logikai feladatmegoldó képességét fejleszteni, csak nagyon lassan és tízmillió példaprogramot átrágva.

Megengedhető-e például az, hogy usgyi, egyből leülünk a forráskód elé és gépelni kezdünk ezerrel nekilendülve?

Szerény véleményem szerint nem, ez nagyon nem elég, ettől nem lesz valaki jó programozó.

Tudni kell, mi az a feltétel ( állítás ), ami a program megoldását jelenti.
Ez szinte magától adja azokat a típusokat, változókat, amiket a progam használni fog.
Az adatok pedig szinte sugallják a programot.
Nekünk Wirth bácsi adattípusaival és struktogramjával tanították a programozást.
Elemi adattípusok ( logikai, halmaz, egész, karakter, állomány ), és konstrukciók ( komplex, vektor, mátrix, verem, sor ) valamint az elemi programok ( üres, értékadás, vége ), valamint a programkonstrikciók ( szekvencia, feltételes ( if ), ciklus, eljáráshívás ( rekurzió is ) ) alapján néhány alapfeladatot érdemes megtanulni, mint például a lineáris keresést.
Ezekből összerakható a program. Persze papíron, később fejben, de érdemes dokumentálni. Kellemetlen, amikor egy év múlva nem értem a saját programom .
Utána jön a kérdés: és ezt most milyen nyelvre kell kódolni?
(( Az utóbbi hasonlít a C fordítóra, aminek megadható, milyen processzorra fordítsa a forrásprogramot. ))
Ha éppen nincs logikai vagy komplex típus, akkor csinálni kell.

Igen, pont ilyesmire gondoltam.

Például létezik-e még, és bevett szokás-e a profibbak körében az, hogy először egy logikai vázlatot építenek fel, mondjuk akár csak papírra vetve? Olyasmire gondolok, hogy folyamatábra készítése, illetve hasonlók... Vagy ez manapság már maradi megoldás nagyon?

Kezdetben egy egyszerű beolvasom-összeadom-kiírom feladatra is struktogrammot ( blokkdiagrammot ) rajzol a programozó. A sokadik után már nem tesz ilyent.
De amikor egy olyan feladattal találkozik, amilyent még nem követett el, bizony előkerül a ceruza. Ha a programban állapotok vannak ( pl. billentyűzet feldolgozása, távíró dekóder ), szinte kötelező.
A dokumentáció sokszor fontosabb, mint a kódolás.
Másrészt a jó rutinokat, függvényeket összegyűjti magának az ember és később csak beépíti, ha kell. Nevezetes a FORTRAN matematikai rutinkészlet, benne mártixinvertálással és egyéb csemegékkel. De C-ben is ott a qsort(). Egy könyvtárfa rekurzív bejárását érdemes egyszer megírni, az állományok és könyvtárak egyedi feldolgozását pedig függvénybe kitenni. Mint a qsort()-nál az összehasonlító függvényt.
Nekem például kedvencem a Magyar Nevezéktan ( Hungarian Notation ), amit a második magyar űrhajós tenyésztett ki. Például az iAktualis = chElozo értékadásnál rögtön szemet szúr, hogy indexnek karaktert akarok adni.

Messze nem vagyok profi, talán ennek tudható be, hogy viszonylag sok vázlatot szoktam készíteni. Programot és eszközt egyszerre igyekszem fejleszteni, mert az egyikben rejlő lehetőségek nagyban megkönnyíthetik a másik feladat befejezését; egy kapcsolási rajz nálam pl. úgy lesz végleges, hogy addigra a programot majdan alkotó logikai blokkok, illetve a köztük lévő kapcsolat is tiszta (inkább a huzalozással játszadozom, minthogy elkerülhető utasításokkal nyújtsam a programot).
Nagyon gyakran rajzolok folyamatábra-szerű valamit, nem a szabványos jelölésekkel, hanem ahogy jólesik; a kiindulási alap mindig az, hogy működést tekintve mit várok el a végén. Először elkészül egy nagy, globális rajz, ami inkább címszavas lista az egyes funkciókról, jelölve a köztük lévő kapcsolatokat, logikai sorrendet stb. Aztán a "címszavak" újabb papírokon önálló blokkok lesznek, egészen addig, amíg egy C nyelvre hasonlító valami nem lesz a végén, amit már akár assembly, akár magasabb szintű nyelveken is úgymond ujjgyakorlat véglegesíteni.
A fejlesztőkörnyezeteket egészen addig nem is szoktam használni, amíg le nem tisztult minden részlet, de ha valahol mégis becsúszik egy kis bökkenő, ismét előkerülnek a papírok, és ott kezdődik a javítás.
Elég vizuális típus vagyok, sokkal jobban haladok, ha egyszerre akár az egész tervet is láthatom a szétpakolt papírokon, mint egy-egy részletet képernyőn.
Természetesen biztosan vannak, akik egyszerűen leülnek és megírják, ez már , ahogy mondani szokták

Igen, a feladatot érdemes több, többszintű részre felbontani.
De minden résznek ( szubrutinnak, eljárásnak, függvénynek ) dokumentálni kell, milyen adatot vár, és mi a végeredménye. Lehetőleg ne legyen mellékhatása, azaz csak a paraméterein és visszatérési értékén legyen kapcsolata. A függvényenként külön papír jó szokás.

Talán nem is a legjobb szóhasználat volt a profi szó említése korábban, ez azért mégsem sugallhatja azt, hogy az a profi programozó, aki képes egy ültő helyében 3000 kódsort begépelni mindenféle segítség nélkül úgy, hogy a végeredmény azonnali siker legyen. Nem, szó sincs erről, én legalábbis nem azt tartom profinak, aki erre képes, mert ebben semmi szépség és megfontoltság nincs. Ez a fajta módszer inkább rabszolga jellegű munkának tekinthető, és nem egy szépen összerakott, megtervezett és kivitelezett feladatmegoldásnak.

De azért jó tudni arról, hogy élnek még olyanok, akik ezt a módszert nem vetik el.

Kíváncsi lennék még többek véleményére is ezügyben, hogy ők hogyan járnak el a korábban vázolt esetben, egy problémamegoldás során és indulásakor.

Előrebocsátom, hogy nincs mikrokontrolleres tapasztalatom, csak - részben tanulmányaimból eredően is - van némi rálátásom a programozásra.

Programot írni sokféleképpen lehet, ahogy Te is említetted. Az, hogy ezek közül melyik módszert érdemes alkalmazni, szerintem a feladattól (~céltól) függ.

Ha olyan a probléma, hogy relatíve egyszerű és gyorsan meg kell oldani, akkor valószínűleg senki nem fog nekiállni tervezgetni, habár valóban ez lenne helyes. (És nyilván ami nekem bonyolult, az bárkinek, akit Te név szerint említettél, lehet, hogy pofonegyszerű, tehát a bonyolultság nyilván függ a tapasztalattól.)

Bonyolultabb alkotások elkészítéséhez viszont mindenképp kell valamilyen tervezés, akár fejben, akár írásban. Én ilyenkor nagyjából átgondolom, mit is fog jelenteni az, hogy megoldom a problémát, aztán utánanézek, oldott-e már meg valaki részben vagy egészében hasonlót, és ha igen, hogyan. Ez fontos, mert kiderülhetnek olyan buktatók, amikre esetleg nem gondoltam, illetve a megoldás tekintetében felmerülhet, hogyan érdemes vagy hogyan nem érdemes azt leprogramozni/hardveresen megvalósítani. Ezután már lehetnek olyan részek, amit 1:1-ben, vagy kis módosítással fel tudok használni a saját alkotásomban. Innentől kezdve pedig, miután már elég jól körvonalazódott a megoldás módja, el lehet kezdeni a részfeladatokra bontást, és ezt újra meg újra addig folytatni, míg elemi eljárásokat/függvényeket nem kapunk. (Az, hogy mi legyen egy elemi részfeladat, a programozón múlik. Általában lehet látni, tudni, hogy mi legyen az, de előfordul, hogy több jó választás is van.) Ezután kézbe lehet venni a billentyűzetet és le lehet programozni a dolgot. Az iskolában nagyjából ezt tanítják, mert ha a dokumentáció már kész van, mikor az ember a gép elé ül, akkor az a későbbiekben is kéznél lesz majd.

A kezdők és a lusta programozók (mint én is), általában nem szeretnek papírokkal bíbelődni. Fejben kigondolják, kb. mit hogyan kellene csinálni, és elkezdik bepüfölni a kódot a gépbe. Ez amolyan "trial-and-error" (azaz próbáld ki és aztán javítsd) programozás. Ha valaki kezdő, így gyorsan tud sok tapasztalatot szerezni (a fejlesztőrendszerről, a program és a hardver működéséről egyaránt). Ha valaki gyakorlott, akkor viszont már gondolnia kell arra is, hogy olvasható, áttekinthető legyen a munkája, azaz a "doksi" megspórolásával nyert idő egy részét utólag rá kell fordítani a forráskód kommentezésére, áttekinthetővé tételére. (Nyilván ez a bekezdés csak bizonyos bonyolultságig érvényes.)

Én tehát örülök, ha valaki papíron kezd programot írni, mert az úgy patent, de nem vetem meg azt sem, aki rögtön leül a gép elé, és (látszólag) gondolkodás nélkül elkezd "zongorázni" a billentyűzeten. A végtermék minőségén úgyis meglátszik, ki az, aki igényesen dolgozott és ki az, aki hanyagul.

Az meg szerintem teljesen mindegy, hogy a papírra folyamatábra, struktogram vagy mórickarajz készül, mert hobbi projekteknél nem ezen van a hangsúly. Nyilván, ha a jelölésrendszer nem egyértelmű, nem következetes, akkor később nehéz lesz majd megérteni, azaz a terv "szinte" olyan lesz, mintha nem is lenne.

Egyébként a programozás módszertanát, ha jól emlékszem, két félévig tanítják az ELTÉn, csak ezalatt a többségnek annyira herótja lesz tőle, hogy úgyis egyéni rendszer "vezet be" magának otthonra.

Végül egy jótanács: Ha valahol elakadtok mert látszólag megoldhatatlan problémába ütköztetek, ne agyaljatok nagyon sokat a megoldáson. Rengeteg idő elmegy vele és csak egyre feszültebbek lesztek. Inkább tartsatok szünetet, csináljatok olyasmit, ami kikapcsol (pl. nekem az úszás bejött anno), aztán figyeljétek meg, egyik pillanatról a másikra be fog ugrani a jó megoldás!

Sziasztok!

Még kezdő vagyok, szeretném megépíteni a kapcsolások között található MIDI vezérlőt.(V-MIDI Project)
Már majdnem mindent meg is vettem hozzá.Csak az STK 200as LPT portos programozó hiányzik de napokon belül az is megérkezik.
Utána olvastam több helyen hogy hogyan megy ez a letöltés a chip-be, de még mindig nem elég világos a téma.
Az lenne a kérdésem/kérésem, hogy le tudná írni valaki hogy mit kell pontosan tennem? Lépésről-lépésre...,
ha van egy hex file-om (.c ből) megy egy ATMEGA16-om meg egy STK200as programozóm?

Ezt az oldalt néztem pl:
LINK
Ez konkrétan az stk200as esetében írja le a dolgokat.
Le is töltöttem az ítt említett programot de nem találtam azt az Options-t amit az elején említ.
Egyébként nekem jó lenne ez a Bascom egyáltalán? (Mert ugye .c fájlom van vagy belőle a hex kód).

Előre is köszi a segítséget!

Opp a hozzászólásom második fele tárgytalan. Rossz programot töltöttem le... sorry

Üdv mindenkinek!
Küzdök az IO.dll lel.
A kimenetekre tudok adatot küldeni de a bemenetekkel gondok vannak. Van esetleg valakinek egy példája a bemenetek kezelésére pascal vagy delphi nyelvre (utóbbi jobb lenne)? Előre is köszönöm.

Egyetértek!

Van persze, egy-két ellenvetésem:
- Fejben nem tervezünk, hacsak nem a "leülsz és egyben begépeled" típusú a probléma.
- "A kezdők és a lusta programozók (mint én is), általában... " A lustán kívül van másfajta is? Azonnal kiközösítem.
- A TOP-DOWN terminológia, ugyebár, csak egy a lehetséges megközelítések közül, bár kétségkívül igen hatékony. Hardverközeli fejlesztésnél viszont elkerülhetetlen, hogy - ha nem is kiváltólag, de legalább szinkronban - BOTTOM-UP megközelítésben is belevörkölj

Papírt nem szokásom használni (ha nem feltétlenül kötelező), mert elkallódik, mert macerás, mert anyagszükséglete van, blablabla

Az utolsó bekezdésed kapásból 10 pont, amolyan kellemesen hackeres, "Na jó, inkább iszom egy sört" utánérzete van.

Apropó! Ha már itt tartunk, megyek és Na jó, inkább iszom egy sört

Sziasztok. Nem tudtam konkrétan melyik témához írjam, de megpróbálom ide. Szóval: van egy nec 78f9177es epromom. Fogalmam sincs arról hogy ez konkrétan AVR vagy PIC. Azt szeretném megtudni, hogy a datasheetjében le vannak írva a lábkiosztások, és engem a RESET lába érdekelne. Tehát elsősorban azt, hogy hogyan lehet leresetelni? és hogy a reset kitörli-e a memóriáját, vagy csak a rajta lévő programot állítja vissza? Ha pedig letörli, akkor pedig milyen programozóval tudom beleégetni a programot?(mert megvan a hozzá tartozó program.) Előre is köszönöm.

Sziasztok!

A kérdésem érzem nem ide tartozik de nem igazán tudom hova sorolni sem. Azt szeretném megtudni, hogy milyen környezetben, nyelven stb érdemes számítógépen programot írni és futtatni ami kommunikálna USB, RS232, párhuzamos stb portokon a külvilággal (uC, egyszerű áramkör stb). Remélem értitek mi a problémám. Nem akarok belemerülni az informatikába ezért keresek egy olyan konkért megoldást ami alkalmas a leírtakra. Kicsit utánanéztem de nagyon összegabalyodtam a C++,C#, visual basic, visual C++, csharp stb fogalmakkal. Nem is nagyon akarok mint írtam belemerülni ezek rejtelmeibe. Bőven elégséges nekem egy válasz ami kielégíti feltételeim és ti is használtok. Örülnék ha csak az ajánlott anyagnak kéne nekilássak és nem kéne még utánanézzek az egésznek, hogy melyik mire jó. Bármi információt örömmel fogadok. Útbaigazítás is jól jön de egy konkrét válasznak örülnék a legjobban valakitől aki már alkalmazza azt amit én is szeretnék. Előre is köszönöm.

További szép estét mindenkinek.

Szia!

Én pl. linux környezetben és C nyelven programozok. Írtam már programot ami Soros porton komunikál a csatlakoztatott áramkörrel, meg olyat is, ami egy PIC18F4550-el kommunikált USB-n (CDC eszközként olyan mintha soros port lenne) C-t tanulni lehet pl. K&R-ből (nem tudom a pontos címét, de ha rákeresel neten, megtalálod google --> "K&R C") soros port kezelést pedig a linux manual termios oldaláról és az ahhoz kapcsolódó oldalakról (man termios). A bejövő adatok eseményvezérelt feldolgozásához signal kezelés kell, amit a "man 7 signal" oldalról kiindulva érdemes tanulmányozni, ehhez még jól jöhet az "fcntl" és az "open" manual oldala. Ezekből a PC és PIC közötti kommunikáció soros porton (és ugyanúgy USB-n cdc eszközként) megvalósítható. Példaprogramokkal a google és én is szolgálhatok. PIC-en az USB kapcsolathoz ott van a Microchip USB framework-je, és ajánlom még a piccolo projektet is http://esca.atomki.hu/PIC18/.

Üdv. és további szép estét neked is.

Minden attól függ, hogy milyen eszközzel és milyen célból akarsz kommunikálni, illetve mennyi időt szánsz rá. Ha pl. Microchip mikrovezérlők kapcsolódnak USB-vel a számítógéphez, akkor célszerű a mintapéldákból kiindulni. Ezekben többnyire Visual C++ 2005 vagy 2008 Express programokat találsz, bár van köztük C# 2005-ös példa is. A libusb-s példához van Linux-os alkalmazás is (a kissé már elavult Qt3-ra alapozva).

Nos, én NI Labview-t, illetve szintén NI-s LabWindows/CVI-t ajánlom. Ez utóbbi kevésbé ismert, de szerintem legalább olyan jó. Hasonló a LabView-hoz, csak itt GUI-hoz tartozó programot nem dobozokból huzigálod össze, hanem C-ben írod, de eléggé baráti módon. Egy hátránya van, hogy USB-t nem tud, de soros portot igen, így ha CDC-s USB-s eszközöd van, akkor nem gond. Én is csak most ismerkedem vele, de ha kell, akkor tudok küldeni példát, bár maga a feltelepített program is rengeteget tartalmaz.