STM32 czy PIC32? Obszerny przegląd mikrokontrolerów dla amatorów z darmowymi narzędziami!

Fri Jan 08, 2016 10:46 pm   

W dniu 2016-01-08 o 22:03, Sebastian Biały pisze:

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


mhm ;)


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

a.

Fri Jan 08, 2016 10:48 pm   

On 2016-01-08 22:46, Artur Miller wrote:

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.


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

Fri Jan 08, 2016 10:55 pm   

W dniu 2016-01-08 o 22:48, Sebastian Biały pisze:


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

a.

Fri Jan 08, 2016 11:00 pm   

On 2016-01-08 22:55, Artur Miller wrote:

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

Sat Jan 09, 2016 12:09 am   

On Fri, 8 Jan 2016 18:59:13 +0100, Sebastian
Biały<heby@poczta.onet.pl> wrote:

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

Sat Jan 09, 2016 12:17 am   

W dniu 2016-01-09 o 00:09, Marek pisze:

kwestia komplikacji softu. w 99% debugger nie jest potrzebny, ale jak
trafisz na ten 1% bez niego, to problem potrafi zjeść zdecydowanie za
duzo czasu

a.

Sat Jan 09, 2016 10:15 am   

On 2016-01-09 00:09, Marek wrote:
[...]

Sat Jan 09, 2016 10:46 am   

On Sat, 9 Jan 2016 00:17:43 +0100, Artur Miller <nomail@nomail.com>
wrote:

Z tego wynika, że ten 1% ma decydujące kryterium wyboru
dyskwalifiujące środowiska bez (dobrego) debuggera, dla mnie to jest
zaskakujące.
Odkładając argument czasu, który do mnie przemawia w okolicznościach
komercyjnych, to w warunkach hobbystycznych takiego znaczenia
(przynajmniej dla mnie) nie ma.
Zdarzyło mi się oczywiście debugować coś ledem (bo innej możliwości
nie było) ale w życiu bym wtedy nie wypadł by pójść na łatwiznę i
użyć debuggera .

--
Marek

Sat Jan 09, 2016 11:02 am   

On 2016-01-09 10:46, Marek wrote:
[...]

są również debuggery. Bo służą do usuwania bug-ów.

Sat Jan 09, 2016 11:04 am   

W dniu 2016-01-09 o 10:46, Marek pisze:

decydujące może nie jest, ale... dla mnie osobiście ma dość duże
znaczenie. chyba, że zostajemy na sterowaniu do bramy albo wyłącznikach
do lampki wtedy pozostaje zdefiniować gdzie kończy się "amator" a
gdzie zaczyna "poważny amator" :)

a.

Sat Jan 09, 2016 12:15 pm   

On 2016-01-09 00:09, Marek wrote:

Prawda jest taka że stosując prawidłową inzynierję programowania (unit
testy, abstrakcje, statyczny polimorfizm) mozna doprowadzić zdecydowaną
częśc firmware do perfekcyjnego przetestowania poza uC. Jednak kiedy
zblizamy się do zagadnień I/O, hardware, cycle exact, specyficzne cechy
kompilatora, optymazliacja kodu etc nie ma jak testować tego in vitro.
Debugger jest istotnym składnikiem programowania, migające diody się nie
sprawdzają [1]. Nawet jesli debugger tak naprawdę nie debuguje sprzętu
tylko symulator.


Myślę że poziom komplikacji softu powoduje że debuggery stają się
niezbedne. Oczywiscie nadal jest nisza na rynku dla programistów asm w
'51 piszących wprost hexy do rom. Ale wykształcil się jakiś poziom
pośredni gdzie firmware liczy się w setkach KLOCów i gdzie bugi są
rzeczą oczywistą i trzeba być na nie gotowym pod względem
organizacyjnym. Tutaj pomaga doświadczenie z dużych aplikacji, wiele
projektów embedded ma kłopoty właśnie z powodu braku doświadczenia
wielkiej skali. Znajomośc na pamięc opcodes '51 nie pomaga.

[1] Pisałem kiedyś soft z metodami wirtualnymi na SAM7. Okazało się że
dostarczony przez atmela skrypt linkera nie wkładał do flasha tablic
wirtualnych ("Bo, Panie, komu to potrzebne!"). Bez debuggera tego nie ma
jak zdiagnozować, chyba że już wiesz w czym problem. Intensywne
wpatrywanie się w kod nie pomogło. Miganie diodą co najwyżej określa że
działa lub nie działa.

Sat Jan 09, 2016 12:23 pm   

Dnia Sat, 9 Jan 2016 12:15:36 +0100, Sebastian Biały napisał(a):


Dooobre
--
Jacek
-Co robi Jarosław jak ma ochotę popieprzyć?
-Odwraca kota ogonem...

Sat Jan 09, 2016 12:33 pm   

Dnia Sat, 9 Jan 2016 12:15:36 +0100, Sebastian Biały napisał(a):

Ano - nie ma jak.
Tym niemniej sporo bledow lezy po stronie programisty (dokumentacji
etc.), i debugger tu sporo upraszcza namierzenie bledu.
Przydatna rzecz.

J.

Sat Jan 09, 2016 12:35 pm   

On Sat, 9 Jan 2016 10:15:24 +0100, JDX <jdx@onet.pl> wrote:

Wbrew pozorom wcale nie to miałem na myśli :)

--
Marek

Sat Jan 09, 2016 12:40 pm   

On Sat, 9 Jan 2016 12:15:36 +0100, Sebastian
Biały<heby@poczta.onet.pl> wrote:

Miałem na myśli komunikację ledem, ja w ten sposób zwracałem
mignieciami wartości liczbowe np. rejestrów, oczywiście w hex ;)

--
Marek