Fumot Tornado 25000 mit LCD -Teardown

[Kilo S. (kilo_s)]

Neues vom "E-Zigaretten Recycling".

Fürs erste nur kurz eine minimale Beschreibung, weiter bin ich gerade 
nicht.

Hardware:
P25Q128HA - Nor Flash.
PY32F030K28 - MCU

Display - Noch nicht genau ergründet, hat aber einen beschrifteten 
connector. I2C Bus steht schon mal fest!
Touch - Muss ich noch schauen, vermutlich morgen genaueres.

Unter dem flex vom LCD liegt RST, RX,TX und Boot.

Schön einsammeln Freunde! Gratis Displays!
Bilder mach ich morgen welche bei gutem Licht!

Ich schau mal was die Möhre auf der seriellen quatscht.

[Matthias S. (Firma: matzetronics) (mschoeldgen)]

...und das scheint ja sowas wie ein 160x240 Pixel Farbdisplay zu sein 
(!)
Die haben doch einen an der Waffel. Versteh mich nicht falsch, für 
Bastler super - aber als Wegwerfware ist das doch Verschwendung pur.
 Aber mit LiIon Akku, Ladeschaltung und noch einer Leistungsendstufe und 
ein paar Knöpfchen fast schon fertige Hardware fü alles mögliche.
Widerstandsheizung oder Induktion?

[Kilo S. (kilo_s)]

Matthias S. schrieb:
> Widerstandsheizung oder Induktion?

Widerstand.

Naja, Stiller Zeitgenosse. Auf der seriellen ist nix.

Ich würde halt fast wetten die haben (laut übersetztem DB) RDP/WRP für 
den internen Speicher des MCU gesetzt. Somit dürfte das erneute 
verwenden des Cortex M0+ der da werkelt vermutlich eher nicht möglich 
sein.
(oder kennt jemand einen Trick?)

Morgen geht's weiter. Irgendwie hab ich einen R an Boot0 in Verdacht der 
verhindert das ich in den Bootloader komme.

Selbst wenn ich nur den Touch (Separates PCB, Ttp223! Sicher sogar, sind 
0,08€ teure Sensormodule) LCD und den Flash benutzen kann. Das Zeug 
liegt GRATIS auf der Straße!

Das sind alleine die LCD wert aufgesammelt zu werden und ausnahmsweise 
haben sie es ja einfach gemacht: Beschriftung auf dem PCB.

[Kilo S. (kilo_s)]

Ach kommt, zwei schnelle snappschüsse. ;-)

[Kilo S. (kilo_s)]

Und das LCD, ich sollte um die Zeit wohl keinen Kaffee mehr Trinken... 
:-D

[Kilo S. (kilo_s)]

Halt, will ja nix vorenthalten.

;-)

[Harald K. (kirnbichler)]

Das ist Elektronik aus so einem Suchtnuckel, aber das ist ja wohl einer 
zum Nachfüllen, denn wozu sonst sollte der eine USB-C-Buchse haben, mit 
der man den Akku wieder aufladen kann?

Insofern werden diese Drecksdinger nicht in der gleichen Menge in die 
Pampa geworfen wie die Einweg-Suchtnuckel.

Diese Menschen sind krank. Schwer krank.

[Matthias S. (Firma: matzetronics) (mschoeldgen)]

Harald K. schrieb:
> wie die Einweg-Suchtnuckel

Die soll es bald nicht mehr geben, weil das ja noch mehr elende 
Verschwendung ist. Wimre wird die EU Einwegdampfer verbieten.

[.● Des|ntegrator ●. (Firma: FULL PALATINSK) (desinfector)]

aber Hauptsache man hat sich auf USB-C geeinigt,
wofür man sich ja ganz toll beweihräuchert.

[Kilo S. (kilo_s)]

Harald K. schrieb:
> Das ist Elektronik aus so einem Suchtnuckel, aber das ist ja wohl einer
> zum Nachfüllen,

Nein, ist er nicht!

Typ und Marke im Titel, das sind ALLES Einweg, der einzige Grund warum 
die Teile USB-C haben und den Akku laden können ist weil das Ding 25.000 
Züge beherbergt. Das schafft ein so kleiner Akku natürlich nicht ohne 
nachgeladen zu werden.

[Kilo S. (kilo_s)]

Hier ist das Gehäuse mit Tank zu sehen. Ein mal Vorderseite und 
Rückseite.

Theoretisch (pinker Deckel, an der Rückseite entfernen und der Tank 
liegt frei) könnte man den nachfüllen. Aber auch wenn der Trend dazu 
Grad online die Runde macht, das ist ekelhaft!
Wie lange die Watte in den Heitzelementen unverkohlt bleibt ect. Und die 
Heitzwendeln lassen sich nicht tauschen ohne riesen Sauerei.

[Rene K. (xdraconix)]

Kilo S. schrieb:
> Wie lange die Watte in den Heitzelementen unverkohlt bleibt ect

So lange wie genügend Liquid enthalten ist - garnicht.

Ich dampfe mit einem Voopoo Drag M100S Smart - also ein Mehrwegdampfer 
mit einem UFORCE Kopf. Der Drag erkennt die Coils anhand ihres 
Widerstandes automatisch und stellt sich darauf ein. Im Grunde, wie 
schon gesagt, braucht der Coil - solange er nicht trocken betätigt wird 
- garnicht gewechselt werden. Ich wechsle dennoch alle 50k Züge.

Und man muss mal sagen, ich dampfe relativ viel, den Drag habe ich jetzt 
ein Jahr und genau 97.727 Züge gemacht. Aber 25.000 Züge von diesem 
Fumot sind schon extrem viel für ein Einwegdampfer. Das Ding hält dicke 
5-6 Monate - so oft wird man den mit Sicherheit nicht finden.



Harald K. schrieb:
> Suchtnuckel

Lass mich raten: du rauchst nicht, du trinkst kein Alkohol und Zucker 
ist dir auch völlig fremd?! ;-)


Btw.: ich bin durch einen Schlaganfall von 2 Schachteln Zigaretten am 
Tag auf das Dampfen (natürlich ohne Nikotin) umgestiegen.

[Torsten B. (butterbrotstern)]

Auch die hochkapazitiven (25000 Puffs = Züge) Einweg-Dinger haben USB-C, 
weil dann können die Akkus kleiner (=billiger) sein. Und bei Fumot 
heißen die Typ-C-Anschluss und Typ-C-Schnellladung, vermutlich weil sie 
sich dadurch Lizenz-Gebühren sparen.

Folgende 2-Milliliter-Regelung habe ich nicht verstanden, dadurch erhöht 
sich doch der Einweg-Müll:
Zitat https://www.randmvape-shop.net/blogs/news/tornado-vape-kaufen
Warum sind Tornado-Vapes in Deutschland verboten?

Der Tornado Vape ist in Deutschland nicht generell verboten, allerdings 
gibt es strenge Vorschriften, die das Gerät in seiner aktuellen Form auf 
dem deutschen Markt einschränken. Ein Grund dafür sind die in 
Deutschland geltenden Regelungen zur E-Zigaretten-Nutzung. Die maximale 
Liquid-Menge in einem Einweg-Vape darf hier 2 ml nicht überschreiten. 
Der Tornado Vape, der bis zu 12.000 Züge bietet, enthält deutlich mehr 
als diese Menge und verstößt damit gegen die deutsche 
E-Zigaretten-Richtlinie.

Zudem gibt es Vorschriften bezüglich der Nikotinmengen, die in 
Vaping-Produkten erlaubt sind. Diese strengen Gesetze sollen den 
Verbraucherschutz stärken, insbesondere in Bezug auf minderjährige 
Nutzer. Deshalb sind viele Einweggeräte, die in anderen Ländern 
problemlos verkauft werden, in Deutschland nicht zugelassen.
Zitatende

Man kann sie dennoch kaufen. Bestellen oder "unter der Hand".

[Kilo S. (kilo_s)]

Rene K. schrieb:
> Das Ding hält dicke 5-6 Monate - so oft wird man den mit Sicherheit
> nicht finden.

Der Kollege der mir den gab, hatte ihn ca. Ne Woche.
Glaub mir die Teile gehen hier an den Kiosken Rum, an Jugendliche 
verkauft, ohne Skrupel. Die halten nicht lange, da nuckeln dann 1000 
Leute dran:"Probier mal".

Und je nach dem wie schnell und lange da wer dran zieht. Ich hör öfter 
mal:"Schmeckt verbrannt". Ich bekomm die ja regelmäßig für die Akkus von 
Freunden und Bekannten.

Rene K. schrieb:
> Voopoo Drag M100S Smart

Smog Mag GRIP 225TC, Kopf weiß ich Grad nicht auswendig, einfaches 
Modell mit Dual Coil.

Benutze ich aber kaum, dampfen ist schön und gut, da hau ich mir aber 
immer zu viel Nikotin rein. Irgendwie bin ich da einer "dem fehlt da 
was". Schwer zu erklären.

Torsten B. schrieb:
> Man kann sie dennoch kaufen. Bestellen oder "unter der Hand".

Leider ja, das schlimmste ist das Gilt sogar für harmlos aussehende aber 
gar nicht so harmlose HHC Vapes. Ich hab die Dinger hier an einem Kiosk 
gesehen und mich gefragt:"HHC?"... Googelt mal, krass was sich so 
mancher da freiwillig in die Synapsen zwiebelt.

[Kilo S. (kilo_s)]

So, jetzt schau ich erst mal was sich an Boot0 noch so verbirgt.

Über 1k an VCC verbunden.

[Kilo S. (kilo_s)]

Hm, Boot0 auf GND bringt nix.

Das Teil spielt stur sein Programm ab.
Tipps wie ich den internen Schutz umgehen kann sind immer noch 
willkommen.

[Kilo S. (kilo_s)]

Display, natürlich hab ich den originalen connector irgendwo auf dem 
Tisch mit dem Ärmel mitgerissen und finde ihn nicht.

So hab ich mir was "Zusammengefummelt".

[Matthias S. (Firma: matzetronics) (mschoeldgen)]

Kilo S. schrieb:
> laut übersetztem DB

Datenblatt auf englisch gibts hier:
https://download.py32.org/Datasheet/en/PY32F030_Datasheet_V1.8.pdf

[Kilo S. (kilo_s)]

Matthias S. schrieb:
> Datenblatt auf englisch gibts hier

Vielen Dank!

Also, wo ich mir Recht sicher bin, ich hab gerade mit dem Diamantkopf 
die GND plane weggenommen, der Hersteller weiß zu verwirren!

Das wird doch SPI sein, I2C geht an den USB-C Port.

1.) GND

2.) LED-K

3.) LED-A

4.) GND

5.) RST

6.) ? (LCD-DCN = MOSI?)

7.) ? (MISO?)

8.) CLK

9+10.) VCC (3,3V)

11.) CS

12.) GND


Wenn ich nach der Auflösung suche lande ich bei einem Modul mit GC9A01 
Controller, das kommt dem sehr nahe.

[Matthias S. (Firma: matzetronics) (mschoeldgen)]

Das Problem beim PY32 scheinen die Option Bytes zu sein. Man hat einen 
Weg zu finden, an die ranzukommen.

[Kilo S. (kilo_s)]

Matthias S. schrieb:
> Das Problem beim PY32 scheinen die Option Bytes zu sein. Man hat einen
> Weg zu finden, an die ranzukommen.

Jepp, der war aber sowieso nicht der Grund für mein Interesse.

Verdammt, das Display ist ganz schön "Zickig".

Ich hab's jetzt mal versucht wie beim ST7735/89, immerhin, es wechselt 
zu "Grau" anstelle weiß.

Irgendwas hab ich noch nicht ganz richtig glaub ich.

[Matthias S. (Firma: matzetronics) (mschoeldgen)]

Kilo S. schrieb:
> Verdammt, das Display ist ganz schön "Zickig".

Kannst du nicht die Verbindungen vom LCD an den MC durchpiepsen?

[M. G. (looking)]

Kilo S. schrieb:
> Schön einsammeln Freunde! Gratis Displays!

Solch ein Exemplar würde ich gern auch mal finden! Leider habe ich hier 
auf dem Land aber bisher kaum E-Vapes in der Pampa gefunden, und wenn, 
dann die einfachen 0815-Teile ohne LED- oder gar LCD-Anzeige.

[Kilo S. (kilo_s)]

Matthias S. schrieb:
> Kannst du nicht die Verbindungen vom LCD an den MC durchpiepsen?

Hab ich. Ich hab sogar mit dem proxon die oberste Schicht abgetragen und 
so gut es eben ging durchleuchtet ect.

Daher kam ich ja zur Vermutung das es in Richtung ST77XX geht, DCN an 
SCL und Data an MOSI.
Scheint aber kein ST77XX zu sein ODER ich hab noch nicht die richtige 
Variante ausprobiert.

Ich scheine jedenfalls dem Rätsel auf der Spur zu sein. Ohne Ansteuerung 
bleibt es einfach Weiß, mit wird es zumindest schon mal Grau und 
flackert leicht. Es versucht also was zu tun.

Da bin ich zuversichtlich das auch noch Platinen von dem Modell 
Reinflattern, bis dahin muss ich mir noch einen LA besorgen.

Gleich löte ich erst mal den Flash um, reinschauen was da so drin ist.

[M. G. (looking)]

Matthias S. schrieb:
> Kilo S. schrieb:
>> laut übersetztem DB
>
> Datenblatt auf englisch gibts hier:
> https://download.py32.org/Datasheet/en/PY32F030_Datasheet_V1.8.pdf

Das Reference Manual liegt hier:
https://download.py32.org/ReferenceManual/en/PY32F030%20Reference%20manual%20v1.3_EN.pdf

