"entroper" <entroper-pocztaonetpeel> wrote in message
news:4ce310b2$0$20996$65785112@news.neostrada.pl...
> Użytkownik "Jerry1111" <j...@w...pl.pl.wp> napisał
> w wiadomości news:ibv08v$17t$1@news.onet.pl...
>
>> Pszemol, moze zacznij od czytania errat?
>
> to go czeka niezależnie od tego, co wybierze :)

No dokładnie.

do góry

On 16/11/2010 23:20, entroper wrote:
> Użytkownik "Jerry1111"<j...@w...pl.pl.w
p> napisał
> w wiadomości news:ibv08v$17t$1@news.onet.pl...
>
>> Pszemol, moze zacznij od czytania errat?
>
> to go czeka niezależnie od tego, co wybierze :)

Ale lepiej przed...

--
Jerry1111

do góry

"Zbych" <a...@o...pl> wrote in message
news:4ce23e6e$0$20991$65785112@news.neostrada.pl...
> W dniu 2010-11-16 01:51, Pszemol pisze:
>
>> I jak jest z narzędziami do tego STM32? Jakieś IDE? Kompilator C++?
>
> Tradycyjnie gcc. IDE jakie chcesz, ja używam VS + zewnętrzny makefile.

VS to jest Visual Studio?

>> Interfejsy JTAG? Używałeś tego?
>
> W wersji dla cierpliwych OpenOCD + FTDI.

Co masz na myśli "dla cierpliwych"? Nigdy tego nie używałem...
Oglądam sobie właśnie OpenOCD i widzę że piszą:

OpenOCD v0.4.0 released

JTAG Layer:

> Support KT-Link JTAG adapter.
> Support USB-JTAG, Altera USB-Blaster and compatibles

Czy to może znaczy, że posiadany przeze mnie JTAG adapter
używany do chipsów Altery (USB Blaster) mogę wykorzystać
do OpenOCD? Czy OpenOCD to tylko programowanie flasha
i boundary scan czy będzie to działać z source-level debugging?

Jeśli tak, to zaoszczędziłbym kasę na zakupie JTAG hardware :-)
Dużo robimy z Alterą, więc ten sam wariat do JTAGa byłby zaletą.

> Jak masz więcej kasy to J-Link.

Widzę na amazon.com za $300...
Ale skoro USB-Blaster chodzi, to nie ma sensu bo go już mam...

> Co do używania, to kiedyś popełniłem na tym projekt
> i z tego co wiem "się produkuje".

No to gratulacje. Czy nie miałeś żadnych niespodzianek?
Wszystko działało jak trzeba? Czego Ty używałeś do source
level debugging?

do góry

wrote:

> Użytkownik "Piotr "Curious" Slawinski"
> <c...@b...internetdsl.tpnet.lp> napisał w wiadomości
> news:4ce2b65a$0$22810$65785112@news.neostrada.pl...
>
>> nie wiem czego wy chcecie od picow... dziala? tanie? z dostepnoscia brak
>> problemow? prosty ASM? sdcc jako prymitywne (i darmowe) C tez jest. no
> to o > co chodzi
>
> o to chodzi, że w przypadku, gdy przydałoby się przeskoczyć na inny,
> nieznany procesor, _szczególnie_ "dla jednego zastosowania", warto
> przeskoczyć na coś sensownego. Po to, żeby za pół roku, gdy jednak okaże
> się, że jest kolejne zastosowanie nie musieć skakać dalej. Sorry, ale
> nawet dla amatora jest to decyzja "strategiczna" i argumenty, że działa,
> da się dostać i jest tanie i w ogóle nie ma się czego przyczepić - są
> jakby mało przekonujące. Wiele mocniejszych procków też spełnia te
> kryteria. A egzotyczne rozwiązania się mszczą.
>

a jesli sie nie okaze?
osobiscie uwazam ze 'fit for purpose' nie jest takie zle. jesli po pol roku
bedzie potrzeba nowego zastosowania - to wybacz, ale pol roku to kawal
czasu, zmienia sie ceny, mozliwosci, ba - nawet preferowany jezyk
programowania czy jego styl moze sie zmienic. zabawke za pare dolarow bez
zalu bedzie mozna wyslac na misje eksploracji wysypiska smieci.

