Két esetben tökéletesen megfelel a tápfeszültség is A/D referenciának:
- potenciométer kezelőeszköz esetén
- ha a mérőszenzor ellenállása változik, és az egy sima feszültségosztóba van bekötve (hőfokfüggő ellenállás, fotoellenállás)
Ha megváltozik a tápfeszültség, akkor a referenciafeszültség és az osztott feszültség is azzal arányosan fog megváltozni, ezért az A/D által mért érték nem függ a tápfeszültségtől (csak az osztási aránytól).

Sziasztok, kérdezném hogy az MPLAB ból étezik "portable" verzió? Sajnos a céges terminálra nem tudom felrakni mert hála az IT nak rendszergazdai jelszó kéne a telepítéshez, márpedig fusizni azt néha kell...

Esetleg az MPLAB Xpress felhőalapú online IDE-vel is próbálkozhatsz.

Kaphatóak a PIC32MM-ek. Lehet, hogy érdekes alternatíva lesz a kislábszámú 16, 18F-eknek? Nekem a CLC is érdekesnek tűnik a CRC-vel együtt, de alapvetően a topológia is érdekes.

Köszönöm, megpróbálom!

SQI Flash-et próbálok használni. Gondoltam a példák alapján valamit csak könnyebben sikerül, csomó munkát spórolok. Van példa az adatlapokban is és a harmony-ban is. Nos egyik jobban félrevezető, mint a másik. Az adatlapi példák kiragadják a program környezetéből a bemutatott részt, nem lehet követni, nincs végigvezetve, alig van magyarázat az is értelmetlen. A harmony pedig egy katyvasz, de ami még nagyobb baj, hibás, nem működik. Szóval ha azt szeretném elérni, hogy úgy kell példát írnom, hogy azt csak azután lehessen megérteni, hogy mélyen beleásta magát valaki mind a PIC-oldali, mind a Flash oldali adatlapba, akkor pont úgy csinálnám, mint a kedves microchippék. Több nap után már dereng valami, most állt össze, délután fogom élesben kipróbálni.
Van aki már használ SQI eszközöket?

Szia!
Sajna a Microchip inkább a saját formátumát kezelő függvényekkel használja ezt a flash-t.De ha nem magad akarod megírni hozzá a progit,hanem kész-szerű kell,akkor a régebbi tcp/ip demókban benne van a kezelése,inicializálása ,csak 1 picit kell módisítani(a mostaniakat még nem néztem).
Nem nehéz kezelni,csak az a fránya írás előtti sector-törlés maradhatott volna ki belőle .Vagyis kétszer nem írhatsz ugyanarra a területre,csak ha előtte törlöd .Az írása,olvasása eléggé egyszerű,csak ez az 1 van amire figyelni kell,mert különben nem írja be. A biztonság kedvéért én úgy írtam meg,hogy egyből vissza is ellenőrzöm,így nem lehet gond,bár így 1 picit lassabb.
Amúgy az adatlapokban elég jól le van írva az összes funkció.
De ha a micros leírás nem jó,akkor nézd meg a Winbond-osat '99%-ban' ugyanazt tudják,csak más az azonosítójuk,stb.
A harmonyt én a helyedben nem erőltetném,eléggé rosszak vele az emberek tapasztalatai,és az enyém is.A legjobban úgy is akkor érted meg,ha te írod az egészet.

Szia! Köszi a választ! Tudnál abban segíteni, mitől lehet az, hogy beérkezik a flashtől a várt 4 bájt, de nem áll be a RXTHRIF. Az RXTHRISE beállítva, az RXINTTHR 4-re állítva és az SQI1THR =1. Minden működik, csak nem állítódik be a threshold interruptot jelző bit. Nem használok megszakítást, most csak a bitet vizsgálnám...

Megvan a megoldás, elég érdekes, de nem akarok senkit terhelni, ha valakit érdekel jelezze, szívesen leírom...

Ha most nem is érint senkit, később azért jól jöhet a megoldás.

Tényleg nem kéretni akarom magam, de érdekelne, hogy más is használ-e SQI Flasht, vagy szeretne-e használni. Ezért várok egy kicsit...

Szia!
Magát a flash-eket napi szinten használom,bár én csak spi-vel,mert kevés a lábacska,és a hely .
Régen,amikor sqi-ben használtam,az szoftveres volt,és nem hardveres,abban a kontrollerben még nem volt.

Én az MZ-s TFT-s panelomon úgy vezettem ki a protokat, hogyha később rávisz az erő az SQI-s flash-t (leginkább SD kártyához) használjak akkor ne csak SPI-vel tudjam kezelni, engem érdekelne.

Jobb a kedvem, hogy ketten is foglakoztatok vele, vagy tervben van, mert már azt hittem valami gond van ezekkel, vagy olyan újak, hogy senki nem használja őket, a neten is alig találni hasznos témát erről. Kicsit azt gondolom, hogy a harmony megtette a negatív hatását az újabb perifériák kárára. Igaz a harmony is kezd tisztulni, de ilyen katyvaszt régen láttam, olvashatatlan, ha gond van valamivel, de sok szempontból jók a megoldások. Itt van pl. egy regiszter beállítása paraméterezhetően úgy, hogy nem függvényt használnak, az-az beszédesen lehet kódot írni, még sem foglal helyet és gyors is.