In Kapitel 4.6.2 steht was zur Flash Read Protection. M.E. sollte es 
möglich sein, die Protection wieder rückgängig zu machen, wobei 
natürlich dadurch das on-chip Flash gelöscht wird. Aber der Chip müsste 
prinzipiell neu programmierbar sein.

[M. G. (looking)]

Kilo S. schrieb:
> Hm, Boot0 auf GND bringt nix.
>
> Das Teil spielt stur sein Programm ab.
> Tipps wie ich den internen Schutz umgehen kann sind immer noch
> willkommen.

Um in den Bootloader zu kommen, müsste BOOT0 auf HIGH gesetzt werden.
(Kap. 3.5. in 
https://download.py32.org/ReferenceManual/en/PY32F030%20Reference%20manual%20v1.3_EN.pdf)

Ebenfalls wichtig:
Es sind mehrere USART-Boot-Interfaces möglich. Die RX-Pins der nicht 
benutzten USARTs dürfen nicht floaten.
siehe Kap. 1 von UM1503:
https://download.py32.org/Tool/en/PY32_IspTool_V1.0.0/UM1503_PY32IspTool_User%20Manual%20V1.0_EN.pdf

ISP-Tool:
https://py32.org/tool/PY32_ISP.html

[Kilo S. (kilo_s)]

M. G. schrieb:
> In Kapitel 4.6.2 steht was zur Flash Read Protection. M.E. sollte es
> möglich sein, die Protection wieder rückgängig zu machen, wobei
> natürlich dadurch das on-chip Flash gelöscht wird. Aber der Chip müsste
> prinzipiell neu programmierbar sein.

Sehr cool! Danke.

Nu, is ja wurscht ob der inhalt danach weg ist!
Mein weg mit den MCU wäre so oder so der uber den Arduino kram:
https://github.com/py32duino/Arduino-PY32

Der inhalt des Flash, 16MB für eine verdammte E-Zigarette! Pffff!
Irgendwie geil für uns bastler, vor allem weil das OTP register komplett 
leer ist usw. Bis auf den inhalt ist der komplett jungfräulich!

[Kilo S. (kilo_s)]

M. G. schrieb:
> Um in den Bootloader zu kommen, müsste BOOT0 auf HIGH gesetzt werden.

OK, also wie es ursprünglich war. (1k an 3,3V)

M. G. schrieb:
> Ebenfalls wichtig:
> Es sind mehrere USART-Boot-Interfaces möglich. Die RX-Pins der nicht
> benutzten USARTs dürfen nicht floaten.

Das überprüfe ich bei der nächsten Platine.

Im allerschlimmsten notfall kauf ich (wenn bis dahin nicht eine 
reinflattert) mir einfach eine!

[M. G. (looking)]

Kilo S. schrieb:

> Im allerschlimmsten notfall kauf ich (wenn bis dahin nicht eine
> reinflattert) mir einfach eine!

Günstig sind die aber nicht ... ;-)

[Kilo S. (kilo_s)]

M. G. schrieb:
> Günstig sind die aber nicht ... ;-)

In etwa so viel wie ein Display Breakout auch. ~20€ wenn ich noch 
handeln kann eventuell auch weniger.

Hab bald Geburtstag, daher wird's von dem geld bezahlt.

[Kilo S. (kilo_s)]

Übrigens lohnt es sich auch die anderen Modelle zu Sammeln.

Wer die in Rund oder flach mit 12.000/15.000/20.000 Zügen und 
Charlyplexing für die Siebensegmentanzeige aufsammelt, da sitzen 
(SOP16/TSOP20) PY32F002 drauf.

[Matthias S. (Firma: matzetronics) (mschoeldgen)]

Kilo S. schrieb:
> M. G. schrieb:
>> Um in den Bootloader zu kommen, müsste BOOT0 auf HIGH gesetzt werden.
>
> OK, also wie es ursprünglich war. (1k an 3,3V)

Allerdings muss dazu das BOOT1n Bit in den Option Bytes auch auf 1 
stehen, Und das scheint auf 0 programmiert zu sein.

[Kilo S. (kilo_s)]

Matthias S. schrieb:
> Allerdings muss dazu das BOOT1n Bit in den Option Bytes auch auf 1
> stehen, Und das scheint auf 0 programmiert zu sein.

Wenn ich nen passendes Breakout organisiert bekomme, versuch ich es nach 
DB mit dem ISP Tool. Aktuell hab ich nix passendes und "Dead Bug" hab 
ich grad echt keine lust zu. 0,5mm pitch is mir grad zu fummelig.

Ein Komplettes Löschen würde ja schon reichen, das würde den anteil von 
"Müll" von den teilen regelrecht auf Gehäuse, Platine und Verdampfer 
reduzieren.
Es gehen sogar die stehenden USB-C Buchsen gut runter.

Ich hab grad die meisten der platinen (platz!) abgeerntet, geht echt 
gut!

[M. G. (looking)]

Matthias S. schrieb:
> Kilo S. schrieb:
>> M. G. schrieb:
>>> Um in den Bootloader zu kommen, müsste BOOT0 auf HIGH gesetzt werden.
>>
>> OK, also wie es ursprünglich war. (1k an 3,3V)

Ist BOOT0 auf dem Board über 1k an 3V3 gelegt? Das wäre seltsam, dann 
müsste ja immer der Bootloader gestartet werden?

> Allerdings muss dazu das BOOT1n Bit in den Option Bytes auch auf 1
> stehen, Und das scheint auf 0 programmiert zu sein.

BOOT1n=0 würde bedeuten, dass versucht wird, Code aus dem SRAM zu 
starten. Nach dem PowerOn dürfte da nichts vernünftiges drin stehen.

Vielleicht wäre SWD eine Möglichkeit?

[Kilo S. (kilo_s)]

M. G. schrieb:
> Vielleicht wäre SWD eine Möglichkeit?

Geduld, einen J-Link hab ich hier. Mein hauptaugenmerk gilt dem Display, 
denn das ist halbwegs "Bastlerfreundlich" mit connector versehen. Das 
passende Breakout dafür wird es bestimmt auch irgendwo geben.

Die aktuelle platine ist zu nix mehr zu gebrauchen weil ich mir die 
layer angesehen hab. ;)
Der MCU liegt aber hier, bisschen angeschliffen bei der aktion, sollte 
aber noch funktionieren.

[Kilo S. (kilo_s)]

Oh, noch was interessantes dazu:

"Der Beitrag scheint Spam zu enthalten: "x-cigarette"", bitte beim 
zweiten link X gegen e ersetzen!

https://hackaday.com/2024/04/25/reverse-engineering-a-fancy-disposable-vape/
https://hackaday.com/tag/X-cigarette-hack/
https://ripitapart.com/2024/04/20/dispo-adventures-episode-1-reverse-engineering-and-running-windows-95-on-a-disposable-vape-with-a-colour-lcd-screen/
https://github.com/ginbot86/ColorLCDVape-RE

Spätestens übernächste woche hab ich ne neue davon hier!
Die infos sind doch erstaunlich ähnlich dessen was ich vermute, 
ähnliches modell.

Genau wie bei denen die hier sind, SWD geht an den USB-C....

[Kilo S. (kilo_s)]

OK!

https://ripitapart.com/2024/04/20/dispo-adventures-episode-1-reverse-engineering-and-running-windows-95-on-a-disposable-vape-with-a-colour-lcd-screen/

Zitat:"During my initial teardown, I noticed that the microcontroller’s 
SWD (Serial Wire Debug) programming lines were brought out to the USB-C 
port, but in an unusual way. The CC1/CC2 lines were not only used as 
regular 5.1k pulldowns to enable USB-C chargers to recognize the vape, 
but also as a programming connector"

Er hat recht, das ist bei diesen Fumot ebenfalls so.
Ich komm allerdings damit gerade nicht wirklich weiter.
Mein J-Link Clon will anscheinend nicht bzw. alles deutet auf 
fehlerhafte verbindungen hin, Pulldown drauf oder entfernt, spielt keine 
rolle.

Auf der einen ist DAT/CLK sogar herausgeführt als testpad, die hab ich 
gerade in der mangel und bekomme einfach keine verbindung.

P.S
Joa, mein fehler!
Einstellungen!

Erst mal reset/boot0 anfrickeln.

[Kilo S. (kilo_s)]

Hm, mit den "kleinen" hab ich kein glück. (Modelle unter 20.000 Züge, 
mit den Charlyplexing Displays)

Mögen einfach nicht mit mir reden!

Dabei hatte ich gehofft wie er einfach so an die firmware zu kommen ect.

[Kilo S. (kilo_s)]

Die tools aus dem link funktionieren auch, hier mal ein ergebniss nur 
mit einem "Schnellen test".
Ist natürlich nicht "Richtig" aber das format scheint zumindest mal zu 
stimmen. ;)

http://www.rinkydinkelectronics.com/t_render_rgb565.php

[Kilo S. (kilo_s)]

Grr... Das ewige hin und her mit unpassenden connectoren.

Jetzt muss ich erst mal einen neuen suchen.

[.● Des|ntegrator ●. (Firma: FULL PALATINSK) (desinfector)]

langsam sieht das aus als hätte jemand zuviel Zeit.

[Kilo S. (kilo_s)]

●Des|ntegrator ●. schrieb:
> langsam sieht das aus als hätte jemand zuviel Zeit.

Nö, haben nicht, die Nehm ich mir aber einfach, es pisst mich mega an 
das die Dinger nix können als ausgenuckelt werden und danach irgendwo im 
Müll oder Gebüsch zu Landen.

Da ich die Teile grundsätzlich (seh ich auch ein wenig als Jugendschutz) 
einsammel und entsorge sofern Defekt oder die Akkus nach Prüfung selbst 
verwende/entsorge und die Dinger mittlerweile immer bessere Hardware 
haben, dachte ich mir das man neben den "Alten" (Drucksensor + IC ) als 
kleine notladegeräte doch bestimmt auch aus den neueren was machen 
könnte.

Die sch.. Dinger haben aber teils Custom Marking, außerdem verschiedene 
Pinout im gleichen Gehäuse ect. Daher kam mir tatsächlich die Idee nicht 
früher. Ich hielt es bis zur 25000 mit Display für Custom IC.

Und die mit TFT (ich hab aktuell auch ganz stark ein ST7735/S/P ect. 
oder sowas in Verdacht, hab einfach 1,77 Zoll Displays verglichen.) war 
jetzt die "Zündende" Hardware.

Ich fände das schon geil die PY32 nach dem zerlegen der kippen auf ein 
breakout zu löten und neben den Akkus so auch noch "on mass" gratis 
"Arduinos" für mich zum basteln und lernen zu haben.

Oder stell dir vor das ganze Forum macht mit und die gesammelten IC 
gehen als "Anfängergeschenke" an die Jugend von Freunden und Bekannten 
oder an sonst jemanden der damit "Gefördert" werden kann.
Kostet uns dann doch nur ein breakout und pinheader! (<=1€)

Das sind die Gedanken die mich dabei antreiben, vor allem jetzt wo die 
Modelle mit richtigem Display einfach total verlockend sind.

Immerhin, ich versuchs öffentlich zu machen damit mehr Leute darauf 
aufmerksam werden. Vielleicht können wir so dafür sorgen daß die Dinger 
nicht mehr nur weggeworfen werden.

[.● Des|ntegrator ●. (Firma: FULL PALATINSK) (desinfector)]

Kilo S. schrieb:
> Da ich die Teile grundsätzlich (seh ich auch ein wenig als Jugendschutz)
> einsammel

Und Du meinst dass Jugendliche an herumliegenden Vapes rumnuckeln?

[Kilo S. (kilo_s)]

●Des|ntegrator ●. schrieb:
> Und Du meinst dass Jugendliche an herumliegenden Vapes rumnuckeln?

Ich meine nicht, ich hab schon gesehen wie KINDER und nicht jugendliche 
die Dinger auf dem Spielplatz sammeln und dran Rum nuckeln.

Der Kiosk der die verkauft ist keine 30m weit weg von dort, abends 
sitzen die Jugendlichen da am Spielplatz und feuern die "leeren" in die 
Büsche...

Mag ja sein das du aus einer schöneren Gegend kommst, hier ist das 
leider Alltag das man sowas sieht!

[Cyblord -. (cyblord)]

Kilo S. schrieb:
> Ich meine nicht, ich hab schon gesehen wie KINDER und nicht jugendliche
> die Dinger auf dem Spielplatz sammeln und dran Rum nuckeln.

Treibst du dich öfter in der Nähe von Spielplätzen rum?

[Kilo S. (kilo_s)]

Cyblord -. schrieb:
> Treibst du dich öfter in der Nähe von Spielplätzen rum?

Natürlich, meine kleine Tochter will ja auch irgendwie beschäftigt 
werden und andere Kinder um sich haben zum Spielen!

Deine dummen Bemerkungen kannst du dir sparen!

[.● Des|ntegrator ●. (Firma: FULL PALATINSK) (desinfector)]

Cyblord -. schrieb:
> Treibst du dich öfter in der Nähe von Spielplätzen rum?

Kommt zumindest vor wenn man selbst Kinder hat.
Also unterstelle hier nichts falsches bitte

[Kilo S. (kilo_s)]

Das gute ist, meine Tochter sieht was Papa macht, findet sie welche beim 
Spielen (nein sie nuckelt nicht daran, auch nicht an sonstigem was sie 
findet!) BRINGT sie mir die:"Papa musst du reparieren!"

Sie ist oft bei mir wenn ich hier was mache. Das ich die Akkus zb. Für 
Lampen benutze ect. kennt sie. Daher das "reparieren".