przypominam ze mowimy tu o projekcie na ~100 linijek C, ew. cos co uda sie
bezproblemowo zakodowac w ASM, a nie o projekcie z 321312 zaleznosci i
2342342 bibliotek.

btw. idac idea 'asekuranctwa' najlepiej od razu wsadzic tam i7, 1g ramu,
linuxa, jave... moze od razu cale gentoo zainstalowac 'na wszelki wypadek' i
pare giga softu devel ;) no i jaka wygoda, logujesz sie po vnc, i skladasz
sobie programik w wygodnym IDE , graficznie, ew. jako jakis interaktywny
applet javy z wodotryskami ;) a , i moze protocol decoder z AI... ;)
no i pamietajmy ze programistow 'mainstreamowych' latwiej znalezc na rynku,
wiec nie ma sensu sie uzalezniac od jakichs 'mikrokontrolerowych magikow' .
wiec moze php, czy w ogole dzial kadrowy spytac jaki jezyk wybrac - niech
podadza na podstawie badania rynku pracy ? :p


--

do góry

"entroper" <entroper-pocztaonetpeel> wrote in message
news:4ce2c16f$0$22807$65785112@news.neostrada.pl...
> o to chodzi, że w przypadku, gdy przydałoby się przeskoczyć na inny,
> nieznany procesor, _szczególnie_ "dla jednego zastosowania", warto
> przeskoczyć na coś sensownego. Po to, żeby za pół roku, gdy jednak okaże
> się, że jest kolejne zastosowanie nie musieć skakać dalej. Sorry, ale
> nawet dla amatora jest to decyzja "strategiczna" i argumenty, że działa,
> da się dostać i jest tanie i w ogóle nie ma się czego przyczepić - są
> jakby mało przekonujące. Wiele mocniejszych procków też spełnia te
> kryteria. A egzotyczne rozwiązania się mszczą.

Wpadł mi właśnie w oko również ColdFire/Freescale. Co myślicie?
Np. MCF52230CAF60
http://www.freescale.com/files/32bit/doc/fact_sheet/
MCF5223XFS.pdf
128kb flasha, 32kb ramu, obudowa lutowalna ręcznie 80-LQFP ale
niestety tylko 3 UARTy i cena powyżej 10 USD spada do $7 @ 1000 szt.
Ciut droższy od STM32F105R... i nieco większa obudowa od 64 pin STM32.
Ale jak by ktoś znał taką kostkę ColdFire ale z 4 uart'ami to zerknałbym...
:-)

do góry

W dniu 2010-11-17 23:58, Pszemol pisze:

>> Tradycyjnie gcc. IDE jakie chcesz, ja używam VS + zewnętrzny makefile.
>
> VS to jest Visual Studio?

Tak.

>>> Interfejsy JTAG? Używałeś tego?
>>
>> W wersji dla cierpliwych OpenOCD + FTDI.
>
> Co masz na myśli "dla cierpliwych"? Nigdy tego nie używałem...
> Oglądam sobie właśnie OpenOCD i widzę że piszą:

Developerzy zbiesili się na binarne sterowniki do ftdi i skompilowane
OpenOcd może być dystrybuowane tylko z libusb, które jest dużo
woooolniejsze. Jak masz trochę czasu to warto samemu skompilować OpenOcd
z binarnymi sterownikami do ftdi.

> OpenOCD v0.4.0 released
>
> JTAG Layer:
>
>> Support KT-Link JTAG adapter.
>> Support USB-JTAG, Altera USB-Blaster and compatibles
>
> Czy to może znaczy, że posiadany przeze mnie JTAG adapter
> używany do chipsów Altery (USB Blaster) mogę wykorzystać
> do OpenOCD? Czy OpenOCD to tylko programowanie flasha
> i boundary scan czy będzie to działać z source-level debugging?

Prawdopodobnie tak. Z tego co widać w internecie to USB Blaster jest
oparty na ftdi.

> Czego Ty używałeś do source
> level debugging?

Programistów :-). A tak na serio to insighta.

