Nog meer ontwerptips en domme fouten

Ontwerptip

Als je begin met belichten dan is het handig om een teststrookje te maken met variabele belichtingstijden.

Ik had het probleempje dat ik niet kon vinden om een deel van de printplaat af te dekken. Nu heb ik daar wat op gevonden.

Met een laser printer aan 2 kanten van de sheet een groot zwart vlak afgedrukt. Dit laat bijna geen licht door en is super dun.

Je zou ook een teststrook (= zwartingstrap) uit de fotografie kunnen gebruiken.... Verder natuurlijk ook een gewoon zwart stukje papier, dat je steeds verschuift of een stuk aluminium folie

 a >> i      <>      a = a >> i 

Grmbll.. soms vraag ik me af of ik de enige ben die zich uren kan blindstaren op dit soort achterlijke code fouten..

@Joeri de Man:
Ik gebruikte hiervoor wat ik het dichtst bij de hand had: Een envelop waar meerdere A4'tjes ingevouwen zaten. Laat ook niets meer door, en scheelt een hoop inkt.

Op 29 augustus 2010 14:20:13 schreef ScuD:

code:

 a >> i      <>      a = a >> i 

Je bedoel a >>= i ? Dat mag ook. (Mijn compiler waarschuwt:

testshift.c:6: warning: statement with no effect
, vandaar dat ik altijd met -Wall compileer en alle onterechte warnings (testshift.c: 7: warning: control reaches end of non-void function) er effe uithaal. Nu geeft ie met regelnummer en al, aan waar je bug zit....)

De beschermfolie op de printjes leek mij ook wel licht dicht?

Dat plakt zo. Die zit dan in 1x helemaal vast aan je glasplaat of printje.

Ik heb dit gedaan, omdat ik bang was dat de andere oplossingen teveel ruimte tussen de glasplaat, layout en print zou veroorzaken.

Op 29 augustus 2010 17:05:02 schreef rew:
[...]
Je bedoel a >>= i ? Dat mag ook.

Klopt, maar dan maak ik alleen maar meer van die fouten zoals bovenstaande
Heb de neiging om code te snel door te typen, en dan verkijk je je al gauw op van die kleine dingen.

Geen warnings gezien op mijn compiler echter, zal het wat dieper moeten onderzoeken, zou me veel tijd kunnen besparen. Thx voor de tip!

Misschien maak je het jezelf nodeloos moeilijk? Bij iets als

    a /= 2;

gaat de compiler echt geen deling uitvoeren, en al zeker niet als de code voor een microcontroller bestemd is. Hij schuift de bits een plaatje naar rechts. Meer hoeft dat niet te zijn.

vandaar dat ik altijd met -Wall compileer ...

Dat doe ik ook rew. En dat waarschuwt je idd. bij dergelijke misstappen. Als je de moeite neemt om naar de output v/d compiler te kijken...

Ging me dan ook niet om de deling, maar om het shiften van een register om naar buiten te kunnen bitbangen. Wsl bestaan er efficientere manieren voor, maar uit asm gewoonte doe ik het nog steeds op die manier..
Wsl kan je ook gewoon een soortement van pointer elke bit van de data laten aflopen, maar dat leek me dan weer omslachtiger?

for (i=0; i<13; i++)
   {
   data_pin = data & 0x01;
   data = data >> i;
   clk_pin = 1;
   Delay_us(100);
   clk_pin = 0;
   Delay_us(100);
}

Compiler die ik gebruik is de MikroC compiler trouwens, al zijn tips voor betere meer dan welkom

Waarom moet het efficiënter als je toch steeds 100us wacht, 2 keer per bit?

Maar hij is wel erg efficiënt hoor. Zo efficiënt zelfs, dat je het grootste deel van de bitjes weggooit voordat ze buiten zijn.

"data = data >> i"

Zie: http://www.circuitsonline.net/forum/view/message/1149980#1149980

