Talán egyszer rájösz miről beszéltem. Remélem nem túl későn..
(eddig nem úgy néz ki mintha megértetted volna amit mondok)

Tartalmilag arra céloztál, hogy ha egy RS232 kimenetéről akarom meghajtani a bemenetét, akkor amellett nem túl sok áram / feszültség fog jutni még egy pic-nek is. Ami igaz is. Viszont nem is fog neki túl sok kelleni.

Egy low freqis pic12f a célpont. Az adatlapja szerint fél mA. Egy buta állapotgép + uart kimeneti periféria, többi kikapocs (nem mintha túl sok minden lenne még benne). Elé egy fesz regulátor, adatlapon másik fél mA. A kimeneten a level shifter tranzisztor hálózat egy harmadik fél mA. Nem rakok oda másik max232-t áramot zabálni, csak egy sima tranzisztor hálózatot uA-es működéssel. Legrosszabb esetben összesen 3 mA a teljes cumóm. A pic azon a frekin az adatlapja szerint 3V-ról már beton stabilan működik. Ha a max232 a kimenetén leadja az 5 V-ot, a fesz stabnak már bőven elég. Ha mellette a 7 mA-t is meglesz (márpedig az alatt az adatlapja szerint nem fog zárni az áramkorlát), már nyert ügyem van. Megeszik a saját ketyerém 3 mA-t, a max232 bemenete azon a feszültség szinten durván 2 mA-t, plussz a kábel parazita értékeit kell még ellensúlyoznom, amihez lesznek feltöltött kondik, és a sebességet sem viszem túl magasra.

A karikázott számok test condition + legrosszabb eset adatok, amik nem túl gyakoriak, de még abban az esetben sem tűnik nekem egészen esélytelennek az elképzelésem. Vagy legalábbis a saját tapasztalataim alapján valóban nem tudom megítélni, mit is kellene észrevennem. Ha mégis bebukom, a hobby időm ment el rá, 2khuf ára anyag, meg a beképzeltségem. Egyikért sem túl nagy kár

Egy próbát lehet megér.Amit úgy láttam nem vettél figyelembe, tápot csak a soros adat magas szintjén kap.Ebből kifolyólag jobban jársz nagyobb adatátiteli sebességgel ,és sok sok pihenővel (ekkor ha jól tudom a jelszint magas) Vagy lehető legtöbb magas állapotot tartalmazó byte küldésével.

Gyenge meghajtásnál egy hosszabb kábel nagyobb sebességnél már gond lehet. Ilyen rigolyák - meg ezernyi másik - persze benne vannak a pakliban. De hát semmi sem tökéletes. Viszont nem is az örökkévalóságnak készülne.

Alapesetben tápot a 3-4-7 lábról tudsz szerezni. Ezek mindegyike alapesetben -6V körüli értéken van (terheletlenül), azaz még el se indul a PIC, mert nincs honnan tápot beszereznie. Persze megoldás lehet valami PC progi/drv ami átállítja a 4/7 lábakat +6V -ra. De szerintem valami gombelem/aksi/nagyobb kondi-val jól járnál, ami ha előtte rá volt dugva a portra feltöltődik és percekig biztosítja a tápot akkor is ha a lábak a "-" tartományban vannak.

Szóval nem reménytelen, de nagyon kicentizett..

Köszönöm a tippeket, majd centizek. Az mplabx-el van inkább problémám, amiben jól jönne valami olvasható tutorial, vagy pár tipp is.

MC libből leválogattam pár file-t, amikből utólag szeretnék projectet gyúrni. Main.c, további .c-k, és halom .h (meg amik még forrásból includeolva vannak). Viszont nem találok olyan opciót, hogy már létező file hozzáadása projecthez. Ha létező file nevet beírok kézileg, akkor pedig jön a sipák, hogy already exists, és szürke next gomb.

Most komolyan muszáj azt játszanom, hogy a normál helyükről kimozgatom a fileokat, létrehozom a projecttel őket, és aztán file tartalom szintjén egyesével copy/paste?

16F877 PORTA 0-1-2-3 kimenetet nem tudom rávenni,ledek villogtatására.
Az összes többi korrektül müxik (B-C-D).
Valahogyan tiltanom kellene az analóg I/O-kat?

Persze, az analóg lábak mindig analóg módban indulnak !
szerk.: az adott PORT leírása után mindig megtalálható a Microchipnél az adott portnál érintett regiszterek táblázata --> nézd meg !

Sziasztok,

feltettem egy kérdést a PIC PWM témakörében a saját topicjában, de az nem egy forgalmas hely ezért gondoltam megkérdezlek titetek itt is.

Itt a probléma leírása!

A lényeg: egy szervot szeretnék majd mozgatni 12F683-mal, potméterekről veszem a kezdeti-vég-sebesség adatokat.
Ami gondot okoz, hogy a PWM modul "látszólag" nem indul el.