Na początek lepiej będzie jak znajdziesz w internecie opis konfiguracji
eclipse i ściągniesz skompilowane arm-gcc z code sourcery.

do góry

Użytkownik "Pszemol" <P...@P...com> napisał w wiadomości
news:ic0m57.8c4.0@poczta.onet.pl...

> Errate przeczytam, ale akurat podtrzymywanie bateryjne nie jest
> mi potrzebne - potrzebne mi 4 sprzętowe uarty

Coś się tak uparł na sprzętowe UARTy? Przy 9600? Bez kontroli przepływu?
(zakładam, że bez). Przecież tam znak idzie milisekundę! To jest kuźwa
wieczność. Zamiast ograniczać sobie wybór do procków bogato obdarzonych
UARTami, weź raczej coś szybkiego.

> Chyba skończy się na pojedynku na narzędzia i cenę JTAGa....

no to już jest sensowne podejście.

e.

do góry

Użytkownik "Piotr "Curious" Slawinski"
<c...@b...internetdsl.tpnet.lp> napisał w wiadomości
news:4ce498d3$0$21001$65785112@news.neostrada.pl...

> > o to chodzi, że w przypadku, gdy przydałoby się przeskoczyć na inny,
> > nieznany procesor, _szczególnie_ "dla jednego zastosowania", warto
> > przeskoczyć na coś sensownego. Po to, żeby za pół roku, gdy jednak
okaże
> > się, że jest kolejne zastosowanie nie musieć skakać dalej.

> a jesli sie nie okaze?

zawsze będzie jakieś nowe zastosowanie, chyba że się Kolega z branży
wycofa :)

> osobiscie uwazam ze 'fit for purpose' nie jest takie zle.

przy milionie sztuk.

> btw. idac idea 'asekuranctwa' najlepiej od razu wsadzic tam i7, 1g ramu,

btw, wszystko można sprowadzić do absurdu przy odrobinie uporu. Jeśli nie
zauważyłeś, doradzałem Koledze użycie najmocniejszego procka w danej
klasie obudów, poboru mocy, komplikacji peryferii (zasilań itp) czy co tam
jest dla niego najważniejsze.

e.

do góry

"entroper" <entroper-pocztaonetpeel> wrote in message
news:4ce53d80$0$27045$65785112@news.neostrada.pl...
> Użytkownik "Pszemol" <P...@P...com> napisał w wiadomości
> news:ic0m57.8c4.0@poczta.onet.pl...
>
>> Errate przeczytam, ale akurat podtrzymywanie bateryjne nie jest
>> mi potrzebne - potrzebne mi 4 sprzętowe uarty
>
> Coś się tak uparł na sprzętowe UARTy? Przy 9600? Bez kontroli przepływu?
> (zakładam, że bez). Przecież tam znak idzie milisekundę! To jest kuźwa
> wieczność. Zamiast ograniczać sobie wybór do procków bogato obdarzonych
> UARTami, weź raczej coś szybkiego.

Bo wygodny jestem i leniwy :-)
I nie ograniczam sobie zbytnio - im dłużej szukam tym więcej
procków z 4-ma lub więcej UARTów znajduję...

Dziś na ten przykład znalazłem innego procka z takim samym core
ARM Cortex-M3 tylko z innej stajni: NXP, part#: LPC1763 .. LPC1769.

Wygląda mi to na te same narzędzia jak miałbym do STM32F105...

>> Chyba skończy się na pojedynku na narzędzia i cenę JTAGa....
>
> no to już jest sensowne podejście.

:-)

do góry

Użytkownik "Pszemol" <P...@P...com> napisał w wiadomości
news:ic2vnf.ca4.0@poczta.onet.pl...

> Dziś na ten przykład znalazłem innego procka z takim samym core
> ARM Cortex-M3 tylko z innej stajni: NXP, part#: LPC1763 .. LPC1769.

NXP mogę polecić.
BTW, kiedyś popełniłem jakiś mostek RS-owy na niski bitrate (3 portowy
OIDP, oczywiście z małymi buforami) na PIC16F84, więc jeśli znajdziesz
jakiegoś ARM-a bez wystarczającej ilości UARTów myślę, że się wyrobi ;)

e.

do góry