[Rene K. (xdraconix)]

Kilo S. schrieb:
> Deine dummen Bemerkungen kannst du dir sparen!

Du musst verstehen das das durchschnittliche Alter hier im Forum so um 
die 60 Jahre liegt - da haben die wenigsten noch Kinder. ;-)

[Kilo S. (kilo_s)]

Rene K. schrieb:
> - da haben die wenigsten noch Kinder. ;-)

Aber vielleicht Enkel oder Urenkel, sowas ist schon knapp an der Grenze!

Meine beste Freundin (R.I.P) hätte jetzt gesagt:"Karma wegen dem dummen 
Spruch. Das Universum gibt dafür was zurück!".

Eine wird eventuell heute Abend, spätestens morgen wenn sie leer ist, 
die andere eventuell am Montag Reinflattern.

Zwei Zusagen für neue hab ich bereits.
Für die 25000 mit LCD.

[Cyblord -. (cyblord)]

Kilo S. schrieb:

> Meine beste Freundin (R.I.P) hätte jetzt gesagt:"Karma wegen dem dummen
> Spruch. Das Universum gibt dafür was zurück!".

Klar, die Sterne regeln das. Wenn du doch ein bisschen an Kristallsalz 
reibst und Räucherstäbchen anzündest, knallts noch mehr.

Hast du keine Voodoo-Puppe?

[Kilo S. (kilo_s)]

Ich bezeichne das als "Networking". Bei dem Thema waren die Eule und ich 
uns nie einig, aber ihre Kenntnisse über viele andere Dinge habe ich 
trotzdem sehr geschätzt.

Höflich fragen kann man immer! Und wer fragt hat auch häufig Erfolg.

Aber schön das du auch noch was sinnvolles beizutragen hast außer über 
Erinnerungen an Tote Freunde Rundumeckern?
Oder ist das weil ich etwas "sozialverträglicher" bin und daher 
erfolgreich und kurzfristig Nachschub bekommen kann?


Fragen über Fragen warum du so "blöd" antworten musst.

[Cyblord -. (cyblord)]

Kilo S. schrieb:
> Ich bezeichne das als "Networking". Bei dem Thema waren die Eule und ich
> uns nie einig, aber ihre Kenntnisse über viele andere Dinge habe ich
> trotzdem sehr geschätzt.

Habe ehrlich keinen Schimmer wovon du redest.

> Höflich fragen kann man immer! Und wer fragt hat auch häufig Erfolg.

Siehe oben. Wen fragen? Nach was?

> Aber schön das du auch noch was sinnvolles beizutragen hast außer über
> Erinnerungen an Tote Freunde Rundumeckern?
> Oder ist das weil ich etwas "sozialverträglicher" bin und daher
> erfolgreich und kurzfristig Nachschub bekommen kann?

Immer noch keine Ahnung. Nachschub an was? Toten Freunden?

Meine letzte Antwort bezog sich allein auf deine Aussage zum Karma. Was 
man auch am Zitat sehen kann. Eine Funktion die dir unbekannt sein 
dürfte.

[Kilo S. (kilo_s)]

Cyblord -. schrieb:
> Immer noch keine Ahnung.

Weshalb du den sonst eigentlich konstruktiven Beitrag störst.

Egal, viel Spaß noch.


Ignorieren wir ihn einfach, ich schau in der Zeit ob ich nicht irgendwo 
noch einen LA kurzfristig auftreiben kann.

Bzw. Ich flashe schon mal den ESP8266 dafür...

[Kilo S. (kilo_s)]

Und auf ein neues!

[Kilo S. (kilo_s)]

Die innereien lassen sich komplett zerstörungsfrei entnehmen!

[Kilo S. (kilo_s)]

Ahhhh!

Endlich, es tut sich was!

[Kilo S. (kilo_s)]

Heut is nicht mein tag irgendwie ... also zum dritten mal!
SWD für die Fumot 2500:
Boot0 auf VCC, SWDO auf SDA, SCKL ist SWDCKL.

Reset auf GND, Debugging Starten und reset loslassen.

[Kilo S. (kilo_s)]

Reset übrigens doch auf GND halten, sonst bekommt man die CPU nicht in 
halt.

So, Feierabend für heute.

Ich such mir zwar eigentlich noch nen Wolf wie genau ich das ISP 
Programm von Puya dazu bekommen kann mit meinem CH340/Jlink zusammen zu 
Arbeiten, alternativ wie ich das alles mit Jlink hin bekomme. (Flashdump 
ect..) Aber immerhin!

Jetzt wo die Kommunikation passt ist es aktuell allein nur mein 
fehlendes wissen, das lässt sich nachholen.

Morgen noch das Display mit dem LA beobachten.

Den Arduino Core hab ich auch bereits, ich muss also eigentlich (da ich 
noch mal die gleiche CPU habe eigentlich auch nicht!) nur noch den 
(vollständigen) flashdump hinbekommen damit das alles hier so weit 
komplett wird.
So können Leute die daran interessiert sind was damit machen.

[Kilo S. (kilo_s)]

Wie ich es auch mache, ich bekomme mit dem ISPtool keine Verbindung.

Es gibt den Hinweis das USART1 bei denen nicht will, jetzt Brauch ich 
aber erst mal mehr Kaffee bevor ich da was anfädel.

LA möchte auch noch nicht, zumindest die erste ausprobierte Variante 
nicht.

[Matthias S. (Firma: matzetronics) (mschoeldgen)]

Sieht doch schon mal gut aus. +1

[Dieter S. (ds1)]

Im externen Flash sind 302 RGB565 Images mit jeweils 128x160 Pixel, die 
konvertierten Images sind als BMP Dateien im angehängten Archiv 
("test000.bmp" bis "test301.bmp"). Einige der Dateien ergeben 
Animationen (u.a. das Würfelspiel und die Umschaltung der Heizleistung).

[Kilo S. (kilo_s)]

Dieter S. schrieb:
> Im externen Flash sind 302 RGB565 Images mit jeweils 128x160 Pixel, die
> konvertierten Images sind als BMP Dateien im angehängten Archiv
> ("test000.bmp" bis "test301.bmp"). Einige der Dateien ergeben
> Animationen (u.a. das Würfelspiel und die Umschaltung der Heizleistung).

Vielen Dank für die Hilfe!

Ich bin dabei den zweiten "Käfer" zum Leben zu erwecken.
Fleißarbeit seit heute morgen, mit Unterbrechungen, mit der Ausrüstung 
geht das ganz schön auf die Augen!

[Kilo S. (kilo_s)]

Matthias S. schrieb:
> Sieht doch schon mal gut aus.

Danke, vom Arduino Zeugs ist man echt verwöhnt. Daher gibt's da noch 
viel was ich lernen muss.

[Dieter S. (ds1)]

Der Flash läßt sich vom J-Link Commander z.B. so auslesen (64 kByte):

savebin flash_dump.bin, 0x08000000, 0x10000

Voraussetzung: RDP ist nicht gesetzt und das Lesen des Flash ist 
erlaubt.

[Kilo S. (kilo_s)]

Dieter S. schrieb:
> Der Flash läßt sich vom J-Link Commander z.B. so auslesen (64 kByte):
>
> savebin flash_dump.bin, 0x08000000, 0x10000
>
> Voraussetzung: RDP ist nicht gesetzt und das Lesen des Flash ist
> erlaubt.

Perfekt! Genau bei den Adressen hapert es noch, das war der Hinweis den 
ich bräuchte.

Flashdump kommt sofort!

[Kilo S. (kilo_s)]

Anfangs leicht "Hakelig" (CPU lies sich nicht gleich anhalten) aber hat 
geklappt!

[Kilo S. (kilo_s)]

So, der Käfer ist so weit!

Durch das umdrehen stimmen die Pin Nummern auch wieder.

[Kilo S. (kilo_s)]

Und der "Deadbug" reagiert auf SWD!

Jetzt muss ich noch die Verbindung mit dem ISPtool zum laufen kriegen!

[Kilo S. (kilo_s)]

PA2/PA3 (8,9) und USART2 ist "Floating".

Klappt trotzdem!

[Kilo S. (kilo_s)]

Und der Deadbug blinkt erfolgreich mit dem ersten Test Scetch, 
programmiert mit der Arduino IDE.

Coole Sache! Ich such schon mal passende Breakout Boards.

Und nun noch das LCD.

Die E kippe liefert einem mal eben ein komplettes Devboard mit Display, 
zwei LL-Fets, Li-Lader, Akku und Touchsensor!

[Kilo S. (kilo_s)]

OK, das spielen mit dem "originalen" PCB hat erst mal einen MCU gekillt.

Wurscht, der zweite liegt nun angepiekst in der Testvorrichtung (Pin 
6/PA0 als wackelpin für ne LED, RX/TX, VCC, GND) und gibt mir über die 
serielle jedes Mal den Text von Setup und der Loop aus. (?)

Was zum Geier geht da ab?

Normal erwarten würde ich 0, 1, 1, 1...

[Matthias S. (Firma: matzetronics) (mschoeldgen)]

Kilo S. schrieb:
> Was zum Geier geht da ab?

Der wird wohl immer wieder einen Reset ausführen.

[Kilo S. (kilo_s)]

Matthias S. schrieb:
> Der wird wohl immer wieder einen Reset ausführen.

Aber weshalb, den hatte ich vorher (Deadbug) umgedreht auf dem PCB, da 
hat er das nicht gemacht. Ohne pullup an Reset o.ä, ohne C Zwischen VCC 
und GND.

Ich zieh Reset gleich mal mit 1k auf VCC, schauen ob das was verändert. 
Muss nur die LED kurz entfernen.

[Kilo S. (kilo_s)]

Kleinen Moment Geduld, Familie geht vor.

[Kilo S. (kilo_s)]

gibts nicht....

//int P = PA0;

void setup() {
Serial.begin(9600);
//pinMode(P, OUTPUT);
Serial.println("ON0");
}

void loop() {
  //digitalWrite(P, HIGH);
  for(int i;i<10;i++){
  Serial.println(i);
  }
  //delay(300);
  //digitalWrite(P, LOW);
}

Ausgabe:

ON⸮ON0
22:23:09.499 -> 536871984
22:23:09.499 -> 536871985
22:23:09.499 -> 536871986
22:23:09.532 -> 536871987
22:23:09.532 -> 536871988
22:23:09.532 -> 536871989
22:23:09.566 -> 536871990
22:23:09.566 -> 536871991
22:23:09.566 -> 536871992
22:23:09.599 -> 536871993
22:23:09.599 -> 536871994
22:23:09.599 -> 536871995
22:23:09.632 -> 536871996
22:23:09.632 -> 536871997
22:23:09.632 -> 53687199O

Da scheint die RTC was auszugeben?

Was ist da los mensch... was mach ich falsch?

[Kilo S. (kilo_s)]

Und ende!....

Zusammenfassung: erneuter versuch zu flashen ergab das er stirbt.

VCC:3,3V daran kann es also auch nicht gelegen haben.

Ich hab den eindruck das liegt am Arduino Core, denn mein einfaches 
serial kann soas nicht anrichten.

[Thomas S. (thommi)]

Schade. Deine Geduld ist zu bewundern. Ist aber auch eine interessante 
Sache.

[Kilo S. (kilo_s)]

OK, drei dinge:

1.) Nach dem ansprechen mit dem ISP Tool (Klappte auf anhieb) "lebt" er 
wieder.

2.) Variablen innerhalb der schleifenbedingungen müssen mit 0 
initialisiert werden, sonst zählt der müll.

3.) Beachtet man 2 nicht hilft nur ansprechen 1 und ein erase!

Gibts einen grund weshalb ein ESP8266 sowas verzeiht?

Also kann das echt am core liegen?

[Kilo S. (kilo_s)]

Thomas S. schrieb:
> Schade. Deine Geduld ist zu bewundern. Ist aber auch eine interessante
> Sache.

;-)

Ich glaub nicht dran das beide IC hin sind... Wenn ich den zweiten auch 
Reanimiert bekomme melde ich das hier.

Irgendwann im laufe der nächsten woche gehts auch mit (der dritten, 
vierte ist auf dem weg!) mit dem display weiter!

Ich besorg mir so einen Salea Clon und fuchs mich auch da ein.

Abgesehen vom Arduino kram ist das mein erster "Echter" ritt mit 
"Blanken" IC.

Aber ich bleib dran!

[Cyblord -. (cyblord)]

Thomas S. schrieb:
> Schade. Deine Geduld ist zu bewundern. Ist aber auch eine interessante
> Sache.

Ich hab schon wieder vergessen was er eigentlich tun will...

[Matthias S. (Firma: matzetronics) (mschoeldgen)]

Kilo S. schrieb:
> 536871984

Wenn ich das in Hex umrechne, kommt da 0x20000430 raus, was zufällig 
(oder absichtlich) eine Adresse im RAM des PY32 ist.
Weiterhin ist natürlich verwunderlich, das die Abbruchbedingung in