Minden segítségért hálám nektek.

Jellemzően az összes pic (8 bitestől 32-esig) analóg lábai reset után analóg inputok. 16f877 adatlapot itt: http://ww1.microchip.com/downloads/en/DeviceDoc/30292D.pdf találsz. Page 112: a konfig tábla szerint az összes jelet visszakapcsolja digitálisra, vrefeket pedig tápfeszre.

Oké hogy 32 bites de elméleti síkon lehetne-e rá operációs rendszert dobni?

Köszönöm,idő közben megtaláltam az adatlapját és kihámoztam belőle a szükséges beállításokat.
Most már az A0-1-2-3 is műxik digitálisan.

Ezt nem teljesen értem. Kicsike magyarázatra szorul.

Ha arra gondolsz, amiket egyesek "pic-linux"-nak csúfolnak, és hogy egy olyasmit rádobni egy 16f pic-re, na azt alaposan felejtsd el. Meg azt is, hogy annak a "linux"-nak - amit pic32-re rádobnak - bármi köze lenne az asztali gépes linuxokhoz, vagy akár csak operációs rendszerekhez úgy egyáltalán. Ugyanis egy egészen szégyentelen marketing-vicc az egész.

Lehetni lehet, de az köszönő viszonyban sincs a PC-n megszokott operációs rendszerekkel. A beágyazott rendszerekben az "operációs rendszer"-nek nem feladat az, hogy alkalmazást töltsön be, és futtasson. Inkább az a cél, hogy egy hardver absztrakciós felületet biztosítson, a feladatokat (taskok) futtassa, s kommunikációs illetve szinkronizációs lehetőségeket biztosítson számukra. Beleérthető az "operációs rendszer" fogalmába az ún. middleware programcsomagok (USB, TCP/IP, fájlrendszer kezelése, stb.).

PIC és minden más mikrovezérlőre készülnek RTOS rendszerek. Van köztük ingyenes, és nyílt forrású is. A Rowebots PIC24/dsPIC-hez való DSPnano és a PIC32-höz való Unison RTOS rendszere annyiban hasonlít a Linuxra, hogy POSIX-szerű szálakat lehet benne létrehozni, de az az igazság, hogy túl sokat nem értettem meg a működéséből az alatt a rövid idő alatt, amíg nézegettem. Nem egyszerű ezen rendszerek használatba vétele.

Még ha egyszerűbbé is válna, valószínűleg feleslegesen. Több szálazni, meg taszkonként bontani a feladatot egy olyan design része, ami egyáltalán képes teljesítményt is produkálni, ahhoz pedig főleg memória kell. Nagyon sok memória. Egy pic-nek versenybe szállnia az arm procik ellen - 128K az 1G ellen - kissé komikus.

Tehát WindowsRT, Android4, Symbian, Maemo vagy hasonló soha nem lesz PIC vagy AVR-en?
A 32bit az nem ad lehetőséget több GB ram és több GB programmemória címzésre?

Ez nem egészen úgy van, ahogy gondolod, mert a feladat taszkokra bontása nem igényel olyan sok memóriát. Egy fejlesztő meg el tudja dönteni, hogy mikor érdemes használnia, mikor nem. Kis méretnél is lehet olyan összetett a feladat, ahol az absztrakció segíti az átláthatóságot és a karbantarthatóságot. Illetve az is lehet szempont, hogy egy már kipróbált, letesztelt, hozzáértők által tervezett rendszerre bízzuk a feladatok ütemezését és szinkronizálását, nem pedig amatőr módon, hozzáértés nélkül állunk neki összegányolni valamit, ami utána vagy működik, vagy nem.
Épp ellenkezőleg: az ARM mikrovezérlők szálnak szembe a PIC és a többi 8 bites mikrovezérlőkkel. A gigahertzek és gigabájtok után most divat lett 48 MHz-es, 32-128 kbájtos programmemóriájú Cortex-M0-át gyártani, amelynek áramfogyasztását és árát a 8-bites mikrovezérlők szintjére próbálják leszorítani.

Ha öreganyámra gumikerekeket szerelünk, attól még nem lesz autóbusz.

Kicsit elkanyarodnék a témától egy kezdő kérdéssel:

Pk3 command line tools-t nézegetem, és nem teljesen világos, hogy ez és ez a paraméter mégis milyen funkciót takar? Programozásra ugyanis van -P -F, minek az a "reprogram"? A batch-et illetően pedig gondolni sem tudok semmire. Google pajtás nem tudta megválaszolni a kérdést.

Ezt is láttad már?

Enné meg a fene, találtam egy kb ugyan olyan szöveg file-t, de abban nem volt benne az important notes rész Így már tiszta, köszönöm.

