klok pic16f628


Ik ben redelijk bedreven in Visual Basic .NET 2010.
Maar weet niet of dat bruikbaar is voor uC's.

Visual Basic is voor Windows....

Je moet geen andere taal leren maar Proton goed in de vingers krijgen.
Hoe Proton die I2C bestuurd maakt voor u niet veel uit en ook niet welke controller je gebruikt.

Wilde ik maar zeggen dat je met die andere controllers geen stap verder bent met uw probleem, tenzij iemand u verder kan helpen.

LDmicro user.

Picbasic is waarschijnlijk niks mis mee, maak ikzelf houd er niet van. (ik gebruik Mikrobasic, is wat gestructureerder van opbouw)
VB is voor PC programma's...

De TS is volledig afhankelijk van Proton, wat heb je er dan aan?

Die ondersteunt toch gewoon 'echte' (hardware) i2c?
Ik neem aan dat de 16f1826 gewoon ondersteud wordt (die bestaat tenslotte ook al weer bijna 9 jaar)

Met een passende controller ben je wel een stap verder: i2c maak je het best met een echte i2c interface.
(simpeler, minder belasting voor de processor. Soft- of hardwarematig maakt bij i2c wel degelijk uit))

Arco - "Simplicity is a prerequisite for reliability" - www.arcovox.com
Lambiek

Special Member

Op 22 september 2019 21:59:02 schreef MGP:
De TS is volledig afhankelijk van Proton, wat heb je er dan aan?

Die snap ik even niet, hij heeft toch Proton en kan goed overweg met Basic. De 16F1826 wordt gewoon ondersteund door Proton, tenminste bij mij wel.

Ik gebruik het zelf al zo'n +/- 20 jaar en ben eigenlijk nooit problemen tegen gekomen dat iets niet kon.

En natuurlijk kun je een andere taal leren, maar waarom zou je. Jij ben helemaal weg van LD-micro en daar is niets mis mee, ieder zijn ding toch. :)

En daar komt nog bij, iedere taal heeft zijn voor en tegen.

pic basic code:


'*  Name    : POORTINSTELLING 16F1826.                                      
'*  Author  : H van Zwieten.                                    
'*  Notice  : Copyright (c) 2019 H.v.Z.                         
'*          : All Rights Reserved                              
'*  Date    : 23-9-2019                                        
'*  Version : 1.0                                              
'*  Notes   :                                                   
                                                   
Device = 16F1826

Config1 FOSC_HS, WDTE_ON, PWRTE_OFF, MCLRE_OFF, CP_OFF, CPD_OFF, BOREN_SBODEN, CLKOUTEN_OFF, IESO_OFF, FCMEN_OFF
Config2 WRT_OFF, PLLEN_OFF, STVREN_OFF, LVP_OFF

Xtal 10                                ; Kristal 10 MHz

All_Digital true                       ; Alle poorten digitaal

Clear                                  ; Wis geheugen

        ;76543210                      ; Hulpregel Poort poort_A
PORTA = %00000000                      ; Zet poort_A laag
TRISA = %00000000                      ; Poort_A I/O
                                            
        ;76543210                      ; Hulpregel Poort poort_B
PORTB = %00000000                      ; Zet poort_B laag
TRISB = %00000000                      ; Poort_B I/O
Als je haar maar goed zit, GROETEN LAMBIEK.

Op 23 september 2019 11:45:53 schreef Lambiek:
[...]
Die snap ik even niet, ..

Nog een poging wagen want je hebt groot deel van de discussie gemist volgens lezen.

De TS heeft een 16F628a en daarmee wil hij communiceren in I2C.
In Proton kan dat volgens lezen perfect werken.
Maar de TS krijgt het maar niet voor elkaar om dat te laten werken.

Plots wordt hem aangeraden van andere controllers te kopen met I2C hardware ingebouwd, wat de TS ook doet, in de hoop van het dan wel werkend te krijgen.
Als hij het nu al niet met een 16F628a werkend krijgt, zal hij het dan wel werken met een 16F1826 MET hardware I2C?

Gezien de TS met Protonbasic werkt, wat ikzelf ook prima vind, zal een andere controller geen soelaas brengen voor zijn problemen, waarvan het gebrek aan programmeerervaring het hoofdprobleem blijkt te zijn.
Dat is geen verwijt want ik ken er nog minder van.

