[solved] Nano Every - Stromaufnahme begrenzen?

Doc_Arduino:
hast du die Registeremulation im Boardmenü ausgeschalten?

Ja, schon deshalb, weil da eben die Chipbezeichnung steht und ich nicht den 328 verwende, war wohl Intuition :smiley:

Was hätte den rauskommen sollen? Bzw was hast du erwartet?

@TO: Du hast aber schon gesehen, dass bei dem von Dir verlinkten Modul absolut gar nix von 12 V in den technischen Angaben steht?? Da steht ganz klar: 2-10V.
Hast Du das richtige Modul verlinkt, oder nimmst Du es einfach hin, dass Dir evt, das Modul hopps geht, wenn Du das mit 12V beaufschlagst?

Ach ja, falls Du wirklich das verlinkte Modul benutzt, ist der Schaltplan eben nicht ok. Wil Spannungsversorgung so nicht zulässig.
LG Slefan

Hi Deltaflyer!
Jou, habe ich gesehen. Ich hatte das kleine Ding 48h dauerbelastet mit 100mAh und 12V. Kein Schaden, es wurde nur warm (sehr :slight_smile: ). Somit hat es für mich den haltbarkeitstest bestanden. Zusätzlich möchte ich ergänzen, dass 12V das absolute Limit ist, womit ich das ganze befeuern wollte - jetzt bin ich auch auf 7V runter: Also alles "safe".

Trotzdem danke für den Hinweis!

Ja, das ist besser für das Modul. Du musst noch was anderes bedenken: Selbst wenn Dein Netzteil noch so präzise auf die 12V eingestellt ist, Da du nen Motor am Modul hast, und dieser Motor auch ein sehr guter Generator ist, kann dieser , wenn , z.B im Moment des Abbremsens der Motor an der Welle angetrieben wird, daus den 12V sehr schnell auch sehr viel mehr als 12 V generieren.
Da sagt so ein 'Leerlauftest' absolut gar nix aus, da diese 'Testbedinung kaum was mit dem realen Betrieb zu tun hat.

Hast Du bei dem 12V Stepper mit 7V noch ausreichend Drehmoment, um dein Projekt anzutreiben?

LG Stefan

Doc_Arduino:
Sorry wenn ich Partei für die neuen Controller ergreife, ich finde die richtig geil,

Der Nano-Every ist ja auch sicher ein interessanter und preislich attraktiver Baustein. Aber er ist eben kein - auch wenn es der Name suggeriert - Nano. Daraus werden viele Probleme resultieren, wenn man das voraussetzt. Auch praktisch alle HW-nahen Libraries ( ausser natürlich denen, die im Core mitgeliefert werden ) laufen darauf nicht. Und eine Portierung ist nicht immer simpel - dazu sind die Unterschiede zu groß.
Alles in allem ist er sicher der deutlich leistungsfähigere Baustein ( was Speicher und Peripherie angeht ) - aber eben nicht kompatibel zum Nano. Deshalb wird es wohl noch etwas dauern, bis er sich in der Breite durchsetzt und den Nano ablöst.

Eine andere Frage ist allerdings, weshalb es hier mit Nano funktioniert, und mit Nano-Every nicht. Denn in dieser Anwendung sehe ich jetzt erstmal keinen relevanten Unterschied.

Hallo,

Ja, schon deshalb, weil da eben die Chipbezeichnung steht und ich nicht den 328 verwende, war wohl Intuition.
Was hätte den rauskommen sollen? Bzw was hast du erwartet?

Ich habe ein BOD Level von 2,6V oder 4,3V erwartet. Wenn die 0 Werte also demnach korrekt sein sollten, dann läuft der Every ohne jede Spannungsüberwachung, weil komplett abgeschalten, kann demnach bei zu niedriger Spannung nicht reseten und muss damit am Ende mit unzureichender Ub zwangsweise Mist machen. Mich wundert das es beim originalen Arduino abgeschalten ist. Das Gute ist, man kann es zur Laufzeit ändern.

Das CLKCTRL.MCLKCTRLB den Wert 0 ausgibt stimmt so erstmal, der Taktgeber läuft ohne Prescaler.

Ich werde dir die Tage einen Code fertig machen womit du verschiedene Einstellungen testen kannst.
Dann siehst du wann er resetet wenn die 12V Mist machen.
Ich möchte ihn ungern ungetestet rausgeben.

