Pic simulator IDE

Ik werk al meer dan 20 jaar met microcontrollers, maar ik heb nog nooit een simulator gezien of gebruikt, en ik zie het nut er ook niet van in, aangezien je de microcontroller niet los kan zien van zijn omgeving.

Ik gebruik visual studio (voorheen devcpp) om algoritmes te testen en debuggen, en verder JTAG debuggers op de echte hardware.

Wat wil je met een simulator doen wat niet veel beter kan met echte hardware?

Misschien eea in VmPlayer draaien en een nieuwe installatie aanmaken wanneer de trial-periode voorbij is? Wel een beetje valsspelen natuurlijk...
Ik zelf heb de simulator geregistreerd, was niet zo heel duur maar ben eigenlijk helemaal naar Arduino over. Wel moet ik zeggen dat PicSim een paar dingen heeft die erg mooi/makkelijk/handig zijn.

Zelf gebruik ik dat ook niet. Als de hardware klaar is kun je daar prima mee testen, ik vind het ook een hoop gedoe om het eerst in een simulatie helemaal op te zetten.

Real Pic Simulator.
<Top of the bill> voor Simul denk ik.

Relatieve PIC-noob hier, maar: wat kan dat programma wat het simuleren van het programma in MP-LAB niet kan?

Ik ga wat betreft de hardware met alle anderen mee: software is 1, hardware is twee en dat weer simuleren (en dus eerst opzetten) zou mij ook teveel werk zijn. Zeker bij dat soort enorm complexe controllers gaan er (naar mijn mening) ook teveel omgevingsvariabelen meespelen.

Proteus Professional is ook een veelgebruikte tool en als je wat thuis bent op het inet is daar makkelijk aan te geraken.

Ik kom al bijna depressief als ik een schema moet tekenen in Splan laat staan van zo'n simulatie te maken

Geef mij maar een prikbord, veel beter

Op 12 maart 2023 15:24:05 schreef SIMUL:
Zie hier wel gratische staat maar met tijd van gebruik .

Als er een tijdsduur bijstaat dan is enkel gedurende die tijd gratis te gebruiken, maar zullen er ook vaak restricties zijn zoals bv grote van het programma, of dat je niet op kan slaan.

Dus uiteindelijk niet gratis.

Er is sinds kort een FPGA simulator voor op de raspberry pi PICO. Dat is echte "hardware", dus dan heb je pootjes om met de omgeving te kunnen communiceren.

Het lijkt even leuk als je NET begint om een simulator te hebben waarmee je naar de "interne state" van de processor kan kijken. Maar al heel snel wil je communiceren met echte hardware. Op een ding als de raspberry pi zou dat een geinige applicatie zijn, maar voor de rest is het niet zo nuttig.

Omdat er zowiezo snel "interactie met de omgeving" bijkomt, wil je dus je boel kunnen debuggen in het circuit waar je het gaat gebruiken. Vroeger (40 jaar geleden) had je dan een "ICE" een In Circuit Emulator. Die pretendeerde naar het circuit dat ie je CPU was, maar kon je vanaf de aangesloten PC dus stoppen starten en meer van dat soort dingen.

Dat is zo nuttig gebleken dat men dat tegenwoordig gewoon in iedere CPU inbouwt: Je kan met een extern paar draadjes de CPU starten, stoppen en bekijken. Het enige wat je nodig hebt is een debug probe van een paar tientjes.

Bij een FPGA is het juist weer precies andersom, daarbij wil je juist interne signalen kunnen volgen, wat met echte hardware moeilijk gaat (al is Chipscope wel handig af en toe). In die wereld is het juist wel heel normaal om simulators te gebruiken, maar dat maak je dan ook eerst een testbench voor, die inputs genereert en eventueel de output controleert.

Simuleren op een RasPi lijkt me vrij zinloos, aangezien die vele malen langzamer zal zijn, en het systeem er omheen dus ook op een totaal andere tijdschaal zal moeten werken.