Volgens mij ondersteunt Proton geen hardware I2C (correct me if I'm wrong) en dus moet hij het met dezelfde instructies doen bij eender welke controller.
Ik heb wel een oudere versie van Proton en daarom ben ik niet 100% zeker.

Dus de aankoop was niet nodig voor zijn probleem maar ze kunnen wel gebruikt worden evenals zijn 16F877/887

Of wie gaat hem bijstaan als die andere controllers binnen zijn?

En herlees nu nog eens de discussie met dit in gedachte ;)

LDmicro user.

Het grootste nadeel vond ik dat picbasic geen functies kent, eigenlijk wel een vereiste vind ik... (gosub is een overblijfsel van oer-basic)
Ook het feit dat de compiler zelf uit kan maken of een pin in of output is vind ik griezelig; ik maak dat zelf wel uit.

Ook de (standaard) libraryfuncties vind ik onoverzichtelijk, maar da's bij bijna elke compiler. Goede libraries schrijf je liefst zelf... ;)

@MGP:
Kom, kom, zo'n 'doomsday' beeld is nu ook weer niet nodig. Natuurlijk kun je met picbasic ook hardware i2c aansturen... ;)
Zo groot is het verschil tussen de midrange (16Fxxx) en enhanced midrange (16F1xxx) ook weer niet, er is zelfs een migration document over...

Arco - "Simplicity is a prerequisite for reliability" - www.arcovox.com

Op 23 september 2019 12:36:27 schreef Arco:
@MGP:
Kom, kom, zo'n 'doomsday' beeld is nu ook weer niet nodig. ..

Doomsday..helemaal niet.. hoogstens een ontgoocheling :p

Op 23 september 2019 12:36:27 schreef Arco:
..
Zo groot is het verschil tussen de midrange (16Fxxx) en enhanced midrange (16F1xxx) ook weer niet, er is zelfs een migration document over...

Een echte aanrader voor beginners :) :)

LDmicro user.
Lambiek

Special Member

Op 23 september 2019 12:30:19 schreef MGP:
De TS heeft een 16F628a en daarmee wil hij communiceren in I2C.
In Proton kan dat volgens lezen perfect werken.

Een 16F628 heeft geen hardware matige I2C pinnen en een 16F1826 wel.

En zelf gebruik ik al jaren I2C met proton, wordt gewoon ondersteund.

Plots wordt hem aangeraden van andere controllers te kopen met I2C hardware ingebouwd, wat de TS ook doet, in de hoop van het dan wel werkend te krijgen.

Als hij dat goed programmeert gaat dat ook werken. Heb hem een werkend voorbeeld gegeven.

Als hij het nu al niet met een 16F628a werkend krijgt, zal hij het dan wel werken met een 16F1826 MET hardware I2C?

Zeker wel.

Als je haar maar goed zit, GROETEN LAMBIEK.

@Lambiek, misschien kun je mij ook vertellen of Proton de hardware I2C ondersteund? want ik kan dat uit de manual niet opmaken.

LDmicro user.

Ik vond dat ook altijd wat wazig. De i2cread/write, serin/out, hserin/out,... is allemaal wat onduidelijk uitgelegd in de manual. (wat doet wat?)
Zo ook dat er 2 verschillende interrrupts zijn: 'echte' en picbasics eigen soort... (was volgens mij iets met een underscore ervoor)

Arco - "Simplicity is a prerequisite for reliability" - www.arcovox.com
Lambiek

Special Member

Op 23 september 2019 13:17:49 schreef MGP:
@Lambiek, misschien kun je mij ook vertellen of Proton de hardware I2C ondersteund?

Zo als ik al zei, I2C wordt gewoon ondersteund.

code:


I2Cin
Syntax
I2Cin Dpin, Cpin, Control, { Address }, [ Variable {, Variable…} ]
Overview
Receives a value from the I2C bus, and places it into variable/s.
Operators
Dpin is a Port.Pin constant that specifies the I/O pin that will be connected to the I2C device's
data line (SDA). This pin's I/O direction will be changed to input and will remain in that state after
the instruction is completed.
Cpin is a Port.Pin constant that specifies the I/O pin that will be connected to the I2C device's
clock line (SCL). This pin's I/O direction will be changed to output.
Variable is a user defined variable of type Bit, Byte, Word, Dword, Float, Array.
Control is a constant value or a byte sized variable expression.
Address is an optional constant value or a variable expression.
The I2Cin command operates as an I2C master, and may be used to interface with any device
that complies with the 2-wire I2C protocol. The most significant 7-bits of control byte contain the
control code and the slave address of the device being interfaced with. Bit-0 is the flag that indicates
whether a read or write command is being implemented.
For example, if we were interfacing to an external eeprom such as the 24LC32, the control
code would be %10100001 or $A1. The most significant 4-bits (1010) are the eeprom's unique
slave address. Bits 1 to 3 reflect the three address pins of the eeprom. And bit-0 is set to signify
that we wish to read from the eeprom. Note that this bit is automatically set by the I2Cin command,
regardless of its initial setting.

