C Programmieren, 10er und 1er getrennt speichern

Simon schrieb:
> Ich möchte bei Microchip die interne rtccTime zum externen MCP7941 RTCC
> kopieren.

Was meinst du mit "interne rtccTime" ?
zB. beim PIC18F27J11 wird auch intern mit dem BCD Code gearbeitet.

Am besten du speicherst und verarbeitest die Zeit auch "intern" in BCD 
und sparst dir die ganze Umrechnerei. Die haben das Format ABSICHTLICH 
so gewählt ...

Simon schrieb:
> (denke ich)

Wenn das Nachschauen so einfach ist wie in diesem Fall, dann sollte man 
besser nicht zu viel denken ...

Simon schrieb:
> Peter II schrieb:
>> x1 = 25 % 10;
>> x2 = 25 / 10;
>
> funzt perfekt.
>
>
> Jetzt knobel ich natürlich am Weg wieder zurück also von 2 und 5 auf die
> 25, am besten ohne multiplikation

Du musst entweder mit 10 multiplizieren oder mal ein wenig nachdenken, 
aus welchen Zweierpotenzen sich die 10 zusammensetzt: 10 = 8 + 2.

Also:

1

      mm = 10 * x2 + x1;

2

<==>  mm = (8 + 2) * x2 + x1;

3

<==>  mm = 8 * x2 + 2 * x2 + x1;

4

<==>  mm = (x2 << 3) + (x2 << 1) + x1;

War das so schwierig?

Leute, bevor ihr euch hier weiter einen abrechnet:

Auch für den PIC32.. gilt:
BCD format for smaller firmware overhead

-> Lass es einfach in diesem Format!

Volker S. schrieb:
> Die haben das Format ABSICHTLICH
> so gewählt ...

Nö, das Format ist historisch entstanden und wurde nur immer weiter 
mitgeschleppt. Damit werden Vergleiche auf >,< zum Albtraum. Auch muß 
man alle Zugriffe atomar kapseln, sonst hat man alte und neue Digits 
gemischt.

Heutzutage hat sich das 32Bit bzw. 64Bit Sekunden Format durchgesetzt. 
Die CPU liest einmalig nach dem Reset diese vergurkte alte Format aus 
dem RTC-Chip und wandelt es in Sekunden um.
Einige neuere RTCs können sogar direkt 32Bit Sekunden zählen.
Damit werden Rechnungen viel einfacher, bzw. eine 32Bit-CPU muß nichtmal 
mehr das Zeit auslesen/setzen atomar kapseln.
Nur zur Anzeige wird wieder zurück gewandelt. Da der Mensch eh nur sehr 
langsam lesen kann (aus CPU-Sicht), kostet das kaum Rechenzeit.

Peter D. schrieb:
> Heutzutage hat sich das 32Bit bzw. 64Bit Sekunden Format durchgesetzt.
> Die CPU liest einmalig nach dem Reset diese vergurkte alte Format aus
> dem RTC-Chip und wandelt es in Sekunden um.

Bei dem PIC32 anscheinend nicht ...

Simon schrieb:
> ich dachte immer da ist das
> format was bei raus kommt direkt die Minuten

Wo raus kommt ?

Da kommt aber ganz schön oft "BCD" vor, in den Kommentaren ;-)

Volker S. schrieb:
> Bei dem PIC32 anscheinend nicht ...

Wenn Du viel mit Zeiten rechnen mußt, lohnt sich die einmalige 
Umrechnung nach dem Reset auch beim PIC32.

Ja, es fällt den Menschen schwer, alte Zöpfe abzuschneiden.
Mich ärgert es z.B. auch, daß bei den ARM-Cortex immer diese grottenalte 
16550 UART vom PC übernommen wird, die nichtmal den 9-Bit Mode kann.
Es wird leider oft dem bekannteren gegenüber dem leistungsfähigerem der 
Vorzug gegeben.

Schrehbfeiler gefunden:

1

uint8_t bcd2bin( uint8_t val )

2

{

3

  return val % 16 + val / 16 * 10;

4

}

Peter D. schrieb:
> Volker S. schrieb:
>> Bei dem PIC32 anscheinend nicht ...
>
> Wenn Du viel mit Zeiten rechnen mußt, lohnt sich die einmalige
> Umrechnung nach dem Reset auch beim PIC32.

