Akkor miért öltek rengeteg pénzt az Enhanced Midrange kontrollerek kifejlesztésébe??? Hiszen úgyis kapható olcsó 18F, más 16, 32 bites típus.
- Mert igény van rá. Tömegtermelésnél az olcsóság dönt.
- Mert a magas szintű nyelv fordítói szószátyárak.
- A régi 16F -en rengeteg utasítással érhetők el azok az apró műveletek, amit a fordítók sokszor használnak.

Köszönöm a tanácsokat, de csak este lesz meleg a pákám... Saját program futott, egy hőmérő prg kijelző részét teszteltem, de utána a PORTB-re csak 0xAA írtam kétsoros ciklusban, de sehol semmi.
Most látom szégyenkezve, hogy a haladó topicba írtam, pedig a kezdőbe szántam...

Részint logisztikai okai vannak, amire valahol offici MC írást is láttam. A 16f-ek nagyon sok tömegtermelési projectben vannak benne, és bár lenne helyettesítő termék, minek akarná bárki is újratervezni a jól bevált eszközöket? Nem akarják. Kérik továbbra is a 16f-eket. Miért akarna az MC egy halom pénzt kidobni az ablakon? Ő sem akarja. Gyártja a 16f-eket.

A fejlesztők tudnának ráhatással lenni a helyzetre, de ott is akadályok vannak. Az ifjak valahogy lusták, az öregek meg csak akkor váltanak, ha informatikailag kényszer helyzetben vannak, mert a mai világ semmire sem akar időt engedni, fejlesztési előkészületekre és új termék erratákra meg pláne nem. Egy gazdasági fellendülés tudna jót tenni a termék piacnak, de az egyenlőre nincsen.

Lassan őrölnek az idő kerekei. Recesszióban meg pláne - ami már egy évtizede tart.

Sziasztok!

PIC32MX170F256B-re UART-hoz írogatok DMA-s kódot. Már működik az RX/TX DMA-an keresztül.
A kérdés az lenne, ha tegyük fel h*lye lennék és egy adat tömb elküldése előtt meghívnám újra a küldő fv. akkor ne engedje elküldeni az újabb tömböt?
a kód:


Próbálkoztam azzal, hogyha a CHEN == 1 akkor nem küld vagy, ha CHSDIF == 0 akkor se küldje újra, de egy Hello World!-ből a legjobb eredmény az lett, hogy a H betű eltűnt az elejéről és nem tudom, hogy tudnám akkor ezt lekérdezni, hogy átment-e UART-on a tömb vagy nem.

Építened kellene magadnak alkalmazás layereket, és a kérést ha egyszer átengedted, tölteni valami boolean flaget, és legközelebb simán eldobni a ráhívást. Ha csak 1 layeren gondolkodsz, úgy nem lesz elegáns sehogyan sem. A retesz flageket természetesen program induláskor egyszer explicite kinullázod. Van annak a 32mx-nek memóriája bőven, nem kell félni felhasználni kényelmi célokra is.

Még nagyon vázlat program 2 napja ismerkedek a DMA-val, régebben is tudtam, hogy erre jó, de sose használtam. A boolean flag dolog megvan valami olyat akarok én is csak a flaget pl CFORCE = 1 után set és hol jön a flagnek a clear? Ezért akartam nézni valami hw flaget, ha átment a blokk jöhet az új.

Na megvan a hiba a CHSDIF/CHBCIF bit a valóságot mutatta és azért maradt le a "Hello Wolrd"-ből a H mert az utolsó adat küldés alatt még foglalt az UART ezzel sikerült megoldani:

Az isWriteable az interrupt seteli, ami viszont ebből kérdés felmerült amíg a DMA tolja az adatot addig a TRMT lehet '1'? Mert, ha nem elég csak a TRMT-t figyelnem.

Üdv. Holott nem is haladó kérdés, de gondolom a haladók már többet láttak.
Van egy programozható IC, (nemtudom hogy AVR vagy PIC, vagy mik vannak még) aminek a teteje olvashatatlan, tehát nem lehet elolvasni hogy mi is az. Az irányát sem tudom, tehát nem tudni melyik az első láb. A nyák, amiben volt, igy volt bekötve. Kisértetiesen hasonlít, egy 16F628A-ra
5ös minusz, vele szembe a plusz. 4es láb a MCRL? lenne, ami felhuzva a +ra.
Mi más PIC lehetne szerintetek?

Ilyen tokozással sok 18 lábú PIC rendelkezik. Egy olvasási kísérlettel könnyen kideríthető a típusa, a programja már nagy valószínűséggel nem.

Nem csak pic létezik a világon, hanem temérdek sok asic is. Bármit lehet az a cucc. Az "irányát" hogy-hogy nem tudod megállapítani? Nincs ott a tokon az egyik oldalon az alakjelölés?