Itt poénkodás megy csak válaszolás helyett..
hiányzik a válasz: miért? öreganyád.

Szia!
Más céllal gyártják az ARM, és PIC/AVR MCU-kat. Egy ARM MCU hardveresen tud kezelni olyan időkritikus dolgokat, amiket a PIC/AVR nem, mert eleve úgy lett tervezve.
Tehát hiába tud ugyanannyi műveletet végrehajtani, meg ugyanakkora memória.. stb, ha nincs meg a megfelelő belső perifériája.

A pic/avr hiába 32 bites, és hiába _tudna_ megcímezni annyi memóriát, ahhoz kell is annyi memória, amit címezhet. És nem tudja kezelni elektronikailag. Egy halom dolgot nem tud elektronikailag. A pic nem számítógép, hanem elektronika. A szoftver nem önálló teljesítmény, hanem elektronikai teljesítmény célirányos felhasználásának eszköze. Amit az elektronika nem tud, azt egy absztrakt valami (a szoftver) sem fogja tudni kihozni belőle. Egyszerűen csak erőteljes tévedés a picek alaptermészetét illetően csak annyit látni belőlük, hogy 32 bitesek, tehát meg tudnak címezni 4 gigát. Az csak elmélet.

Persze lehet olyannal vakítani a népet, hogy hozzá raksz egy spi microSDHC-t, meg soros spi ramokat, és "nesztek memória", épp csak elérési ideje is van annak a memóriának, ami köszönő viszonyban sem lesz az elvárásokkal. Bármit is lehet emulálni vele, az mind csak kirakat. Hozzá lehet rakni SD-t, LCD-t, lehet rajta valamilyen webszervernek csúfolt alkalmazást futtatni, de ezek mind csak illúziók. Marketing. Valójában sem igazi real time reflexeik nincsenek (mert az az fpga-nál kezdődik), sem logisztikai teljesítményük (mert az meg asztali számítógép fürtnél kezdődik). Egy köztes dolog, ami pár helyen költséghatékonyan megállja a helyét - a saját korlátai között. Valójában egy buta bináris állapotgép kategóriája, ami sem nem igazán intelligens, sem nem igazán gyors, cserébe olcsó. Nem kevesebb, de nem is több. Tessék beletörődni.

Zöld?

Minden mikrovezérlőnek és processzornak megvan a maga tulajdonsága, erőforrása, így az adott feladat határozza meg, hogy mit kell hozzá felhasználni. Egy LED villogtatáshoz természetes, hogy nem egy ARM procit használunk és fordítva, egy bonyolult rendszerben (ahol op. rendszer is szükséges) nem egy 16F628-ast használunk

Én csak mint érdeklődő figyelem a témát, a beszélgetés így kezdődött:


innen jutott eszembe hogy apró eszközökre miért nem lehet elméletileg programot utólag feltölteni úgy mint egy okostelefonra vagy pda-ra? (esetleg Ti vagy HP zsebszámológép) Vajon a Harvard arhitektúra ennek az oka, vagy valami más.

Lehetni lehet, hiszen a bootloaderek is ezt csinálják. PIC32 Ethernet Starter Kiten futtattam már a StickOS BASIC értelmezőjét, amelyik a RAM-ba bepötyögött és kipróbált programot engedte elmenteni a flash memóriába. De a mikrovezérlők nem erre lettek kitalálva, nem intaraktív felhasználsra tervezték (kevés a RAM. a flash memória pedig korlátozott számú újraírást tesz lehetővé). Az általad kívánt funkciókra ott vannak a mikroprocesszorok, amelyek jellemzően külső RAM-ot (és flash-t) használnak.

Azt hittem, kitalálod: "motor" is kellene hozzá.

Szégyellem magam erőteljesen, de nem jövök rá, hol a hiba. Íme egy program részlet:



A változó definíciója:


A led2 kigyullad, a led3 nem. A led makrok tesztelve vannak, ott nincs hiba, muxik mind a 3, mint a kicsike angyalka. Abban a logikai muvelet sorban nem gondoltam csinalni semmi mast, csak biztositani, hogy a 64 bites valtozo felso 32 bitje tuti nulla legyen. Fogalmam sincs, miert nyirja ki a teljes valtozomat. C32-vel fordul a kod.

Mit rontottam el?

Sziasztok, mostanság állnék neki PIC-ekkel foglalkozni és a következő kérdésem lenne. C fordítót mit ajánlotok? 12f illetve 18f et is szeretnék majd használni. Van e valami olyan program amivel virtuálisan tudnám tesztelni a megírt programomat? Ha sikerül működő dolgot alkotnom, akkor van aki kiírja nekem a hex file-t, illetve később majd vennék vagy építenék saját égetőt is. Előre is köszönök minden segítséget.