PICKIT2 / ICD3 probleempje

Goedemiddag allen,

Ik ben hier tegen een heel raar probleem aangelopen.
Voor een printje gebruik ik de PIC16F913. ik weet het, een hele simpele controller, maar hij voldoet.
Op de print zitten wat IO voor lampjes, schakelaars, buzzertjes en zo voort. Ook zit er een debug heartbeat op en wat ledjes die de mode van de print aangeven.

Als ik de 913 programmeer met de pickit start de pcu soms met een deel uitgaande pinnen hoog. Lampjes staan aan, buzzers piepen alsof alle routines die de pinnen aansturen tegelijk aan staan. Het gekke is echter dat de heartbeat wel keurig blijft knipperen. Ook de ledjes die de functie aangeven schakelen goed mee met de functie waarin de cpu staat.
Schakel ik de voeding even kort uit en weer aan, probleem opgelost.

Nu komt het gekke.
Programmeer ik de zelfde print met de ICD3, dan werkt alles gewoon goed.
Programmeer ik hem vervolgens weer met de pickit, dan is het weer mis.

de oplossing is dus vrij simpel, geen pickit gebruiken, maar ik wil eigenlijk weten waarom.
Heeft iemand hier ervaring mee?

RTFM, dan pas vragen...
Arco

Special Member

Er zal toch wel wat verkeerd staan ingesteld. Ik gebruik diverse pickit2/3 al heel lang, en nog nooit wat vreemds gehad.

Arco - "Simplicity is a prerequisite for reliability" - hard-, firm-, en software ontwikkeling: www.arcovox.com

Ja dat dacht ik ook.
Alleen zijn die programmers zo eenvoudig dat er eigenlijk niks verkeerd in te stellen is..

RTFM, dan pas vragen...

Misschien moet je de pinnen in de setup van je programma laag zetten, aangezien je nooit weet in welke toestand ze zich bevinden als je het programma start.

Gedaan, blijft helaas het zelfde.
Ook vreemd er aan, de buzzers zijn resonators (PWM sturing). Als die pen alleen hoog zou staan hoor je niks. Maar ze staan keurig op 1k8 de oscilleren.
Dat is dus ook het deel wat ik echt niet begrijp. Alsof de routine bij het starten wordt aangeroepen en blijft loopen.
In die routine staat toch echt een break.

RTFM, dan pas vragen...
If you want to succeed, double your failure rate.
EricP

mét CE

Ik gok op een reset probleem van je pic-ding.
De ene programmer zal het wat anders doen dan de andere. Met name timing.
Wat gebeurt er als dat pic-ding zich raar gedraagt en je doet op de hand een fatsoenlijke reset?

Gevonden!

de pickit bakt de complete hexfile in de CPU.
de MP lab programmeer omgeving filtert eventuele debug informatie en bakt die niet mee....

compiler probleempje dus..

Ik heb alle debug info er uit gehaald en nu werkt het wel goed.

RTFM, dan pas vragen...

Tja, dat had je er wel even bij mogen melden.

Als jij met je PICKIT een andere hex-file erin zet en/of een andere compiler/programmeeromgeving gebruikt als met je ICD dan is het natuurlijk geen vergelijk.

If you want to succeed, double your failure rate.

Nou Jochem, niet zo grommen.
Zelfde hex, andere programmer. Dat zou geen probleem mogen zijn.
Dat de ICD omgeving wel zo snugger is om compiler errors te filteren had ik ook niet kunnen gokken. Bij een fatsoenlijke compiler zou die debug info helemaal niet in een hex mogen belanden.

Het is en blijft microchip he ;)

RTFM, dan pas vragen...
Arco

Special Member

De pickit doet het juist goed!   Als je het debug bit aan zet in de hexfile, dan worden sommige pins dedicated for debugging gebruikt.
Een programmer moet doen en doet ook wat je vraagt, als die zelf wijzigingen aan gaat brengen is dat niet gewenst en raar.
Er wordt verwacht dat je de code en config goed maakt, het is niet aan de compiler of programmer om daarin te gaan rommelen... ;)

Arco - "Simplicity is a prerequisite for reliability" - hard-, firm-, en software ontwikkeling: www.arcovox.com
Lambiek

Special Member

Als je haar maar goed zit, GROETEN LAMBIEK.
Arco

Special Member

Het is altijd makkelijker iets af te schuiven op een ander, dan toe te geven dat je iets verkeerd gedaan hebt... :)

Arco - "Simplicity is a prerequisite for reliability" - hard-, firm-, en software ontwikkeling: www.arcovox.com
Lambiek

Special Member

Ja, dat is waar. :) Maar ik begin dat gezever over Microchip een beetje zat te worden, er is helemaal niets mis met pic-controllers.
Heb al ik weet niet hoeveel ontwerpen gemaakt rond pic-controllers en nooit problemen ondervonden, ook in de industrie niet.

Als je haar maar goed zit, GROETEN LAMBIEK.
Arco

Special Member

Wij hebben er vele duizenden gebruikt in allerlei types en nog nooit iets vreemds meegemaakt. (of het was door ons zelf veroorzaakt...)

Arco - "Simplicity is a prerequisite for reliability" - hard-, firm-, en software ontwikkeling: www.arcovox.com
Lambiek

Special Member

Zoveel heb ik er niet gebruikt, maar wel enkele honderden. :)

Als je haar maar goed zit, GROETEN LAMBIEK.
EricP

mét CE

er is helemaal niets mis met pic-controllers.

Los van dat dit topic een gevalletje PEBKAC is... Zijn er heel veel mensen die daar zeer nadrukkelijk een andere mening over hebben :+

Lambiek

Special Member

Als je haar maar goed zit, GROETEN LAMBIEK.
Anoniem