[edit] SCUD, ik zie een domme fout in je code.. Die hoort dus inderdaad in dit topic...
[edit2] Sparky was me voor.

ik maak het precies alleen erger door te posten.
De i moet idd gewoon 1 zijn in dit geval, was als voorbeeld bedoeld, redelijk slecht uitgepakt.. Schaam op mij.

Sparky, an sich hoeft het niet efficienter, vroeg me gewoon af of er een betere manier was om te bitbangen in C dan door te shiften. Het bijgevoegd stukje code was maar als voorbeeld van hoe ik het dacht aan te pakken, al is de 'i' hier dus niet van toepassing.

jep, dit is de gebruikelijke manier om te bitbangen.

Ik heb

a >> i

naar AVR assembly laten vertalen, en dat blijkt met een software loopje te gaan: for (;i>0;i--) a >>= 1; Maar als ik het met de hand uitschrijf wordt het ineens weer veel ingewikkelder.

Maar de les is dus: Het is efficienter om iedere keer je data 1 op te schuiven dan om in een expressie (data >> i) & 0x01 te gebruiken.

Ook al ben ik nog een leek in picbasic...
Met de datasheet voor mijn neus, kreeg ik het toch voor elkaar een hele avond(je)naar een fout in een code te zoeken.
Eindelijk heb ik die dan gevonden.
Het gaat om een LDR met adc uit te lezen.
Ik gebruik hiervoor de 16F87

Is dit een fout tengevolge van logisch redeneren of toch gewoon een domme (beginners)fout?

Device 16F877A
Config hs_osc, wdt_off, pwrte_off, BODEN_On, LVP_OFF
 XTAL = 20  
ALL_DIGITAL = true


;        76543210
 Declare ADIN_RES 10       ' 10-bit result required 
 Declare ADIN_TAD FRC      ' RC OSC chosen 
 Declare ADIN_STIME 50     ' Allow 50us sample time 
 Dim VAR1 As Word 
 
 PORTA = %0000000
 TRISA = %0100000         ' Configure AN5 (PORTA.5) as an input 
 ADCON0 = %0000010        ' Set analogue input on PORTA.5 
              ' Place the conversion into variable VAR1 
 

Clear                         ;Wis alle RAM geheugen
DelayMS 500                   ;LCD stabilisering

 While 1 = 1
VAR1 = ADIn 5
VAR1 = VAR1/100
DelayMS 10
Print At 1,1, "LDR:"
Print At 1, 6, Dec VAR1, " "
Wend
End

Wat is hieraan fout?
Ik ben benieuwd of hier meerderen zo oveheen kijken.

ALL_DIGITAL = true?