code:


I2Cout
Syntax
I2Cout Control, { Address }, [ OutputData ]
Overview
Transmit a value to the I2C bus, by first sending the control and optional address out of the
clock pin (SCL), and data pin (SDA).
Operators
Dpin is a Port.Pin constant that specifies the I/O pin that will be connected to the I2C device's
data line (SDA). This pin's I/O direction will be changed to input and will remain in that state after
the instruction is completed.
Cpin is a Port.Pin constant that specifies the I/O pin that will be connected to the I2C device's
clock line (SCL). This pin's I/O direction will be changed to output.
Control is a constant value or a byte sized variable expression.
Address is an optional constant, variable, or expression.
OutputData is a list of variables, constants, expressions and modifiers that informs I2Cout how
to format outgoing data. I2Cout can transmit individual or repeating bytes, convert values into
decimal, hex or binary text representations, or transmit strings of bytes from variable arrays.
These actions can be combined in any order in the OutputData list.
The I2Cout command operates as an I2C master and may be used to interface with any device
that complies with the 2-wire I2C protocol. The most significant 7-bits of control byte contain the
control code and the slave address of the device being interfaced with. Bit-0 is the flag that indicates
whether a read or write command is being implemented.
For example, if we were interfacing to an external eeprom such as the 24LC32, the control
code would be %10100000 or $A0. The most significant 4-bits (1010) are the eeprom's unique
slave address. Bits 1 to 3 reflect the three address pins of the eeprom. And Bit-0 is clear to signify
that we wish to write to the eeprom. Note that this bit is automatically cleared by the I2Cout
command, regardless of its initial value.
Als je haar maar goed zit, GROETEN LAMBIEK.

Dat bedoel ik nou met wazig: bij die i2cin/out commando's staat nergens duidelijk of het hardware of een software implementatie is...
(ik vermoed het laatste)

Maar hardware i2c aansturen kan altijd: direct de betreffende registers aansturen. (niet echt ingewikkeld)

Arco - "Simplicity is a prerequisite for reliability" - www.arcovox.com
Lambiek

Special Member

Op 23 september 2019 14:15:34 schreef Arco:
Dat bedoel ik nou met wazig: bij die i2cin/out commando's staat nergens duidelijk of het hardware of een software implementatie is...

Ja, echt duidelijk is het niet. :)

Ik doe het altijd met de daarvoor bestemde pinnen met dit commando.

pic basic code:


Declare SCL_Pin PORTC.3           ; I2C klok pin
Declare SDA_Pin PORTC.4           ; I2C data pin
Declare I2C_SLOW_BUS 1            ; I2C bus op 100KHz

En dan gewoon de juiste data versturen.

Als je haar maar goed zit, GROETEN LAMBIEK.

Zoals ik al vermoedde is alles software aangezien je elke pin kunt kiezen als SDA of SCL wat bij hardware I2C niet mogelijk is.

Bij MikroBasic heb je meer mogelijkheden volgens zien, maar voor gewone toepassingen is software I2C meer dan voldoende.

Op 23 september 2019 14:01:22 schreef Lambiek:
[...]
Zo als ik al zei, I2C wordt gewoon ondersteund.

Dat was de vraag niet ;)

LDmicro user.

Ik heb toch liever hardware i2c voor betrouwbare toepassingen.
Met softwarimplementaties weet je nooit hoe errors worden afgevangen. (veel software blijft gewoon hangen als er iets onverwachts gebeurt...)

Als het toch softwarematig moet, dan zou ik de library zeker zelf schrijven. Geldt trouwens ook voor de hardware library hoor...
(ook die hangen meestal bij onverwarchte gebeurtenissen.)

Dat een systeem hangt bij een i2c fout is volstrekt onacceptabel.

Arco - "Simplicity is a prerequisite for reliability" - www.arcovox.com

Library's schrijven is niet voor iedereen weggelegd en als die dan nog uitgebreid moeten getest worden al zeker niet.

Op 23 september 2019 18:10:36 schreef Arco:
Met softwarimplementaties weet je nooit hoe errors worden afgevangen. (veel software blijft gewoon hangen als er iets onverwachts gebeurt...)

Over doemscenario's gesproken ..

