Milyen nyelven próbálkozol?

Persze, hogy nem latod a forras kodban, mert azok mas elore elkeszitett kodokban vannak (konyvtarakban es un. inklude file-okban).

A konyvtar (library) hasonlo mint a Turbo Pascalban a Unit (TPU). Tehat ott is mikor mondod 'Uses Crt;' akkor a CRT nevu Unitot (CRT.TPU) fogod hasznalni. Anelkul ilyenek, hogy GotoXY() stb nem mukodnek ott sem...

A konyvtarak es a bennuk talalhato fuggvenyek a C forditohoz adott dokumentacioban talalhatok meg. Reference Manual, vagy Users Manual - ilyesmiket kell keresni, most nincs leottem, de biztosa vagyok benne megtalalod

potyo, trudnai: A nagy mennyiség jelen esetben eléggé relatív, nem MB-os a nagyságrend, kb 20-30kB/hét. Persze ahhoz sok, hogy soros porton, pl. 9600 b/s-os sebességnél az 1 perces időrésbe beleférjen mondjuk 1 hónap, ami már 100kB körüli méretet eredményez.
A távolságom kb. 6m tehát mindkettő átviteli mód szóba jöhetne (USB külső vinyóm 12m-en simán viszi a 25MB/s sebességet hibamentesen + egér + billentyű), de ettől függetlenül az USB-től egy kicsit tartok, nem akarom még jobban bonyolítani a dolgot sem PIC sem PC oldalon, sokkal "emberközelibb", megfoghatóbb nekem még mindig a soros (RS-232) protokoll

A soros adatátadás simán működik az Timer és az SPI megszakításai mellett. Ez pont egy olyan tevékenység , aminek az indítása, illetve a következő bájt kivitele várhat.

Érdemes lenne egy kicsit átgondolni a program szervezését. Fölösleges itt egyperces időrésekhez igazodni, meg az interruptra várni, hiszen a megszakítás pont arra való, hogy a futó programnak ne kelljen azzal foglalkoznia, hogy mikor következik be a lekezelendő esemény.

Egyetlen dolog okozhat csak bonyodalmat, ha a kártya írása és olvasása "összeakad" (közösen használt változók, nem újrabelépő kód, stb). Ez is megoldható, hiszen azt a percenként keletkező néhány bájtot nem lehet nagy gond a RAM-ban bufferelni addig, amíg az átvitel befejeződik.

Ami az USB-t illeti: könnyen megoldható egy USB-UART konverterrel is (pl, MCP2200). Az AN956 alkalmazási mintapélda pont erről szól. Bővebben: Link

Azt sejtem, hogy valahol előzőleg definiálva van, de az nem tudom, honnan bogarásszam elő. Mert ugye nem üthetek a hasamra... Az Mplab-ban nekem a tools menüben a mellékelt menu1-es képen látható dolgok vannak. A Configure menü néz úgy ki, mint a menu.jpg-n, de ott ha rábökök a Configuration bits...-re akkor jön a bits.jpg-n látható ablak. Ebből aztán fogalmam sincs, hogyan hivatkozzak a be- vagy kikapcsolásra.

Watt-nak:
Nekem mindegy lenne, hogy c, Pascal, vagy gépi, csak el tudjak indulni. Bármelyiket hajlandó vagyok megtanulni, ha van dokumentációm. Persze magyarul, mert az angolt éppen csak olvasom.

A leírtak alapján akkor viszont én mindenekelőtt angol tanulást ajánlanék.

Úgy már könnyebben fogsz tudni angol irományokat, hibaüzeneteket olvasni és megérteni, definíciókat lefordítani, programok használatát megtanulni. S menni fog a ki- és bekapcsolt állapotok felismerése is, avagy enabled - disabled páros és a többi hasonló is. Valamint könnyedén meg fogod érteni az utasításokat is, mert azok angol szavak rövidítései szoktak lenni.

A Tools menüt viszont valóban elírtam sajnos, elnézést érte, volt egy megérzésem, hogy fejből nem biztos, hogy a megfelelő főmenüt fogom tudni leírni.

potyo, Hp41C: Nekem a 8.000.000 / 4 / 250 / 16 az 500-ra jön ki, még egy 4-es osztás kellene a 125-höz... Na oké, a PIC elvégzi, már beugrott, 4 óraciklus/utasítás, ha jól gondolom, így kijöhet.

