Hallo, ich habe ein Problem: zur Zeit bastle ich an einen Funktemperatursensor, der die Daten per NRF24L01+ verschickt. Das verschicken läuft auch soweit. Die bisherigen Routinen brauchen ca 1,45 kB (ich hab auf meinem tiny2313A insgesamt 2 kB - da braucht ihr nicht erst ins Datenblatt zu gucken :) ). Nun habe ich die DS18S20 Lib von Stefan Sicklinger eingebunden und compilliert: 6 kB Codegröße. Das ist villeicht - etwas - zu viel für meinen tiny. Hat jemand eine 1W oder DS18x20 Lib, die <= 500 Byte, villeicht, wenn ich den restlichen Code optimiere, auch 700 Byte groß ist? Selber möchte ich die Routine nicht schreiben, weil ich bezweifle das bei meinem Programmier-Stil ich unter die "magischen" 500 Byte komme. PS: Optimierung steht auf Os
Gast
#3623980
Sorry, aber was soll an der Abfrage eines Temperatursensors so viel Speicherbedarf erfordern. Wenn es hoch kommt 200 Byte. Zumal du die komplette Kommunikation in 1,5kB realisiert hast, was mMn wesentlich umfangreicher ist. Das sollte dir zeigen, dass mit dem Code was nicht optimal läuft. Als Alternative könntest du statt 1W auch I²C (bei Atmel heißt das glaube ich TWI) nehmen. Das ist noch mal ein ganzes Stück einfacher weil die Kommunikation simpler ist. I²C sollte auch bei Atmel zum Standard gehören.
Jens schrieb: > Sorry, aber was soll an der Abfrage eines Temperatursensors so viel > Speicherbedarf erfordern. Wenn es hoch kommt 200 Byte. Keine Ahnung. Der Code kann hier heruntergeladen werden: http://www.sicklinger.com/en/component/remository/func-startdown/4/?Itemid=54 Das mit dem I2C kapier ich gerade nicht. Falls ich es vergessen hab zu erwähnen, ich hab einen DS18S20 Temperatursensor. Der läuft nur mit 1W. Und falls du meinst, das ich die 1W über das I2C Interface abfragen soll, dann geht das in meinen Fall auch nicht, weil das USI schon durch das NRF24L01 belegt ist.
Es gibt den Tiny4313. Wo ist das Problem? Oder Tiny167 oder Tiny841. Für Einzelstücke ist es sinnlos, auf den letzten Cent an Bauteilkosten zu optimieren. fchk
Frank K. schrieb: > Es gibt den Tiny4313. Wo ist das Problem? - Auch nur 4K Flash - Gibts nur bei Pollin, wollte ich vorerst nicht bestellen > Oder Tiny167 oder Tiny841. - Zahlst du mir die Versandkosten von Mouser oder Digikey?
Gast
#3624014
Peter K. schrieb: > - Zahlst du mir die Versandkosten von Mouser oder Digikey? Wieviel Zeit kostet es dich, eine andere Lösung für dein Speicherproblem zu finden, welchen persönlichen Stundenlohn rechnest du und was kostet der Versandanteil, wenn du dich an eine Sammelbestellung hier im Markt ran hängst? Bestell dir gleich ein paar mehr. Dann stehst du beim nächsten Projekt nicht wieder vor dem gleichen Problem.
Peter K. schrieb: > Frank K. schrieb: >> Es gibt den Tiny4313. Wo ist das Problem? > - Auch nur 4K Flash > - Gibts nur bei Pollin, wollte ich vorerst nicht bestellen > >> Oder Tiny167 oder Tiny841. > - Zahlst du mir die Versandkosten von Mouser oder Digikey? Nö. Ich hätte für den Anfang einen PIC24FV32KA301 genommen und am Schluss geschaut, ob es auch ein kleinerer getan hätte. Für ein Einzelstück ist das eine sinnvolle Vorgehensweise. fchk
Das Problem ist, das es eine geätzte Platine ist. Die Frage war nur, ob jemand eine kleine 1W Lib hat, nicht nach alternativen Mikrocontrollern. Falls es wirklich nichts wird hab ich sowieso einen Plan B: Mega 8/16 auf neuer Platine. Und PIC sowieso nicht. Ich hab inzwischen eine ganz ordentliche Atmel-Ausrüstung.
Gast
#3624027
Lasst die Finger von diesen Tinies. Die bringen nichts. Was sollen die 20 Cents pro Stueck, die gespart werden? Ich habe meinen Standard im TQFP44 Gehauese. Den Mega644P. Den kaufe ich fuer 4.65, was soll's. Die schematischen Ausschnitte und die Pcb Ausschnitte sind auch immer dieselben, so ein geht ein Design flot. Der Code ist auch immer aehnlich, auch nur Copy-Paste.
Ich weiß, ich weiß. Im Nachhinein war das eine blöde Idee mit den Tinies, u.a. auch weil mich das USI am Anfang blockiert hat. Ich möchte, wenn es geht, aber gerne vermeiden eine neue LP zu ätzen.
Probiers doch mit der Library: http://www.dietfig.org/avronewire.html
Wenn du nur einen ds pro tiny hast (danach klingt deine Beschreibung), dann kannst du direkt mit "skip-rom" lesen und schreiben. Das spart massiv Speicher.
Max D. schrieb: > Wenn du nur einen ds pro tiny hast (danach klingt deine Beschreibung), > dann kannst du direkt mit "skip-rom" lesen und schreiben. Das spart > massiv Speicher. Sorry, ich arbeite eigentlich nicht mit 1W. Hast du Beispiele?
Bei 1W hängen alle (viele) Devices am Bus. Damit man mit einem spezifischen Device reden kann werden am Anfang alle Devices über einen binären suchbaum ermittelt und gemerkt. Hat man nur ein Device kann man sich das sparen. Am Ende von Seite 18 im Datenblatt ist dafür ein Beispiel.
Hi, im Anhang mal meine Routinen. Mit CRC-Prüfung der Daten und Auswahlmöglichkeit des Sensors (DS18S20 oder DS18B20). Codeverbrauch: 562 Byte für die beigefügte Beispiel-main() in der Header-Datei kann wenn nötig
1 | |
einkommentiert werden (wenn du die ROM-ID des Sensors lesen möchtest). Dann braucht das Programm 646 Byte. Mit leerer main-Funktion sind es 538 Byte. lg Chris edit: du kannst ja wenn nötig noch die CRC-Prüfung rauswerfen, dürfte auch nochmal ein bisschen Code sparen. Oder die Unterscheidung der Sensortypen in der Auswertefunktion, und dort nur deinen verwendeten Sensor behandeln
Hallo, mit dem "bereinigten" Code von Chris und mit -O1 (statt -OS) passt es jetzt mit ca 1,8 kB.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.