Mal eine saublöde Frage.

Wenn ich innerhalb einer Do...Loop Schleife ein Lable mit Gosub anspringe, dann müsste das Return am Ende des Labels ja wieder in die Do-Loop-Schleife führen.

Warum aber wird bei mir die Einschaltmeldung nach jedem Return gesendet, die doch vor der Do-Loop Schleife liegt?

Diesen Effekt hatte ich schon häufiger, bin da aber nie dahinter gekommen woran es liegt.
In Zeile 28 wird PIND.2 eingelesen und bei steigender Flanke das Label SQLopen angesprungen.
Das Lable soll mir UART-Meldungen ausgeben, "SQL Open" nach einer steigenden Flanke und ein "SQL Close" wenn eine fallende Flanke erkannt wird.

Sobald aber diese fallende Flanke an PIND.2 erkannt wird, führt das Return nicht zurück in die Do-Loop Schleife!
Dämlicher weise wird nach diesem Return die UART-Ausgabe in Zeile 21 ausgeführt.
Die If Then-Funktion habe ich schon extra hinzugefügt, damit diese Boot-Meldung auch nur nach einem POR gesendet wird.
Hilft aber nicht...das Return springt sogar in Zeile 8 zurück die für mich definitiv im Konfigurationssetup liegt.

Wie kann ich dem Return diesen Amoklauf abgewöhnen?

Jürgen

Hallo!

Anfangs hwstack 800, swstack 320 und framesize 640, zwischenzeitlich jedoch wieder gekürzt auf 80 / 32 / 64.
Hatte diese Parameter in diesem Fall vor knapp zwei Wochen vorsichtshalber verzehnfcht, als das Programm unhandlich wurde.
Die 32k Flash eines 328P zeitweise zu 92% genutzt. Dazu seitenweise Initialdatensätze für nen blöden I²C-Slave mit noch blöderer Dokumentation.
Nachdem ich gestern den Chip endlich ans laufen bekommen habe, ist der Spuck vorbei und das zeitweilig große Programm mächtig geschrumpft.

Ziemlich sicher. Watchdog und Brown per default deaktiviert. Ist ein Nano an USB-Spannung und einem 3,3V I²C-Slave der bis zu 60mA zieht.
Die 3,3V kommen aber nicht aus dem Nano, sondern von einem MCP1700-3302 an Vusb.

Ah, das war es...funzt!
Aber...selbst wenn ich mit einem Goto in ein Label / Sub springe, erwarte ich das der pointer am ende des Returns einen definierten Punkt anspiengt.
Und eben nicht Zeile 1 irgendwo in der Konfiguration.

Im selben Programm nutze ich gezielt Gotos zur Fehlerbehandlung in einer I²C-Routine:

Soll dazu dienen das wenn irgendein gesendetes Byte mit einem NACK beantwortet wird, direkk abgebrochen und die Sub neu gestartet wird.
Scheint auch zu funktionieren, seit Tagen absolut unauffällig.
Nun frage ich mich:
Wenn alles mit Ack bestätigt wird, führt das Return den Pointer wieder zu der Stelle von wo aus die Sub angespungen wurde.
Wohin aber führt der Pointer wenn doch mal ein Nack kommt?

Jürgen

Hallo!
Ja, so etwa hatte ich mir das Gedacht mit den GOTO's im Send: Lable.

Wie bereits angedeutet hänge ich da an einen ziemlich komplexen I²C-Slave welcher zudem undokumentierte Eigenarten hat die ziemlich gewöhnungsbedürftig sind.
Beim sniffen des I²C-Verkehrs einer fremden Firmware sah ich das etwa 5% aller Schreibzugriffe vom Slave mittels Nack abgewiesen wurde.
Allerdings nicht weil Registeradresse oder Wert ungültig war, sondern weil der Slave gerade wichtigeres zu tun hatte als sich um I²C zu kümmern.
Genau das wollte ich mit den GOTO's in meiner I²C-Ausgabe entsprechen behandeln nach der Logik: Bei Nack sauberen I²S Stop ausführen und von vorm beginnen.

Aber jetzt wo ich dieses Teil endlich da habe wo er das tut was ich von ihm will habe ich da erst mal eine Projektpause eingelegt.
Knappe 3 Jahre scheiterte ich bei mehreren Anläufen an diesem Teil aufgrund der grottenschlechten Informationslage und der Verschlossenheit des Herstellers.
Nun wo ich da einen gehörigen Schritt weiter bin, überrollen mich drei weitere Projekte die erst mal dringender sind.

Jürgen

