Jeśli projekt nie jest duży to możesz użyć darmowej wersji CCS od Texasa. Ja jestem zadowolony z msp-gcc. Jeśli chodzi o IDE to można łatwo zintegrować msp-gcc z Eclipsowym CDT. Na sieci są dokładne opisy krok po kroku. Z tego co pamiętam działa bez większych niespodzianek. Debugowania nie miałem okazji sprawdzić, bo miałem drobne problemy z komunikacją z mspdebug ze starszej wersji gdb, ale podobno działa z gdbproxy.
j.
W dniu 2010-11-16 01:51, Pszemol pisze:
Tradycyjnie gcc. IDE jakie chcesz, ja używam VS + zewnętrzny makefile.
W wersji dla cierpliwych OpenOCD + FTDI. Jak masz więcej kasy to J-Link. Co do używania, to kiedyś popełniłem na tym projekt i z tego co wiem "się produkuje".
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
jesli ktos potrzebuje do jednego , konkretnego zastosowania (czytaj - nie planuje nagle przeskoczyc do rodziny prockow z mega ramu, drugim rdzeniem DSP i wyswietlanie menu uzytkownika na plazmie 40' , naturalnie zmieniajac tylko kilka linijek w kodzie ... )
--
Użytkownik "Piotr "Curious" Slawinski" snipped-for-privacy@bwv190.internetdsl.tpnet.lp> napisał w wiadomości news:4ce2b65a$0$22810$ snipped-for-privacy@news.neostrada.pl...
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ą.
e.
Działa. Niestety jak wiekzośc armów jest upierdliwy przeraźliwie pod względem ilości połaczeń masy, vcc i vcore, jest tego po kilka sztuk.
Przy 60MHz zrobienie tego softwareowo nie stanowi raczej problemu.
Zero == kwarc, resyztor i dwa kondensatory jako minimum do odpalenia.
Nie używam.
Nie wiem czy pytasz o texasa, ale dla ARM7 jest *bardzo* przyzwoite bo pozwala na debugowanie w systemie za pomocą gdb. Z ograniczeniem na dwie pułapki sprzetowe, ale zawsze.
No i bez problemu działa C++ :P
A to nie ten Cortex w ktorym pamiec RAM znika gdy go uspisz na najbardziej oszczedny tryb? Ktorys Cortex zmniejsza zasilanie RAMu w ramach oszczednosci pradu ponizej napiecia podtrzymania pamieci ;-)
Pszemol, moze zacznij od czytania errat?
Dnia 16-11-2010 o 18:42:24 entroper <entroper-pocztaonetpeel> napisał(a):
No bez jaj. PIC24 "egzotyczny"?
Zobacz może sobie listę tych procesorów, jakie mają peryferia, konfiguracje RAM/Flash/piny. PIC24 pozwala się wygodnie przemieszczać od
512B RAM / 4kB Flash do 98304B RAM / 256kB Flash i od 12 do 100 pin. Toż nie ma architektury, która by załatwiła wszystkie potrzeby, od mini sterownika do procesora "prawie jak pecet". Jak będziesz potrzebował 512B RAM i 4 kB Flash w obudowie 12 pin za poniżej 1$ to też ARMa włożysz?ae
Użytkownik "Andrzej Ekiert" snipped-for-privacy@tlen.pl napisał w wiadomości news: snipped-for-privacy@jabba.jedi...
Ale ja znam PIC-e :) Sporo na nich działałem, ale nie jestem ich wyznawcą. W pewnych obszarach zastosowań (szczególnie "mocniejszych") z pełną premedytacją przerzuciłem się na inne rodziny, które mi bardziej odpowiadają (choć jeszcze rozważam PIC32). Podtrzymuję swoje zdanie, że pchanie się przez osobę w ogóle nie obeznaną z PIC-ami w 16-bitowce obecnie nie ma żadnego sensu. Jest na to po prostu za późno.
zdaje się, że nie ma to żadnego odniesienia do problemu podniesionego w tym wątku. Do takich zastosowań Wątkotwórca weźmie sobie 51, który zna (a ja wezmę PIC-a, bo też znam). Ale sorry, do mocniejszych rzeczy weźmie sobie ARM-a i zrobi tyle (dobrych)portów programowych, ile starczy pinów i mu się to bez problemu wyrobi a że mu 95% flasha będzie leżało odłogiem to nie ma w tej chwili najmniejszego znaczenia.
e.
Użytkownik "Jerry1111" snipped-for-privacy@wp.pl.pl.wp> napisał w wiadomości news:ibv08v$17t$ snipped-for-privacy@news.onet.pl...
to go czeka niezależnie od tego, co wybierze :)
e.
Errate przeczytam, ale akurat podtrzymywanie bateryjne nie jest mi potrzebne - potrzebne mi 4 sprzętowe uarty, mała obudowa i niska cena i sporo ramu aby łykać paczki po 1000-2000 znaków od różnych urządzeń i nie robić baletów. Jedno urządzenie wymaga załadowania mu 2-3kb tekstów z pamięci, teksty przychodzą z innego urządzenia i trzeba je przechować - flash może się skiepścić od częstego w nim pisania/kasowania... Po prostu z tym 8kb ramu w tym
8051 co pierwsze planowałem go użyć byłaby duża gimnastyka. Płytka zasilana jest z sieci i nie będzie przerw w komunikacji, więc nie przewiduję niepotrzebnej komplikacji systemu przez używanie trybów oszczędzających baterię czy tym bardziej usypiających procesor.Potrzebuję coś, co nie zniknie z rynku za parę lat i coś co da się wykorzystać w przyszłości do innych projektów jak już kupię narzędzia i kompilator.
Na razie wybór ograniczam pomiędzy:
STM32F105 MSP430F5419
Chyba skończy się na pojedynku na narzędzia i cenę JTAGa....
No dokładnie.
Ale lepiej przed...
VS to jest Visual Studio?
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:
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ą.
Widzę na amazon.com za $300... Ale skoro USB-Blaster chodzi, to nie ma sensu bo go już mam...
No to gratulacje. Czy nie miałeś żadnych niespodzianek? Wszystko działało jak trzeba? Czego Ty używałeś do source level debugging?
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
Wpadł mi właśnie w oko również ColdFire/Freescale. Co myślicie? Np. MCF52230CAF60
W dniu 2010-11-17 23:58, Pszemol pisze:
Tak.
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.
Prawdopodobnie tak. Z tego co widać w internecie to USB Blaster jest oparty na ftdi.
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.
Użytkownik "Pszemol" snipped-for-privacy@PolBox.com napisał w wiadomości news: snipped-for-privacy@poczta.onet.pl...
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.
no to już jest sensowne podejście.
e.
Użytkownik "Piotr "Curious" Slawinski" snipped-for-privacy@bwv190.internetdsl.tpnet.lp> napisał w wiadomości news:4ce498d3$0$21001$ snipped-for-privacy@news.neostrada.pl...
zawsze będzie jakieś nowe zastosowanie, chyba że się Kolega z branży wycofa :)
przy milionie sztuk.
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.
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...
:-)
Użytkownik "Pszemol" snipped-for-privacy@PolBox.com napisał w wiadomości news: snipped-for-privacy@poczta.onet.pl...
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.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.