W dniu 2016-01-08 o 20:08, Sebastian Biały pisze:
> On 2016-01-08 19:19, Artur Miller wrote:
>>> Dlaczego? STM supportuje w większości cpu jtag, dorzucasz openeocd + gdb
>>> i masz de facto pelny debug pod czym chcesz.
>> po stronie CPU tak. a debuger?
>
> OpenOCD + gdb. Dalej to już kto co woli, np. Eclipse.
>
>> te chińskie jtagi (ulink2) działają w
>> ogóle sensownie?
>
> Każdy JTAG zadziala sensownie. Uzywam staruszka Olimex na USB. Mam też
> taki na LPT i jakiś noname który emuluje bodaj byteblaster. Każdy działa
> o ile rozpozna go OpenOCD. A on rozpoznaje chyba wszystkie, wliczając w
> to chińskie klony za 1E.
>
>> może jakies inne są w rozsądnej dla amatora cenie?
>
> *Każdy* wspierany przez OpenOCD i mający prawidłowe napięcia. Ten na 6
> rezystorach z LPT też ;)
>

hm... gdyby jeszcze ten cholerny UART mnie tak nie zraził do STMów, to
może... ;)

a.

do góry

On 2016-01-08 20:30, Artur Miller wrote:
> hm... gdyby jeszcze ten cholerny UART mnie tak nie zraził do STMów, to
> może... ;)

A co w nim złego? Z ciekawości pytam, w zasadzie uarty wszystkie takie same.

do góry

On 2016-01-08 13:07, Atlantis wrote:
> Dostępne jest darmowe środowisko i kompilator?

Tak.

> Nie ma
> żadnych ograniczeń w optymalizacji i/lub rozmiarze generowanego kodu?

Żadnych. Chyba że z powodów religijnych albo certyfikacyjnych g++ się
nie nadaje.

do góry

W dniu 2016-01-08 o 20:41, Sebastian Biały pisze:
> On 2016-01-08 20:30, Artur Miller wrote:
>> hm... gdyby jeszcze ten cholerny UART mnie tak nie zraził do STMów, to
>> może... ;)
>
> A co w nim złego? Z ciekawości pytam, w zasadzie uarty wszystkie takie
> same.

podczas transmisji UARTem ze sprzętowym handshakiem i (zwłaszcza) z
wykorzystaniem DMA spodziewam się, że RTS sie aktywuje na początku
transmisji i gaśnie po wysłaniu całego bufora (zakładając, że odbiorca
może odbierac i CTS ciągle jest zapalony). Otóż nie, w STM32
(przynajmniej w wersji F103) RTS jest najwyraźniej "hardwired" do
sygnału "tx buffer empty", więc po każdym wysłanym znaku RTS gaśnie na
czas potrzebny do zassania nowego znaku z RAMu do nadajnika UARTa przez
DMA.

niby pierdoła, ale ten ficzer ślicznie wykładał GSMowy modem EHS-5
Cinterion'a (reset modemu bez żadnego komunikatu o błędzie po
kilkudziesięciu przesłanych bajtach). Niestety sprzęt nie był moim
wyborem, a projekt był za daleko, zeby go zmienić...


drugą raczej ciekawostką było odkrycie, że sam chip mocno emituje
zakłócenia RF w swoim sąsiedztwie. w układ poskładany na pająku (STM32 +
GPS + GSM) działał, a ściśnięty w małej obudowie wykazywał problemy z
GPSem. Oczywistości były wykluczone oczywiście :) to nie był mój
projekt, szczegółow nie znam, ale mam dostęp do osób, które z tym
walczyły, mogę wyciągnąć więcej info w razie potrzeby.



a.

do góry

On 2016-01-08 21:50, Artur Miller wrote:
> RTS jest najwyraźniej "hardwired" do
> sygnału "tx buffer empty", więc po każdym wysłanym znaku RTS gaśnie na
> czas potrzebny do zassania nowego znaku z RAMu do nadajnika UARTa przez
> DMA.

W wolnej chwili zerknę na to. Nie używam sprzetowej kontroli więc nie
zauważyłem.

> niby pierdoła, ale ten ficzer ślicznie wykładał GSMowy modem EHS-5
> Cinterion'a (reset modemu bez żadnego komunikatu o błędzie po
> kilkudziesięciu przesłanych bajtach).

Czyli jednak nie wina stm32 :D

> drugą raczej ciekawostką było odkrycie, że sam chip mocno emituje
> zakłócenia RF w swoim sąsiedztwie.

