PC Programma

[velswijk]

Arjen H.

Helemaal mee eens, en een goed plan.

Mijn toekomstige toepassing is de besturing van een modelbaan, en het is heel goed denkbaar dat daarbij uiteindelijk behoefte is aan meer dan 1 I/O kaart, en het is waarschijnlijk dat die dan functioneel verschillend zullen zijn (b.v. aparte voor input, output, interrupts, etc).
In zo'n geval betekent "soortgelijkheid" een combinatie van 1 VID en diverse PIDs, die het functionele onderscheid aangeven. De voorgestelde interface zou hiermee dus rekening moeten houden.

Er zijn verder nog wel wat verbeteringen die ik zelf t.z.t. nog in de PIC zelf wil aanbrengen (b.v. synchronisatie-signalen genereren bij het wijzigen van outputs, of het ondersteunen van interrupts (die zijn tenslotte mogelijk via USB)). Dat brengt mij op de suggestie om een verzamelpunt te maken voor nuttige uitbreidingen aan de PIC, met bijdragen en adviezen van her en der, b.v. een aparte thread.

Ik moet zeggen dat ik tot dusver erg veel nut heb gehad van de discussies in dit forum. Dank aan alle contribuanten!

vr.gr.
PvE

[jiha]

Een interessante link voor wie zelf wil programmeren en met de mpusbapi.dll aan de slag wil.

http://www.comvcon.com/PICUSBDLLDemoFirmware1.html

[arjen h.]

@Jiha
Als je de link tussel url tags zet, dan kunnen we er op klikken.
Is knop Url als je een bericht aan het typen bent.

[arjen h.]

In zo'n geval betekent "soortgelijkheid" een combinatie van 1 VID en diverse PIDs, die het functionele onderscheid aangeven.

Ik ben bezig met het communicatieprotocol aan te passen. Kort samengevat:
- Elk soort type device een eigen ProgrammaID (hardcoded in de pic) zodat de pc software kan verifieren of het een juist device is (functioneel onderscheid).
- Elk device een eigen DeviceID zodat onderscheid gemaakt kan worden tussen devices met hetzelfde ProgrammaID (dit DeviceID softwarematig wel aan te passen).

Op deze manier geen gedoe met VID, PID, drivers en wat al niet meer...

Dat brengt mij op de suggestie om een verzamelpunt te maken voor nuttige uitbreidingen aan de PIC, met bijdragen en adviezen van her en der, b.v. een aparte thread.

Goed plan.

Ik moet zeggen dat ik tot dusver erg veel nut heb gehad van de discussies in dit forum.

Post ook je eigen bevindingen zou ik zeggen, kunnen wij ook weer van leren .

[pjongen]

Aansluitend op mijn eerdere opmerkingen: het viel mij wel op dat jouw testprogramma vrolijk lijkt te werken, zonder dat er een USB kaart inzit; zou daar niet op getest moeten worden (zoals ook het origineel doet)?