for(int i;i<10;i++){

ignoriert wird. Als oller C-Programmerer würde ich vermutlich mal auf 
das Arduino Zeugs verzichten und ein simples C Programm einnageln. Wenn 
es eine Startup.S oder so gibt, solltest du dir die mal angucken.

[Kilo S. (kilo_s)]

Cyblord -. schrieb:
> Ich hab schon wieder vergessen was er eigentlich tun will...

Schlaf weiter, wir wecken dich wenn's nötig wird.
Aber zusammengefasst nochmals für dich:
Ziel (Neben der Identifikation des Display und der Nutzbarmachung 
selbigen) war es die PY32F030 mit der Arduino IDE programmierbar zu 
machen.

Ist erledigt, Grundsätzlich geht's.

Oder anders gesagt eines von zwei Zielen erreicht.

Matthias S. schrieb:
> Wenn ich das in Hex umrechne, kommt da 0x20000430 raus, was zufällig
> (oder absichtlich) eine Adresse im RAM des PY32 ist.
> Weiterhin ist natürlich verwunderlich, das die Abbruchbedingung in
>
> for(int i;i<10;i++){
>
> ignoriert wird. Als oller C-Programmerer würde ich vermutlich mal auf
> das Arduino Zeugs verzichten und ein simples C Programm einnageln. Wenn
> es eine Startup.S oder so gibt, solltest du dir die mal angucken.

Danke für den Hinweis.

Was sagt man dazu, mit folgendem Syntax funktioniert es einwandfrei, 
Setup nur ein mal ausgeführt (wie es soll) und der Zähler läuft sauber 
durch.

for(int i=0;i<10;i++){
...
}

"Normales" C kommt noch für mich.

Jetzt ist nur die Frage, wieso ignoriert der Compiler die zuweisung in 
der Schleife?
Für mich ist int i; eqivalent zu int i=0; Das muss aber irgendwo 
zwischen zählen und Ausgabe verändert Werden, nur wo und wieso?

Ich will ja wissen wie gut sich die Dinger eben für Arduino eignen.
Ich hab hier einige an der Hand die das nutzen, daher liegt der Fokus 
darauf.

[Kilo S. (kilo_s)]

Matthias S. schrieb:
> Wenn
> es eine Startup.S oder so gibt, solltest du dir die mal angucken.

Bin grad dabei.

Da passiert nicht viel, muss gleich noch zwei dateien finden dann weiß 
ich mehr...

[Kilo S. (kilo_s)]

Erst ein mal den "Zombiebug" um ein paar weitere Testnadeln erweitern.

[Cyblord -. (cyblord)]

Kilo S. schrieb:
> "Normales" C kommt noch für mich.

Was ist "Normales" C und mit was arbeitest du aktuell?

[Kilo S. (kilo_s)]

Cyblord -. schrieb:
> Was ist "Normales" C und mit was arbeitest du aktuell?

Aktuell Arduino, da nimmt einem die IDE einfach viel ab.
Unter "Normalem" C verstehe ich eher sich die sachen per hand zusammen 
zu stricken anstelle eines fertigen core der so sachen wie compiler ect. 
für einen bedient.

[Kilo S. (kilo_s)]

Aktuell habe ich diesen code laufen.

void ser_contr(){
  int i = Serial.parseInt();
  int x = 0;
  switch(i){
  case 1:
      Serial.println("A");    
    break;
  case 2:
    Serial.println("b"); 
    break;
  case 3:
    Serial.println("C"); 
    break;
  default:
    Serial.println("Loop:");
    } 
}

void setup() {
Serial.begin(9600);
Serial.println("ON0");
}

void loop() {
 ser_contr();
}

Ich glaube einfach das war ein Syntaxfehler, irgendwas mochte bei der 
ubersetzung nicht so wie ich mir das einfach dachte.

Alles andere geht tadellos!

[Cyblord -. (cyblord)]

Kilo S. schrieb:
> Cyblord -. schrieb:
>> Was ist "Normales" C und mit was arbeitest du aktuell?
>
> Aktuell Arduino, da nimmt einem die IDE einfach viel ab.
> Unter "Normalem" C verstehe ich eher sich die sachen per hand zusammen
> zu stricken anstelle eines fertigen core der so sachen wie compiler ect.
> für einen bedient.

Das ist eine Abstruse Ansicht. C ist C auch bei Arduino (oder C++ 
stellvertretend gemeint).

Weder hängt das davon ab, ob du ein Million fertiger Funktionen aufrufst 
oder ob die IDE dir die Einrichtung der Toolchain abnimmt. Es ist und 
bleibt C.

Ein Beispiel wo C nicht mehr C (oder C++) ist, wäre z.B. QT, wo man das 
native C++ mit Makros so lange vergewaltigt hat bis man de facto neue 
Sprachelemente reingepfuscht hat. Das könnte man durchaus als nicht mehr 
echtes C++ bezeichnen.

Arduino macht das aber nicht.

Korrekte Terminologie steht am Anfang.

[Kilo S. (kilo_s)]

Seis drum...

Nächste woche organisier ich mir den LA, muss noch schauen welchen jetzt 
genau.

Breakouts für 0,5mm pitch sind auch auf der liste.
12 PIN FPC breakouts mit 0,5mm pitch auch, für das Display.

[Kilo S. (kilo_s)]

Ich wusste es!

Beide MCU Leben noch.

Der Schluckauf den ich da verursacht habe muss wohl irgendwas seltsames 
getriggert haben.

Jetzt ist er leer, kann also erneut beginnen ihn zu nutzen.

[Kilo S. (kilo_s)]

OK, Jetzt ist es seltsam!

Der erste "Deadbug" (erkenne ich an der angeschliffenen kante) kann den 
gleichen code wie der neue NICHT fehlerfrei ausführen!

Scheint ein loop zu sein, setup-reset-setup-reset.

[Kilo S. (kilo_s)]

Aufbau ist der selbe wie vorher.

[Soul E. (soul_eye)]

Kilo S. schrieb:
> Aufbau ist der selbe wie vorher.

Dann versuch doch mal, da irgendwie ein paar Abblockkondensatoren in die 
Nähe zu bringen. Ein 8031 läuft auch ohne alles an der Motorradbatterie, 
aber diese neumodischen Controller mit internen Corespannungen verstehen 
da relativ wenig Spass.

[Cyblord -. (cyblord)]

Kann es nicht einfach an der abenteuerlichen "Deadbug" Kontaktierung mit 
viel zu dicken Anschlussleitungen liegen?

[Kilo S. (kilo_s)]

Soul E. schrieb:
> Dann versuch doch mal, da irgendwie ein paar Abblockkondensatoren in die
> Nähe zu bringen.

Jo, wenn ich weiter mach. Muss morgen erst mal kurzfristig weg.
Ich geh allerdings nicht davon aus das die was helfen.

Cyblord -. schrieb:
> Kann es nicht einfach an der abenteuerlichen "Deadbug" Kontaktierung mit
> viel zu dicken Anschlussleitungen liegen?

Ne, das vermute ich weniger.

Das sind P50-01 nadeln die sauber auf den kontakten aufliegen.
Das gleiche verhalten zeigt er mit kurzen stücken draht einer 
relaisspule auf einem stück platine.


Erstmal werkzeug einpacken....

[M. G. (looking)]

Kilo S. schrieb:
> Was sagt man dazu, mit folgendem Syntax funktioniert es einwandfrei,
> Setup nur ein mal ausgeführt (wie es soll) und der Zähler läuft sauber
> durch.
> for(int i=0;i<10;i++){
> ...
> }
>
> "Normales" C kommt noch für mich.
>
> Jetzt ist nur die Frage, wieso ignoriert der Compiler die zuweisung in
> der Schleife?
> Für mich ist int i; eqivalent zu int i=0; Das muss aber irgendwo
> zwischen zählen und Ausgabe verändert Werden, nur wo und wieso?

Wenn du nur
int i;
schreibst, wird die Variable i nicht initialisiert, der Wert ist also 
undefiniert, entsprechend dem Wert, der an dem verwendeten Register oder 
im entsprechenden Stackbereich steht.

[Kilo S. (kilo_s)]

M. G. schrieb:
> Wenn du nur
> int i;
> schreibst, wird die Variable i nicht initialisiert, der Wert ist also
> undefiniert, entsprechend dem Wert, der an dem verwendeten Register oder
> im entsprechenden Stackbereich steht.

OK, danke für den Hinweis. Ich dachte das wäre das gleiche. Wenn ich den 
gleichen Code auf einem Mega oder ESP8255 benutze passiert das 
lustigerweise nicht.
(muss ich bei einem Projekt tatsächlich noch ändern bevor das mal zu 
Problemen führt!)

Interessant was man so alles finden kann, schaut aus wie die nicht 
initialisierte RTC (die letzten vier stellen in der Ausgabe der 
seriellen sehen halt wie ein Datum aus) die ich auf diesem weg 
ausgegeben habe.

Bleibt Frage Nummer zwei, weshalb verhält sich der erste PY32 nicht wie 
der zweite.

Der eine wurde nach dem erfolgreichen schreiben des "serial" 
Testprogramm und ausführen des selbigen einfach unter der 
Testvorrichtung "heraus geschoben" und der andere in Position gebracht, 
erfolgreich programmiertund getestet.

Wo der erste ausgibt:
ON0
Loop:
Loop:

Macht der zweite:
ON0
ON0
ON0

In der Zwischenzeit wurde nur der Chip getauscht, sonst gab's keine 
Änderungen.

[.● Des|ntegrator ●. (Firma: FULL PALATINSK) (desinfector)]

löppt dat nu!

[Kilo S. (kilo_s)]

●Des|ntegrator ●. schrieb:
> löppt dat nu!

Geduld, Familie Besuchen. Bin 200Km vom PY32 weg.

Hab dafür anderes zu tun.
Verdammte Noframe Displays, Patienten mit Provisorium beschwert auf der 
mobilen Arbeitsmatte.
;-)

Wenn das falsche Ersatzteil Arbeitszeit kostet.

[Kilo S. (kilo_s)]

Heute noch mal mit den Kids zum Umzug, dann geht's langsam weiter.

Kurzer "Status":
Patient "ON ON ON" ist bereits auf einem breakout, Display breakout ist 
fertig, ein einfacher 8 Kanal LA+SW läuft.

Ich muss schauen ob ich selbst noch eine Vape besorge oder warte bis der 
Kollege zurück ist und seine leer hat.

Pinout habe ich ja, ich könnte also mit den breakout Boards das 
notwendige (Flash + Display) verbinden und das originale flashdump 
verwenden.

Mal schauen, ich hab für den Fall der Fälle ein 12pin FPC Kabel das 
passt und als Erweiterung an der originalen Platine dienen kann.

Ich hab jetzt X mal hin und her, das liegt nicht am "Deadbug" Design 
oder den Drähten ect. Beim Aufbau.

Ich erinnere mich das ich beim ISPTool beim einen IC eine andere 
Einstellung (Full Erase) nutzen musste um ihn erneut mit der IDE flashen 
zu können.
Beim anderen reichte ein Flash Erase.
Ich lese mich bezüglich der Register noch ein, vermutlich kann es aber 
auch daran liegen.

Geduld, das Display zu identifizieren steht aktuell mit ganz oben auf 
der Liste!
Geschenkidee für meine Frau.
Ich hab hier so ne schöne Glaskuppel die so toll auf einen Messingsockel 
passt, das wäre mit dem kleinen Display ein echt schöner "Mini Digital 
Fotorahmen".

;-)

[Michael (Gast)]

Rene K. schrieb:
> Btw.: ich bin durch einen Schlaganfall von 2 Schachteln Zigaretten am
> Tag auf das Dampfen (natürlich ohne Nikotin) umgestiegen.

https://www.aerzteblatt.de/news/studie-e-zigaretten-loesen-potenziell-schaedliche-immunreaktionen-in-der-lunge-aus-6f2ebfe3-8623-40e9-be5a-93a43ca34078

Schön.
Den Teufel mit dem Belzebub austreiben.

Bevor Du fragst:
Ich habe 30J geraucht und habe vor dem Schlaganfall aufgehört.
Das dicke Ende kommt aber vielleicht noch.
Der Körper vergisst 30J Schindluder nicht.
Du wirst doch wohl die innere Stärke finden mit einer Gewohnheit 
aufzuhören?

Kilo S. schrieb:
> Geschenkidee für meine Frau.
'Schatz, ich habe Dir was aus Müll gebaut' käme bei meiner nicht so gut 
an.

Geh lieber Flaschen sammeln.
In der Zeit in der Du jetzt ekelhafte, verkeimte, vollgespeichelte und 
versiffte E-Zigaretten auseinanderbaust, hättest Du da mehr Kohle über 
und könntes Dir die Bauteile kaufen die Du brauchst.

[Kilo S. (kilo_s)]

Michael schrieb:
> 'Schatz, ich habe Dir was aus Müll gebaut' käme bei meiner nicht so gut
> an.

1.) Die Dinger kommen aus dem Bekanntenkreis, "verkeimt" ist da nicht 
viel schlimmer als der normale Kontakt den man sonst so pflegt. Deren 
Kaffeetasse muss ich auch wegräumen wenn die gehen.

2.) Meine Frau findet das (sie ist selbst handwerklich begabt) viel 
besser als gekauft. Kaufen kann jeder!

3.) Sind die Teile nur theoretisch "Müll". Aktuell kostet mich so ein 
"PY32Duino" 96 Cent. (breakout Platine)
Für das Display 86 Cent.

Michael schrieb:
> Geh lieber Flaschen sammeln.

Ich kann mir meine Zeit gut selbst einteilen und entscheiden was ich 
mache!
Es geht nicht um Geld, es geht darum das die Dinger für jeden GRATIS 
rumliegen und so eben nicht die Umwelt mit Nikotin (schau mal was das 
mit dem Grundwasser macht) Plastik und sonstigem was mit der Zeit 
verottet, wenn die Leute alles damit zu Müllen, belastet und eventuell 
noch einer sinnvollen Verwendung zugeführt werden können.

[Kilo S. (kilo_s)]

Meine Frau ist totaler Fan von "Die schöne und das Biest".

Daher ist die selbstgemachte "Rosenkuppel" mit einem "Schrottdisplay" 
als Fotorahmen in Handarbeit nicht nur schöner als gekauft, es ist 
wirklich persönlich!