Hallo Mitch!
Seit drei Jahren der Versuch eine günstige Alternative: AT1846S.
Die alten RDA1846 werden seit >10 Jahren nicht mehr produziert. Dementsprechend gibt es diese nur noch hoffnungslos überlagert und mit häufig oxidierten Pads.
Die letzte Charge musste ich mit Glasfaserpinsel und brachalen 350°C und massenhaft Flußmittel bearbeiten, damit sie überhaupt wieder lötbar waren.
Wirklich krass...und das mit QFN32 5x5mm!
Aktuell, oder "frischer" gibt es nur noch den Nachfolger AT1846S.
Blöd dabei: Den alten RDA1846 den ich vereinzelt schon einsetzte, ist nicht kompatibel mit dem Nachfolger.
Damals wichtige Register wie h0F sind heute ersatzlos entfallen, dafür komplett neue Register, andere Adressen.
Das was man im Internet als Programmierhandbuch findet beschreibt nur einen winzigen Bruchteil der knapp 200 Register.
Und diese stark gekürzte PDF wo extrem wichtige Informationen fehlen ist ein Leak.
Denn laut dem Hersteller unterliegen alle Informationen einer RDA die man erst bekommt wenn man 30.000 Stk./Jahr abnimmt.

Da ist die größere, aufwändigere Methode rund um CMX72x1 deutlich aufgeschlossener.
Seit über 15 Jahren werkel ich mit diesen Teilen in mehreren Kleinserien.
Und ohne übertriebene Mindestabnahmemengen habe ich bei CML problemlos einen Login bekommen wo ich mir alle Details ziehen kann.

Das Dingen nur mit dem AT1846S:
Abgesehen vom Chippreis (2€ versus 20€) ist auch die Schaltungsgröße ein Argument.
Ein Funkgerät mit CMX7241 z.B. ist enorm kritisch im EMV-Design weil kaum trennbar zwischen analog- und Digitalteil.
Zusammen mit dem SPI-Flash und dem µC der nach jedem POR erst die >1MB große Firmware in den CMX schaufeln muss bin ich schnell bei Größenordnungen >100x100mm.

Bei dem AT1846S heute bzw. den damaligen Projekten mit RDA1846 passen LDO, TCXO und Chip auf so kleinen Raum das alles unter einem kleinen Abschirmbecherchen platz findet und man lediglich den I²C-Bus bezüglich EMV zähmen muss.


Das Hauptproblem die letzten 3 Jahre für mich:
Zum aktuellen AT1846S findet man im Internet nur ein total verzerrten Scan in dem die Bilder alle unleserlich sind, was aber zu verschmerzen ist weil Pinning und die meisten Grafiken identisch sind mit den Datenblättern zum RDA1846 und AT1846 die man als Leaks findet.
Ebenso findet man ein AT1846S Programming Guide mit 25 oder 26 Seiten mit sehr mangelhaften Einblick in die Registerfunktionen.

Völlig unerwähnt dort die Eigenschaften:
Gute 30-40% aller Register kann man und muss man beschreiben, kann diese aber nicht zurücklesen. Denn beim auslesen enthalten sie ganz andere Inhalte als man zuvor rein geschrieben hat.
Weiterhin müssen diverse Register wie z.B. der h30 sequenziell mehrfach hintereinander geschrieben werden.
In diesem Beispiel muss man zum ändern anderer Register (Frequenz, Kanalbreite, Subaudio u.v.m.) erst in einem definierten "Edit-Mode" schalten.
Also in einer logischen Reihenfolge zuerst das "chip_cal_En" Bit auf 0 setzen, dann das "sq_on" Bit auf 0 setzen, das Bit "rx_on" auf 0 setzen, eventuell wenn auf 1 auch das Bit "vox_on" auf 0 setzen, dann "tail_elim_en" auf 0 setzen, sowie "mute" auf 0 setzen.
Erst dann kann/darf man die gewünschten Register editieren, um anschließend wieder in 5 Schritten die vorher abgeschalteten Funktionsbits nacheinander in der richtigen Reihenfolge wieder aktivieren.

Hört sich für mich nach einer Art State Machine an die grundlegende Änderungen nur in einem Mode verarbeiten kann der kurz vor "Aus" liegt.

Jürgen

Hallo!
Naja, wie bei solch tollkühnen Sachen üblich hatte ich 5 Testplatinen wo am Ende 3 Platinen mit mehr oder weniger ansehnlich montierten RDA1846S bei rum kamen.
Davon zwei die selbst unter dem Mikroskop brauchbar aussahen und eine die wenig hoffnung machte.

Beim ersten Funktionstest haben diese drei Module, selbst das traurige grundlegende Funktionen gezeigt: I²C hat reagiert, Stromaufnahme OK usw.
Der Default-Reigisterinhalt dieser drei Platinen hat diese brutale Prozedur auch überlebt.
Aber alle drei machten keinen Mux.