Csak halkan jegyzem meg, mielőtt Ti vagy bárki megkövezne, akár csak virtuálisan is :yes: a megszakításokkal és időzítőkkel, illetve azok közvetlen programozásával annyi a gondom, hogy a programot Basic-ben írom és nem bízok annyira az egyedi megszakítás és időzítés hibátlan leprogramozhatóságában... elég sok rémhírt olvastam ezekkel kapcsolatban. Proton IDE illetve mikroBasic-ben készül a progi, párhuzamosan mindkettőben, mert kiváncsi vagyok egy összehasonlítás erejéig, a neten talált kódméret adatok valódiságára. A Proton állítólag messze a legkisebb méretű kódot generálja, én úgy vettem észre, tartja a kb 2/3 arányt... Igaz a mikroBasic viszont jóval barátibb, pl. a Help, a konfig beállítás, stb. és úgy általában az egész szimpibb. Mondjuk ha beleférek a végére a PIC-be akkor tulképp mindegy. Mindkettőt folyamatosan ellenőrzöm, igaz egyenlőre csak az ISIS-ben. Az onewire + soros átvitel + SD kezelés + LCD legalábbis kisebb tesztadat mennyiséggel működni látszik, de félek, ha hozzányúlnék Basic-en keresztül akár a megszakításhoz, akár az időzítőkhöz, lehet hanyatt dobná magát a dolog, hiszen nem tudom melyiket és hol használja a programnyelv maga is. Igazából az 1 perces intervallum a kritikus pont számomra illetve az előzőek alapján az idő is, úgy tűnik Lehet, kellene egy külső 60mp időalap mégis?

Bocsánat, amiért folyamatosan változik az elképzelésem, de ez Nektek is köszönhető, illetve ahogyan tisztul, vagy inkább kuszálódik össze a kép az egészről :yes:

Félre értettél. Nincs gondom az utasítások megértésével. A szintaxis viszont teljesen más dolog. Ha például a Brown Out Reset bitet vesszük, a táblázatban az van, hogy BOREN erről hogyan döntöm el, hogy mit írjak ha bekapcsolom, és mit ha ki? Tudjuk jól, hogy a programnyelvekben csak azokat a szintaxisokat használhatjuk, amiket deklaráltak bennük, nem azokat, amiket én gondolok, hogy jó lesz. Próbáltam Deguss cikke alapján megírni a programot. 877-re akartam átírni, és ezt a táblázatot használtam. (A CCS fordítónak nincs menüje) Beírtam a BOREN-t és a fordító nemlétezőnek jelezte.

Egyetlen dolog okozhat csak bonyodalmat, ha a kártya írása és olvasása "összeakad" (közösen használt változók, nem újrabelépő kód, stb). Ez is megoldható, hiszen azt a percenként keletkező néhány bájtot nem lehet nagy gond a RAM-ban bufferelni addig, amíg az átvitel befejeződik

Ez jó ötlet, mehet addig tényleg a RAM-ba

De az USB-től akkor is félek :yes:

Illetve küldésnél a hardver shiftregiszter gondolom nem áll le, ha esetleg közben a PIC program futás mondjuk kap egy megszakítást, jól gondolom? Elvégre azért hardveres Megkapja az adatokat, paramétereket, aztán szépen teszi a dolgát mindenkitől függetlenül, majd dolga végeztével vár, akár csak a PC-n a program.

Milyen USB-től? Az általam javasolt megoldásnál nem is tud róla a PIC program, hogy USB-n kapcsolódik a géphez. Azt hiszi, hogy UART kapcsolaton kommunikál...

Fölösleges itt egyperces időrésekhez igazodni, meg az interruptra várni, hiszen a megszakítás pont arra való, hogy a futó programnak ne kelljen azzal foglalkoznia, hogy mikor következik be a lekezelendő esemény Én is így gondolom/tudom, és az előbb a soros átvitelt watt segítségével megoldottnak is tekinthetjük, de áll az az elmélet az SPI-re is valamilyen szinten? Az órajelet is PIC adja, tehát ha a megszakítás a hardveres SPI interészt esetlegesen megakaszt(hat)ja akkor az órajel is megáll az én értelmezésem szerint, majd újra indul, tehát ebbő az SD kártya nem vehet észre semmit. Vagy roszul gondolom?
Egy hardveres egységnek pont az a lényege, persze egyéb dolgok mellett, hogy nem a program vezérli, mármint lépésről lépésre, hanem kap egy feladatot amit aztán önállóan végrehajt.

Oké és a másik oldalon? Ott sem vagyok ám igazán képben USB terén

Szia!

Minden programban valahogy meg kell adni a cél kontroller típusát:
pl:
C18:

