Zahlenschloß mit einamliger Kombination

[kunnotto]

Hallo zusammen,

ich hatte eine Idee, von der ich nicht weiss, ob und/oder wie sie sich realisieren lässt. Ich würde gerne einen Atmel µC (ATTinyXX, oder ATMegaXX) so programmieren, dass man eine bestimmte Zahlenkombination eingeben muss um weitere Bedingungen zu erfüllen (Zahlenschloß). Diese soll mit einer Kobination aus einem definierten Pool verglichen werden. Wenn es sie gibt, ist die Bedingung erfüllt. Jetzt soll allerdings auch diese Kombination aus dem Pool gelöscht werden, damit sie nicht mehr funktioniert. Ist das möglich? Und wenn ja, wie?

Die Eingabe erfolgt über ein Numpad mit 3x4-Matrix ggf erfolgt eine Textausgabe über ein LCD. Die Abfrage des Numpads und die Ansteuerung des LCDs dürfte ich anhand der Bascom-Doku noch hinbekommen, des Rest leider nicht

Hat hier jemand die Muße mir dabei zu helfen?

[schnasemann]

im eeprom die möglichen Kombinationen ablegen und wenn die Kombination eingegeben wurde, diese mit einem "magischen Byte" überschreiben. Bei jeder Eingabe werden es dann aber weniger Möglichkeiten.

[kunnotto]

Ok, das hab ich verstanden. Aber wie?
Was ist ein "magisches Byte"?

Inzwischen bin ich ja lernbereit, aber völliger Noob

[KoenigDickBauch]

Was ist ein "magisches Byte"?

42 ist doch klar oder?

[huzzel]

Frage 1: Wie viele Stellen soll die Zahl haben?
Frage 2: Nach wie vielen Eingaben, willst Du eine Wartung machen? (wie willst Du die Anzahl der Eingaben kontrollieren??)