Erst als ich letzte Woche mit den diversen GPIO's rumspielte das erstmalige Ergebnis das TX und RX auf der zuvor eingestellten Frequenz plötzlich funktioniert.
Und das ist dann neben den Eigenarten diverser Register noch die Krönung des ganzen:
Das Pad PDN liegt nach einem POR auf 3,28V (bei 3,3Vcc), also ganz offensichtlich hat der 1846S da einen undokumentierten PullUp.
Würde man PDN aug GND ziehen, würde der Chip in den PowerDown gehen.
Aber nein...dieser undokumentierte PullUp reicht dem Chip nicht!
Er rennt erst los wenn man PDN hart auf 3,3V zieht!
Was nun der Unterschied zwischen OPEN (3,28V) und Vcc (3,30V) für den Chip sein soll, hätten die Chipdesigner anständig dokumentieren sollen.


Da draußen gibt es verflixt viele Fundstellen mit Input. In den letzten 3 Jahren musste ich aber erkennen das vieles davon gefährlichens Halbwissen ist.
Vieles an Informationen dreht sich um die erste Chipgeneration RDA1845, wozu sogar eine detaillierte Initialisationsanleitung verfügbar ist.
Hier ab Seite 9:
vrtp.ru/index.php?act=Attach&type=post&id=775449

Damit konnten viele Funkamateure und sonstige Freaks den RDA1845 problemlos ansteuern.
Der dann 2009 erschienene Nachfolger RDA1846 nutzt eine ganz andere Registersortierung und offenbar auch weitgehend geänderte Funktionsblöcke auf dem DIE.
Die Ähnlichkeit zum RDA1845 waren aber noch so groß, das es im Detail um knapp 30 Register ging die abwichen, welche man mit Try&Error knacken konnte.

Im August 2010 bereits kam dann die Serie RDA1846S raus bei der bis auf Gehäuse und Pinning nix mehr Ähnlichkeit hatte zum Ursprungsmodell.
Der aktuelle AT1846S von Auctus hingegen ist 100% kompatibel mit dem RDA1846S von 2010.
Und genau das geht im Internet durcheinander. Weil es viele erfolgreiche Bastelprojekte damals mit dem RDA1845 gab, meinen viele 1845/1846 und mit oder ohne S-Suffix wären das selbe.
Aber mitnichten.
Was ich hier seit 1,5Jahren der 3 Jahre immer wieder mache, gut 70% der Gesamtzeit in diesem Projekt ist nicht programmieren in Bascom, sondern das aussniffen des I²C oder SPI-Datenverkehrs diverser Geräte mit dem AT1846S.
Eben um heraus zu finden welche Register mit welchen Parametern und in welcher Reihenfolge der Chip angesteuert werden muss.

Wenn es zu den aktuellen Chips, bzw. den Chips mit S-Suffix im Internet überhaupt irgend eine interessante Seite gäbe, dann nur die Sackgasse in der ich immer wieder lande.
Die (unter NDA stehenden) Unterlagen zum RDA1846S = AT1846S als Komplettpaket gibt es auf dieser Plattform angeblich zum Downloaden:
dssz.com/558883.html
Blöd nur: Man braucht da ein paar Punkte für die man sich kaufen müsste.
Ja gut, womit denn? Alipay! Autsch!

Dabei aber ist genau dieses Rätselraten rund um die nicht zugängliche Dokumentation eine große Ungewissheit.
Denn SDR-Techniken haben ihre Feinheiten in zahlreichen Einzelregistern.
Es geht da um AGC, um Oversampling, Undersampling, CIC-Parametern, Laufzeitparametern.
Nix davon ist irgendwie beschrieben.

