Programování uC Microchip v C

A co zkusit tohle :

[code]char Pole[PocetPrvku];
char *AdresaBukny, *AdresaPole;

AdresaBunky = &Pole[KteryPrvekChces];
AdresaPole = Pole;[/code]
případně

AdresaPole = &Pole[0];

To by snad mělo chodit v jakémkoliv Cčku.

Bývalo dobrým zvykem, že kompilátory generovaly LST soubor (listing - nemusí mít vždy příponu .lst), kde byly všechny adresy a symboly shrnuty - XC16 už to neumí?

Edit: Takže si odpovím sám - XC16 User’s Guide praví:

Díky moc borci,
Balů: Vyzkouším.

Mahoney: O listingách zhruba vím, já jsem právě potřeboval něco zcela automatickýho, nevím na kolik je kompilátor ochotnej při vícenásobným překladu přehazovat proměnný v RAM na jiný místo aby to bylo zábavný :slight_smile:

V tom případě jsi spíš špatně zformuloval otázku, protože jsi psal, že k tomu nemůžeš dojít, ne že chceš, aby k tomu dokázal dojít program v MCU (teda jestli to dobře chápu). Ale stejně mi není jasný k čemu to můžeš potřebovat, kompilátor se o svoje proměnný dokáže postarat dobře sám a program v MCU se vůbec nemusí zajímat o to, kde co leží.

Balů: Díky funguje to. Popravdě jsem pintery do teď nepotřeboval, takže ani nevím, že to jde použít takhle jednoduše.

Mahoney: No když to čtu znova, tak to mám napsáno lehce divně :slight_smile:

Kompilátor se o proměnný stará v pohodě. Já mám v RAM pole 1024B pole, který potřebuju přes SPI přenýst do LCD co 100 ms. Standartní ruční prací, to zabere strašný množství procesorovýho času.
PIC24 má DMA řadič, kterýmu akorát sdělím adresu odkud má začít sypat data (počáteční a koncová adresa pole) a kam (SPI buffer). Celý tohle to zabere CPU jen pár stovek ns, všechno tam přesune DMA řadič úplně sám.

No ono když to čtu znova zas já, tak zjišťuju, že jsem poprvé tu druhou část tvého příspěvku (s tím LCD, SPI atd.) úplně přehlídnul. Takhle to smysl samozřejmě dává :wink: takže psát asi umíš, jen neumím číst :confused: (ach jo).

Co máš přesně za PICku a za displej (jen tak pro zajímavost)?

No ty neumíš číst a já neumím psát :slight_smile:

LCD mám tme.eu/cz/details/eadogl128w-6/graficke-lcd-displeje/electronic-assembly/ea-dogl128w-6/
Mám na tom nalepenej i ten odporovej dotykovej panel, tak jsem zvědavej jak se s tím poperu.

PICy používám ve velkým PIC24FJ64GA306 na tom jsem v práci postavil spec. PLC. Na pokusy používám ještě PIC24FJ256GB206.
V měničích (DC-DC, DC-AC) používám ještě dsPIC33FJ16GS504, ten je výkonově totálně nejmasakrálnější, nicméně ho bude nahrazovat dsPIC33EP64GS504 a ten je ještě víc nabušenej.

To Billy Bob Bean, mám malý dotaz trochu mimo dané vlákno. Je na ds picech možnost debug v reál čase, bez ovlivňování chodu programu? Ptám se proto, že dlouho jsem používal pic18, kde se o nějakém použitelném debugování nedalo mluvit. Přešel jsem na Motorola Freescale, debug v reálném čase jede ok, ale stejně šilhám zpět po picech …
A malý dotaz ještě, používáš v měníčích měření limit vf výkonového proudu z výstupu?

Noname: Debug vůbec nevím, já tohle nepoužívám. Od doby co jsem objevil Saleae Logic a blikání ledkou + UART nic jiného nepoužívám, takže nevím.
dsPIC má JTAG, a na standartním debug má daleko větší HW množství breakpointů a možnosti SW breakpointů.

Limit VF proudu na výstupu? Jak to myslíš? Nebo co myslíš konkrétně?

Zdravím, myslím to tak, že se měří výstupní proud z IGBT tranzistoru a v případě zkratu na výstupu dojde k vyhodnocení limity proudu a vypnutí měniče než bude po něm. Ochrana je provedena hardverově mimo cpu a měla by zvládnout tvrdý zkrat na výstupu v řádu max jednotek mikro sekund. Dělám výkonové měniče a tuto část zatím ještě nemím dostatečně ošetřenou.

