losse bits in een byte schuiven.

uint8_t byte;
uint8_t i;

for (i=0;i< 8; i++) {
  byte = byte << 1 + get_and_wait_for_bit();
}

Maar het gaat om die <<. Daarmee schuif je de bestaande bits in byte door, en kan je de nieuwe erin stoppen.

[Bericht gewijzigd door blurp op dinsdag 28 mei 2019 21:01:29 (33%)]

De hamvraag is eerder : wanneer mag je de status evalueren van de input ? Normaal heb je ook nog een "clock" signaal nodig, dan kan je lezen bij elke clock flank. C-code om bits te schuiven is niet zo moeilijk, zoek op bit shift.

Blurp: Doe me een plezier en schrijf:

  byte = (byte << 1) + get_and_wait_for_bit();

Worst case doet de compiler anders:

  byte = byte << (1 + get_and_wait_for_bit());

niet wat je bedoelt.

Deels heb ik hier een slecht gevoel over omdat ik de precentie regels niet goed genoeg ken, maar anderzijds, zijn er met shifts en and-or dingen dat sommige compilers de boel precies anders doen als andere compilers. -> Nooit op vertrouwen: extra haakjes, ook waar ze soms niet nodig zijn.

vergeten te zeggen, de bits komen op een clock signaal binnen.

die << shift had ik wel al aan gedacht, maar ik ging er van uit dat de bits die al in de byte staan worden overschreven.

Stukje assembly maken. Met een rotate with carry instructie kun je het carrybit naar binnen schuiven.

c is al lastig genoeg.

Drie regels inline assembly lukt iedereen toch wel?...

Op 28 mei 2019 21:06:11 schreef rew:
Blurp: Doe me een plezier en schrijf:

  byte = (byte << 1) + get_and_wait_for_bit();

Worst case doet de compiler anders:

  byte = byte << (1 + get_and_wait_for_bit());

niet wat je bedoelt.

Deels heb ik hier een slecht gevoel over omdat ik de precentie regels niet goed genoeg ken, maar anderzijds, zijn er met shifts en and-or dingen dat sommige compilers de boel precies anders doen als andere compilers. -> Nooit op vertrouwen: extra haakjes, ook waar ze soms niet nodig zijn.

Ik ben hierdoor zo vaak uren van mijn leven kwijt geraakt. Vaak is te veel niet goed, maar gecombineerd met haakjes ben ik het daar niet meer eens.

Haakjes maken het vaak ook een stuk leesbaarder

Blz 53 ANSI-C K&R

Op 28 mei 2019 22:29:42 schreef GJ_:
Haakjes maken het vaak ook een stuk leesbaarder

Ik heb een hekel aan overbodige haakjes en meer dan drie keer inspringen is voor mij onleesbaar.

Haakjes zijn onmisbaar. Zorgen ervoor dat iedere compiler een regel hetzelfde verwerkt...

Op 28 mei 2019 21:26:04 schreef Arco:
Stukje assembly maken. Met een rotate with carry instructie kun je het carrybit naar binnen schuiven.

"The eighties called, they need you back!".

Echt, de jaren tachtig zijn al enige tijd voorbij en dat soort verouderde technieken moet je niet meer mensen aan gaan leren in deze periode van de historie.

Ja, voor bepaalde klusjes kan je efficienter werken in assembly. Maar 99% van de gevallen kan je een factor 10 "verklooien" zonder dat het een probleem wordt. Met wat moeite kunnen ze op een 12MHz (of was het 16?) AVR 1.5Mbit USB decoderen in software. Dan moet je inderdaad ofwel andere hardware kiezen (een at90USB162 bijvoorbeeld met hardware USB aan boord) of des noods in assembly werken. Maar TS werkt met een 160 bps signaal, dus zelfs als de C-code 10x langzamer is als de assembly code, is er nog een factor duizend marge.