@ Microbahner:
Das soll aber jetzt kein Grund sein auf immer und ewig auf die alten Controller angewiesen zu sein?
Ich meine, schau dir die ESPs an, was dort schon angepasst wurde.
Wenn man sich die neuen megaAVR0 und die neuen tinyAVR1 einmal genauer anschaut, stellt man fest, dass die Register aufgeräumt wurden. Man hat damit weniger Wartungsaufwand. Dort hat jemand so richtig mitgedacht. Wer verschiedene Typen supporten muss hat es mit den Neuen um Welten einfacher.

MicroBahner:
Der Nano-Every ist ja auch sicher ein interessanter und preislich attraktiver Baustein. Aber er ist eben kein - auch wenn es der Name suggeriert - Nano. Daraus werden viele Probleme resultieren, wenn man das voraussetzt. Auch praktisch alle HW-nahen Libraries ( ausser natürlich denen, die im Core mitgeliefert werden ) laufen darauf nicht. Und eine Portierung ist nicht immer simpel - dazu sind die Unterschiede zu groß.
Alles in allem ist er sicher der deutlich leistungsfähigere Baustein ( was Speicher und Peripherie angeht ) - aber eben nicht kompatibel zum Nano. Deshalb wird es wohl noch etwas dauern, bis er sich in der Breite durchsetzt und den Nano ablöst.

Eine andere Frage ist allerdings, weshalb es hier mit Nano funktioniert, und mit Nano-Every nicht. Denn in dieser Anwendung sehe ich jetzt erstmal keinen relevanten Unterschied.

Ja ich finde den auch cool, finde aber, dass Arduino hier in der Pflicht steht, wenn sie das Teil schon als original Arduino lancieren, dass es eben auch vernünftig in die original-Arduino Umgebung einzubinden.
Oder dann im Shop hinschreiben "kann mit erheblichen einschränkungen in der Arduino-Umgebung genutzt werden. Sonst ist das, als würde man nen Sportwagen anbieten, der jedoch nur für ein par Platzrunden vor dem Haus zu gebrauchen ist.
Wenn ich schon ein Original kaufe, möchte ich es auch in/mit der original Umgebung nutzen können.

bie irgend nem billigen china nachbau/clon rechne ich damit, dass da mal inkompatiblitäten oder fehlende Unterstützung durch die Original-Umgebung auftreten können - dieses Risiko erkaufe ich mir ja durch den unverschämt günstigen Preis. Bei einem Original erwarte ich entsprechende Unterstützung durch den Hersteller.

LG Srefan

Naja, in die Arduino Umgebung ist er mMn schon ordentlich eingebettet. Aber das ist ja nicht alles. Diese Aussage:

If you used Arduino Nano in your projects in the past, the Nano Every is a pin-equivalent substitute. Your code will still work, ...

finde ich deshalb etwas gewagt, und kann eher zu Frust und Ablehnung führen, wenn man denn mal reingefallen ist. Es wird so getan, als wäre er absolut kompatibel und es steht eben nicht dabei, dass das nur für die Libs aus der IDE gilt. Bei allen anderen kann es funktionieren, muss aber nicht.

Bei allen anderen kann es funktionieren, muss aber nicht.

In den Lib Properties gibt es ein Feld, wo man den µC Type eintragen kann.
Wenn der Libersteller dort ein * statt AVR einträgt, kann man das nicht Arduino anlasten!

Ich finde es gemein, den erstbesten zu erschießen, nur weil man meint, dass er Schuld ist.
Etwas tiefer sollte man da schon schauen.

Hi

Naja - Die Tradition, den Boten zu erschießen ist ja nicht von ungefähr zur Tradition geworden.
Nicht, weil's einfach richtig ist - aber es ist richtig erfrischend einfach.

Das Problem bei den Libraries sehe ich darin, daß man (also z.B. ich) meine Kreation vll. auf drei Arduinos getestet habe - wovon Uno und Nano nahezu identisch sind - einziger Ausrutscher wäre dann wohl der Mega.
Somit müsste ich meine Lib ausschließlich für diese Drei 'freigeben' - oder zumindest eine Warnung raus hauen, wenn Da 'was Anderes' daher kommt.
Da meine Libs bisher nur an meine Arduinos gelassen wurde, fehlt diese Überprüfung sogar gänzlich - nun bin ich nicht der Nabel der Welt - aber anscheinend ähnlich faul :wink: gestrickt wie so ziemlich der Rest der Welt.
"Funktioniert bei mir - Wer's gebrauchen kann - Bitte" ist dann zwar ganz nett gemeint, aber leider in den Tiefen nicht wirklich hilfreich.
Wenn's läuft - ist's eh egal - daran stört Sich Keiner.
Wenn aber NICHT, ist das Geschrei auch schon da.