Ja, wenn ...
Ich hatte erst einmal das Vergnügen mit der internen RTCC und da musste 
ich eigentlich nur vergleichen. Habe dann die Vergleiche einfach in BCD 
gemacht.

Simon schrieb:
> So sieht das bisher aus und funzt schonmal bestens
>
> ob "<<4" das selbe ist wie "*16" ? (ich meine nach dem compilen)
> ...

4 mal shiften (4 mal mit 2 multiplizieren oder 2^4) = 16
aber was deine Funktion anbelangt: "Verstehe ich nicht ;-)"

Simon schrieb:
> Das sah zwar super aus, funktioniert jedoch nicht wirklich.

So ist das mit Schnellschüssen.
Aber das Prinzip sollte erkennbar sein, kann jeder also leicht 
korrigieren.

> uint8_t bin2bcd( uint8_t val )
> {
>   return val / 10 | val % 10 * 16;
> }

uint8_t bin2bcd( uint8_t val )
{
   return val / 10 *16 | val % 10;
}

<edit> ääähhh, zu spät ;-)

Ich verstehe es immer noch nicht ;-)

Karl M. schrieb:
> Volker,
> was fehlt noch zu deinem Verständnis ?

Von den Variablen-Namen (h für stunden m für minuten alles in einem 
byte) in der Funktion mal abgesehen, verstehe ich den Sinn der 
Umwandlung nicht, da eigentlich beide RTCCs BCD Formate verwenden.

npn schrieb:
> Volker S. schrieb:
>> Karl M. schrieb:
>>> Volker,
>>> was fehlt noch zu deinem Verständnis ?
>>
>> Von den Variablen-Namen (h für stunden m für minuten alles in einem
>> byte) in der Funktion mal abgesehen, verstehe ich den Sinn der
>> Umwandlung nicht, da eigentlich beide RTCCs BCD Formate verwenden.
>
> Wenn man aber mit den Zeiten rechnen will/muß, dann ist das BCD-Format
> nicht so gut geeignet. Hat Peter Dannegger weiter oben schon ausführlich
> erklärt. Ist es das, was du meinst?

Nein, von rechnen war doch nie die Rede !

Simon schrieb:
> Ich möchte bei Microchip die interne rtccTime zum externen MCP7941 RTCC
> kopieren.




Also wenn wir die "zusätzlichen Steuerbits" mal vorerst beiseite lassen, 
weil das ein anders Problem ist. Was soll die Konvertierung ?

Simon schrieb:
> Ich möchte bei Microchip die interne rtccTime zum externen MCP7941 RTCC
> kopieren.

Volker S. schrieb:
> Was soll die Konvertierung ?

Simon schrieb:
> jetzt bleibt nur noch zu klären welches format dann die rtccTime und
> rtccDate structure enthällt.

Was glaubst du soll das BCD in den Kommentaren bedeuten ???

Umrechnen musst du vielleicht schon, weil es in deinem Programm
dann "möglicherweise" einfacher wird mit irgendwelchen Berechnungen.
(Darum ging es bisher aber nicht ;-)

Simon schrieb:
> Machen wir doch mal nen simples Beispiel. du willst ein Datum/Uhrzeit
> per UART ausgeben. Dann wird man das umrechnen müssen, da führt doch
> kein weg mehr daran vorbei.

Eben nicht ;-)
Es ist doch viel einfacher, wenn du die Ziffern schon separiert (BCD) 
vorliegen hast.

Simon schrieb:
> Machen wir doch mal nen simples Beispiel. du willst ein Datum/Uhrzeit
> per UART ausgeben. Dann wird man das umrechnen müssen, da führt doch
> kein weg mehr daran vorbei.

Kommt drauf an. Bei reiner Ausgabe (und keiner Rechnung) reicht einfach 
die Ausgabe in Hex - welche auf vielen µCs einfacher als in Dez ist.

Sag ich doch. Viel einfacher ;-)

Also es hat schon einen Grund, warum das Format so ist wie es ist.
Auch wenn das wie Peter D. anmerkte vielleicht nicht so "modern" ist.
Ganz schlecht ist es auch nicht. Sonst gäbe es nur noch RTCC die 
Sekunden-Formate von einem best. Zeitpunkt aus verwenden.