Tja,
't Is logisch dat mensen die geen verstand van assembly hebben er negatief op afgeven...
Zelfs voor starters zou ik het nog aanraden nu. Je leert de werking van de controller kennen.
(hoeveel mensen 'programmeren' er niet in picbasic die eigenlijk geen benul hebben waarom iets wel of niet werkt, en of het goede of slechte code is...)

Zoals ik zei: inline assembly is nog steeds handig en makkelijk in het gebruik. (voorbeeld in mikrobasic)

Asm
  bsf     status,c
  rlf     _mybyte, f
End Asm

Ik persoonlijk vind idd ook assembler makkelijker, je gaat dan als een processor denken.(dat kost me soms wel moeite )

Ik vind dat je in een opleiding tot bijvoorbeeld "elektrotechnisch ingenieur" er wel een keer aan geroken moet hebben.

Kijk, dit is een ARM processor. Die heeft 16 registers en instructies die dingen uit het geheugen in registers kunnen halen, instrucies om bewerkingen op de registers te doen en conditionele jumps om beslissingen te nemen. Schrijf een programma om de eerste 100 fibonnachi nummers uit te rekenen.

Dit is omdat een elektrotechnisch ingenieur geacht wordt iets van de basis af te weten.

Maar een random hobbyist die een specifieke taak voor ogen heeft kan prima op het abstractie niveau "C" of "Picbasic" werken.

Net als "je moeder" die d'r huishoudgeld bij mekaar optelt in Excel en vraagt hoe ze twee getallen moet optellen,

   ld a, r1
   ld b, r2
   add r1, r2, r3
   st r3, c

[Bericht gewijzigd door rew op woensdag 29 mei 2019 08:07:45 (13%)]

Op 28 mei 2019 21:00:38 schreef RP6conrad:
De hamvraag is eerder : wanneer mag je de status evalueren van de input ? Normaal heb je ook nog een "clock" signaal nodig, dan kan je lezen bij elke clock flank. C-code om bits te schuiven is niet zo moeilijk, zoek op bit shift.

Als ik TS begrijp moet er alleen bij binnenkomst van een bit geschoven worden. Na verloop van tijd zal er dus alleen rijtje enen is het register staan.
Als je de binnenkomende "1" direct in bit 0 zet kun je het toch direct schuiven? Of met twee vermenigvuldigen.
Je trigger is dan een "1" in bit 0, of een oneven getal in je register.

1) koffie drinken
2) beter lezen

Huh? Ik denk dat er een klok signaal is.
De code is dan iets van:

  // 40 bits, 5 bytes. 
  for (i=0;i<5;i++) {
    for (j=0;j<8;j++) {
      while (readbit (CLK) == 0) ;
      // clock signal has had a up transition

      d = (d << 1) | readbit (DATA);

      // now wait for the clock signal to go low again.
      while (readbit (CLK) == 1) ;
    }
    data[i] = d;
  }

Aiii, je hebt gelijk. Ik zag het clock signaal over het hoofd.

Ik moet niet posten voor ik een stevige bak koffie op heb.

Op 28 mei 2019 21:06:11 schreef rew:
Blurp: Doe me een plezier en schrijf:

  byte = (byte << 1) + get_and_wait_for_bit();

Worst case doet de compiler anders:

  byte = byte << (1 + get_and_wait_for_bit());

niet wat je bedoelt.

Ik heb hem effe opgezocht. Je worst case is best case, '+' heeft hogere precedence dan '<<' dus mijn code was hardstikke fout.

En omdat het in de standaard vast ligt, is een compiler die toch eerst de shift doet, en dan pas de optelling ook hardstikke fout, en die moet je niet willen gebruiken. Maar TS gaf al aan atmelstudio 7 te gebruiken, en ik ga er effe van uit dat ie gewoon de default (gcc) compiler gebruikt.

inderdaad de gcc compiler.

het stukje van rew lijkt me wel te werken, ik moet het even tot me laten indringen.

bedankt.