, ami az MPLAB -ban beállított kontrollerhez tartozó állományt választja ki

assembly:

stb.
Ezekben az állományokban illetve az ezekbe is behívott állományokban megtalálhatók, olvashatók az előre definiált szimbólumok. A könyvtárat, amiből a fordító az említett állományokat veszi, a project és a fordító beállításánál lehet/kell megadni.
pl: az assembly programból hivatkozott p16F886.inc állomány (default telepítési könyvtárak esetén) a c:\Program Files\Microchip\MPASM Suite\p16F886.inc néven található és benne ott van a pl. a BOR feszültségek megadására szolgáló szimbólumok (az állomány végén).

Szia!
Való igaz, ha az SPI-t az MSSI modullal kezeled, akkor egy művelet (1 byte adása vagy vétele) után átmenetileg megáll az órajel, de az SPI szabvány szerint ez megtehető. A következő adat átvitelére szóló MSSI művelet indítása után az órajel automatikusan újraindul. A SD kártya ebből semmi sem vesz észre...
Nem is emiatt említették az összeakadást:
A következő eset már kényesebb. A mérési eredmény tárolását már elkezdted, de még nem fejezted be. Ebben az időben egy kiolvasási parancs is érkezik a soros felületről. Itt valahogy sorrendezni kell a műveleteket...

Értem, igen, természetesen írásnál nem szabad engedélyt adni a kiolvasásra, ekkor várakozni kell amíg az befejeződik, illetve a soros kommunikáció alatt, ha új letárolandó adat "érkezik", akkor vagy felfüggesztésre kerülhet az átvitel, vagy, hogy mondjuk egy blokk átmehessen, le lehet tárolni a RAM-ba az új adatot átmenetileg, majd amikor szabad az SD kártya, megtörténhet az írás.

Ha #Fuses, akkor CCS-ről van szó. Annak van egy varázslója, amivel a konfigurálás lépésről lépésre beállítható, s végül mindet egy header állományba írja. (természetesen a CCS C-nek dokumentációja és kitűnő helpje is van, melynek szapora olvasgatását semmivelsem lehet pótolni)

Magyar nyelvű útmutatót a PIC programozáshoz itt meg itt találsz.

Természetesen, bájt az SPI is hardveresen támogatott. Az SPI egyébként szinkron soros átvitel, tehát ha elakad a master órajele, akkor a slave is csendben vár a sorára...

A másik oldalon is soros portnak látszik, tehát az alkalmazásnak ott sem kell tudnia róla...

Köszönöm, tényleg nagyon sok információ található ezekben a fájlokban. Talán a legértékesebb volt számomra ez az információ. Közben átnéztem a gépemen található .dev fájlokat is, és hasonló dolgokat találtam benne. Ezek szerint ezeket is felhasználhatom?

Nem tudom kipróbálni, mert ha lekötöm, akkor megszűnik a zavarforrás is, azaz a gyujtás. De azt kipróbáltam, hogy autón kívül szimuláltam a bemenő jeleket, és órákig hiba nélkül működött. Az autóban pedig, -amint megnő a sűrítési végnyomás, tehát nagyobb feszültség kell a gyergya szikraközének átütéséhez- pl. kis gázfröccs, vagy terhelt motor, azonnal jelentkezik a kóbor megszakítás.
Tehát az biztos, hogy a gyujtás impulzusai zavarnak, csak az nem tiszta, hogy ez hol és hogy juthat át a szűrőkön, a táp felől, vagy a jeladók felől, vagy máshogyan?

Hp41C:
Az RB1 megszakítás folyamatosan engedélyezve van, úgyhogy ISR-ben csak ...IF bitet ellenőrzöm, majd törlöm.

Megpróbálom a bemenetek leválasztását optokapuval, de ha nem jön be, akkor a táp marad. Erősítsetek meg, hogy az opto ledje nem fog felvillanni zavaroktól..
Milyen opto legyen? 6N137 digitális átvitelre? Vagy az túl gyors, biztosabb lenne valami lassabb?

Üdv. Keresgettem de nem találtam a kérdésemre választ. Egy pic hány mA képes leadni?

Ismét egy jó példa a segítségnyújtásra. Nagy örömömre szolgál, hogy ennyi jó szakember van ezen a honlapon. Köszi, már átlapoztam a linkeken talált anyagot. Remek olvasnivaló lesz. Az asm egyébként nem olyan idegen számomra. Átnéztem a helpet is. Persze ez is olyan volt, mint amikor új kütyüt veszünk, és először félredobjuk a használati útmutatót. Aztán meg lázasan keresni kezdjük...