MfG

Hallo,

ich glaube man sollte grundlegend unterscheiden zwischen Arduino und deren Libs und den Libs von anderen Leuten. Solange man nur die Arduino Funktionen verwendet hat, funktioniert alles wie gehabt. Sobald aber jemand in seiner Lib Hardware nah programmiert hat, ja dann ist es logisch das mit neuen Controller nichts mehr funktioniert. Seitens Arduino funktioniert alles. Ich stelle es natürlich jeden frei sich nicht mit neuen Controller zu beschäftigen. :grin:

Was ich eigentlich schreiben wollte ...

Zum Glück habe ich nichts voreilig verkündet. Aktueller Stand ist.
Man kann zwar die Fuses zur Laufzeit einstellen, ja, aber das macht keinen Sinn. Denn nach Reset werden die Einstellungen der Fuses geladen und damit würde der Test keinen Sinn machen, wenn die auf 0 stehen. Weil er kann nicht sauber starten wenn die Spannung zu niedrig ist, er aber mit 20MHz takten soll. Also müssen die Fuse geändert werden. Das geht nur mittels UPDI.

Die Fuse von meinem nackten ATmega4808 kann ich mit der Arduino IDE, der Boarderweiterung MegaCoreX von MCUdude und meinem jtag2updi Programmer ändern. Das sollte auch mit einem Arduino Nano Every laut Beschreibung funktionieren - ohne zusätzlichen Programmer.

Ich guck morgen noch in der Arduino IDE Installation nach, was dort beim flashen für die Fuses original für den Every vorgesehen ist. Vielleicht kann man auch hier ansetzen. Wenn ja, bräuchte ich dabei sicherlich Hilfe die IDE anzupassen. Wobei die MegaCoreX Erweiterung auch schnell hinzugefügt ist. Mal sehen ...

Hallo,

das mit den Arduino Nano Every Fuses ist anders wie bisher gelöst. Es gibt keine Settings in der boards.txt. Es gibt eine Datei Namens fuses_4809.bin. Hat jemand eine Idee wie man in eine .bin Datei schauen kann? Ist 9 Byte groß. Mit 7zip gehts nicht. Ich hänge die mal ran. Ich möchte herausfinden ob original wirklich nichts eingestellt ist oder doch.

fuses_4809.zip (173 Bytes)

Hi

Ok - die 9 Byte lassen Sich schauderlich zippen :wink:
Drin steht:
00 00 01 FF 00 CD 00 00 02
(GHex auf Linux Mint)

MfG

Doc_Arduino:
Hat jemand eine Idee wie man in eine .bin Datei schauen kann?

Ein beliebiger HEX-Editor.

Gruß Tommy

Besten Dank.

Ich wollte da keinen empfehlen, da die Vorlieben doch teilweise stark auseinander gehen.

Gruß Tommy

Tommy56:
Ich wollte da keinen empfehlen, da die Vorlieben doch teilweise stark auseinander gehen.

Dann mache ich das: PSPad

Ja natürlich ist es böse , den Boten zu erschiessen, nur liegt es eben meiner Meinung nache eben auch in der Verantwortung des Herstellers/Vertreter des Originalproduktes, dafür Sorge zu tragen, dass seinem Boten sowas schreckliches nicht passiert, in dem er bei seinen Produkten entsprechende Vorsicht und Umsicht walten lässt.

LG Stefan

nur liegt es eben meiner Meinung nache eben auch in der Verantwortung des Herstellers/Vertreter des Originalproduktes, dafür Sorge zu tragen, dass seinem Boten sowas schreckliches nicht passiert, in dem er bei seinen Produkten entsprechende Vorsicht und Umsicht walten lässt.

Das ist mir zu diffus!

Welches konkrete Problem meinst du?

Hallo,

ich weiß ja durchaus was Deltaflyer und andere meinen. Aber die Anschuldigung an die Adresse von Arduino.cc zu schicken ist falsch. Weil ihre Produkte laufen in ihrer Umgebung. Support für fremde Libs können sie nicht geben. Wie auch. Genau wie der Arduino Due läuft und sehr speziell ist.

Ohne konkrete Bsp. sage ich dazu nichts mehr.

Wegen Hex Editor musste dir keinen Kopf machen - Tommy. Hatte dann noch HxD entdeckt.
PSPad ist ja schon eine halbe IDE. :wink:
Programmierst du combie mittels Arduino IDE und diesem externen Editor?

Jetzt kümmere ich mich erstmal um die Fuse Bits mit ihrer verdrehten Logik ...