JAL compileertijd tot 19u


Neen, de PIC hangt rechtstreeks aan de pc via de USB poort van de PIC, en op de computer zie ik dan COM9, wat de pic is.

Bestaat er voor microbasic ook zo'n library?

Ik begrijp niet hoe je dat precies bedoelt. Als je al een USB <-> USB connectie hebt, waarom dan nog een COM poort emuleren?
(voor virtuele com poort via USB gebruik ik normaal iets als een MCP2200 via UART)

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

Ik deed dat eigenlijk omdat JAL die library heeft en omdat ik in visual basic goed met de com poort kan werken...

Wat ik eigenlijk wil doen is een byte kunnen verzenden van visual basic naar de pic en omgekeerd. Wat zijn de mogelijkheden hiervoor in microbasic? Hoe kan ik dit integreren in visual basic op de pc?

Hoeben

Golden Member

Op 19 mei 2017 23:08:49 schreef SparkyGSX:
@Hoeben: bullshit, de read/write buffers zorgen er wel voor dat het prima mogelijk is om byte voor byte te lezen met acceptabele snelheid (megabytes per seconde)

Dat zou je verwachten, maar met mijn oude jaren 80 PLM51 compiler scheelt het zowat een factor 100. Misschien worden calls naar het OS gedaan die een harde read en write geven in plaats van de cache, anders kan ik dat ook niet verklaren. Wel worden er veel .tmp files gemaakt.

D'r is een verhaal waarbij een een of andere library was gemaakt om uit een file te lezen.

Het lees-een-byte werd dan intern lees-de-byte-op-positie (POS) en dan POS=POS+1.

En het lees-de-byte-op-positie, was open-file, lees POS bytes naar een tijdelijke buffer, en daarna lees 1 byte naar de aanroepende functie, sluit file......

Dat je dan compileertijden van 19 uur krijgt is aannemelijk.

four NANDS do make a NOR . Kijk ook eens in onze shop: http://www.bitwizard.nl/shop/

Op de Lakeview site van Jan Axelson zijn veel Visual basic (en meer) voorbeelden te vinden...
http://janaxelson.com/hidpage.htm

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

Bedankt, zal het eens bekijken.

In de library voor de ADC is bijvoorbeeld geen functie voorzien om Vref+ en Vref- te gebruiken. (In JAL was dat ook niet, maar heb ik die library zelf aangepast.)

Hoe kan ik in microbasic de library van ADC openen en min of meer op assembler language niveau kijken wat er gebeurt en aanpassen?

@REW: dat is wel echt vreselijk slechte code.

@Hoeben: voor compilers e.d. die een spreekwoordelijke miljoen tijdelijke files aanmaken kan het wel schelen. FPGA synthesizers hebben daar ook een handje van, erg leuk als je officieel verplicht bent om alles op een server te doen, en die tijdelijke files dus ook over het netwerk moeten.

Het is wel raar dat de TS het op 3 verschillende computers heeft geprobeerd, en overal hetzelfde probleem heeft.

Ik snap echt niet waarom je met zo'n exotische one-of-a-kind taal zou gaan programmeren; C is echt niet moeilijk, en zeker op embedded systems waar je meestal geen dynamische geheugen allocatie doet, en weinig met pointers, zie ik echt niet in wat er mis is met C.

Een manager is iemand die denkt dat negen vrouwen in één maand een kind kunnen maken
Hoeben

Golden Member

C is hier inderdaad de aangewezen programmeertaal. Overal zijn gratis compilers te verkrijgen, veel documentatie.

buckfast_beekeeper

Golden Member

Een µC een com poort laten emuleren lijkt me niet de meest logische keuze. Een FTDI kan dat zoveel sneller en is daarvoor gemaakt. Je hoeft dan in je µC alleen een uart te gebruiken. Op je PC spreek je inderdaad een com poort aan.

Van Lambiek wordt goede geuze gemaakt.

VRef source kun je instellen bij initialiseren ADC (functie ADCx_Init_Advanced() )   http://download.mikroe.com/documents/compilers/mikrobasic/dspic/help/a…
De meeste libraries op Libsock zit de source bij, alleen niet bij de standaard ingebakken libraries...

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