Die Optik passt auch schön zum Film, sieht halt aus wie aus dieser Zeit.

[Michael (Gast)]

Kilo S. schrieb:
> für jeden GRATIS
> rumliegen

Ich hätte Hundekacke in großen Mengen abzugeben.
GRATIS für jeden!
Einzeln verpackt in bunten Plastiktüten, die für sich alleine ja schon 
einen Wert darstellen.

Was man alles tolles damit machen kann:
- Kompost
- Gesichtsmasken
- Handschmeichler

Immerhin kostet 1m² Kompost locker 30€
Was man da alles sparen kann!

Darüber hinaus biete ich Tetrapacks, Wurstpelle und Hundefutterdosen in 
rauen Mengen.
Rasenschnitt und Laub, Holzasche und nur einmal benutztes Klopapier.

Greift alle zu. Ist genug für alle da!

[Andreas M. (amesser)]

Kilo S. schrieb:
> Erst ein mal den "Zombiebug" um ein paar weitere Testnadeln erweitern.

Sehr geil, so was brauch ich auch :-)

[Kilo S. (kilo_s)]

Andreas M. schrieb:
> Sehr geil, so was brauch ich auch :-)

Bedarf aber einigem an Verbesserungen bezüglich des "Arbeitskomfort".

Das positionieren der spitzen ist etwas fummelig.

Variante 2, kugelgelagerter drahtarm mit fixierschraube im Messing 
klemmblock ist bereits (Prototyp) in Arbeit. Ich muss nur mehr der 
Messing klemmblöcke besorgen oder eben Stangenmaterial zum selber 
herstellen. ;-)

Ich empfehle stark (wenn jemand nachbauen möchte) Variante 2 
nachzubauen! Das aufdrücken der Pogopins geht damit viel besser.

[Kilo S. (kilo_s)]

So, unverhofft kommt oft.

Bisschen Geduld noch, komme vermutlich heute Abend dazu weiter zu 
machen.

[Kilo S. (kilo_s)]

Breakout für den LA ist vorbereitet, jetzt lüftet sich bald das 
Geheimnis um das Display!

Und dazu noch frischer Kaffee und Apfel Zimt Kuchen, Lecker!

[Dieter S. (ds1)]

Kilo S. schrieb:
> Breakout für den LA ist vorbereitet, jetzt lüftet sich bald das
> Geheimnis um das Display!

Im Firmware Dump vom weiter oben sieht man sehr schnell wie das Display 
initialisiert wird. Allerdings scheint es keiner der verbreiteten 
Display Controller zu sein, auch wenn man einige der verwendeten 
Kommandos bei anderen Display Controllern findet.

[Kilo S. (kilo_s)]

Ich hänge mal die session vom analyzer an.

[Kilo S. (kilo_s)]

Die Vermehren sich heimlich...

Die nächste Reingeflattert!

[Kilo S. (kilo_s)]

Dieter S. schrieb:
> Allerdings scheint es keiner der verbreiteten Display Controller zu
> sein,

Hast du irgendeinen Hinweis was eventuell "nahe dran" sein könnte?

Ich trau mir viel zu, für das LCD alles selbst zu schreiben ist aber 
aktuell noch nicht darunter.

Da muss ich erst noch ne ganze Menge lesen und ausprobieren.

[Dieter S. (ds1)]

Kilo S. schrieb:
>
> Hast du irgendeinen Hinweis was eventuell "nahe dran" sein könnte?

Das Problem ist dass die Kommandos zum Schreiben von Daten in den 
Display Speicher (das benutzt die Firmware) bei vielen Display 
Controller (auch von unterschiedlichen Herstellern) fast gleich sind, 
daher ist eine Zuordnung kaum möglich.

Und da ich ich kein so ein Teil zum Testen habe kann ich es auch nicht 
ausprobieren (Nein, hier in der Gegend liegt so was nicht rum und mir 
ist auch niemand bekannt der diese Teile benutzt).

[Kilo S. (kilo_s)]

Wenn du magst schicke ich dir eine. PN mit einer Mail-Adresse, dann ist 
die Kommunikation weniger "zäh" als per PN.

Den Verdampfer hab ich vorher raus geholt, ich geh noch mal mit iso 
drüber und dann sollte das gehen mit dem Versand.

Bzw. Von mir aus auch nur PCB+LCD, wie du magst.

[Kilo S. (kilo_s)]

Zu lange auf eine sache konzentrieren kann einen manchmal den blick auf 
"Wesentliches" kosten.

Tipp zu den "Digital Box" (12.000/15.000, Eckig) und "Randm Tornado" 
(12/15/20.000, Rund) achtet beim zerlegen auf das Marking "XWH-" auf der 
platine.

Auf denen sitzen auch Puya, mehr wird noch nicht verraten. ;-)

[Kilo S. (kilo_s)]

Jetzt geht's erst richtig los.

Ich hab Grad im örtlichen Supermarkt mein Netzwerk erweitert!

Nachschub ist sicher Leute!

[Kilo S. (kilo_s)]

Uff, viel zu lernen.
Dank Ghidra und dem svd bin ich jetzt jedenfalls schon mal 
zuversichtlich das ich in absehbarer Zeit Fortschritte mache.

Die Initialisierung des Displays scheint in mehrere Funktionen 
aufgeteilt. Außerdem verknüpft mit einem Timer?(Dazu eine Antwort wäre 
sehr nett,
Ja/Nein reicht, dient nur der Selbstkontrolle. Den Rest will ich selbst 
herausfinden.)

Jedenfalls zerlege ich aktuell die Funktion die das Interface über das 
AFL Register konfiguriert. Oder sagen wir so, ich Versuche es so gut es 
geht.

[Dieter S. (ds1)]

Hier ist ein "Proof of Concept" um das Display zu initialisieren.

Es handelt sich um ein Code-Fragment dass das Prinzip zeigt, man muss es 
allerdings erst in eine Display Library einbinden um es sinnvoll nutzen 
zu können.

Gezeigt wird welche Pins der PY32F030 zur Ansteuerung des Displays 
verwendet, wie der Display Controller initialisiert wird und noch ein 
kleiner Test der ein paar Farbbalken anzeigt (siehe das nicht besonders 
gute Bild im Anhang).

Einen bestimmten Display Controller konnte ich nicht identifizieren, ein 
paar der Kommandos findet man aber z.B. im Datenblatt des GC9A01A, 
vermutlich gibt es aber auch noch andere mit änlichen Kommandos.

Das Ganze ist "Bare Metal" und die seriellen Daten werden per 
Bit-Banging zum Display übertragen. Die entsprechenden Funktionen lassen 
sich aber leicht durch etwas anderes ersetzen (z.B. SPI per Hardware 
mit/ohne DMA).

Mein Testcode läuft direkt im RAM des PY32F030, daher war es zum Testen 
nicht nötig die Firmware im Flash zu überschreiben.

Was man unabhängig davon beachten sollte: Die Firmware verwendet IWDG 
als Hardware Watchdog, das wird im Konfigurationsbereich des Flash 
festgelegt. Daher startet der IWDG unmittelbar nach dem Reset. Das 
sollte man beachten bzw. die Konfiguration entsprechende ändern sonst 
bekommt man periodisch einen Reset wenn man den IWDG nicht regelmäßig 
triggert.

[Kilo S. (kilo_s)]

Dieter S. schrieb:
> Die Firmware verwendet IWDG als Hardware Watchdog, das wird im
> Konfigurationsbereich des Flash festgelegt. Daher startet der IWDG
> unmittelbar nach dem Reset. Das sollte man beachten bzw. die
> Konfiguration entsprechende ändern sonst bekommt man periodisch einen
> Reset wenn man den IWDG nicht regelmäßig triggert.

Mal doof gefragt, wie machst du das?
Über USB-C scheitert es schon am "Halt" (kann nicht angehalten werden?!) 
geschweige denn am lesen oder schreiben von Registern.

DBGMCU_APB1_FZ zb. Ist für mich überhaupt nicht erreichbar. Also selbst 
wenn ich Versuche an Adresse 0x40015808 zu schreiben (so macht es Ozone 
so weit ich gelesen habe) bekomme ich das nicht hin.

Irgendwie mach ich gerade was grundlegend falsch, ich komm nur nicht 
drauf was es ist.

[Dieter S. (ds1)]

Wenn der Watchdog aktiv ist und man eigenen Code im RAM laufen lassen 
will baut man das Triggern des Watchdog in den eigenen Code so ein dass 
es regelmäßig passiert. Außerdem sperrt man die Interrupts damit einem 
die Firmware nicht in die Quere kommt (z.B. die Timer Interrupts der 
Firmware). Das Ganze ist zum schnellen Testen kleiner Code-Teile 
gedacht, nicht für umfangreiche Software (dafür ist der RAM des PY32F030 
zu klein).

Den Code kann man vom J-Link Commander aus mit "loadbin" in den RAM 
laden und danach den PC auf den eigenen Code setzen, das geht schnell 
genug (man kann auch mehrere Kommandos per "Paste" hintereinander 
ausführen).

[Kilo S. (kilo_s)]

Dieter S. schrieb:
> Den Code kann man vom J-Link Commander aus mit "loadbin" in den RAM
> laden und danach den PC auf den eigenen Code setzen, das geht schnell
> genug (man kann auch mehrere Kommandos per "Paste" hintereinander
> ausführen).

Genau das Versuche ich.

Aktuell Versuche ich folgendes:

Halt
Loadfile fumot.bin, 0x20000000
Setpc 0x20000000
Go

Noch bevor ich bei "Go" bin, kommt der Reset.

Natürlich hab ich bisher noch nicht herausgefunden wie ich den watchdog 
abgeschaltet bekomme.
Je mehr ich lese um so undurchsichtiger wird es aktuell.

[Dieter S. (ds1)]