Z ciekawostek, Atmelowski SAM7 popędzałem kiedyś w celu sterowania
wyswietlacza. Słuchałem radia kiedy to nagle ... jak by coś piszczało.
Nie, to nie jest możliwe, ale przenisłem układ bliżej. Jak to pieknie
grało! Okazało się ze grało równie głośno po odpięciu kabli od LCD, a na
płyce tylko cpu i zasilanie :D

do góry

W dniu 2016-01-08 o 22:03, Sebastian Biały pisze:
> On 2016-01-08 21:50, Artur Miller wrote:
>> RTS jest najwyraźniej "hardwired" do
>> sygnału "tx buffer empty", więc po każdym wysłanym znaku RTS gaśnie na
>> czas potrzebny do zassania nowego znaku z RAMu do nadajnika UARTa przez
>> DMA.
>
> W wolnej chwili zerknę na to. Nie używam sprzetowej kontroli więc nie
> zauważyłem.

gdzieś nawet oscylogram miałem, ale nie mogę znaleźć teraz

>
>> niby pierdoła, ale ten ficzer ślicznie wykładał GSMowy modem EHS-5
>> Cinterion'a (reset modemu bez żadnego komunikatu o błędzie po
>> kilkudziesięciu przesłanych bajtach).
>
> Czyli jednak nie wina stm32 :D

mhm ;)

>
>> drugą raczej ciekawostką było odkrycie, że sam chip mocno emituje
>> zakłócenia RF w swoim sąsiedztwie.
>
> Z ciekawostek, Atmelowski SAM7 popędzałem kiedyś w celu sterowania
> wyswietlacza. Słuchałem radia kiedy to nagle ... jak by coś piszczało.
> Nie, to nie jest możliwe, ale przenisłem układ bliżej. Jak to pieknie
> grało! Okazało się ze grało równie głośno po odpięciu kabli od LCD, a na
> płyce tylko cpu i zasilanie :D
>

SAM7 to chyba już relikt... i może zapomniałeś o "EMC design guidelines" ;)

a.

do góry

On 2016-01-08 22:46, Artur Miller wrote:
> SAM7 to chyba już relikt...

Nie używam go głównie z powodu głupiel polityki cenowej Atmela (pewnego
dnia ceny we wszystkich sklepach skoczyły koło 5x o ile pamiętam). Ale
kiedyś wydawał mi się ciekawy ... do pierwszego buga w inkludach
dostarczanych w examplach. Strata kilku dni to jednak bolesna sprawa.

> i może zapomniałeś o "EMC design guidelines" ;)

Kto robiąc prototypy zajmuje się pierdołami ;) ?

do góry

W dniu 2016-01-08 o 22:48, Sebastian Biały pisze:
> On 2016-01-08 22:46, Artur Miller wrote:
>> SAM7 to chyba już relikt...
>
> Nie używam go głównie z powodu głupiel polityki cenowej Atmela (pewnego
> dnia ceny we wszystkich sklepach skoczyły koło 5x o ile pamiętam). Ale
> kiedyś wydawał mi się ciekawy ... do pierwszego buga w inkludach
> dostarczanych w examplach. Strata kilku dni to jednak bolesna sprawa.
>


to chyba DSPków Texasa też nie lubisz ;)

a.

do góry

On 2016-01-08 22:55, Artur Miller wrote:
> to chyba DSPków Texasa też nie lubisz ;)

Nie używam. Da facto od kilku lat jestem zdecydowanie software niż
hardware developer. Ale odkurzam się powoli i nie wykluczone że coś z
dsp można by użyć w celu twórczej straty czasu. Albo choćby żeby
potrolować potem na grupie o wyższości C++ nad C w dsp :D

do góry

On Fri, 8 Jan 2016 18:59:13 +0100, Sebastian
Biały<h...@p...onet.pl> wrote:
> Dlaczego? STM supportuje w większości cpu jtag, dorzucasz openeocd
+ gdb
> i masz de facto pelny debug pod czym chcesz.

> Chyba wszystkie army z tej okolicy debuguje się identycznie i
raczej
> *niczego* nie brakuje, może poza sprzetowymi pułapkami

Zastanawia mnie bardzo często ostatnio używany argument "łatwości
debugu". Praktycznie nigdy nie miałem potrzeby debugować (a
programuje unices, mcu 8 i 32bit}. Serio średnio tak wszyscy kiepsko
teraz programują, że bez debuga ani rusz, wręcz staje się to
kryterium wyboru narzędzi/platformy??

--
Marek

do góry