(heb nog nooit een pic geprogged, maar je zegt dat je een AD conversie gaat doen:p

Deze had ik ook al als mogelijke oorzaak eraf gehaald, maar dat gaf geen effect

Hilbert transform benaderen met FIR filter. Niet verschoven signaal moet ook verschoven worden. Ik verschoof het evenveel als er taps op de fir zitten, moet maar de helft natuurlijk...

Kan je me ff uitleggen wat het nut is van die 'while 1=1'?
Of moet je op die manier do-loops (oneindige lussen) programmeren?

Op 3 september 2010 16:50:06 schreef watchout3:
Kan je me ff uitleggen wat het nut is van die 'while 1=1'?
Of moet je op die manier do-loops (oneindige lussen) programmeren?

while 1=1 is idd voor oneindige lussen in sommige talen

[Bericht gewijzigd door ganzzz op 3 september 2010 16:55:47 (68%)

ow, weer wat bij geleerd
Weldra kan ik ook het topic aanvullen over C# blunders , kben met die usb-scope bezig (is ondertussen omgedoopt tot logger )

---TRISA = %0100000
ADCON0 = %0000010
(kga toch mr ff de datasheet opengooien of ik blijf maar gissen)

ADCON0 = %00      000   1           0          0
          F-Osc/2 chan0 ADC starten ongebruikt ADC staat af 
                                               voor power reductie

Foute kanaal+ ADC niet geactiveerd? (is men laatste poging:p)

[Bericht gewijzigd door watchout3 op 3 september 2010 17:14:05 (30%)

ADCON0 = %0000010 ipv ADCON1 = %10000000 ?
(even met de oude papieren versie van de handleiding erbij. Heb geen zin om m'n Windows (virtuele) machine op te starten om alleen dit even na te kijken).

Die registers goed instellen is wel belangrijk ja... LDDDDD! (Lees Die Dikke Datasheet Dan, Dombo!, als alternatief voor RT<bleep>M!)

(hehe, had zelf ook zoiets met de ADC van de 16F887, result verkeerd om gejustified (links ipv rechts, of andersom). iig hele rare getallen d'r uit, boven de 1024. LDDDDD geldt dus ook voor mij)

All_digital kan gewoon blijven staan, dat wordt toch overruled door de latere instellingen. Levert hooguit meer code op als je 't laat staan.

[Bericht gewijzigd door Lucky Luke op 3 september 2010 17:44:08 (12%)

Op 3 september 2010 16:02:01 schreef Kareltje:
Ook al ben ik nog een leek in picbasic...
Met de datasheet voor mijn neus, kreeg ik het toch voor elkaar een hele avond(je)naar een fout in een code te zoeken.
Eindelijk heb ik die dan gevonden.
Het gaat om een LDR met adc uit te lezen.
Ik gebruik hiervoor de 16F87

Is dit een fout tengevolge van logisch redeneren of toch gewoon een domme (beginners)fout?

pic basic code:

Device 16F877A
Config hs_osc, wdt_off, pwrte_off, BODEN_On, LVP_OFF
 XTAL = 20  
ALL_DIGITAL = true


;        76543210
 Declare ADIN_RES 10       ' 10-bit result required 
 Declare ADIN_TAD FRC      ' RC OSC chosen 
 Declare ADIN_STIME 50     ' Allow 50us sample time 
 Dim VAR1 As Word 
 
 PORTA = %0000000
 TRISA = %0100000         ' Configure AN5 (PORTA.5) as an input 
 ADCON0 = %0000010        ' Set analogue input on PORTA.5 
              ' Place the conversion into variable VAR1 
 

Clear                         ;Wis alle RAM geheugen
DelayMS 500                   ;LCD stabilisering

 While 1 = 1
VAR1 = ADIn 5
VAR1 = VAR1/100
DelayMS 10
Print At 1,1, "LDR:"
Print At 1, 6, Dec VAR1, " "
Wend
End

Wat is hieraan fout?
Ik ben benieuwd of hier meerderen zo oveheen kijken.

Ik dacht eerst:
VAR1 = ADIn 5
TRISA.5 lijkt 0 te zijn en dus output
Maar toen zag ik dat je voor TRISA maar 7 bits had gedefinieerd. Waarom je dat doet snap ik niet, maar het kan aan mij liggen.
Binaire waarden doe ik personalemente altijd met 8 bits tenzij het om individuele bitjes gaat.

In je post heb je het over de 16F87, in de code over de 16F877A.
Verder mis ik de declaraties voor de LCD.
Tenslotte: ADCON0 is verkeerd. Je hebt nu bit 1 aangezet en die is "unimplemented". Verder doe je met de andere bits in ADCON0 een deel van je declares teniet. ENNN: met de LSB disable je de ADC.

[Bericht gewijzigd door hadv op 3 september 2010 17:58:35 (18%)

antwoord: Ik heb op mijn pcb headers gesoldeerd die ik als ingangen gebruik, dus zeker ook analoge ingangen.
Ik ging gewoon logisch tellen: RA.0 = AN0, RA.1 = AN1, etc.
Dus, zou RA.5 AN5 moeten zijn (dacht ik)
RA.4 is geen analoge poort......dus..RA.5 = AN4

VAR1 = ADIn 4 'en geen 5

Met verdorie de datasheet voor mijn neus