Der Watchdog ist im PY32F030 Reference Manual beschrieben ("22. 
Independent watchdog (IWDG)"). Abschalten kann man ihn nicht mehr wenn 
er mal gestartet wurde und wenn er als Hardware Watchdog konfiguriert 
ist (siehe "4.4. Flash option byte") startet er nach dem Reset. In 
diesem Fall muss man den Watchdog also regelmäßig triggern (0xAAAA ins 
IWDG_KR Register schreiben).

Im RAM stehen ab 0x20000000 die Interrupt Vektoren (die Firmware kopiert 
sie dort hin). Am einfachsten schreibt man eigenen Code in den RAM ab 
0x20000C20, der Bereich von dort bis zum RAM Ende (0x20001FFF bei 8 
kByte SRAM) wird von der Firmware nicht verwendet.

Und die vier Kommandos kann man auf einmal per "Paste" an den J-Link 
Commander schicken, dann werden sie ohne Unterbrechung hintereinander 
ausgeführt.

[Kilo S. (kilo_s)]

Dieter S. schrieb:
> Und die vier Kommandos kann man auf einmal per "Paste" an den J-Link
> Commander schicken, dann werden sie ohne Unterbrechung hintereinander
> ausgeführt

Ja, das klappt an und für sich schon.

Da müsste dann doch wenigstens bis der Watchdog am ende des counter 
angelangt ist ein mal das "Streifenbild" wenigstens aufblitzen?

Was jedenfalls schon mal sicher ist, das schreiben selbst funktioniert.
Ich hab den RAM danach ausgelesen, das programm ist da.

Hm.

Magst du mal schauen ob das bin das ich erzeugt hab auch funktioniert? 
(anhang)

Erzeugt hab ich es so:(display_init wurde in main.c umbenannt)

arm-none-eabi-gcc -o fumot.elf main.c  -mcpu=cortex-m0 -mthumb -Wall -Wextra -Os  -specs=nano.specs -nostartfiles

arm-none-eabi-objcopy fumot.elf -O binary fumot.bin

[Dieter S. (ds1)]

Ich habe oben bereits geschrieben dass man die Interrupts sperren muss 
und der Watchdog periodisch getriggert werden muss wenn man Code im RAM 
laufen lassen will, beides sehe ich nicht in "fumot_kilo.bin".

Außerdem liegt das Hauptprogramm an Offset 0x4FC in der Datei 
"fumot_kilo.bin", man muss also den PC auf diese Stelle setzen.

[Kilo S. (kilo_s)]

Wollte nicht so Recht, egal was ich da versucht habe.

Gut, das Projekt "Run Code in RAM" Werd ich später noch mal aufgreifen. 
Ich glaub da fehlt es noch bisschen mehr an Grundlage bis das klappt.

[Kilo S. (kilo_s)]

Ich glaub ich hab es endlich geschafft.
Zumindest scheint es erst mal zu funktionieren.

#include <Arduino.h>  // Standard Arduino header

void setup() {
  // Enable the LSI (Low-Speed Internal) oscillator used by the IWDG
  RCC->CSR |= RCC_CSR_LSION;  // Enable LSI oscillator
  // Wait for the LSI to become ready
  while (!(RCC->CSR & RCC_CSR_LSIRDY)) {
    // Wait here until LSI is stable
  }
  // Unlock the IWDG registers
  IWDG->KR = 0x5555;  // Writing 0x5555 unlocks the control registers of IWDG
  // Set the prescaler (divides the LSI clock to determine the watchdog timeout)
  IWDG->PR = 0x03;  // Set prescaler to divide by 64 (prescaler values range from 0-7)
  // Set the reload value (this sets the timeout period)
  IWDG->RLR = 0x0FFF;  // Maximum reload value for the longest timeout
  // Start the watchdog timer
  IWDG->KR = 0xCCCC;  // Writing 0xCCCC starts the IWDG
  // Initialize serial communication for debugging purposes
  Serial.begin(115200);
  Serial.println("IWDG Initialized.");

}

void loop() {
  // The main loop where we periodically refresh the watchdog
  refreshIWDG();
  // Do some work here and simulate task delays
  Serial.println("Running tasks...");
  // Add some delay to allow tasks to run and avoid over-refreshing the watchdog
  delay(500);  // Example delay (this can be adjusted based on your requirements)
}

// Function to refresh the Independent Watchdog (IWDG)
void refreshIWDG() {
  // Unlock the IWDG registers
  IWDG->KR = 0x5555;  // Writing 0x5555 unlocks the control registers of IWDG
  // Write 0xAAAA to the KR (Key Register) to refresh the IWDG counter
  IWDG->KR = 0xAAAA;  // Writing 0xAAAA resets the watchdog timer counter
  Serial.println("IWDG Refreshed.");
}

Die dazu gesetzten Option Bytes:(PuyaISP!)
IWDG_SW=0
WWDG_SW=1

Getting option bytes successfully!
AA 8E 55 71 FF 00 00 FF FF FF FF FF FF FF 00 00

Init, refresh, task:

IWDG Initialized.
11:55:38.887 -> IWDG Refreshed.
11:55:38.887 -> Running tasks...
11:55:39.420 -> IWDG Refreshed.
11:55:39.420 -> Running tasks...

[Kilo S. (kilo_s)]

Mal schauen ob ich (ist gar nicht so leicht) den pin finde der scheinbar 
"Hauptschalter" spielt.

Dann versuch ich diese version des code:

#include <Arduino.h> 
#include <SPI.h>

// Pin definitions for the LCD
#define LCD_PIN_RESET    4    // PB4: LCD Reset
#define LCD_PIN_CLOCK    3    // PB3: LCD Clock
#define LCD_PIN_DATA     5    // PB5: LCD Data
#define LCD_PIN_SELECT   8    // PA8: LCD Select
#define LCD_PIN_CMD_DATA 12   // PA12: LCD Command or Data
#define LCD_PIN_BACKLIGHT 11  // PA11: LCD Backlight

#define LCD_WIDTH   128
#define LCD_HEIGHT  160

// Some RGB565 colors
#define LCD_RGB565_BLACK    0x0000
#define LCD_RGB565_WHITE    0xFFFF
#define LCD_RGB565_RED      0xF800
#define LCD_RGB565_GREEN    0x07E0
#define LCD_RGB565_BLUE     0x001F

// Initialize SPI communication and GPIO
void setup() {
  // Enable the LSI (Low-Speed Internal) oscillator used by the IWDG
  RCC->CSR |= RCC_CSR_LSION;  // Enable LSI oscillator

  // Wait for the LSI to become ready
  while (!(RCC->CSR & RCC_CSR_LSIRDY)) {
    // Wait here until LSI is stable
  }

  // Unlock the IWDG registers
  IWDG->KR = 0x5555;  // Writing 0x5555 unlocks the control registers of IWDG

  // Set the prescaler (divides the LSI clock to determine the watchdog timeout)
  IWDG->PR = 0x03;  // Set prescaler to divide by 64 (prescaler values range from 0-7)

  // Set the reload value (this sets the timeout period)
  IWDG->RLR = 0x0FFF;  // Maximum reload value for the longest timeout

  // Start the watchdog timer
  IWDG->KR = 0xCCCC;  // Writing 0xCCCC starts the IWDG

  
  // Set up pin modes for control pins
  pinMode(LCD_PIN_RESET, OUTPUT);
  pinMode(LCD_PIN_CLOCK, OUTPUT);
  pinMode(LCD_PIN_DATA, OUTPUT);
  pinMode(LCD_PIN_SELECT, OUTPUT);
  pinMode(LCD_PIN_CMD_DATA, OUTPUT);
  pinMode(LCD_PIN_BACKLIGHT, OUTPUT);

  // Start SPI communication (SPI pins are pre-defined in Arduino)
  SPI.begin();
  SPI.setBitOrder(MSBFIRST);  // Set bit order to MSB first
  SPI.setDataMode(SPI_MODE0); // Set SPI mode to 0 (CPOL=0, CPHA=0)
  SPI.setClockDivider(SPI_CLOCK_DIV2); // SPI speed setting

  // Initialize the LCD
  LCD_GPIO_config();
  LCD_init();
  LCD_transfer_test();
}

// Main loop
void loop() {
  // Normally, you can add additional functionality here if needed.
  refreshIWDG();
}

// Set GPIO pins to control LCD functions
void LCD_GPIO_config() {
  digitalWrite(LCD_PIN_RESET, LOW);
  digitalWrite(LCD_PIN_CLOCK, LOW);
  digitalWrite(LCD_PIN_DATA, LOW);
  digitalWrite(LCD_PIN_SELECT, HIGH);  // Deselect
  digitalWrite(LCD_PIN_CMD_DATA, LOW); // Command mode initially
  digitalWrite(LCD_PIN_BACKLIGHT, HIGH); // Turn on backlight
}

// Reset the LCD
void LCD_Reset(int iReset) {
  if (iReset)
    digitalWrite(LCD_PIN_RESET, LOW); // Reset
  else
    digitalWrite(LCD_PIN_RESET, HIGH); // No reset
}

// Clock pulse for SPI
void LCD_Clock(int iClockLevel) {
  if (iClockLevel)
    digitalWrite(LCD_PIN_CLOCK, HIGH);
  else
    digitalWrite(LCD_PIN_CLOCK, LOW);
}

// Set LCD select pin (active low)
void LCD_Select(int iSelect) {
  if (iSelect)
    digitalWrite(LCD_PIN_SELECT, LOW);  // Select the display
  else
    digitalWrite(LCD_PIN_SELECT, HIGH); // Deselect the display
}

// Command mode (send command byte)
void LCD_Command(int iCommand) {
  if (iCommand)
    digitalWrite(LCD_PIN_CMD_DATA, LOW); // Command mode
  else
    digitalWrite(LCD_PIN_CMD_DATA, HIGH); // Data mode
}

// Send data byte through SPI
void LCD_send_SPI(uint8_t u8_byte) {
  SPI.transfer(u8_byte);
}

// Delay loop (adjust as necessary)
void delay_loop(int iDelay) {
  delay(iDelay);
}

// LCD initialization function
void LCD_init() {
  LCD_Select(1); // Select the LCD
  LCD_Command(1); // Command mode

  // Reset sequence
  LCD_Reset(0); 
  delay_loop(500);
  LCD_Reset(1);
  delay_loop(5000);
  LCD_Reset(0);
  delay_loop(12000);
}

// Send command byte
void LCD_send_CMD_byte(uint8_t u8_byte) {
  LCD_Select(1);
  LCD_Command(1); // Command mode
  LCD_send_SPI(u8_byte);
  LCD_Select(0); // Deselect the LCD
}

// Send data byte
void LCD_send_DATA_byte(uint8_t u8_byte) {
  LCD_Select(1);
  LCD_Command(0); // Data mode
  LCD_send_SPI(u8_byte);
  LCD_Select(0); // Deselect the LCD
}

// Send RGB565 data
void LCD_send_RGB565(uint16_t u16_rgb565) {
  LCD_send_DATA_byte((uint8_t)(u16_rgb565 >> 8));  // High byte
  LCD_send_DATA_byte((uint8_t)(u16_rgb565 & 0xFF)); // Low byte
}

// Test pattern (fill screen with different colors)
void LCD_transfer_test() {
  uint8_t u8_col_start = 0;
  uint8_t u8_col_end = LCD_WIDTH - 1;
  uint8_t u8_row_start = 0;
  uint8_t u8_row_end = LCD_HEIGHT - 1;

  LCD_send_CMD_byte(0x29);  // Display ON

  // Column and Row Address Set (2A, 2B)
  LCD_send_CMD_byte(0x2A);
  LCD_send_DATA_byte(0x00); // Start high
  LCD_send_DATA_byte(u8_col_start); // Start low
  LCD_send_DATA_byte(0x00); // End high
  LCD_send_DATA_byte(u8_col_end); // End low

  LCD_send_CMD_byte(0x2B);
  LCD_send_DATA_byte(0x00); // Start high
  LCD_send_DATA_byte(u8_row_start); // Start low
  LCD_send_DATA_byte(0x00); // End high
  LCD_send_DATA_byte(u8_row_end); // End low

  // Memory Write (2C)
  LCD_send_CMD_byte(0x2C); 

  // Loop to fill screen with colors
  for (int row = u8_row_start; row <= u8_row_end; row++) {
    uint16_t color;

    int which_color = (row - u8_row_start) / ((u8_row_end + 1 - u8_row_start) / 8);

    if (which_color == 0)
      color = LCD_RGB565_WHITE;
    else if (which_color == 1)
      color = LCD_RGB565_RED;
    else if (which_color == 2)
      color = LCD_RGB565_GREEN;
    else if (which_color == 3)
      color = LCD_RGB565_BLUE;
    else if (which_color == 4)
      color = LCD_RGB565_BLACK;
    else if (which_color == 5)
      color = LCD_RGB565_RED | LCD_RGB565_GREEN;
    else if (which_color == 6)
      color = LCD_RGB565_RED | LCD_RGB565_BLUE;
    else
      color = LCD_RGB565_BLUE | LCD_RGB565_GREEN;

    for (int col = u8_col_start; col <= u8_col_end; col++) {
      LCD_send_RGB565(color);
    }
  }
}

// Function to refresh the Independent Watchdog (IWDG)
void refreshIWDG() {
  // Write 0xAAAA to the KR (Key Register) to refresh the IWDG counter
  IWDG->KR = 0xAAAA;  // Writing 0xAAAA resets the watchdog timer counter

  Serial.println("IWDG Refreshed.");
}

[Kilo S. (kilo_s)]

Da fress ich nen besen... ich find den pin nicht!

PA5/PA6 sind auf dem E Kippen PCB die zwei Pins für die verdampfer.
Da blinken grad zwei LED.

#include <Arduino.h>  // Standard Arduino header

void setup() {

  // Enable the LSI (Low-Speed Internal) oscillator used by the IWDG

  RCC->CSR |= RCC_CSR_LSION;  // Enable LSI oscillator

  // Wait for the LSI to become ready

  while (!(RCC->CSR & RCC_CSR_LSIRDY)) {

    // Wait here until LSI is stable

  }

  // Unlock the IWDG registers

  IWDG->KR = 0x5555;  // Writing 0x5555 unlocks the control registers of IWDG

  // Set the prescaler (divides the LSI clock to determine the watchdog timeout)

  IWDG->PR = 0x03;  // Set prescaler to divide by 64 (prescaler values range from 0-7)

  // Set the reload value (this sets the timeout period)

  IWDG->RLR = 0x0FFF;  // Maximum reload value for the longest timeout

  // Start the watchdog timer

  IWDG->KR = 0xCCCC;  // Writing 0xCCCC starts the IWDG

  // Initialize serial communication for debugging purposes

  Serial.begin(115200);

  Serial.println("IWDG Initialized.");
  pinMode(PA5, OUTPUT);
  pinMode(PA6, OUTPUT);
  pinMode(PA11, OUTPUT);
  digitalWrite(PA11, HIGH);
}

void loop() {

  // The main loop where we periodically refresh the watchdog

  refreshIWDG();

  // Do some work here and simulate task delays

  Serial.println("Running tasks...");
  digitalWrite(PA5, HIGH);
  Serial.println("PA5 HIGH");
  delay(1000);
  digitalWrite(PA5, LOW);
  Serial.println("PA5 LOW");
  refreshIWDG();
  delay(1000);
  digitalWrite(PA6, HIGH);
  Serial.println("PA6 HIGH");
  delay(1000);
  digitalWrite(PA6, LOW);
  Serial.println("PA6 LOW");
  refreshIWDG();

  // Add some delay to allow tasks to run and avoid over-refreshing the watchdog

  delay(500);  // Example delay (this can be adjusted based on your requirements)

}

// Function to refresh the Independent Watchdog (IWDG)

void refreshIWDG() {
  // Write 0xAAAA to the KR (Key Register) to refresh the IWDG counter

  IWDG->KR = 0xAAAA;  // Writing 0xAAAA resets the watchdog timer counter

  Serial.println("IWDG Refreshed.");

}

[Kilo S. (kilo_s)]

TH (Touch_High, Touchsensor) liegt auf Pin 8/PA2/USART1_TX/ISP
Den man auch anzapfen muss um mit der Arduino IDE zu Flashen! Ist eine 
leiterbahn, Pin9 PA3/USART1_RX/ISP ist eine VIA, nur ganz knapp am MCU 
angebunden, die rupft man auch leicht ab. (Grrr, bitte lass das nicht 
den schalter für POWER sein der auch die hintergrundbeleuchtung mit 
aktiviert, das geflicke....)

"M" (Unterdrucksensor) liegt auf Pin 25/PA15.

So weit bisher...

Code gibt es da grad keinen zu, hab die mit dem Multimeter so weit es 
ging  durchgeklingelt.

[Dieter D. (Firma: Hobbytheoretiker) (dieter_1234)]

Kleiner Hinweis:
Solche längeren Programmschnipsel sollten als Anlagedatei hochgeladen 
werden.

[Kilo S. (kilo_s)]

Dieter D. schrieb:
> Kleiner Hinweis:
> Solche längeren Programmschnipsel sollten als Anlagedatei hochgeladen
> werden.

Werde ich berücksichtigen.
Ich selbst mag es eigentlich lieber "Direkt" lesen zu können.


Pin6/PA0 ist der ADC der über einen teiler an B+ geht.

10K (in der schaltung!) von PA0 nach GND, 10K in reihe PA0 zu B+.
Und ein C Parallel, keine ahnung wie groß.

[Kilo S. (kilo_s)]

Pin 5  PF_3, über 2K an einen der "Schalter" (VDD!)


Ich glaub da hab ich ihn!

Oder nur einen von mehreren? klingt nach VCC_DIGITAL_DATA
also nach der versorgung für den controller?

Dieter (ds1), kannst du da licht ins dunkle bringen?

[Kilo S. (kilo_s)]

Uuups, Verrutscht.

Der ADC ist Pin 7 /PA1.

[Kilo S. (kilo_s)]

Ah... mieses gefummel.

BEIDE Pin 6 und 7 sind ADC.
Pin 7 /PA1 ist für die 5V in, 33k, 33k.
pin 6 /PA0 ist für B+ mit 10k, 10k.

[Dieter S. (ds1)]

Zu den GPIO Pins im Zusammenhang mit Run/Sleep:

PF3: 0 -> Run   1 -> Sleep
PA9: 1 -> Run   0 -> Sleep

Und noch ein paar weitere GPIO Pins:

SPI Flash:
  PA3 Select
  PB6 SPI2_MISO
  PB7 SPI2_MOSI
  PB8 SPI2_SCK

[Kilo S. (kilo_s)]

Herzlichsten Dank.

Als nachstes werd ich mir die SPI initialisierung des MCU vornehmen.
Da passt was noch nicht.

[Kilo S. (kilo_s)]

Watchdog, GPIO (ADC, Backlight..) und flash hab ich schon mal so weit.

Nur das Display das will noch nicht so recht!

Der code oben erzeugt (auf der zweiten seriellen unter dem Display FPC!) 
diese ausgabe:

IWDG Initialized.
16:57:39.169 -> Manufacturer ID: 0x85
16:57:39.169 -> Memory Type: 0x20
16:57:39.169 -> Capacity: 0x18
16:57:39.169 -> 0.00
16:57:39.169 -> 2.00
16:57:39.169 -> IWDG Refreshed.
16:57:39.666 -> IWDG Refreshed.
16:57:40.162 -> IWDG Refreshed.
16:57:40.659 -> IWDG Refreshed.

Bild kommt auch gleich noch eins. ;)

