Re: Dotazy k STM32F103C8T6 a multiplexované řw616ZW7DrSBMRUQgZGlzcGxlamUu

[Jiří Nesvacil]

Díky. Jak píšete Rust se dynamicky vyvíjí a ještě dodám, že si ho musí 
všimnout více editory, aby nějakou intelisence měl více podporovánu. To, 
že je rekompilovatelný do C je asi dobrý, protože máte aspoň standardní 
debugger.

Vidím to, zůstat u C++ , používat syntaxi s referencí:

 1. |voidf1(constcomplex*x,constcomplex*y)// without references|
 2. |{|
 3. |complex z =*x+*y;// ugly|
 4. |// ...|
 5. |}|
 6. ||
 7. |voidf2(constcomplex&x,constcomplex&y)// with references|
 8. |{|
 9. |complex z =x+y;// better|
10. |// ...|
11. |}|

A taky možná nějaké lepší stringy, s pascal notací délky na začátku a 
třeba i délky bufferu. Ty standardní string operace jsme všechny 
přepsali, to je šílenost na únik... .Jestli máte nějaký lepší tip. Jinak 
jedeme v UTF8 s zakončením 0.

Jirka


Dne 12.03.2021 v 10:58 Miroslav Mraz napsal(a):
> Do nativního kódu jde přeložit ledacos, třeba i java. Pokud chcete 
> experimentovat, doporučuji vyzkoušet Rust. Řeší některé problémy 
> C/C++, především bezpečnost - takové ty pravidla MISRA pro C máte de 
> facto zakompovány (a o mnoho lépe) už v jazyce.
> Před časem jsem to zkoušel, ale moc mě to nenadchlo, pro bare-metal je 
> Rust příliš restriktivní, C++ mně poskytuje daleko větší volnost. Což 
> samozřejmě znamená i větší prostor pro to udělat chybu.
> Ale hodně dynamicky se to rozvíjí a od té doby to udělalo dost velký 
> skok dopředu. Co jsem tak koukal, tak už je v tom udělaný i nějaký 
> RTOS a začíná to vypadat trochu použitelně. Dokonce je v tom i nějaké 
> jakoby Arduino.
> Opět to asi nebude univerzální všelék, nějaké problémy to řeší a na 
> druhou stranu to jiné bude přinášet. Protože je to myšleno jako jazyk 
> dost univerzální, tedy i low-level, umožňuje spojit Rust + C/C++ 
> (dokonce i assembler), takže možná by bylo schůdné udělat nějaké 
> "jádro" pro přístup na železo v C a logiku aplikace pak psát bezpečně 
> v Rustu. Ale zřejmě je v tom nějaký čertík skrytý v detailu, co jsem 
> zatím zkoumal, tak je spíš snaha vše udělat v Rustu (což mi připadá 
> poměrně komplikované).
>
> Mrazík
>
> Dne 12. 03. 21 v 10:29 Marek Sembol napsal(a):
>> Jen poznamka: pokud vam ten nativni kod pripada jako vyhoda, tak vam 
>> nic nebrani si ten C# (obecne .NET) nechat prelozit do nativu. A 
>> treba pro Micro.NET (pro embeded) se to taky prekladalo do nativu 
>> (nevim jestli se to nezmenilo, ale spis ne, prece jen neni tam 
>> prostor ani vykon)
>> Na velke masine je ten nenativni kod .NET spis vyhodou :)
>> BR,
>> Marek
>>
>> On Fri, Mar 12, 2021 at 8:30 AM Jiří Nesvacil <nesvacil na posys.eu 
>> <mailto:nesvacil na posys.eu>> wrote:
>>
>>     Psát kousek programu v C, struktury, mraky pointeru se dá, ale při
>>     větším projektu to bývá neudržitelné. Při porovnání verzí, 
>> commitu se
>>     jednoduše nějaká * či & ztratí.
>>
>>     Mimochodem,  šlo tady spoustu emailů na Pascal a ten je daleko
>>     čistější.
>>     Oproti C se vypořádal dobře i s řetězci a ne jako dnes v C je 
>> spoustu
>>     kódování, převodů, zkoumání délek, indexací,... . Nemá taky pro 
>> neznalé
>>     pointery přes * & a je to daleko čistější. Navíc je to nativní 
>> kód na
>>     rozdíl od Java,C#. Pro u embedded systémů je taky, že nemá garbadge
>>     collector. Jsou tady novější jazyky jako GO, ale ten má garbadge
>>     collector, to je pro embedded zařízení trošku moc. Takže pascal by
>>     mohla
>>     být lepší forma než C až na úplně nejnižší volání.
>>
>>     V c++ se zápisu občas dá vyhnout použitím pointerů zápisů přes
>>     referencování a následně na properties čistě přes ".", to 
>> považuji za
>>     čistější.
>>
>>     Psát komplexnější projekt v ARMu čistě v C má své limity dle mého 
>> soudu.
>>
>>     Jirka
>>
> _______________________________________________
> HW-list mailing list  -  sponsored by www.HW.cz
> Hw-list na list.hw.cz
> http://list.hw.cz/mailman/listinfo/hw-list


-- 
Tento e-mail byl zkontrolován na viry programem AVG.
http://www.avg.cz
------------- další část ---------------
HTML příloha byla odstraněna...
URL: <http://list.hw.cz/pipermail/hw-list/attachments/20210312/7edb69da/attachment-0001.html>