E mögött ez van:

Aztán ez:

Majd a regiszter, amire mutat:

Ugye agyrém!
Máshogyan ez a sor így néz ki (az érték nem egyezik, csak példa):

Ha nem gyártaná le a harmony a headereket, akkor soha nem írnám meg így, viszont most hogy kezdem érteni a logikáját, kihasználom az előnyeit.

Ellenben a harmony SQI példa több ponton hibás és tele van felesleges sorokkal is, amiket érdemes kigyomlálni. Már az inicializálásnál eltérnek a flash adatlapjától, bár abban az adatlapban sem találni olyan kódot, ami segítene sokat! Többek között nem állítja be a kódban a REFO2CON regisztert, így nincs órajele a modulnak. Szép...

A kérdésemre, amit feltettem a RXTHRIF-el kapcsolatban érdekes megoldást találtam. Nem elég beállítani a RXTHRISE-t, be kell állítani a SQI1INTENbits.RXTHRIE megszakítás engedélyező bitet is. Egyrészt ezt a harmony nem állítja be, még is vizsgálja az RXTHRIF-t, másrészt a logika szerint nem akarok valós megszakítást, nem indokolt a beállítása. Viszont van még egy megszakítást engedélyző bit a SQI1IE, ami az egész SQI megszakítását engedélyezi, ezt nem kell beállítani és akkor a RXTHRIF működik, vizsgálható while-ban és közben nem fut a szál megszakításra.

Kicsit elkeserítő, hogy ilyen támogatást ad a microchip...

SD kártyához nem jó az SQI sajna, én is belefutottam, de nem...

Ezt kifejtenéd, az SD-vel van a baj vagy a PIC-el?
Ha jól tudom az SD kártya megy 1 bites SDO SDI SCK CS (én is így használom)
Meg egy ilyen parralell 4 bites interfacen is és az SQI pont az nem?

Nem olvastam még utána komolyan a dolognak úgyhogy ez nálam még csak elvi elgondolás volt mert a jelenlegi projekthez elég az SPI.

SPI megy, természetesen. Az SD protokol, ami 4 bites nem egyezik meg az SQI protokollal. Van olyan mikrovezérlő(nem PIC), amiben benne van a hardveres támogatás. Jó lenne, ha a microchip is felébrende végre és behozná a lemaradásokat (DDR RAM, SD protokol).

A Microchip sqi-je jelenleg egyetlen dologra jó ténylegesen, és az a saját sqi flash termékeik felhasználása, amihez külső kód végrehajtást is fejlesztgetnek éppen - az lenne a koncepciójuk. Lévén az átlagos alkalmazásoknak a magok saját 2 megabyte flashmemóriája is végtelennek tűnő kapacitás, amihez inkább ramot fejlesztenének, mint még több flasht, mert az most a fejlődés tényleges korlátja, az sqi kb nem jó semmire. Ha külső nagy tömbös flasht akarsz kezelni, arra is az sd kártya a már meghonosított szokvány. Az sd protocol és a microchip sqi-je nem kompatibilisek, amibe simán csak törődj bele. Ha nagyobb throughput kell, a 32mz-ken 6 spi port is lenni tud, párhuzamosítsd a kommunikációt. Elbírnak az mz-k annyi dma csatorna kezelést, hogy 6 sd kártyát is ráakassz. És akkor a sebesség sem lesz egészen kukás.

Szia! Volt már gondod az órajellel? Engem ver a sors, mert ilyet még nem láttam. Csak akkor működik helyesen a flash, ha ráakasztom a digitanalizátorom egyik kimenetét az órajelre. Egy ideig eltartott mire rájöttem, mi a baj, mert a műszer rajta volt végig a fejlesztés alatt és mikor levettem összekeverte a vétel a nibbléket. Most kondikkal próbálkozok...

Az SD sebessége lassú, de ahogy írod, lehet, hogy működne. Az SQI flash 8MByte, egyet-kettőt használva egy TFT-nek a háttér és egyéb képei tárolhatóak, DMA-val gyorsan mozgathatóak, ez a terv. Abban is igazad van, hogy az SQI a microchip saját háziállata, de nem rossz elképzelés 104MHz-en ilyesmire használni. Igaz, a 100MHz, csak álom, jó ha 50 kijön egy MZ-vel...

Mekkora szinkron sebesség kellene összesen írni / olvasni?

Az írás nem kritikus, mert előre letárolt képekről, karakter táblákról van szó. Olvasás a lehető leggyorsabb a megjelenítés érdekében.

Most ott tartok, hogy 25MHz-el működik valahogy, ami ~12MByte/sec, ha számolom a beolvasást, majd a kivitelt, akkor 0,2sec körül van egy 800x480 kép átvitele, ami tűrhető. De még nem tartok ott, hogy ezt ki tudtam volna próbálni, mert gondjaim voltak a módok beállításainál. Úgy tűnik, csak Mode 3-ban tud működni és azért működött Mode 1-ben akkor, amikor rajta volt a logikai analizátor, mert az analizátor felhúzta a CLK-t magasba, ahogyan az a Mode 3-nál van alapból. De a fázist is át kellett váltanom (CPHA), hogy magasabb frekin is működjön. Lehet, hogy a hosszú vezetékek miatt is gondok vannak, valószínű sokkal közelebb kell tervezni a panelen a Flash-t a PIC-hez, mint most, hogy elérjem az 50MHz-t, bár olvastam valahol egy fórumon, hogy nem megy 50-en... ?
Fura (rossz?) egy kicsit az adatlap megfogalmazása (vagy én nem értem jól) a CPOL-nál. Aktív szintekről beszél, holott az aktív szint mindig a magas, csak az Idle state lesz alacsony, vagy magas a CPOL beállításokkal. A kommunikáció megkezdésekor a nibblek beállításakor a CLK alacsonyra vált, vagy ha alacsony az Idle state szint akkor ott van és az érvényes adat átvitele mindig a magas szintnél, illetve a felfutó élnél történik. Legalább is az analizátor ezt mutatta. Szenvedek vele...

Valahol anno beleakadtam egy MC prezentációba, ami a 32 bit mcu-kat szedte össze listában, milyen helyezése van az MC-nek, kik vannak fölötte, kik alatta. Ha valakinél véletlenül megvan az az anyag, és tudna írni egy pontos brossúra címet, vagy internet linket dobni, örülnék neki. Éppen keresem, és nem találom. Kellene a top 6-8 cég, akik 32-bit mcu-kat gyártanak 200mhz és az alatti kategóriában.

Ha a túl nagy sebesség nem jönne össze, próbálj ki egy olyan design-t, hogy pici helyettesítő képeket használsz, és kockánként töltesz be felületet. Akkor nem kell akkora sebesség, és bőven jó egy sd kártya is. Persze az nem sqi, én is tudom, de megoldásnak elég jó tud lenni a gyakorlatban.

Ez olyasmi lenne, mint a mozaik háttér, van ahol jó, van ahol nem. Szeretnék képekből felépített objektumokat kezelni (gombok, ablakok, stb.). Ez a 25MHz elvileg elég kéne legyen, meglátom, ha sikerül írni és olvasni, mert jelenleg csak a JEDEC-ID-t tudom kiolvasni. A DMA Mode 3 -ban úgy is csak 33MHz-et ír (mondjuk ezt sem értem miért, mert Mode0-ban 66...).

Vannak arra példák, hogy nem képeket tölteni, hanem generátor függvényekkel gyártani le a képet. Úgy sokkal kevesebb adatot kell mozgatni.

Igen, jelenleg minden objektumot kalkulálok egy egyszínű háttér elé, de ez nem gyorsabb a számítások miatt, csak kisebb helyet igényel, mivel nem pixelenként van tártolva. Az adatokat mindenképpen ki kell vinni, a kalkulálás és a szoftveres adatátvitel lassabb elvileg, mint a DMA.
Az ilyen kalkulált objektum képek akár egész pofásak is lehetnek, de messze nem olyan, mint amit mondjuk egy CAD-ben generálunk le fotorealisztikusan. Ha olyan sebességű lesz, mint amit a számoktól remélek, akkor az elég gyors megjelenítést ad. Persze nem olyat, mint egy okosteló, de nem is akarok olyan gyorsat, csak használhatót. Jelenleg egy komplett felület kivitele olyan 0,1sec, amiben az egyszínű háttér(800x480), a gombok és egyéb megjelenítendő értékek vannak. Ha ez az idő a kétszeresére nyúlik a külső memóriából való betöltés miatt, akkor a még vállalható. Azt még hozzá kell vennem, hogy most szoftveresen viszem ki a TFT-re a PMP-n keresztül a szavakat, de a tervem az, hogy az SQI Flashből és a TFT felé is DMA-val oldom meg az átvitelt. Sajnos közvetlen átvitelt ha jól olvastam nem lehet megoldani, ezért egy teljes képet több darabban kell áttolni, de remélem ez nem lesz zavaró. Az is lehetséges, hogy sorkihagyásokkal teszem ki két, vagy három részben, úgy nem annyira látható a kép felépülése. A letárolást már eleve ehhez lehetne optimalizálni, bár a külön parancsok kivitele a TFT-nek sokat lassíthat a folyamatos ömlesztéshez képest. Majd meglátom...

Nem akarok bele kotyogni, mert nem olvastam végig az előzményeket.
De esetleg ezzel a HMI modullal nem megoldható a feladatod?

Hát, gyorsan átolvastam, valószínűleg igen. Hogy milyen buktatói vannak, csak akkor derülne ki, ha használnám, de jónak tűnik. Jó lenne látni a sebességét és ismerni a korlátait (pl. a soros porton keresztül milyen sebességű vezérlés oldható meg, gondolok itt a touch kiértékelésére, gyors lapváltásokra, objektumok mozgatására, ha ilyet egyáltalán lehet. stb.) De ez itt off lenne... Köszi!