Forum: Mikrocontroller und Digitale Elektronik PICkit2 und XLP


von Christian H. (netzwanze) Benutzerseite


Lesenswert?

Ich arbeite bisher mit AVR, finde aber für einige Projekte die XLP-Pics 
sehr interessant.

Ich bin gerade dabei, mich etwas schlauer zu machen, komme durch den 
Dschungel aber nur schwerlich voran.

Meine Frage ist erstmal, welcher Programmer für die XLP-Pics geeignet 
ist. Er muss ja 3,3V können. Ist da der PICkit2 (oder 3) geeignet? Oder 
gibt es da bessere Varianten, die nicht zu sehr ins Geld gehen. 180€ für 
einen MPLAB ICD 3 sind mir zu viel. Später vielleicht.

Ach ja, ich arbeite hauptsächlich unter Linux bzw Mac. Ich möchte für 
das Programmieren der Pics nur ungerne auf Windoof wechseln (habe ich 
zwar auch noch, müsste aber umbooten).

Ich möchte möglichst in C programmieren, da ich aus der 
Assemblerprogrammierung mittlerweile knapp 20 Jahr raus bin.

von Sascha F. (sascha_focus) Benutzerseite


Lesenswert?

Hallo,

PICKIT2 geht auch. Sehr günstig, da Clone inkl. Versand ca. 22€
Taugt auch für 3.3V typen. Ansonsten unter den Supported Devices 
schauen, da teilweise mit der PICKIT Software welche gehen, aber unter 
MPLAB nicht.

Gruß Sascha

von Joe (Gast)


Lesenswert?

Hallo Christian,

ich finde es interessant, für welche Projekte siehst Du den XLP besser 
geeignet?

Danke für die Info!

von Christian H. (netzwanze) Benutzerseite


Lesenswert?

Joe schrieb:
> ich finde es interessant, für welche Projekte siehst Du den XLP besser
> geeignet?

Ich habe nichts von "besser" gesagt ;-)

Mich interessiert vor allem der Stromverbrauch im PowerDown-Mode (20nA 
XLP gegenüber 100nA zB Tiny44). Werte laut Datenblatt!

Also speziell für batteriebetriebene Geräte die nur einmal pro Minute 
kurz aufwachen müssen (Sensoren).

Oder (ketzerische Frage) gibt es bei AVR ähnliches?

von stephan_ (Gast)


Lesenswert?

Bei www.sprut.de gibt es Brenner, die können 5- und 3.3-Volt-PICs 
brennen.

Ich habe den Brenner8P9smd von Lars und bin sehr zufrieden. Der 
Brenner9L sieht auch sehr interessant aus, weil er sehr einfach 
aufgebaut ist und mit einer einseitigen Platine auskommt. Das hat man in 
einem Abend fertig, den LF-PIC bekommt man bei Farnell.

http://www.sprut.de/electronic/pic/projekte/brenner8/index.htm#smd8p9

von Christian H. (netzwanze) Benutzerseite


Lesenswert?

stephan_ schrieb:
> Ich habe den Brenner8P9smd von Lars

Dort steht "Dadurch kann dieser SMD-Brenner nach einfachem Tausch der 
Firmware auch 3,3V-PICs brennen".

Ist das bei jedem Wechsel 5V auf 3,3V oder zurück notwendig?
Oder wie ist das gemeint?

von stephan_ (Gast)


Lesenswert?

jede Spannung hat ihre eigene Firmware ... leider. Das liegt daran, dass 
der Brenner die Programmier-Spannungen durch einen kleinen step-up 
erzeigt, der durch den PIC per PWM gesteuert wird. sprut ist aber recht 
erfinderisch, vielleicht kriegt er das auch noch hin.

Die XLP-PICs brauchen übrigens auch im SLEEP-Modus meistens doch mehr 
mehr Strom als 20nA: wenn z.B. der Timer1 (zum Aufwecken) läuft, dann 
sind es beim PIC18LF14K22 doch wieder 650nA, aber nur bei 1.8 Volt und 
nur bei den LF-Typen. Aber interessant finde ich die Technologie 
trotzdem.

von stephan_ (Gast)


Lesenswert?

noch etwas zum PICKit2: es gab schon mehrere Bericht hier, dass neue 
Typen nicht mehr unterstützt werden, könnte also ein Auslaufmodell sein 
???

von gerd_meier (Gast)


Lesenswert?

Die Brenner von sprut sind auch insofern interessant, als es dafür ein 
Brennprogramm für Linux gibt. Das suchst Du doch.

von Joe (Gast)


Lesenswert?

Christian H. schrieb:
> Joe schrieb:
>> ich finde es interessant, für welche Projekte siehst Du den XLP besser
>> geeignet?
>
> Ich habe nichts von "besser" gesagt ;-)
>
> Mich interessiert vor allem der Stromverbrauch im PowerDown-Mode (20nA
> XLP gegenüber 100nA zB Tiny44). Werte laut Datenblatt!
>
> Also speziell für batteriebetriebene Geräte die nur einmal pro Minute
> kurz aufwachen müssen (Sensoren).
>
> Oder (ketzerische Frage) gibt es bei AVR ähnliches?


Naja nicht direkt, ich wollt auf etwas anderes hinaus.

Ob 20nA oder 100nA ist meiner Meinung nach völlig unerheblich, denn zum 
einen ist jede Batterie Selbstentladung deutlich höher,
zum anderen ist der Ausdruck Sleep Mode hier etwas übertrieben, denn der 
PIC ist absolut aus, nichts läuft oder arbeitet. Keine SRAM retention, 
nur eine Mimik sorgt dafür, dass Pegelwechsel an dedizierten Portpins
das System hochfahren können.

Z.B dauert das dann "ewig", der dann auch neu gebootet werden muß. Diese 
zeit hat kaum eine Anwendung, denke ich (außer wenn dein 
batteriebetriebenes überwiegend wochenlang im Schrank verbringt).

Für mich wären also die 20nA
-ist in der Praxis irrelevant
-ist aber ein eye-catcher und damit sicher geeignet, das Augenmerk der 
Entwickler wieder auf die PICs zu lenken.
-die wirklich wichtigen Werte sind:
32kHz on, WDT on , BOD on ( "power-save" beim AVR ), und Power-Down mit 
WDT und BOD aktiviert.

von John (Gast)


Lesenswert?


von Joe (Gast)


Lesenswert?

Bisher können nur sehr wenige das, wobei der Xmega mit RTC auch die 
550nA macht. Hier hat Mchip schon gut aufgeholt, und gegen MSP430 
natürlich genauso wie der Xmega sind beide vorn.

Wo ich hier ein bisschen zögere ist, dass man bei MChip dank des "neuen" 
Prozesses scheinbar nun auch die Probleme bekommt die man bei Atmel 
kennt, das die Oscillator "Genauigkeit" schon auch mal bei +/-5% liegt, 
was den PIC User nicht freuen wird.

Flash Endurance von 1k Cycles bei VDD>3V (siehe Erratas) ist auch nicht 
sexy oder?

Core Compatible ist man mit dem neuen Extended Core auch nicht mehr (das 
war ja immer ein Vermarktungs-Argument bei Mchip, das alles beim Alten 
bleibt).
Ich denke mal der neue STM8 (und bei den 32Bittern der neue RX von 
Renesas) wird da in Zukunft mehr bieten können (hab mir sagen lassen, 
der hat eine 16Bit PWM ...und schöne Preise).

Grüße
Joe

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.