Het zou toch heel jammer zijn moesten de software I2C implementatie's in Picbasic of Mikrobasic nog altijd niet goed werken.

LDmicro user.
Lambiek

Special Member

Op 23 september 2019 17:58:27 schreef MGP:
Zoals ik al vermoedde is alles software aangezien je elke pin kunt kiezen als SDA of SCL wat bij hardware I2C niet mogelijk is.

Ik had het de hele tijd al over de hardware toepassing, ik gebruik de I2C toepassing nooit.

En bij de hardware toepassing zijn er maar een paar pinnen die je kunt gebruiken.

Als je haar maar goed zit, GROETEN LAMBIEK.

Als bijv. om een of andere reden de SDA of SCL lijn laag blijven (da's geen doemscenario: het gebeurt), dan hangen de meeste libraries (hard of software).
En dat is onacceptabel.

Arco - "Simplicity is a prerequisite for reliability" - www.arcovox.com

Op 23 september 2019 18:27:20 schreef Lambiek:
[...]
Ik had het de hele tijd al over de hardware toepassing, ik gebruik de I2C toepassing nooit.

En bij de hardware toepassing zijn er maar een paar pinnen die je kunt gebruiken.

Heb je zelf die library geschreven? volgens de handleiding kun je elke pin kiezen en dat is dus software I2C of BUScontrol.

@Arco, Tja ..wat kun je daar tegen doen? ik zou het niet weten en met een zelfgeschreven library ben je ook nooit 100% zeker.
Om nog niet te spreken over programmeerfouten... :S

LDmicro user.

Tja ..wat kun je daar tegen doen?

Alle punten waar je moet wachten op iets voorzien van een time-out. Iets meer code, maar de boel blokkeert nooit meer.
(je kunt dan de gebruiker in ieder geval nog informeren over het defect. Bij 'hangen' kan dat niet meer)

Arco - "Simplicity is a prerequisite for reliability" - www.arcovox.com

Binnen enkele dagen ontvang ik de PIC 16F1826's. Die hebben een hardwarematige I2C en dan maar weer verder gaan.

Ik ben pas begonnen met de microcontrollers, maar ik merk dat er erg veel bij komt kijken en je rolt van het een in het ander.

Ledjes aansturen, geluidje maken lukt nu prima. De volgende stap in mijn 'leergang'is nu het geluid afhankelijk te maken van de datum (bv op verjaardag ander toontje). Daarvoor had ik de RTC DS3231 aangeschaft, die met I2C werkt.
Daarmee wilde ik de datum en/of tijd uitlezen (die je natuurlijk ook moet 'setten').

Ik heb een hele dag allerlei voorbeelden geprobeerd. Veel zijn in C geschreven. Dus dan maar de C-compiler van MPLAb geïnstalleerd. Voor je die aan de praat hebt ben je zomaar een paar uur verder.
De voorbeelden geven in veel gevallen dan ook compilatie errors omdat er variabelen zijn die hij niet kent of dat er wordt gerefereerd aan 'include's' die er niet zijn.
Nu kan ik me wel in C gaan verdiepen, maar na het volgen van de PICBasic cursus (die op enkele fronten ook weer wat verouderd schijnt te zijn) is dat toch een stap te ver.
Ik probeer het langzaam op te bouwen.
Ik heb nog gezocht naar conversieprogramma's van C naar PicBasic maar kon ze niet vinden.
Vallen en opstaan dus. Dat hoort nu eenmaal bij hobby's.
Gelukkig is dit forum er en ik heb al veel hulp ervaren!

Start dan maar tegelijk een nieuw topic want ik heb u al de ganse tijd als TS aangewezen wat je natuurlijk niet bent ;)

LDmicro user.

Op 23 september 2019 14:22:53 schreef Lambiek:
[...]
Ja, echt duidelijk is het niet. :)

Ik heb nog eens de handleiding van Proton picbasic doorgenomen en ook die heeft 2 soorten I2C instructies.

-De "software" instructies zoals I2Cin, I2Cout, Busin, Busout kunnen gebruikt worden op PIC's die geen ingebouwd MSSP module hebben zoals een 16F628A en natuurlijk ook op alle andere pic's.
Daar kun je zelf de SDA en SCL pinnen kiezen.

-De "hardware" I2C instructies zoals Hbusin, Hbusout .. worden gebruikt op PIC's met ingebouwde MSSP module en daar liggen de SDA, SCL pinnen vast.
Bij deze pic's kun je ook die module gebruiken voor SPI data transferts.

Hiermee is een klein stukje van de discussie opgehelderd ;)

LDmicro user.