De 12f675 is een 8 pin obsoleet bestempelde PIC, programeerbare logica, van microchip. De opvolger 12f683 kan meer met dezelfde pinning. Het mooie is dat het een 10bit AD converter bezit.
Met een PICkit3 kun je, met MPLAB X maximaal versie 6.20, hem programmeren, simuleren en debuggen.
Bij debuggen zijn er echter 3 (clock,data,reset) van de 6 pins (+2 pins voor voeding) nodig zodat je er eigenlijk niet veel aan hebt.
Dus wat gaat erom in zo'n 12f675 als hij eenmaal geprogrammeerd is en niet doet wat hij moet doen.
Veelal wordt 1 pin gebruikt als ingang voor een button schakelaar. Deze 1 pin (stel GP1) kunnen we tijdelijk misbruiken voor een trace routine, zie tracer.txt.
In de routine is GP1 de pin die we eerst tot output maken en aan het eind weer tot ingang maken. Tijdens de routine wordt er een patroon gestuurd naar GP1. De routine wordt tijdens het programma op verschillende plekken aangeroepen zodat we, met een digitale scoop aangesloten op pin GP1, kunnen tracen wat er gebeurt .
Het zou mooi zijn als we bijv. met een arduino nano het patroon kunnen omzetten naar zinvolle informatie op een pc.
Weet iemand of zoiets al bestaat.
char k=0;
char l=0;
void trace(char K , char L) // voor debugging / K aantal perioden / L duur
{
TRISIO=0b00011100 ; //GP1 temp output
GP1=0;
__delay_us(500);
for (k=1;k<=K;k++)
{
GP1=1;
for (l=1;l<=L;l++) __delay_us(10);
GP1=0;
for (l=1;l<=L;l++) __delay_us(10);
};
GP1=1;
__delay_us(500);
TRISIO=0b00011110 ; //GP1 is weer input
}
[Bericht gewijzigd door Henry S. op (16%)]
SparkyGSX
Een manager is iemand die denkt dat negen vrouwen in één maand een kind kunnen maken
Plak je hier nou je CrapGPT output? Wat wil je nou van ons?
SparkyGSX
Een manager is iemand die denkt dat negen vrouwen in één maand een kind kunnen maken
Maar wat is je vraag nou? Je wilt de bitjes die je zelf verstuurt ergens mee opvangen en doorsturen, maar waarom stuur je ze niet gewoon op de snelheid van een normale seriële poort met start en stop bits, zodat je het met een normale seriële poort kunt ontvangen?
Eigenlijk is de vraag bestaat er een debugger voor de 12f675 die niet gebruik maakt van clock data reset lijnen en dan bedoel ik niet een dure Microchip oplossing met een adapter die er tussen in gaat zitten.
De 12f675 heeft geen uart. Het is niet enkel doorsturen maar je moet ook een programma hebben die het fatsoenlijk bruikbaar weergeeft. De arduino heeft een uart en dient als eerste tussenlink tussen de pic en de pc en kan op volle snelheid volgen wat er op GP1 pin gebeurt. Op de pc draait dan een programma die de patronen omzetten in bijv. grafische data zodat je kan zien wat er speelt.
Een variabele kan bijv. weergegeven worden als een bar die van lengte veranderd.
Een while loop wordt een cirkel. Welke procedure roept wie aan in welke volgorde (tracen).
Het geheel is er enkel voor om een fout in je programma op te sporen, niet als luxe ondersteuning van wat de pic moet doen.
Dan neem je een pic die wel een uart heeft, dan kun je direct met de pc communiceren.
Kijk hier eens naar.
Of je bit-banged een uart
SparkyGSX
Een manager is iemand die denkt dat negen vrouwen in één maand een kind kunnen maken
Ja dat zei ik, want je hoeft toch niet te ontvangen, maar dat je data kunt versturen zonder UART is nog niet helemaal ingedaald geloof ik. Je hoeft er alleen één startbit, één of twee stop bits, als je het echt fancy wilt doen (nergens voor nodig) een parity bit aan toe te voegen, en zorgen dat de bitrate klopt.
[Bericht gewijzigd door SparkyGSX op (39%)]
Profilab is een mooi programma kost ongeveer 100 Euro en dat is het wel waard.
De grap is juist een simpele pic te gebruiken die heeft dus geen uart en als die dat heeft gaat dat ten koste van tenminste 2 pinnen. Gebruik ik één met meer pinnen dan kan ik ook de debugger van de PICkit3 gebruiken.
Ik maak het mij zelf onnodig moeilijk door een te simpele pic te gebruiken maar ik vind die 12f675 gewoon leuk.
Ik dacht er bestaat wel iets met een arduino als debugger maar iedereen gebruikt gewoon een 18 pin dip oid.
Ik kom nog terug met een simpel ontwerp die ik eerst met een 16F628A wou doen, foutieve print had ik al.
Ik heb daar nu de 12F675 opgezet met heel veel extra draden en spooronderbrekingen.
Ik wou graag de AD converter gebruiken maar dat lukt nog steeds niet naar tevredenheid.
Het was makkelijker geweest met de comperator module en een 12F683 met pwm en eigenlijk de 16F628 omdat ik die al heb en niet hoef te kopen.
SparkyGSX, ja dat zou een oplossing zijn 1 lijn naar buiten via com1 moet dan nog wel het één en ander geprogrammeerd worden en profilab zou dat meteen kunnen verwerken.
Oh ik zie wel een probleem profilab komt enkel in windows, misschien dat wine werkt.
Iedereen bedankt.
Op dinsdag 18 augustus 2026 21:13:08 schreef Sine:
Of je bit-banged een uart
Dat is ook de mode die ik gebruik bij kleine picjes, gewoon ascii tekst bit-bangen.
Arco
Special Member
Arco - "Simplicity is a prerequisite for reliability" - hard-, firm-, en software ontwikkeling: www.arcovox.com
Een Pic 12F1571 of 72 is een stuk nieuwer, kan veel meer, en is een stuk goedkoper...
Is ook een 8 pinner...
@nonius Ja de HP4957A is het helemaal. Maar het grafische gebeuren ontbreekt. Misschien kun jij de firmware even aanpassen en de rest zoals smilies in pixel vorm. 
Ik kan natuurlijk mijn eigen protocol bedenken los van de uart communicatie.
Eerst maar eens afwachten wat profilab brengt. Hoe ik mij daar moet aanpassen.
Voorlopig gebeurt er niets want ik heb nog genoeg te doen.
@Arco Ja de PIC12F1572 is het helemaal (hmm zei ik ook al bij de HP, maar dit keer echt) AD en veel meer geheugen en stuk goedkoper.
En Henry S bedankt, maakt het allemaal wat makkelijker om te verteren.
Arco
Special Member
Arco - "Simplicity is a prerequisite for reliability" - hard-, firm-, en software ontwikkeling: www.arcovox.com
Hij is ook (zelfs op dezelfde clocksnelheid) veel sneller als je veel interrups gebruikt.
Bij de oudere pics moest je context save/restore doen (kost vele instructiecycles)
De 1572 en alle pics met enhanced instructieset (type begint met 1xxx) doen dat automatisch zonder extra instructiecycles.
Ik heb zelf eens een biepje geschreven met macro's die "uart achtige" data uitspuugt. Die kun je dan eenvoudig vangen in een logic analyzer.
#ifdef DEBUG_PORT
// Just to make sure the user knows the debug code is inserted.
// Higher optimisation levels disrupts the timing for debugging.
// #warning Debug code inserted. Use optimisation level: -O1.
// Use this macro to enable the debug output pin.
#define DEBUG_OUTPUT_ENABLE DEBUG_SET, (DEBUG_DDR |= DEBUG_BIT)
#define DEBUG_SET (DEBUG_PORT |= DEBUG_BIT)
#define DEBUG_CLEAR (DEBUG_PORT &= ~DEBUG_BIT)
#define ON_OFF_BIT(X,Y) ((X) &(0x01 << (Y)) ? (DEBUG_SET) : (DEBUG_CLEAR))
#define DEBUG_SLOW
#ifdef DEBUG_SLOW
#define ON_OFF_SLO(X,Y) ((X) &(0x01 << (Y)) ? (DEBUG_SET) : (DEBUG_CLEAR))
#else
#define ON_OFF_SLO(X,Y) asdfg
#endif
// Startbit, a bunch of data bits and a stop bit.
#define DEBUG(X) ( \
DEBUG_CLEAR, \
DEBUG_CLEAR, \
DEBUG_CLEAR, \
ON_OFF_BIT( X, 0), \
ON_OFF_SLO( X, 0), \
ON_OFF_SLO( X, 0), \
ON_OFF_BIT( X, 1), \
ON_OFF_SLO( X, 1), \
ON_OFF_SLO( X, 1), \
ON_OFF_BIT( X, 2), \
ON_OFF_SLO( X, 2), \
ON_OFF_SLO( X, 2), \
ON_OFF_BIT( X, 3), \
ON_OFF_SLO( X, 3), \
ON_OFF_SLO( X, 3), \
ON_OFF_BIT( X, 4), \
ON_OFF_SLO( X, 4), \
ON_OFF_SLO( X, 4), \
ON_OFF_BIT( X, 5), \
ON_OFF_SLO( X, 5), \
ON_OFF_SLO( X, 5), \
ON_OFF_BIT( X, 6), \
ON_OFF_SLO( X, 6), \
ON_OFF_SLO( X, 6), \
DEBUG_SET \
)
#else#ifdef DEBUG_PORT
// Just to make sure the user knows the debug code is inserted.
// Higher optimisation levels disrupts the timing for debugging.
// #warning Debug code inserted. Use optimisation level: -O1.
// Use this macro to enable the debug output pin.
#define DEBUG_OUTPUT_ENABLE DEBUG_SET, (DEBUG_DDR |= DEBUG_BIT)
#define DEBUG_SET (DEBUG_PORT |= DEBUG_BIT)
#define DEBUG_CLEAR (DEBUG_PORT &= ~DEBUG_BIT)
#define ON_OFF_BIT(X,Y) ((X) &(0x01 << (Y)) ? (DEBUG_SET) : (DEBUG_CLEAR))
#define DEBUG_SLOW // Make it slower for STM32.
#ifdef DEBUG_SLOW
#define ON_OFF_SLO(X,Y) ((X) &(0x01 << (Y)) ? (DEBUG_SET) : (DEBUG_CLEAR))
#else
#define ON_OFF_SLO(X,Y) asdfg
#endif
// Startbit, a bunch of data bits and a stop bit.
#define DEBUG(X) ( \
DEBUG_CLEAR, \
DEBUG_CLEAR, \
DEBUG_CLEAR, \
ON_OFF_BIT( X, 0), \
ON_OFF_SLO( X, 0), \
ON_OFF_SLO( X, 0), \
ON_OFF_BIT( X, 1), \
ON_OFF_SLO( X, 1), \
ON_OFF_SLO( X, 1), \
ON_OFF_BIT( X, 2), \
ON_OFF_SLO( X, 2), \
ON_OFF_SLO( X, 2), \
ON_OFF_BIT( X, 3), \
ON_OFF_SLO( X, 3), \
ON_OFF_SLO( X, 3), \
ON_OFF_BIT( X, 4), \
ON_OFF_SLO( X, 4), \
ON_OFF_SLO( X, 4), \
ON_OFF_BIT( X, 5), \
ON_OFF_SLO( X, 5), \
ON_OFF_SLO( X, 5), \
ON_OFF_BIT( X, 6), \
ON_OFF_SLO( X, 6), \
ON_OFF_SLO( X, 6), \
DEBUG_SET \
)
#else
// Preprocessor removes debug statements.
#define DEBUG_OUTPUT_ENABLE
#define DEBUG(x)
#define DEBUG_SET
#define DEBUG_CLEAR
#define ON_OFF_BIT(X,Y) // This one is not meant for external use.
#endif
// Preprocessor removes debug statements.
#define DEBUG_OUTPUT_ENABLE
#define DEBUG(x)
#define DEBUG_SET
#define DEBUG_CLEAR
#define ON_OFF_BIT(X,Y) // This one is not meant for external use.
#endif
Super simpel biepje, maar ik vind het een erg nuttig stuk debug gereedschap. Elke DEBUG() genereert slechts een handvol ASM instrukties, dit maakt het snel genoeg om ook in ISR routines gebruikt te worden met minimale invloed op de snelheid van het hoofd programma. Met de logic analyzer kun je andere data invangen tegelijkertijd met deze "trace", en daarmee kun je dingen vergelijken en correleren. Omdat de Logic Analyzer data vangt in de achtergrond, kun je ook heel gemakkelijk data vangen tot er een fout optreed, en dan terug scrollen om te kijken welke code uitgevoerd werdt voordat de fout zichtbaar werdt door de buitenwereld. En je kunt het hele ding uit zetten met een enkele #define. (& hercompileren).
Verder ben ik grotendeels afgestapt van code schrijven en debuggen op een klein processortje. Ingewikkelde funkties schrijf en debug ik eerst op en PC. Dan kun je b.v. gemakkelijk grote hoeveelheden data in een tabel printen om te kijken of dingen goed werken, code toevogen om het programma zelf te controleren, enz.
Ook is het veel handiger om een grotere microcontroller te gebruiken. Door i.p.v. het biepje hierboven een "reserve" uart of SPI poort te gebruiken, kun je de data naar buiten spugen door een enkele byte naar een UART of SPI randappraat te schrijven. Daarmee heeft de debug code nog minder invloed op de timing, en is ook veel minder afhankelijk van optimalisatie van de compiler.
Ik heb dit biepje origineel geschreven voor AVR. Later aangepast voor STM32 ("Extra langzaam", om de data nog gemakkelijk te kunnen vangen met een EUR 10 Logic Analyzer en Sigrok / Pulseview). Maar omdat het gwoon C code (macro's) is, is het gemakkelijk om te zetten naar elk platform wat met C werkt.
Op dinsdag 18 augustus 2026 23:21:44 schreef Arco:
Een Pic 12F1571 of 72 is een stuk nieuwer, kan veel meer, en is een stuk goedkoper...
Of een chipje EUR 2 meer of minder kost is niet relevant. Dat verdien je terug met een half uur hobby tijd, zelfs als je vind dat je eigen tijd bijna niets waard is. Ik snap helemaal niets van die mensen die een 8 pins uC gebruiken (maar wel in DIP, want anders kunnen ze de pootjes niet meer zien), en dan een schuifregister toe gaan voegen omdat ze te weinig I/O hebben. Zolang een uC bordje onder EUR 10 blijft, dan vind ik het wel best voor hobby en lage aantallen.
Ja zover ben ik allemaal nog niet.
Mijn eerste toepassing is zonder interrupts maar met polling.
Kost allemaal onnodig meer tijd maar de taak laat dat toe..
benleentje
Golden Member
Dus wat gaat erom in zo'n 12f675 als hij eenmaal geprogrammeerd is en niet doet wat hij moet doen.
Heb je hem zelf geprogrammeerd en heb je zelf dat programma of zit het ergens in maar heet sniffen toch weinig zin als je niet weet wat het hoort te doen?
@Kortsluiting_Online
Bedankt voor je input.
Voert mij nog even te ver ,gaat mijn kennis te boven, om het programma (macro) te doorgronden.
Ik zal met een timer ook voor de baudrate moeten zorgen. Is elke bit 1 instructie lang?
Ik zie een 7 bit treintje dat is aan te passen naar 8.
DEBUG(X) wordt dan de routine? waarbij X van type char kan zijn.
Wat is die asdfg een test, marker, routine.
@benleentje
Programma is van mijzelf. Een steppermotor wordt via een driver aangestuurd.
Ik wil met de AD weten hoeveel stroom er loopt zodat als de stepper vastloopt een buzzer gaat klinken.
De AD wordt ook nog gebruikt om de positie van een potentiometerloper te bepalen die de positie weergeeft.
Op de 1 of andere manier gaat de buzzer vaker af dan moet.
Ik denk dat ADRESL van de ene meting bij de andere terecht komt.
Programma is klein en ik weet dat jij of iemand anders ook een driver programma gemaakt hebt.
Het heeft allemaal te maken met een eigenwijze deuropener.
[Bericht gewijzigd door Bart777 op (42%)]
Programma is van mijzelf. Een steppermotor wordt via een driver aangestuurd.
Ik wil met de AD weten hoeveel stroom er loopt zodat als de stepper vastloopt een buzzer gaat klinken.
De AD wordt ook nog gebruikt om de positie van een potentiometerloper te bepalen die de positie weergeeft.
Dit is beiden ongebruikelijk.
Veranderd die stroom daadwerkelijk? Het is niet mogelijk de stappen te tellen?
Op woensdag 19 augustus 2026 00:22:01 schreef Bart777:
Ik wil met de AD weten hoeveel stroom er loopt zodat als de stepper vastloopt een buzzer gaat klinken.
Een stappenmotor is zelf al een buzzer als hij vast loopt.
En een stappenmotor trekt niet veel meer stroom als hij vast loopt, tenzij het een closed-loop stappenmotor is. Anders zal het moeilijk te detecteren zijn denk.
Arco
Special Member
Arco - "Simplicity is a prerequisite for reliability" - hard-, firm-, en software ontwikkeling: www.arcovox.com
Stroomverbruik is zoals gezegd geen goede leidraad of de stepper wel/niet beweegt, dat verandert nauwelijks.
Daarvoor zul je een positiesensor moeten gebruiken.
Of de back-emf testen, die verandert behoorlijk (wordt bijna nul) bij een 'stall'.
Ik heb dat ooit willen gebruiken, maar nooit aan toe gekomen.
(werkt ook met solenoids bij aantrekken, maar daar kun je ook de inductie testen...)
https://mechtex.com/blog/understanding-back-emf-in-stepper-motors
@Aart
De stroom neemt ongeveer met 10% toe bij afremmen met de hand.
Complete stilstand niet geprobeerd maar zal zeker 15% zijn. Op zich zorgt de driver ervoor dat stromen gelimiteerd worden maar toch zie je wel verandering.
Positiebepaling is eigenlijk niet nodig met 2 eindschakelaars. Vond het toch leuk om positie te bepalen.
Ik hoef de stappen niet te tellen wat ik forceer ze, leg het op.
Wat een goede indicatie zou zijn is (verandering positie)/(aantal steps) maar dan moet de mechanica ook al af zijn.
@Lambiek
Ik wil eigenlijk ook al een indicatie hebben als het stroef loopt. Meestal een opmaat voor niet functioneren.
Het is mij nog niet gelukt afremming te detecteren maar er zit een "foutje" in de software. Wat ook niet meehelpt is dat de driver enorme spanningsstoring geeft met vele pieken op het meetsignaal.
@Arco
Allemaal leuk en aardig maar zeggen er niet bij hoe je die back EMF meet.
De driver zet een vaste spanning (ga even uit van full step) over een spoel. Aan die spanning zien we dus niets. Er gaat een stroom lopen die normaal lineair toeneemt via U=L*dI/dt. Door de back EMF en weet ik wat meer wordt die lineariteit doorbroken en krijgen we meer een exponentiele curve zoals bij ontladen van een condensator. Aan die curve zou je dus wat moeten aflezen.
Wat wel goed blijkt is dat willen we een bepaalde omwenteling snelheid halen er een minimale spanning nodig is om de EMF te compenseren
Ik zal vanavond nog het gehele gebeuren met een nieuwe post, schema, programma, verduidelijken..
[edit]
Excuses. Ik vergiste mij hier
Natuurlijk is er ook bij microstep drivers wel een en ander in de stroom te zien. Want het benodigde vermogen is kleiner als er geen tegen EMK is.
[Bericht gewijzigd door Aart op (79%)]
benleentje
Golden Member
Allemaal leuk en aardig maar zeggen er niet bij hoe je die back EMF meet.
Daar is genoeg over te vinden. Maar ergens is het gewoon een spanning die op een niet aangestuurde spoel komt te staan vaak dan een simpel laag doorlaat filter en dan naar een adc ingang wel nog wat diode toevoegen als de spanning te hoog kan worden.