Ein vielleicht hinkender, aber in Sachen Funktionsblöcke eines SDR-Transceivers wieder stimmig ist der Vergleich dieser 1846S mit dem hier im Forum bekannteren sx1231(h) auf den beliebten RFM69 Datentransceivern.
Der offensichtliche Unterschied liegt in der Datenform die übertragen werden soll: analoge Sprache (300-3000Hz) beim 1846S oder digitale Daten (SX1231(h)).
Beim SH1231 kann man alle HF-Parameter wie z.B. die Kanalbreite problemlos einstellen. Zwar mit kyptischen Registerweten die man aus dem Datenblatt abtippen muss, sowie ebenso komplexen "Hinterkopfvariablen" (Stichwort z.B. SingleSideBW oder die Zwischenwerte Baud/2 und Baud x 2.
Erst wenn man sich intensiv rein kniet in die SDR-Logik und der nötigen Parameter fällt es einem wie Schuppen von den Augen.
Ein "runterprügeln" z.B. auf 4800Bd GFSK in einen konformen 12,5kHz Kanal ist dann problemlos möglich,
Beim 1846S fehlt das total. Es gibt Defaultwerte für 12,5kHz und 25kHz Kanäle, aber ein anpassen auf andere Kanalbreiten wie 9kHz oder 20kHz können diese Chips auch, aber das wie und wo wird eine teuflische Sucherrei.

Derzeit funktionsfähig ist ein gesnifftes I²C Protokoll aus einem Fremdgerät.
Zur Initialisation nach dem POR 53 Register die beschrieben werden wollen.

Dann bei jedem Betriebsmodewechsel, egal ob Kanalwechsel oder einfach Senden und danach wieder auf Empfang schalten braucht bislang 17 Register (Senden) oder 23 Register (Empfang & Kanalwechsel).
Und noch so eine Eigenart:
Einen Burst-Mode wie man von vielen I²C-Devices kennen die 1846S nicht.
Man muss also jedes der nötigen Register einzeln beschreiben: I2cstart, I²Cadresse, Registeradresse, Highbyte, Lowbyte , i2cstop

Naja, ich bin da auf jeden Fall einen gehörigen Schritt weiter gekommen letzte Woche.
An den Grundfunktionen der RDA1846S/AT1846S kann ich bislang 70% nachbilden von dem was ich bislang mit den RDA1846 bedienen könnte.
Das ist ein Punkt wo ich erst mal wieder Pause mache mit diesem Wahnsinn.

Jürgen

Hallo!
Gibt es schon längst.
Und das was beim RDA1846 bis AT1846S nur eine seichte Vermutung war wird bei den Nachfolgern ganz offensichtlich:
Das ist keine minnimalistisch zusammengeklickte µC mit ein paar angepassten Funktionsblöcken, ziemlich komplexe Strukturen, irgendwas zwischen SoC und ARM.

en.auctus.cn/productinfo6.html


Nunja, mir bleibt keine andere Wahl, das ist es ja.
Wann immer ich in den letzten 20 Jahren irgendwas auf Kundenwunsch designen musste wo ein Sprechfunktauglicher FM-Empfänger drin vor kam, griff ich zu NXP SA604 oder zuletzt SA636, packte da Quarz- und Keramikfilter passend zum Funkstandard dran, und der Rest war auch Standard den ich mir aus dem Ärmel schütteln konnte.
Tja...NXP hat die letzten Jahre diese ganzen Chips abgekündigt, und kurz darauf hat der Weltmarktführer Murata sein komplettes Portofio an Keramikfiltern eingestampft.

Da aber gerade das Schaltungsdesign von kundenangepassten Sonderlösungen lukrativ war, widerstrebt es mir da einfach auf zu geben.
Lösungen gibt es, aber Sprechfunk-SDR mit Chips von CMLmicro ist für viele dieser Sonderlösungen schlichtweg als ob man mit Kanonen auf Spatzen schießen würde.

Aber in diesem Thema hat sich in den letzten Stunden was getan, was mich fassungslos machte.
Nicht nur das ich versuchte direkt beim Chip-Hersteller zu betteln, sondern parallel auch bei zwei Geräteherstellern von denen ich Vertragspartner bin und die diesen Chip auch einsetzen.
Unterlagen habe ich nirgendwo bekommen, aber je tiefer ich bohrte ein immer deutlichere Stimmung von Frust über das Thema Doku zum Chip.
Aus einer dieser Richtungen kam vorhin ein Link zu einer anderen chinesischen Plattform die man wenigstens via Paypal zahlen kann.
Also flux 20$ für Downloadcoins gezahlt und runter geladen.
Hänge da seit knapp ner Stunde drüber.
Tjaa...also jetzt wo ich diese Infos habe...
Irgendwie scheinen die Chinesen eine sehr merkwürdige Auffassung von Dokumentation zu haben.
Zum einen in manchen PDF's eine Mischung aus 70% Chinesisch und 30% englisch.
Zum anderen viel Wörter für Wenig Inhalt
Mit Hilfe des Google-Übersetzers dann langsam schlüssige Sätze.
Aber bis auf vielleicht 3 meiner mindestens 30 offenen Fragen klärt auch die Doku nicht.

Mir scheint das andere Hersteller die diesen Chip verwenden auch viel auf Try&Error angewiesen waren.

Auf der anderen Seite begreife ich auch nicht das da keine anderen Chiphersteller mit mischen.
Für Datenfunk wie ISM/IOT usw. sind neben Semtech noch Analog, TI, ja sogar vereinzelt Maxim und Microchip vertreten.
Aber analog, Sprechfunk...da klafft zwischen dem 1846 und CML eine riesige Lücke.

Jürgen