Tudnál egy képet mutatni az elkészült áramkörről? Nekem is vannak autóban cuccaim, igaz én nem megszakítással dolgozok, hanem pollinggal, de soros 1k és 100nF a láb-föld közé eddig még elegendőnek bizonyult, pedig van ahol három méternyi dróton mennek a jelek a pic-hez.

Adatlap->Electrical characteristics.

Az SPI egyébként szinkron soros átvitel, tehát ha elakad a master órajele, akkor a slave is csendben vár a sorára...

Jól hangzik így próbáltam én is értelmezni.

A másik oldalon is soros portnak látszik, tehát az alkalmazásnak ott sem kell tudnia róla...

Akkor ha jól értelmezem, gyakorlatilag az átviteli út USB, de ennek nem látom értelmét azon az érpáron az RS232 is elmegy és így két konverziót ill. esetleges hibalehetőséget kihagyhatok, nem?

Ez az eredeti kapcsolás, de legutóbb úgy próbáltam ahogy fent leírtam, minden sallag nélkül. 2 kondi, két ellenállás.
A gratcz híd két dióda szerepét tölti be GND és 5V felé, hogy ne a PIC diódáit terheljük. A kép közepén 20 pólusú tüskesor felső sor 2. pin -ami ki van jelölve- megy a PIC RB1 lábára (egy másik panelen).
Fennt a nagy csatinál (21 pin-re megy a hall jeladó) 100n GND-re, Lejjebb 1k az 5V-ra a rajzon "gumikábellel" mert utólag lett beforrasztva. Aztán bottom oldalon az 1k soros, és a többi. Alul még egy 47k SIL 5V felé és 100n kondi a GND felé.
A másik panelen a PIC egy másik 7805-ről kapja a tápot.

Akkor érdemes ez az USB-n soros átvitel, ha mondjuk van egy kész cuccod, ami soros portra van kitalálva, viszont a gépeden nincs soros port. Ekkor beteszel egy ilyen átalakítót, és akkor a PC oldali program is és a kontroller is soros portként fogja látni, elméletileg változtatás nélkül lehet tovább használni. Ha viszont most fejlesztesz, akkor én ilyen megoldásban nem gondolkodnék. Ha van a gépeden soros port, akkor legyen normál soros, ha nincs, akkor meg inkább szánj rá egy kis plusz időt és csináld meg USB-n. Mellesleg az FT232R nem épp olcsó chip, bár otthoni barkácsolásnál ez talán nem annyira szempont, mint sorozatgyártásnál.

Sajnos az is szempont, hogy bármilyen egyszerű, és ezeknek a céloknak tökéletesen megfelelő lenne az RS232, egyre kevesebb az olyan PC, amin van soros port. Ha meg már úgyis faragni kell valamit valamelyik oldalon, akkor talán célszerűbb eleve a saját kütyüre tenni olyan felületet, ami általánosan elérhető. Ez manapság az USB szokott lenni.

Személy szerint az FT232-vel én ki vagyok békülve, bár tényleg lehetne olcsóbb. Ha valami olcsóbb, PIC-es megoldással biztonságosan ki lehet váltani (pl.18F14K50 vagy az abból származó, gyári kialakítású MCP2200), akkor érdemes elgondolkodni azon is.

Még egy szempont jut egyébként eszembe, mégpedig az, hogy ha én egy ilyen eszközt építenék, akkor a mérési adatgyűjtőt (PC) galvanikusan megpróbálnám elválasztani a teljesítményvezérlő elektronikától. Erre is kiválóan alkalmas az USB/soros átalakító, mivel az mehet a PC oldali USB-s tápfeszültségről, a teljesítményvezérlővel pedig optocsatolóval elválasztott, TTL szintű RS232-n kommunikálhat. A teljesítményvezérlőnek nyilván saját tápegysége van.

Az autó nem működik a saját vezérlőjéről? Lehet, hogy a tápon jön be zavar.

Az RB1 megszakításal az lehet a gond, hogy mindkét irányba megszakít, ha jól emlékszem. Ha van rá lehetőséged, próbáld ki valamelyik CCP bemenetet. Azt lehet konfigolni, hogy le, vagy felfutó élre legyen érzékeny. Persze, lehet, hogy ez nem számít, ha valóban van egy nagy zavarjel. A fura az, hogy nem látod a szkópon. Ha meg nem látod, ki kéne szűrje az RC tag!