Antwoord: Ja natuurlijk en daar test ik ook op!!!.
Ik heb er voor de test (mijn C# versie) bewust gekozen om dan géén boodschap te geven en vrolijk te blijven wachten tot er een PIC wordt aangesloten.
Ik doe vóór iedere Send/Recieve een "Open pipes" en erna een "Close Pipes" Dat kost wat CPU tijd, maar dat heb ik over voor de flexilbiteit met testen.
Op deze manier kan ik de PIC resetten, nieuwe firmware code laden en weer aanzetten en dan loopt het programma vrolijk door, want hij pikt de PIC weer gewoon op.
Dus in feite check ik dus tijdens iedere timer interrupt, dus vóór elke bewerking of de PIC er is. Alleen geef ik geen error boodschap. Omdat ik de scans in alle versie met een timer interupt doe, blijft het programma ook niet hangen etc.

In de VB6 (en VB.NET) versies die ik in dit forum plaatste controleer ik wel of een PIC is aangesloten en doe ik één keer een openpipes en sluit de pipes pas als ik het programma sluit. Maar (zie die thread op dit forum) dat leverde dus ook commentaar op (zie daar). Tijdens het debuggen blijven de pipes open en bij herstart krijg je dan een error.

Let op het zijn test programma's.
Gemaakt om de PIC met zijn originele firmware code te testen en als uitgangspunt te dienen voor uitgebreide eigen programma's. De VB6 en VB.NET versies zijn gemaakt op een stromachtige middag/nacht zonder dat ik uitgebreid heb getest.

In mijn definitieve programma's zal dit allemaal iets anders gaan. Daar open ik de pipes één keer, en bewaak of ze "open" blijven etc. Maar het zal wel flexibel genoeg zijn om on-the-fly PIC's erbij te zetten of eraf te halen, zonder dat het programma er de brui aan geeft zoals de orignele TAD_V.

Mijn controle programma moet meerdere PIC's aankunnen met meerdere identiteiten.

Van de originele Firmware in de PIC is bij mij niets meer over. Ik heb nu een "digitale I/O" FW gemaakt die 64 buttons en 64 led's kan lezen/besturen. 8 of 16 buttons zijn te vervangen door 4 of 8 rotary encoders. De 64 leds zijn individueel bestuurbaar. Het zouden ook 8 7-segment displays kunnen zijn. Maar daarvoor maak ik een tweede kaart met FW ("display card") die gaat 16 (of meer) 7-segment displays aansturen. (allemaal zonder enige andere chip!)

Ik heb mijn PIC18 processors allemaal "USB programmable gemaakt". Dat wil zeggen dat ik geen programmer meer nodig heb om nieuwe firmware te laden als de PIC eenmaal in de schakeling zit. Zie HG 2007, blz 74.

Zie mijn weblog over mijn project : phpjj.web-log.nl

Peter.'

[velswijk]

Ik heb mijn PIC18 processors allemaal "USB programmable gemaakt". Dat wil zeggen dat ik geen programmer meer nodig heb om nieuwe firmware te laden als de PIC eenmaal in de schakeling zit. Zie HG 2007, blz 74.

Zie mijn weblog over mijn project : phpjj.web-log.nl

Peter.

Dit past wonderlijk goed bij wat ik zelf ook van plan was; ik vind programmers niet meer van deze tijd. Ik ga zeker op de weblog kijken. (Op het gevaar af een domme vraag te stellen, wat is "HG"?)

vr.gr.
PvE'

[pjongen]

(Op het gevaar af een domme vraag te stellen, wat is "HG"?)

Domme vragen bestaan niet, alleen domme antwoorden.

HG = Halfgeleider Gids, Elektor Juli/Augustus 2007.

Let op dat je voor de programma's die je via USB-bootloader wil programmeren met een speciaal linkscript moeten worden gemaakt anders overschijf je de USB bootloader!

Als daar belangstelling voor is, zal ik alle SW die ervoor nodig is bij elkaar zippen met wat instructies. Dat kan je heel wat zoekwerk besparen. Ik heb b.v. een bootloader gemaakt die dezelfde ledjes voor status gebruikt als de Data-Acquisition card.

Peter

[velswijk]

Als daar belangstelling voor is, zal ik alle SW die ervoor nodig is bij elkaar zippen met wat instructies. Dat kan je heel wat zoekwerk besparen. Ik heb b.v. een bootloader gemaakt die dezelfde ledjes voor status gebruikt als de Data-Acquisition card.

Peter

Daar is wat mij betreft wel belangstelling voor. Ik begreep uit je weblog dat je hiervoor op een of andere manier PICKIT2 (hebt) gebruikt?

vr.gr.
PvE

[pjongen]

Ja je moet in staat zijn éénmalig het "Bootloader" programma in de PIC18F4550 te (laten) branden. Met welke brander je dat doet is natuurlijk om het even.

De bootloader van het artikel in de HG2007 (halfgeleide gids 2007 ) is voor het Data-Aquisitie kaartje niet helemaal te gebruiken, omdat de bootloader van de demo print andere LEDS gebruikt voor status indicatie.
Ik zal deze week een paar dingen in een docje zetten en dat samen met een ZIP met software hier aanhechten. FF geduld.

Peter

[pjongen]

Voor de belangstellenden.

Hierbij dan de beloofde beschrijving + wat software over de USB Bootloader voor het Data Acquisitie kaartje.

Success ermee,

Peter