[Kilo S. (kilo_s)]

Der CH340 ist ISP (Pin 1, CS vom Flash, TH, Touch_High)
Der CH341 die serielle.

[Kilo S. (kilo_s)]

So bald ich LCD_transfer_test ausführe endet es im Reset Loop.

Mensch, ich seh den fehler nicht!

[Dieter S. (ds1)]

SPI für das Display und externen Flash sind unterschiedliche GPIO Pins 
(das Display ist SPI1, der Flash SPI2), die SPI Transfers im Code gehen 
also wohl alle zum externen Flash.

Außerdem sollte PA9 auf High gesetzt sein (siehe wieter oben im Bezug 
auf Run/Sleep in der Firmware).

[Kilo S. (kilo_s)]

Dieter S. schrieb:
> Außerdem sollte PA9 auf High gesetzt sein (siehe wieter oben im Bezug
> auf Run/Sleep in der Firmware).

Lustige Sache, mit denen hatte ich vorher testweise gewackelt Um zu 
sehen welchen Einfluss sie genau haben.

Ich Versuche mal was passiert wenn ich die SPI init vom Flash auf die 
Pins vom LCD (das sollten zwei Initialisierte SPI Interfaces sein und 
SPI1 sollte theoretisch das Display sein) anwende.

[Kilo S. (kilo_s)]

Es ändern sich pixel... trotzdem ein reset loop.

[Dieter S. (ds1)]

Wenn Du den IWDG nicht konfigurierst ist der Default Timeout nach dem 
Reset nur 0.5 Sekunden. Dann geht "delay(500)" relativ sicher schief.

Setzte den IWDG Prescaler auf 256, dann ist genügend Zeit (32 Sekunden).

[Kilo S. (kilo_s)]

Jetzt kommt auf dem Display immerhin mal "etwas".
Dafür streikt die BL Steuerung.

Code kommt gleich.

[Kilo S. (kilo_s)]

Ich bin gespannt wo ich es diesmal verhauen hab!

[Kilo S. (kilo_s)]

da kann ich sowohl in der init als auch in der funktion:

// Memory Access Control
    lcdCommand(0x36);
    lcdData(0x60);

verwenden. Orientation ändert sich nicht.

Backlight bekomme ich auch ncht mehr zum laufen, völlig egal was ich da 
mache....

Ein schritt vor und drei zuruck!

[M. G. (looking)]

Kilo S. schrieb:
> Ich bin gespannt wo ich es diesmal verhauen hab!

In den Funktionen lcdCommand und lcdData würde ich erst den Pin 
LCD_PIN_CMD_DATA setzen und danach LCD_PIN_CS. Hat evtl. zwar keinen 
Einfluss, ist aber besser verständlich.

[Kilo S. (kilo_s)]

M. G. schrieb:
> Hat evtl. zwar keinen Einfluss, ist aber besser verständlich.

Den einzigen Einfluss den ich feststellen konnte ist im Zusammenhang mit 
PB3/LCS_PIN_SCK.

Kommentiere ich SPI.setSCLK(LCD_PIN_SCK); aus geht die 
Hintergrundbeleuchtung.

Der Fehler ist mir Grad zu hoch.

Egal wie und in welcher Kombi ich da mit was wackel. Da geht nix!

[Dieter S. (ds1)]

Kilo S. schrieb:
>
> Kommentiere ich SPI.setSCLK(LCD_PIN_SCK); aus geht die
> Hintergrundbeleuchtung.

PA11 hat als mögliche Funktion SPI1_MISO. Eventuell macht die Arduino 
Runtime hier irgendwas falsch, vielleicht mal 
"pinMode(LCD_PIN_BACKLIGHT, OUTPUT)" nach "SPI.setSCLK(LCD_PIN_SCK)" 
aufrufen und schauen ob das hilft.

[Kilo S. (kilo_s)]

Beide änderungen getestet.

Bild bleibt das gleiche, anscheinend um 90° nach rechts/links gedreht 
und nur vier streifen die je ca 1/4 der 128 pixel breite belegen. 
(hell,dunkel,hell,dunkel)

Ich hab eben auch ne Soft SPI variante ausprobiert.

Das exakt gleiche verhalten.

Möglichkeit A: Ich hab irgendwo die init oder sonst was verkackt!
Möglichkeit B: Der Arduino core ist nicht ganz fehlerfrei.

[Dieter S. (ds1)]

Eventuell hilft ein "SPI.setMISO(NC)" bevor SPI für das Display benutzt 
wird und danach dann nochmal PA11 für das Backlight initialisieren.

[Kilo S. (kilo_s)]

Dieter S. schrieb:
> Eventuell hilft ein "SPI.setMISO(NC)" bevor SPI für das Display benutzt
> wird und danach dann nochmal PA11 für das Backlight initialisieren.

Genau das versuche ich Gerade. ;-)

Ich wühl mich gerade durch den core.

https://github.com/py32duino/Arduino-PY32/blob/master/variants/PY32F030xx/PY32F030_Base/PeripheralPins.c


Lustig, hab es mal mit dem core für "Generic" STM32F03 ausprobiert.

Nach der anderung einiger kleinigkeiten kam zwar ein bin bei raus, 
funktioniert aber leider nicht.

Kleine änderungen ab jetzt: Watchdog ist aus, mit dem ISPtool beides auf 
"Software" (0,0) gesetzt. Einfach zum test ob es einen unterschied 
macht. (Ich vermute es macht keinen, wenn doch beiss ich mir in 
hintern!)

[Kilo S. (kilo_s)]

So weit so gut.

Jetzt "Kratzt" er beim init des LCD ab, springt mit lcdInit nicht in die 
loop, kommentiere ich lcdInit aus (egal welche varinte gewählt, also ob 
1/0) läuft die loop klaglos.

Backlight ist allerding an.

[Kilo S. (kilo_s)]

Lustig.

NUR wenn

SPI.setMISO(NC);

gesetzt ist, springt er nicht in die loop.

Ansonsten ist immer die "Init" Falsh, das display zeigt die streifen 
(foto mit Taschenlape als BL) und die beleuchtung ist aus.

Wenn wenigstens nur das licht aus wäre aber die init ok...

[Kilo S. (kilo_s)]

Kurze Runde frische Luft schnappen und dann geht's weiter!

Backlight ist aus wenn das Schreiben klappt, immer, immerhin konnte ich 
eben (Taschenlampe zur Beleuchtung) schon mal genug testen um wenigstens 
einen Teil des Displays (knapp weniger als das obere Drittel) zu 
beschreiben.
(lcdFillScreen Funktion)

Kaum geht das Backlight ist nix mehr mit schreiben des Displays.

Und wie man sieht, erweiterte Fehlersuche ist auch gestartet.

[Kilo S. (kilo_s)]

Es geht Natürlich im stillen weiter.

Ich bin noch immer erstaunt das meine Vermutung richtig war: Der Core 
ist fehlerhaft.

Dieter hat es bestätigt, PF3 wird nicht initialisiert und daher VDD, 
Versorgung des Controller, nicht eingeschaltet wird.

Aktuell bastel ich (mit Hilfe des Workaround das Dieter mir hat zukommen 
lassen) an einer Header Datei die man in sein Arduino Projekt einbinden 
kann.

[DavidBlaine D. (davidblaine)]

Auch die hochkapazitiven (25000 Puffs = Züge) Einweg-Dinger haben USB-C,
weil dann können die Akkus kleiner (=billiger) sein. Und bei Fumot
heißen die Typ-C-Anschluss und Typ-C-Schnellladung, vermutlich weil sie
sich dadurch Lizenz-Gebühren sparen.

Folgende 2-Milliliter-Regelung habe ich nicht verstanden, dadurch erhöht
sich doch der Einweg-Müll:
Zitat https://jr-vape.com/
Warum sind Tornado-Vapes in Deutschland verboten?

Der Tornado Vape ist in Deutschland nicht generell verboten, allerdings
gibt es strenge Vorschriften, die das Gerät in seiner aktuellen Form auf
dem deutschen Markt einschränken. Ein Grund dafür sind die in
Deutschland geltenden Regelungen zur E-Zigaretten-Nutzung. Die maximale
Liquid-Menge in einem Einweg-Vape darf hier 2 ml nicht überschreiten.
Der Tornado Vape, der bis zu 12.000 Züge bietet, enthält deutlich mehr
als diese Menge und verstößt damit gegen die deutsche
E-Zigaretten-Richtlinie.

Zudem gibt es Vorschriften bezüglich der Nikotinmengen, die in
Vaping-Produkten erlaubt sind. Diese strengen Gesetze sollen den
Verbraucherschutz stärken, insbesondere in Bezug auf minderjährige
Nutzer. Deshalb sind viele Einweggeräte, die in anderen Ländern
problemlos verkauft werden, in Deutschland nicht zugelassen.
Zitatende

Man kann sie dennoch kaufen. Bestellen oder "unter der Hand".

2025-02-17 18:06: Bearbeitet durch User

[Kilo S. (kilo_s)]

Naja, ich zerlege hauptsächlich, was daran liegt das ich diese am 
häufigsten finde, die illegalen Modelle.

Und ja, die Menge an Müll ist enorm.

In den 12/15-000 Züge Modellen (Rund) sind 850mAh Zellen verbaut. Flache 
haben 680mAh. In den 25.000 ~680mAh.
Die legalen haben meist zwischen 350-400mAh.

Aktuell habe ich herausgefunden das sich die Palette an "Nutzbaren" IC 
in den Teilen erweitert hat.

Neben den 25.000 Zügen mit LCD und F030 befinden sich scheinbar auf 
einigen der Runden und Flachen 12/15-000 Züge mit Charlyplexing LED 
Anzeige PY32F002AW15 (Das A ist wichtig, dafür gibt es einen Arduino 
Core.)

Leider ist die Rate Verwertbar/Schrott sehr niedrig, auf insgesamt drei 
Platinen mit F002AW15 und drei mit Risc V PY32C642F15 kommt der kleine 
Eimer "Schrott". Also 6 Nutzbare (!) MCU und beim Rest hauptsächlich die 
Akkus.
Auf den platinen für den schrott sind zwar Kleinteile (Laderegler, USB-C 
Buchsen, manchmal P-Channel Fet's) aber am liebsten wäre mir ich könnt 
noch mehr der MCU identifizieren und nutzbar machen.

Das unter Ausschluss der aktuell in Wellen und selten auftauchenden 
25.000 Züge Modelle mit LCD.

Die können direkt inklusive Platine für Kleine Projekte verwendet 
werden. Die einzigen bei denen diese Lösung denkbar ist. Die anderen 
höchstens wenn man sich ein neues Cover für die LED Displays druckt, 
ansonsten ist es sinnvoller die IC auf eine eigene Platine zu bringen.

[Cyblord -. (cyblord)]

Kilo S. schrieb:
> Das A ist wichtig, dafür gibt es einen Arduino
> Core.)

Gott sei Dank. Wie würden wir auch Hardware in Betrieb nehmen ohne 
Arduino Core. Unvorstellbar.

[Kilo S. (kilo_s)]

Cyblord -. schrieb:
> Unvorstellbar.

Das man sowas als nützlichen Vorteil erachten könnte um die Teile für 
alle, inklusive Schulkindern und wenn's sein soll sogar der Oma von 
nebenan programmierbar zu machen!

Aber sei's mal wieder drum, nochmals als Erklärung: Ziel ist es 
möglichst viel von den MCU Wieder zu Verwenden und das so einfach das 
"Jedermann" aus dem Kram was basteln kann.