Het lukt mij nog niet om zelf nieuwe libraries te maken in Mikrobasic.

Ik heb de module aangemaakt en opgeslagen in E:\Program Files\Microelektronics\Mikrobasic\Uses\P18
Zoals in de helpfunctie staat, declareer ik in de library de functie eerst boven "implements" (om de functie publiek te maken in andere programma's) en doe ik dit opnieuw hieronder met de uitgewerkte functie.

In het programma zet ik dan bovenaan "include naammodule".

Dit werkt niet, de code en fouten zitten in de 2 bijlages van dit bericht.

Wat doe ik verkeerd?

Wat er precies misgaat weet ik niet, ik doe het ook zo...
Ik kan hier wel proberen of ik het kan compileren, maar niet met die stenen tijdperk versie. (waar heb je die opgedoken?... :) )
(die versie moet al zo'n 8 jaar oud zijn, sinds 2010 is het MikroBasic Pro...)

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

Dat mag je zeker proberen, hier is de kopieerbare code:

programma:

code:


program Ledknipperen

include TomBleeser

symbol groenled = PORTC.7
symbol roodled = PORTC.6

dim getal1, getal2 as byte
dim tekst as string[16]

main:
TRISB = 0
Lcd_Config(PORTB, 7, 6, 5, 4, PORTB, 2, 0, 3)
Lcd_Cmd(Lcd_CURSOR_OFF)
getal1 = 2
getal2 = pluseen(getal1)
byteToStr(getal2, tekst)
Lcd_Out(2, 1, tekst)

end.

code:


Module TomBleeser

Sub function pluseen(dim byref a as byte) as byte

Implements

Sub function pluseen(dim byref a as byte) as byte
    result = a + 1
end sub

End.

Ah, dat merk ik nu pas op precies, dat is versie 7.0.0.2 uit 2008. Omdat dit een gratis volledige versie (die meer dan 2000 regels aankan) is om het zo te zeggen. Is er veel veranderd sindsdien?

Er is nooit een gratis volledige versie geweest, die oude had een 2k democode limit. MBPro heeft een 4k democode limit.
Je code compileert hier gewoon zonder fouten. (ik heb wel de 3 Lcd_xxx calls uit moeten zetten, want die bestaan niet meer in de nieuwe versie...)

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

Op 20 mei 2017 14:57:43 schreef Arco:
Ik begrijp niet hoe je dat precies bedoelt. Als je al een USB <-> USB connectie hebt, waarom dan nog een COM poort emuleren?
(voor virtuele com poort via USB gebruik ik normaal iets als een MCP2200 via UART)

Hoe dat precies zit weet ik niet, maar bij de Arduino werkt dat ook zo; misschien is het op de een of andere manier makkelijker om 'intern' met een COM-poort te werken.

@elektronica. Stond jouw post ook niet op de JAL discussiegroep? Daar werd gezegd dat je de laatste versie van de compiler moest gebruiken omdat er mogelijk in het verleden een fout in zat. Ik gebruik op dit moment versie jalv24q6.

met dergelijke 'oude' software op een nieuwere windows versie kan je altijd problemen krijgen.
een goeie oplossing hiervoor is om virtualpc of virtual machine te gebruiken en daar een antieke windows aan te koppelen. heel makkelijk om snel eens iets te testen zoals nu je compileer code.
het enige moeilijke eraan is je usb/com poort doorschakelen naar dat virtuele ding

ik hou van werken ..., ik kan er uren naar kijken

Op 27 mei 2017 08:09:01 schreef RobBest:
@elektronica. Stond jouw post ook niet op de JAL discussiegroep? Daar werd gezegd dat je de laatste versie van de compiler moest gebruiken omdat er mogelijk in het verleden een fout in zat. Ik gebruik op dit moment versie jalv24q6.

Ja, dat heb ik geprobeerd, maar dan krijg ik volgende foutmelding:

code:


Compilation started at :27/05/2017 13:48:03
jal jalv24q6 (compiled Oct 25 2016)
[Error] (usbadc.jal) [Line 1063]  error: Out of data space!
Compiler CommandLine:  C:\Users\TOMBLE~1\DOWNLO~1\JALLIB~1\compiler\JALv2.exe -Wno-all -long-start -clear  -s c:\picdev2\jal\libraries "C:\Users\Tom Bleeser\Desktop\006 USB oscilloscoop\usbadc.jal"  

Errors :1       Warnings :0

Op 27 mei 2017 08:23:29 schreef fcapri:
met dergelijke 'oude' software op een nieuwere windows versie kan je altijd problemen krijgen.
een goeie oplossing hiervoor is om virtualpc of virtual machine te gebruiken en daar een antieke windows aan te koppelen. heel makkelijk om snel eens iets te testen zoals nu je compileer code.
het enige moeilijke eraan is je usb/com poort doorschakelen naar dat virtuele ding

Op een originele windows xp werkt het ook niet.

[Bericht gewijzigd door elektronica op 27 mei 2017 13:50:27 (25%)]

Welke type PIC gebruik je? Out of data space geeft aan dat hij onvoldoende ruimte heeft om je variabelen op te slaan of je gebruikt een buffer (array) van meer dan 80 bytes.

Ja, ik gebruikte inderdaad een array van 500 bytes, wanneer ik die op 20 zet is het met die nieuwe versie inderdaad gedaan op seconden!!!
Bedankt!

(Overigens: die grote array zorgde niet voor het lange compileren in de oude versie, want toen als die er nog niet in stond duurde dit ook al zo lang)

En het is nu geen optie meer om grotere arrays dan 80 bytes te gebruiken? Dan opsplitsen in meerdere van 80?

Bij een 'normale' compiler kun je bijna al het beschikbare ramgeheugen gebruiken. Compiler maakt daar zelf een aaneengesloten blok van.
De 18F4550 heeft 2k ram, dus dat mag geen probleem zijn.
Wat doe je met zo'n groot array? (als het constantes zijn, kun je ze beter in flash zetten...)

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

Op 26 mei 2017 23:28:28 schreef Arco:
Er is nooit een gratis volledige versie geweest, die oude had een 2k democode limit. MBPro heeft een 4k democode limit.

Officieel...

Op 27 mei 2017 16:28:52 schreef Arco:
Wat doe je met zo'n groot array? (als het constantes zijn, kun je ze beter in flash zetten...)

Pogingen om een oscilloscoop te maken.
Meting per meting rechtstreeks doorsturen naar pc via rs232 emulatie met usb duurt 4 ms per meting.
Eerst in RAM geheugen zetten en dan alles na elkaar doorsturen naar pc was mijn volgende poging, maar toen stootte ik op het probleem van 34 u compileertijd en ben ik er even mee gestopt.

Andere suggesties om een oscilloscoop te maken? (En om real time spanning-tijd grafieken op pc te krijgen)

Ik neem aan dat die USB een HID interface is? Dan kun je 64 bytes ineens versturen, dat gaat een stuk sneller.
Als je twee buffers van 64 bytes maakt, kun je de ene versturen terwijl je de andere vult...
(de 18F4550 heeft een speciaal ram gebied voor usb buffers)

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

Neen, ik doe dat tot nu toe dus door byte per byte te verzenden, te wachten tot ze ontvangen zijn door pc, dan nieuwe meting en dan opnieuw.

Zal het binnenkort eens bekijken hoe de usb library van MikroBasic werkt. Dan iets in de aard van 64 bytes beginnen te verzenden, tegelijk nieuwe metingen starten, als de 64 bytes door pc ontvangen zijn de pc iets terug laten sturen naar pic, zodra dit ontvangen is door pic opnieuw 64 bytes verzenden?

Heb het ondertussen gevonden hoe je zelf nieuwe libraries maakt in mijn versie van MikroBasic: de library zetten in de map defs (niet uses) en de functies enkel onder "implements" declareren (niet nog eens extra erboven).