zu 1: alles größer der Zahl 255 erfordert min 2 Byte und da ist der Speicher schnell voll
zu 2: Wenn Du sicher sein willst, dann lasse die Zahl durch Berechnung überprüfen (z.B.

Code: Alles auswählen

if Eingabe mod 147 = 97 then
   goto ok
else 
   goto Fehler
end if

[chrysophylax]

Ich weiß ja nicht, wie viele Zahlen es so sein sollten.... Mein Vorschlag wäre, irgendeinen 16bittigen unsigned-Variablentyp zu nehmen. Das ist im Prinzip dann eine 5stellige Zahl zwischen 0 und 65535. Die Megas sind ja reichlich mit Speicher gesegnet - wenn du 256 Byte EEPROM über hast, dann würd ich die opfern um mir eine "Auskreuz-Tabelle" zu machen für 256Byte á 8 Bit = n = 2048 mögliche Zahlenkombinationen. Ist ein Bit gesetzt, wurde die Zahlenkombi Nr. n schonmal verwendet - ist also ab sofort nicht mehr gültig. Hat den charmanten Vorteil, daß durch welchen Unfall auch immer gelöschte EEPROM-Bytes automatisch sagen "Zahlen sind nicht mehr gültig".

Und irgendwo in den obersten 4kB deines Programmspeichers legst du dir eine Tabelle mit 2048 Einträgen aus 16Bit-Zahlen als Konstanten hin. Die kannst du dir dann in einem schleifentechnisch möglichst einfachen Schema deiner Auskreuztabelle im EEPROM zuordnen (z.B. Byte0 sind die Einträge 1..8, Byte 1 sind die Einträge 9..16, Byte 2 sind die Einträge 17..24 usw.) und wenn jemand eine Zahlenkombi eingibt ziemlich flott durchsuchen.

Ist die Zahlenkombi sowohl im Flash vorhanden als auch im EEPROM nicht ausgekreuzt, dann ist sie gültig, wird für dieses eine Mal akzeptiert, und direkt im EEPROM ausgekreuzt.

So kombinierst du die relativ hohe Anzahl an möglichen Schreibzyklen im EEPROM am elegantesten zusammen mit der großen Speichermenge des Flash-Programmspeichers, den man allerdings nicht so oft beschreiben kann und sollte.

Je nach verwendetem Prozessor kann man das Ganze natürlich noch beliebig rauf- oder runterskalieren (128 Byte EEPROM und 2kB Programmspeicher geben 1024 Zahlenkombis, 512 Byte EEPROM und 8kB Programmspeicher geben 4096 Zahlenkombis, etc....)

Die Atmegas sind ja ziemliche Rechensäue, ich würde mir also beim Test auf "gültige" Zahlenkombis gar nicht so viel Mühe machen und kackfrech und gnadenlos jedesmal die komplette Tabelle im Flash durchsuchen. Wenn kein Treffer vorliegt, war die Kombination nicht gültig. Wenn ein Treffer vorliegt als nächstes im EEPROM schauen, ob er schon ausgekreuzt ist - wenn ja, ist die Kombination nicht MEHR gültig. Wenn er noch nicht ausgekreuzt ist auskreuzen und rückmelden "paßt!". Keine Ahnung wie lange das in Basic dauert, in Assembler sind Millisekunden. LPM ist ziemlich flott, und 16Bit-Arithmetik geht mit den AVRs auch recht dankbar.

Hoffe, geholfen zu haben.....

chrysophylax.

[radioscout]

Du solltest, wenn eine bestimmte Zahl nur einmal verwendbar ist und die Reihenfolge relevant ist überlegen, wie Du mit dem Fall umgehst, daß eine Zahl z.B. nicht verwendet wurde oder die Zahlen in einer anderen Reihenfolge verwendet werden als sie ausgegeben wurden.

[kunnotto]

Oha, das war jetzt mehr Input als ich erwartet hatte.

@KoenigDickBauch: Klar, aber wenig hilfreich

@huzzel: 5-Stellig wäre gut. Wenn nur zehn Kombinationen im Speicher wären, wäre das völlig ausreichend.

@chrysophylax: Liest sich alle wunderschön was Du geschrieben hast, aber was hast Du gesagt? Aber mal im Ernst: Ich kann Dir in der Theorie schon folgen was Du meinst, hab aber nicht die geringste Ahnung wie das umzusetzen ist, da ich ziemlicher Noob bin. Assembler zu lernen scheidet aus, dafür bin ich zu alt und hab zu viel zu tun. Mit Basic bekomme ich mich wohl halbwegs durchgewurschtelt.

Gibt es gute Quellen (Netz, tote Bäume u.ä.) wo man sich zum Thema einlesen kann, die nicht ein Studium der Elektrotechnik oder Nachrichtentechnik vorraussetzen?

@radioscout: Die Reihenfolge ist nicht relevant.

Danke jedenfalls für Eure Antworten bisher. Ich hoffe ihr helft mir noch weiter

[KoenigDickBauch]

@KoenigDickBauch: Klar, aber wenig hilfreich

Wieso, man überschreibt die gebrauchte Zahl mit 42 und die 42 wird als Code von Hause aus nicht benutzt. In so einer einfachen Antwort steht doch alles drin.

[chrysophylax]

Oha, das war jetzt mehr Input als ich erwartet hatte.

Besser als zuwenig

@huzzel: 5-Stellig wäre gut. Wenn nur zehn Kombinationen im Speicher wären, wäre das völlig ausreichend.

Huch, das ist ja ein Hauch von gar nichts. Die paar Zahlen kannst du dir auch direkt im EEPROM merken - genau das Verfahren, was weiter oben mit dem magischen Byte vorgeschlagen wurde - auch wenn ich immer noch für eher 16bittige Werte plädieren würde. Mal ganz ehrlich - eine 3stellige Kombination für ein Zahlenschloß ist doch eher, äh, harmlos. Ich frage mich mehr, wie häufig du das Ding "warten" willst, wenn du alle 10 Dosensucher einmal einen Satz neue Zahlen reinprogrammieren mußt

@chrysophylax: Liest sich alle wunderschön was Du geschrieben hast, aber was hast Du gesagt? Aber mal im Ernst: Ich kann Dir in der Theorie schon folgen was Du meinst, hab aber nicht die geringste Ahnung wie das umzusetzen ist, da ich ziemlicher Noob bin. Assembler zu lernen scheidet aus, dafür bin ich zu alt und hab zu viel zu tun. Mit Basic bekomme ich mich wohl halbwegs durchgewurschtelt.

Nunja, mein Problem ist, daß ich mich mit Bascom überhaupt nicht auskenne. Ich habe bisher AVRs immer nur in Assembler programmiert, und werde wohl notgedrungenermaßen irgendwann in den nächsten (einstelligen) Wochen einen Code in C für AVR zur Pflege und Einarbeitung bekommen, dann könnte ich dir irgendwann in C weiterhelfen....

Wenn das Prinzip halbwegs verstanden ist, dann dürfte es hier genügend Leute geben, die dir helfen können, das in Basic zu formulieren. Konstanten und Tabellen im Flash scheint unglaublich einfach zu sein - weil nämlich die Standardeinstellung von Bascom. Guckstu hier. Tabellen im EEPROM ist wohl ähnlich einfach, du machst dir einfach ein Array und deklarierst das als eram. Guckstu hier. Da du beides brauchst, wird dir hoffentlich irgendein Bascom-Howto verraten, wie man vor dem .data deklariert, ob und was im EEPROM und was im Flash liegen soll. Das bißchen Schleife und Zählen was noch überbleibt wird wohl hier mit gemeinschaftlichen Kräften lösbar sein.....

Gibt es gute Quellen (Netz, tote Bäume u.ä.) wo man sich zum Thema einlesen kann, die nicht ein Studium der Elektrotechnik oder Nachrichtentechnik vorraussetzen?

Ich bin ja immer ein Freund von toten Bäumen - die kann man sich neben den Rechner legen und hat nicht immer gleich den halben Bildschirm belegt, wenn man mal was nachschlagen will. Auch Eselsohren und gelbe Nervzettel funktionieren in toten Bäumen besser als in LCDs. Eine bevorzugte Sorte kann ich dir da nicht empfehlen, weil Bascom überhaupt nicht meine Baustelle ist - Schuß ins Blaue: Schonmal geschaut, ob es "Bascom für Dummies" gibt ? Die "...für Dummies"-Bücher gibts doch für Alles, vielleicht auch dafür ? Ansonsten führt der googlehupf recht häufig zum mikrocontroller.net, da bist du unter Horden anderer Hobbybastler relativ gut aufgehoben und findest vielleicht auch jemanden, der dir helfen kann.

chrysophylax.