Das ist wichtig um die Einstiegshürden klein zu halten und das Interesse 
daran besser wecken zu können.

[Kilo S. (kilo_s)]

Oha!

Heute bekomme ich wo nach ich schon ne Weile gesucht habe: 
https://vaping360.com/de/product/halo-vapor-synix-30000/

Kann ich heute Abend gegen 19 Uhr abholen.

Endlich, EEEEENDLICH!

Das Teil wird so Spaß machen zu zerlegen und zu analysieren!

[Georg M. (g_m)]

Kilo S. schrieb:
> Oha!
>
> Heute bekomme ich wo nach ich schon ne Weile gesucht habe:
> https://vaping360.com/de/product/halo-vapor-synix-30000/
>
> Kann ich heute Abend gegen 19 Uhr abholen.
>
> Endlich, EEEEENDLICH!
>
> Das Teil wird so Spaß machen zu zerlegen und zu analysieren!

Was ist der Unterschied zwischen einem Fachforum und einem persönlichen 
Tagebuch?

[Kilo S. (kilo_s)]

Hier haben sich ein paar Leute eingefunden, die Interesse daran haben 
könnten.

Ob du es glaubst oder nicht, hier gibt's auch Mitleser die nicht viel im 
Beitrag mit schreiben aber trotzdem in Kontakt mit mir stehen.

Ob ich jetzt ne Rundmail mache oder hier offen poste um weitere 
Interessenten zur Beteiligung animiere steht gar nicht zur Debatte.

Wenn's dir nicht passt klick einfach weiter!

[Cyblord -. (cyblord)]

Georg M. schrieb:

> Was ist der Unterschied zwischen einem Fachforum und einem persönlichen
> Tagebuch?

Wenn man sich ansieht was hier inzwischen für Threads laufen gelassen 
werden: Knackers Lauf- und Gartentagebuch, Kochrezepte, Esoterik, Musik 
usw. usw.

Sachliche Beiträge werden hingegen rigoros gelöscht. Möchte man hier 
nicht mehr haben.
Nur noch seniles Geronten-Gelaber ist erwünscht.

[Kilo S. (kilo_s)]

Ich freue mich sehr über diesen Beitrag hier.

Dieter S. (ds1) Und andere helfer haben mit ihrer freundlichen Hilfe 
bewiesen das dieses Forum hier durchaus dazu im Stande ist gemeinsam was 
zu schaffen.

Das Display ist verwendbar, jeder der möchte kann nun wenn er so ein 
Ding aufsammelt das Display abstecken, ein 12 Pin FPCC breakout kaufen 
und dann an seinen Arduino klemmen oder auch die ganze E-Zigarette 
nutzen.

Ich finde das ist schon ein ERFOLG für das Forum.

Noch dazu hab ich bisher schon viel von den anderen lernen können.

Und natürlich werde ich auch bei der neuen E-Zigarette schauen ob ich 
mehr als ein Exemplar organisieren kann. ;-)

Zwei Stück sind direkt vorgemerkt!

[David G. (Firma: 10.08.1985) (follow2000)]

Hallo Kilo S.

wie genau kontaktierst du die Tornado 2500 ? Du schreibst man kann auch 
den internen MC benutzen. Kann man den Tornado über die Pins die auf der 
USB C Buchse programmieren und die Hardware (LCD, Touchscreen) mit 
dieser verwenden ? Gibt es eine Integration in der Arduino IDE ? Sind 
DIO herausgeführt auf dem Board so das man eigene Sensoren etc daran 
anschliessen kann ?

Sorry für die vielen Fragen. Aber der Thread ist so lang und in viele 
kleine Infos zerlegt...

[Kilo S. (kilo_s)]

David G. schrieb:
> wie genau kontaktierst du die Tornado 2500 ?

Guten morgen David, entschuldige die späte Antwort.

Es gibt zwei Möglichkeiten:
1.) SWD über USB-C.
2.) ISP über USART.

Der UART liegt auf Flash Select (Pin 9 am μC USART RX) und Touch Signal 
(Pin 8 am μC USART TX)

SWD hab ich über einen alten OTG Adapter gelöst, die musst du dir je 
nach Adapter durchmessen, meiner hat mehrere lagen und ich musste zwei R 
entfernen um über SWD zu verbinden.

Die Pins RX/TX unter dem flex Kabel sind leider die zweite Serielle 
Schnittstelle, die eignet sich nicht zum Flashen wie es scheint.

David G. schrieb:
> Touchscreen

Ist nur ein "Touch Button", prinzipiell nix anderes als ein Taster. 
Zeichnen oder direkt auf dem Display was tippen ist bei denen nicht 
möglich.

David G. schrieb:
> Gibt es eine Integration in der Arduino IDE ?

Ja gibt es, PY32Duino.

Leider ist der Core fehlerhaft, ein Pin kann nicht vernünftig 
initialisiert werden. (PF3, Physikalisch Pin 5 am μC)

Der ist leider für die Stromversorgung des Display Controller 
verantwortlich und kann daher nur mit einem entsprechenden Stück C Code 
verwendet werden.

David G. schrieb:
> Sind DIO herausgeführt auf dem Board so das man eigene Sensoren etc
> daran anschliessen kann ?

Die zweite Serielle Schnittstelle lässt sich problemlos benutzen, auch 
als GPIO und ist herausgeführt, ein paar Pins müssten zumindest 
theoretisch frei sein. Aber ob die noch irgendwo herausgeführt sind hab 
ich bisher nicht nachgesehen.

[Kilo S. (kilo_s)]

So sieht das übrigens bei mir gerade aus.

Ich packe dir gleich mal ein Beispiel zusammen. Das beinhaltet aktuell 
aber NUR die ADC und Displayfunktionen. Die Textfunktion ist auch nicht 
wirklich gut gelungen.

Alles Work in Progress bei mir.

[Kilo S. (kilo_s)]

Das ist exakt der Code der auf den bildern zu sehen ist.

Und die links zum arduino core: https://github.com/py32duino

Boardverwalter URL: 
https://github.com/PY32Duino/Arduino-pack-json-ci/releases/download/Nightly/package_py32_index.json

[David G. (Firma: 10.08.1985) (follow2000)]

Hi,
Das sieht ja richtig gut aus.
Erstmal ein großes Lob an dich.
Die Hardware ist doch super um mobile Tester damit zu bauen. Mir schwebt 
da schon ein anwendungsfall vor. Hast du eventuell rausbekommen ob der 
Controller einen sleep Modus hat ? Um die Batterie zu schonen. Oder ist 
das bei der großen Batterie nicht erforderlich ? Wie wird die vape 
normalerweise eingeschaltet ? Auf den touch Button drücken ? Oder dran 
ziehen ? Wenn über den touch dann wird damit wahrscheinlich der richtige 
PIN bedient um das Teil aus dem depp sleep zu bekommen.

Und die letzte Frage. Wo kriegt man so ein Teil (leer) am besten 
organisiert ?

[Kilo S. (kilo_s)]

David G. schrieb:
> Erstmal ein großes Lob an dich.

Das geht an Dieter S. (ds1)!

Er ist der mit der größeren refahrung und hat die sachen zum laufen 
gebracht.
Ich bin aktuell nur der, welcher durch die tipps lernt und die 
erkentnisse hier postet.

David G. schrieb:
> Hast du eventuell rausbekommen ob der
> Controller einen sleep Modus hat ?

https://download.py32.org/ReferenceManual/en/PY32F030%20Reference%20manual%20v1.3_EN.pdf

Seite 55.

David G. schrieb:
> Wie wird die vape
> normalerweise eingeschaltet ?


Gute frage, hab ich mich absolut noch nie mit auseinandergesetzt.
Das initiale aktivieren hab ich aktuell nicht gefunden, vermute aber das 
die original firmware auf den touch oder zugsensor reagieren wird. (n X 
tippen/ziehen) Bis dahin bleibt ja nur sleep, hardwareschalter gibt es 
keinen!

David G. schrieb:
> Wenn über den touch dann wird damit wahrscheinlich der richtige
> PIN bedient um das Teil aus dem depp sleep zu bekommen.

Eleganter als meine lösung ist ja ein timer/interrupt für die abfrage, 
wenn ich das richtig in erinnerung hab gibts nen timer der auch im sleep 
läuft und der rest vermutlich nur in software.

David G. schrieb:
> Und die letzte Frage. Wo kriegt man so ein Teil (leer) am besten
> organisiert ?

Das bekommen wir hin. ;-)

[Kilo S. (kilo_s)]

David G. schrieb:
> Und die letzte Frage. Wo kriegt man so ein Teil (leer) am besten
> organisiert ?

Vorsorglich, falls meine PN nicht angekommen ist.

Schreib mir mal deine Mailadresse per PN.

[Dirk (dirk74)]

Hab das Ding auch mal auseinandergebaut. War bei mir ein PY32F030 + 
P25Q128 Flash, Display über SPI, GC9A01 passt.
Spannend ist, wie viel Technik in so nem Wegwerfteil steckt – zum 
Basteln gar nicht schlecht.
Wer vergleichen will, was in den verschiedenen Modellen drin ist (LCD 
oder nicht, Akku usw.), findet z.B. hier ’ne ganz brauchbare Übersicht: 
https://randmsmoke.net
Ist zwar eigentlich ein Shop, aber als Modell-Referenz nicht verkehrt.

[Kilo S. (kilo_s)]

Dirk schrieb:
> War bei mir ein PY32F030 +
> P25Q128 Flash, Display über SPI

Bei den 25.000 ist die hardware bisher immer gleich gewesen.

Bei den 12/15-000 modellen gibt es unterschiedliche PCB/Hersteller.

Darunter auch welche mit PY32F002 und PY32C642F15 drauf.

[Jason (jasonht)]

Fumot, was für ein vertrauter Name. Früher habe ich Produkte dieser 
Firma verkauft, aber jetzt habe ich meine Karriere geändert.

[Kilo S. (kilo_s)]

Jason schrieb:
> Früher habe ich Produkte dieser Firma verkauft, aber jetzt habe ich
> meine Karriere geändert.

Oh, interessant.

Sag mal, du weißt nicht zufällig wie man anhand der Innereien (Aufdruck 
auf den Platinen, verwendeten IC ect..) Fälschungen (bei den 
12000/15000) erkennt?

Oder anhand anderer Merkmale?

[Jason (jasonht)]

Tut mir leid, ich weiß es nicht.
Ich kaufe direkt beim offiziellen Fumot-Verkäufer und bestätige, dass 
ich keine gefälschten Produkte kaufen werde.

[Kilo S. (kilo_s)]

Jason schrieb:
> Tut mir leid, ich weiß es nicht.

Schade, danke für die Info.

Es ist erstaunlich wie viele verschiedene Platinen (Layout, Bauteile, 
Aufdruck) ich von denen schon gefunden habe. Herauszufinden welche davon 
nun "Fake" und welche original sind, wäre nur nach einer Analyse eines 
"frischen" echten Karton möglich.

[Jason (jasonht)]

Es gibt tatsächlich viele Imitationen auf dem Markt. Um die Echtheit zu 
gewährleisten, muss man sie offiziell bei Fumot kaufen. Ich weiß nicht, 
ob sie in Deutschland einen offiziellen Shop haben. Es gibt viele 
Imitationen auf dem Markt, das gilt auch für Elfbar.

[Stefan K. (stk)]

Jason schrieb:
> Es gibt viele
> Imitationen auf dem Markt, das gilt auch für Elfbar.

ELF Bar Vapes wurden neben anderen in einer Studie zu Metallen in deren 
Aerosolen untersucht. Gefunden wurden bei ELF Bar u.a. Chrom und Nickel.
Bei anderen Einweg-Vapes war nach einiger Benutzungszeit auch Blei and 
Antimon im Aerosol.
Bericht im MDR mit Link zur Studie:
https://www.mdr.de/wissen/medizin-gesundheit/einweg-e-zigaretten-vapes-metalle-im-dampf-gesundheitsschaedlich-100.html

Salazar, M. R. et al.: Elevated Toxic Element Emissions from Popular 
Disposable E_Cigarettes: Sources, Life Cycle, and Health Risks.
https://pubs.acs.org/doi/10.1021/acscentsci.5c00641

[Jason (jasonht)]

Zum Glück rauche ich nicht, haha

[Kilo S. (kilo_s)]

Wenn man das liest bin ich froh beim Rauchen geblieben zu sein.

Vozol schießt jetzt als nächstes den LCD vogel ab: 
https://www.vapepenzone.de/blog/vozol-magic-30000-testbericht.html

Hab bereits eine Zuhause, kann ich aber erst mit anfangen wenn endlich 
mal der Ärzte Marathon durch ist den ich Grade laufe...

[.● Des|ntegrator ●. (Firma: FULL PALATINSK) (desinfector)]

Kilo S. schrieb:
> Wenn man das liest bin ich froh beim Rauchen geblieben zu sein.

und ich bin froh rechtzeitig damit aufgehört zu haben.
seit 24 Jahren nikotin- und ersatzstofffrei

[Kilo S. (kilo_s)]

.● Des|ntegrator ●. schrieb:
> und ich bin froh rechtzeitig damit aufgehört zu haben.
> seit 24 Jahren nikotin- und ersatzstofffrei

Nicht schlecht!

Aber wie das halt ist, aufhören triggert mich Grade nicht sonderlich.

[Kilo S. (kilo_s)]

Update.

Aktuelle Fassung des Display Treiber + Font nicht fehlerfrei, nicht 
optimal. Trotzdem besser als vorher.

[Kilo S. (kilo_s)]

Demobild vergessen.