De simulator voor de C64 op Raspberry pi draait sneller dan realtime. Voor een AVR lijkt me dat je een vergelijkbare performance kan hopen te halen.

Ik heb een softcore AVR in een (toen goedkope) FPGA gestopt. En dat draaide sneller dan de echte hardware. Ik gebruik sommige van m'n AVRs op 8MHz, dus met een 800MHz ARM heb je ongeveer 100 instructies om 1 instructie van de AVR te emuleren. Ziet er haalbaar uit.

Als je dan "linux" aan laat staan kan je interrupts verwachten waardoor je realtime eigenschappen van de AVR mogelijk wat verloren gaan. Dan moet je met prioriteiten gaan spelen en dergelijke om het te perfectioneren. Maar als je een ledje wil laten knipperen dan kom je zonder ook al een heel eind. En bij protocollen als "SPI" is een delay in het midden van een bitje van 20ms niet eens een probleem.

IK gebruik codelite om voor de PC C++ code te schrijven. daarin zit ook een soort simulator debugger. Het is soms wel handig om te weten hoe C/C++ iets op de achtergrond doet en om te zien dat een procedure ook echte zijn eigen scope aan variabelen heeft en na als dat klaar is dat het ook weer eg is. Maar voor het debuggen van een Arduino heb ik dat nog nooit nodig gehad dan gebruik is wel de seriele monitor of een led.
Toch kan het wel leuk en handig zijn als je echt nieuwsgierig bent in hoe het intern in de microcontroller werkt om dat te simuleren. Als je doel dus niet is om een werkend programma te schrijven maar is om te leren hoe in microcontroller intern werk is een simulator wel een goed hulpmiddel

Op 12 maart 2023 21:11:33 schreef rew:
De simulator voor de C64 op Raspberry pi draait sneller dan realtime.

Maar een C64 nadoen is toch wel iets anders dan een FPGA. Ik gebruik een dikke server die 30 seconden werk heeft om 30ns van een (weliswaar erg grote) FPGA te simuleren.

En bij protocollen als "SPI" is een delay in het midden van een bitje van 20ms niet eens een probleem.

Alleen als je de master bent.

Iedereen hartelijk dank .
Heb eens de trial versie gebruikt en meen ook te weten dat deze traag de waardes aan neemt .van de schakeling .
Dus schakeling maken op breadbord en testen en programmeren lijkt mij ook het beste .

Ik heb een simulator ook nog nooit gebruikt, voor 'real-life' taken klopt dat toch meestal niet.
(het is meestal niet mogelijk om de juiste input te genereren, of dat duurt veel te lang, een 'echte' schakeling is sneller en accurater)

Enige die ik wel eens gebruikte is MPSIM. Handig om klitische loops exact te timen...
Simuleren is ook de omgekeerde wereld: je maakt software en gaat dan kijken wat die doet... (ik weet dat vooraf al... )

Wat veel handiger is: een seriële poort op de schakeling maken.
Dan kun je met een UART TTL-USB kabeltje bij debuggen info naar je pc sturen. (ik gebruik 115k2, kost weinig tijd)

@SIMUL: je vraagt naar een gratis versie van een programma waarin jaren ontwikkelwerk is gestoken, en dat nu een paar tientjes kost.
Sommige software kost geld, ja...

Als je met krap budget hobbiet kan je beter een goedkope USB logic analyzer, een UART TTL naar USB converter en misschien later een oscilloscoopje aanschaffen.
Mocht je die al hebben.... wat verwacht je nog voor magie van een picbasic simulator?

- edit: ik lees net dat je al tot inkeer bent gekomen. happy breadboarding! -

Voor MPSIM moest je een stimulus file aanmaken met de simulator input data (bijv. 'na xx ms wordt input 1 hoog').
Kans dat daar iets mis gaat is veel groter als in de simulatie zelf. (als je er troep in stopt, komt er ook troep uit...)