Elk merk van om het even wat heeft tevreden en ontevreden klanten.
Als hier een pic niet doet wat ik verwacht ligt het altijd aan de programmeur
en dat ben ik dan zelf dus met een foute redenering of een zwart gat in de kennis.

EricP

mét CE

Ja, van jou weten we het.

En ik ben zeker niet de enige met dat inzicht.

Als hier een pic niet doet wat ik verwacht ligt het altijd aan de programmeur

Of aan je verwachting natuurlijk :) Of aan de compiler - het zal zeker niet de eerste keer zijn dat ik een compiler op een willekeurige architectuur op een misser betrap.

Feit blijft dat de pic-architectuur vol zit met maffe kronkels. Bankswitching. RMW issues. PLL om het ding nog een beetje vooruit te laten komen. Rare quircks met timer/counters.
En ja, als je je daar goed in verdiept, dan is er wel wat werkends mee te maken. Vast wel.

Nou...
Ik heb hier nog een tray nieuwe 18F liggen die eigenlijk zo de container in kunnen.
Wanneer die warmer worden dan 35 graden gaat de ADC op de loop.
Mijn mening is niet helemaal ongegrond...

Maar eerlijk is eerlijk, ook hier enkele duizenden waar nooit een probleem mee geweest is.

RTFM, dan pas vragen...
JoWi

Special Member

Op 3 februari 2017 06:29:15 schreef EricP:
[...]En ik ben zeker niet de enige met dat inzicht.

Als ik zo'n inzicht begin jaren 80 had volgehouden (PDP/VAX/MC68000 architectuur versus de waardeloze 80x86 architectuur met al die dedicated registers) was het vast niet zo goed gegaan met mijn loopbaan.
Dus een tip: Get over it.

Ignorance is bliss
EricP

mét CE

Joh, ik heb goud geld verdiend aan re-design van pic-ding based ontwerpen naar iets fatsoenlijks - schema re-work. PCB omkrikken, software opnieuw schrijven en nu wel gewoon werkbaar. Het was niet (alleen) mijn inzicht waar mijn loopbaan aardig op draaide :)

Maar ook hier zie je hetzelfde gebeuren als met de voorbeelden die jij noemt of bijvoorbeeld OSen of videorecorders. Niet het technisch mooiste spul wint de race, maar de toko die (oa.) het meest aan marketing besteed...
Welnu, dat had men destijds aardig voor elkaar met enorme hoeveelheden gratis samples enzo!

Arco

Special Member

Of aan de compiler - het zal zeker niet de eerste keer zijn dat ik een compiler op een willekeurige architectuur op een misser betrap.

Ik heb eens heel lang moeten zoeken naar een fout. Een apparaat deed soms volslagen onverklaarbare dingen.
Zat een 68FN11 processor in van Freescale, programma was gemaakt met de originele assembler.
Na uitvlooien van de assembly listing bleek dat de assembler de LDD instructie (Load reg D) omzette in LDY (Load reg Y)...
Iets wat je ook niet echt verwacht... :)

Vergelijken van oude processoren heeft trouwens weinig nut. De nieuwe PIC's als de 24F laten eigenlijk niets meer te wensen over.
Bankswitching had Atmel ook in hun 8051 processoren, niet echt fijn. Maar daar heb je eigenlijk alleen last van in assembly.

Arco - "Simplicity is a prerequisite for reliability" - hard-, firm-, en software ontwikkeling: www.arcovox.com
EricP

mét CE

Na uitvlooien van de assembly listing bleek dat de assembler de LDD instructie (Load reg D) omzette in LDY (Load reg Y)...
Iets wat je ook niet echt verwacht... :)

Die zijn 'leuk' inderdaad. En dan maar hopen dat je disassembler niet dezelfde fout maakt, anders zoek je je echt een ongeluk... Er was een tijd dat ik 6502 opcodes kon lezen. Gelukkig ligt dat achter me - is niet gezond :+

Bankswitching had Atmel ook in hun 8051 processoren, niet echt fijn. Maar daar heb je eigenlijk alleen last van in assembly.

Bankswitching is hoe dan ook een hork van een oplossing - of het nou een pic-ding, een 8051 of een 8086-achtig-iets is. Maar ja, als je uit het jasje van je architectuur groeit (cq. die is veel te beperkt bedacht), dan moet je wel eens wat.
Deze misser kun je Atmel niet echt verwijten - zij maken alleen maar een soort van kloon van wat Intel ooit verzonnen heeft. Je kunt dan wel dat recht gaan trekken, maar daar gaan geen software meer op lopen (tenzij je alles nieuw maakt) en geen compiler meer mee werken. Feitelijk geen 8051 meer dus...
Alleen last van in assembly? Niet altijd. Ook in C kan je er aardig mee voor gaas gaan omdat bepaalde constructies opeens een stuk 'duurder' worden dan verwacht. Zeker als het iets repeterends is kan het pijn doen.

Het zou kunnen dat die 24F serie eindelijk eens wat fatsoenlijker in elkaar zit. Ik heb het wel gehad met microchip-ontwerpen. M'n neus hard gestoten met die pic-dingen (en snel de hoek weer in geschopt), paar keer op m'n m**l gegaan met memory wat z'n specs niet bleek te halen (ja, 2 maanden later was er een errata note van en nog een paar maanden later een revision die het wel goed deed... heb ik wat aan). Temp sensor die rottigheid bleek te bevatten. En als je nou TS ook weer ziet met z'n ADCs die het alleen onder strikte randvoorwaarden doen... Laat maar...
Ohja... immitatie uit China? Ik kan het niet verifiëren. Maar ik acht het bij toko's als Farnell en Digikey niet waarschijnlijk...