Já si myslím, že funkční nadproudová ochrana je na celým tom měniču to nejsložitější. Ochrany řeším přes CPU, taky to není úplně dokonalý.
Hlavně to chce mít na výstupu měniče dostatečnou indukčnost, aby se trochu zmenšíla strmost dI/dt a byl volný čas na posnímání nadproudu.

Teď jsem si z hrozné lenosti porával s Arduinem musím říct, že se mi neskuetčně zalíbila funkce Serial.print(“Retezec znaku”);, Kdy se přes Uart pošle řetezec znaků co je předán jako parametr funkci.

Jak toho docílit v XC30?

Resp. jak zadefinovat funkci do které půjde dynamicky předávat string o délce max třeba 64B? Dál co se s tím má jak dít bych už dopsal sám.

Díky.

Myslim, ze u XC by mohlo fungovat **printf() **; ,tam je to myslim taky na UART1.
Jinak samozrejme pres pointer:

void sendString (consta char *str, unsigned int size)
{
     while(size --)
    {
        UxTXREG = (unsigned char) *str;
        str++;
        while (UxSTAbits.UTXEN)    // ceka na odelani
            continue; 
    }
    return;
}

kod jsem nezkousel … nebudou sedet asi nazvy registru …

Díky za odpověď. Printf z knihovny právěže použít nechci :slight_smile: a nedokázal jsem překladači vysvětlit jak zadefinovat ten vstup. Tohle vypadá dobře. JAk budu mít večer čas, tak to vyzkouším.

Jestli to stojí na GCC, tak ideálně přes fprintf.

#include <stdio.h>

FILE usart0 = FDEV_SETUP_STREAM(usart0_Out,usart0_In,_FDEV_SETUP_RW);

fprintf(&usart0,“TEXT\r\n”);

Funkce usart_Out() , usart_In() si napíšeš sam jak uznáš za vhodný.

Tahle praxe funguje na AVR tak snad by se dala aplikovat na Michrochip.

fprint ostane stáť na tom, kým sa celý reťazec neodvysiela a dovtedy mcu nerobí nič iné?

Neviem, nepoužívam. Mám spravené funkcie cez prerušenie.
No ak áno, potom je to rovnaká zhovadilosť ako delay a čím skôr od toho preč. Ak si funkcia fprint kompletne ošetrí prerušenie od UART-u (o čom v celku pochybujem), tak potom klobúk dole.

Prečo sa na to pýtam. Ak potrebujem odvysielať 60 znakov rchlosťou 9600Bd, 8N1, tak sa pod 62,5ms nemám ako dostať. Ale ak procesor má 62,5ms má stáť na mieste, tak to je v celku prúser. A zdanie, že funkcia fprint (sprint) niečo za mňa geniálne vyrieši hraničí so sľubmi nemenovaných politikov, ako robia pre ľudí :slight_smile:

Ďakujem skúsených za objasnenie.

Martine, jak si to kdo napíše je jeho věc.
Já to mám přes IRQ/DMA podle potřeby a typu procesoru.

Na to aby se mi procesor neužitečně vrtěl v čekací smyčce kdekoliv v programu nemám náladu takže často píšu pod RTOS (mám napsaný vlastní).

fprint/sprint za mě řeší formátování a to i variabilní. Nebudu se srát s takovou volovinou, mám jiné věci na práci :wink:

Jo a Martine, to stou poznámkou o tom, že si funkce printf sama kompletně ošetří všechno kolem výstupního kanálu, v tomto případě USART, nemůžeš snad ani myslet vážně. To seš C-čkař? Jedná se přece o nadřazenou funkci, kterou výstupní kanál vůbec nezajímá. FATFS taky neví nic o SD kartě.

Myslel som to vazne.

Aby som absurditou otazky primel uvazovat nad (ne)uzitocnostou takehoto pristupu na 8b jednocipoch bez OS :slight_smile:

Snad sa mi to podarilo a tazatel bude hladat jednocipakovo zmysluplnejsie riesenia. :slight_smile:

Martin: Mě to přijde maximálně užitečné, jinak bych se neptal. Potřebuji napsat vlastní funkci, která bude podle mě poměrně jednoduchým způsobem příjímat debug zprávy a posílat UARTem do světa.
Silně pochybuju o tom, že vestavěný Sprintf používá IRQ a DMA a nemám čas to zkoumat.

Hlavně jsem zásadně proti používání cizích knihoven a funkcí, prostě si do svojí aplikace nepustím cizí kód, kdy nevím kdy a co to v průběhu činnosti dělá, jestli to či ono.

8B nepoužívámm, to je v dnešní době akorát pro děcka, ptal jsem se na XC30 (Což je pro dsPIC a PIC24 :smiley: )