Sziasztok.

Bocs, hogy ide is felteszem a problémámat, hátha valaki...!

Megépítettem ezt az órát , működik szépen, csak valami nem stimmel a programban, mert 19:59 után nem 20 órát mutat, hanem 00-át és akkor vált át AM-ről PM-re, de a perceket jól mutatja tovább. Aztán reggel 6 órakor már jól mutatja az időt, és a dátum is jó. (Nem tudom mikor vált vissza, talán éjfélkor). Én úgy látom, hogy a 20 órából csak a kettes számot jeleníti meg.

Valaki segítene, hogy mit kellene átírni a kódban, hogy jó legyen és az " AM PM" sem lenne szükség a 24 órás megjelenítésnél.

Köszönöm előre is.

Első ránézésre ebben a sorban sántít vallami ...
hr = hour & 0b00011111;
Nekem a működő programomban 00111111 van a maszkolásnál.

Persze lehet máshol oldották meg a 20 óra utáni idő dekódolását ...
az 5-ös bit jelenti a 20 órát ...

Köszi a választ,

Ezt hogy állapítom meg, hogy 5 vagy 6 bit?

Elkezded számolni: a legalacsonyabb helyiérték a 0.
Különben hibás az adatlap. (Jé, nem csak a Microchip -é... ) A óra regiszterben az 5.4 bitek a 10 óra, a 3..0 bites az óra BCD értékét tartalmazzák.

Ha jól értelmezem, az óra tud 12 órás módban is működni, akkor az 5. bit az AM/PM, és csak a 4. biten van az óra tizeseinek ábrázolása. 24 órás módban pedig az 5-4. bitek az óra tizesek, és értelemszerűen nincs AP/PM bit. A 12/24 órás működést a 6. bit határozza meg, már ha jól értelmezem ezt a táblázatot.

Úgy látom mintha hiányozna a 12 órásra beállítás a case 1 résznél (6 bit 1 be állítás), de amúgy 12 órás beállításra van megírva, ezért számol 24 órás ütemben. A kiolvasásnál viszont levágja a kettest, így a PM azt jelzi, hogy ott 2-es van.

Helló.

Én ezekből semmit nem értek!
Hol, mit írjak át, hogy jó legyen?

Nincs rajta. Be volt öntve az egész, hogy vizálló legyen. Köszörülgettem a nagygát, de épp elkaptam az IC tetejét is. Így sima lett.

Jó lenne kicsit többet tudnod arról, mi is az az eszköz egészében. Mi volt az eredeti funkciója, mi minden van még a panelen, milyen teljesítménnyel tudta, amit tudott. Ha semmit sem tudsz az eszközről, én azt sem venném biztosra, hogy az az eszköz mikrovezérlő. Bármi analóg eszköz is lehet.

A program case 1: részében az alábbi sorban 0x13 helyett nem sima (decimális) 13 kellene? Annak ugyanis semmi értelme, hogy 19 óránál váltson!


Én így próbálnám meg:

BCD-ben ábrázolja az órákat, így még jó is lehet a 0x13.

Már próbáltam 0x18-at, ami 24, de ugyan az volt az eredmény.

Én már nem tudom követni a sok oda-vissza alakítást...

Én úgy látom, abban a case ágban a BCD-ben ábrázolt órákat növeli (vagy csökkenti) a set értékével, és csak az összeadás miatt van egy oda-vissza alakítás. Ami utána történik, az a 12 órás időkezelés miatt van, az első if-ben 13-ból 1 lesz (a 14-ből meg nulla!?), a következő if-ben pedig a 0-ból 12. Mindkét esetben megfordítja az AM/PM jelölőt.
Ebből nekem úgy tűnik, hogy ez az óra 12 órás kijelzésre van kitalálva (leglábbis itt, a beállításnál), nem is értem, hogyan mutathat 19 órát.

Ez csak a beállításnál figyeli, hogy ne pörögjön túl, és igen BCD-ben tárol, tehát 0x24 kellene a 24 órás kijelzéshez, de ehhez a kijelző részt is át kellene alakítani. Inkább valami ilyesmit hiányolok:

Így legalább a 12 órás mód helyesen működne.

Mert a DS 24-es módban megy, a 20:00 a kijelzésnek a 00:00-át jelent a kettes pedig a PM-et jelenti.

Végül is nem bonyolult:

Kiolvasásnál:

Kiírásnál pedig AM/PM helyett írjon space-t, vagy kitörlöd az inicializáló részben a PM-et, akkor ez a rész sem kell.

Köszi, ezt is kipróbálom.

Ez melyik rész? int ap; ez lenne?

Ezer hála és köszönet a segítségetekért,
@ktamas66 Tiéd lett a helyes "megoldás". nyereményed