Programování uC Microchip v C

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: )

Sorry, prehliadol som typ mcu.

Ak na tom XC30 používaš nejaký operačný systém, potom to určite zmysel má.

Alebo ak vieš, že debugovacie správy budú tak malé, aby Ti zaskenutie sa mcu na tom, kým sa celá správa odvysiela nebude vadiť, tak je to tiež OK.

Len si treba byť vedomý, že čakanie mcu na dokončenie odvysielania môže v časovo kritických situáciách viesť k falošným výsledkom.

Pod časovo kritickou situáciou si netreba hneď predstavovať riadenie raketoplánu. Stačí programovať staničku na počítanie impulzov z elektromerov, kde impulz trvá 20ms a viac. Tak si spravím rutinu, ktorá testuje fyzický vstup napríklad každých 5ms.

No ak sa mcu rozhodne začať niečo vysielať, a správa bude trvať 45ms, potom sa môže kľudne stať, že budem mať hlavu v smútku, že mi nesedí počet prijatých impulzov s číselníkom elektromera. Ak tieto všetky súvislosti dopredu domyslím a viem s tým žiť, tak je všetko OK a presmerovanie fprint môže byť silnou pomôckou.

Držím palce

Martin

P.S. Inak som rád, že podľa Tvojej definície stále patrím medzi decká (duchom mladým) a ešte sa tým dá celkom slušne uživiť :slight_smile:

Martin: Hlavní programová smyčka má periodu 100 us. Řídím tím spínaný zdroje. Nemám právěže vůbec čas na kraviny. Neexistuje možnost, že by se mi zasekl cpu na 1 ms, kvůli nějaké kravině. Jak jsem psal, používám na vše IRQ a DMA.
200B odvysílám do stovky cpu us při 115200 Baud :slight_smile:

Proto si nemůžu dovolit se zabývat a zdržovat se vestavenýma funkcema v kompilátoru. Nejsou takto tvrdě optimaliovány na rychlost.
dsPIC má od kde jaké periferie 3 - 5 IRQ zdrojů (vyjma časovačů), ty můžou mít různou prioritu (celkem max 7). PIC24 to má stejně.

ZA ty 8b se omlouvám, bral jsem to ze svého úzkého pohledu. :smiley:

Drzim palce :slight_smile:

Nezáleží na procesoru.
Dospěle napsanej musí být hlavně program.
Vhodná volba procesoru je věc druhá.

Presne tak :slight_smile:

ako napríklad tento progam je fakt dobre napísaný, C-čko ne C-čko :slight_smile:

touchit.sk/hlada-sa-programator … eko/113266

8kB operačnej pamäte - z Plated wire memory, čo sa dá voľne preložiť ako pamäť z oplášťovaných drôtov - stačí prakticky na “šecko” :slight_smile:

Těžko říct jestli je dobře napsaný, neviděli jsme ho :smiley:

Fortran nebo Cobol by se ještě daly, ovšem pokud je to ve Forthu tak do toho nejdu :smiley:

Podľa mňa dobre napísaný program sa pozná podľa toho, že robí to čo má.
A evidentne tento to robí a už vyše 40 rokov. Tak asi dobre napísaný bude.

Samozrejme, že ho na ďiaľku preprogramovávali . Napríklad keď letel okolo (sa mi zdá) Saturnu, ho preprogramovali tak, že vedel lepšie komprimovať fotografie a vďaka tomu poslal z obdobia rádiového tieňa asi o 40% viac fotiek ako pôvodne mal.

Kurňa.

8kB pamäte?

A kus z nej slúži na diaľkové preprogramovavávanie?

A ešte to má niečo vysoko sofistikované a zmysluplné robiť?

Napríklad lepším algoritmom komprimovať prenášané fotky?

Sa skláňam pred tvorcami tohto neskutočného technického počinu :slight_smile:

Tak samozřejmě že jsem si dělal hlavně legraci, nesmíš to hned brát tak vážně. Navíc tu nikdo nepopírá ani nijak nezpochybňuje že to byli machři, kteří dokázali za pomocí (na dnešní poměry dost omezeného) hardware i software a i jinak za dost omezených možností (například pohony, nosiče atd atd) předvádět neskutečné kousky (někdy i improvizační) a vytřískat z toho všeho doslova co se dalo.

Jinak pár zajímavostí, když už to tedy pitváme: Sondy sice mají malou RAM, ale mají magnetopáskovou jednotku, takže data si pro následné zpracování kam odkládat mají. Nikde jsem se nedočetl***** rozlišení kamer, ale je třeba si uvědomit, že v té době to tak jako tak nebylo a ani nemohlo být “kdovíco” (samozřejmě také ve srovnání s dnešními poměry, tehdy to samozřejmě bylo to nejlepší co měli a tudíž velký pokrok, vždyť předtím se fotilo i ve vesmíru na filmy, s jejichž zpětnými návraty a vyzvedáváním byly samozřejmě neskutečné potíže).

Další věc je, že sondy toho dneska už moc nedělají, protože jednak za hranicemi sluneční soustavy v mezihvězdném prostoru víceméně nemají co (jen měření záření, některých částic a magnetického pole, kamery už k focení nepoužívají), a jednak s energií už na tom taky nejsou tak dobře jako byly na počátku misí, takže ani nemají dost energie pro všechny doposud provozuschopné přístroje. Další věcí je že komunikační prodleva je obrovská, například v roce 2011 byla u Voyageru 1 16,5 hodiny - na příjem dat to tolik nevadí, ale na zadávání nějakých povelů (nebo přímo přeprogramování) je to prodleva doslova šílená (x2, nejdřív tam a pak ještě zpátky) - nechtěl bych, děkuju pěkně.

voyager.jpl.nasa.gov/mission/status/

A navíc - Microchip C a MCU na tom stejně nepoužívají a nemají, takže jsme tak jako tak offtopic :wink:


  • Už jsem se ho dočetl - 800x800, tj. teoretických 0,64 Mpix max., ovšem nejsou to kamery ve smyslu, v jakém je známe dnes, jsou tvořeny fotodiodami, pohyblivými zrcadly a příslušnou optikou.

physics.stackexchange.com/quest … ger-probes
theskylive.com/voyager1-tracker
en.wikipedia.org/wiki/Voyager_1

Ďakujem za spresnenie :slight_smile:
Inak aj tak, magnetopásková pamäť na data - po 40 rokoch - nemám už poriadne funkčnú kazetu na ZX Spectrum ani po rokoch dvadsiatich :slight_smile: