CT1+/CT2 Betriebsverbot und ISM Frequenzen?

Die Foenchen sind hier inzwischen recht klein, da gehen so Dinger nicht rein. Aber ok, selbst mit Eneloop koennte sich das noch lohnen. Obwohl die Dinger teuer sind, hatte gerade einen Schwung davon geholt. Die Sache ist aber, dass nach mehreren Jahren die Tasten ziemlich abgeschliffen sind und auch sonst einiges. Ist hier etliches heisser im Sommer als bei Euch, da leidet so etwas.

--
Gruesse, Joerg

http://www.analogconsultants.com/

"gmail" domain blocked because of excessive spam.
Use another domain or send PM.

Hey, ich will ein Telefon, keinen Pokerchip zum Reinquatschen.

Die üblichen DECT-Handgeräte sind wohl so 15x5x2 cm. Da gehen sogar AA-Akkus prima rein. Klar, nach Mobiltelefon-Maßstäben sind das Telefonzellen. Aber ich find's fast schon grenzwertig, kleiner sollte es wirklich nicht sein. Oder muss ich dann immer eine aufgebogene Büroklammer mit mir rumtragen, um die Tasten bedienen zu können?

Stefan

Das ist nicht so weit von der Realitaet entfernt. Als ich mit 85 mph auf Kaliforniens Highways unterwegs war, merkte ich _sehr_ deutlich, das weder die Strassen[0] noch die Autos (Chevrolet Cobalt) fuer dieses Tempo ausgelegt sind. Dabei ist das gerade mal langsames Autobahn-Reisetempo.

Man liest sich, Alex. [0] Ich will ja nicht laestern, aber was einem da manchmal als regulaere Strasse begegnet, waere in .de/.ch aufgrund des Belagszustandes als baufaellig eingestuft worden.

--
"Opportunity is missed by most people because it is dressed in overalls and
 looks like work."                                      -- Thomas A. Edison

Moin!

Weil Oma Jansen jetzt ein Gästezimmer für ihren Enkel eingerichtet hat und dort auch ein schnurloses Telefon haben will, es ihr 10 Jahre altes aber nicht mehr gibt?

Ich wette, Oma Jansen will lieber ihr altes Telefon mit den großen, abgewetzten Tasten, dessen Bedienung sie in- und auswendig kennt weiterbenutzen, als sich was neues mit Mini-Tasten und anderer Benutzerführung anzuschaffen.

Gruß, Michael.

Wenigstens in dem Bereich gibt es ja jetzt altersgerechte Geraete. Bei Thermostaten und dergleichen aber leider immer noch nicht, da muss selbst ich die Brille holen und erstmal Licht machen :-(

--
Gruesse, Joerg

http://www.analogconsultants.com/

"gmail" domain blocked because of excessive spam.
Use another domain or send PM.

*Alexander Schreiber* wrote on Sun, 09-01-04 23:39:

Immer nur fordern. Ich habe es genossen, auf DDR Autobahnen, bei denen die 40-Tonner alle links fuhren, mit knapp 140 km/h rechts vorbeizuziehen. Erst da lernt man die Investition in gute Fahrwerksbauteile so recht genießen.

Axel Berger schrieb:

In den vergangenen Jahren sind zigtausende 'Bundesbürger', überwiegend in Form anschlussinhabender Familienväter, zur Begleichung von Abmahngebühren und Schadenersatz mit Beträgen zwischen einigen Hundert und zehntausend Euro verknackt worden, weil Kinder, Bekannte, etc. Fliesharing Clients mit urheberrechtlich relevantem Material bespielt haben. Nur mal angenommen, so eine Abmahnung läge in deinem Briefkasten

- würdest Du dein Netz weiter offen betreiben?

Ich finde offene WLANs ja prinzipiell auch gut - allerdings - unbedingt 'nötig' finde ich sie nicht, die meisten Leute, die als Nutzer in Frage kommen haben eh einen eigenen Internet Zugang. Und die 'WG-artige' gemeinschaftliche Nutzung eines Zuganges lässt sich ja auch ohne offenes Netz realisieren. Solange die rechtliche Situation so unüberschaubar ist, wäre mir das zu heikel 'einfach so'. Ein ausführliches Logging und das Sperren bestimmter Dienste wäre das Minimum, was man da haben sollte.

- Carsten

nger.

Also reicht es, als Lawinenopfer irgendein kleines MW-Radio in der Tasche zu haben? :-) Gruss Harald

z n

Es gab da in den siebziger Jahren jede Menge Bauanleitungen in einschl=E4gigen Zeitschriften. Sendeantenne war ein Ferritstab, Empangsantenne eine im Boden versenkte Leiterschleife. Funktionierte nat=FCrlich nur im Nahbereich. Gruss Harald

D.h. man musste die Garageneinfahrt aufstemmen oder schlitzen? Das wird ja immer merkwuerdiger. Hier sind das mehr oder weniger genormte Funkkaeschtle, die in ein extra dafuer vorgesehenes Klappfach im Dachhimmel des Autos passen. Dort kann man dann passend Deckelsegmente rausnehmen, sodass der Knopf frei bleibt. Als ich bei der Probefahrt den Verkaeufer fragte, wozu das Klaeppchen da oben sei, guckte der mich an als sei ich gerade vom Mars eingewandert.

Nahbereich ist auch nicht so der Hit. Wir koennen die Tore so starten, dass sie bei normaler Schrittgeschwindigkeit offen sind, wenn man da ankommt.

--
Gruesse, Joerg

http://www.analogconsultants.com/

"gmail" domain blocked because of excessive spam.
Use another domain or send PM.

On 3 Jan., 20:37, Joerg

Genau, die benutzt CT1 (siehe Titelthema) und ist dann bass erstaunt, wenn irgendwann ein Auto mit "Geweih" vor der T=FCr steht. :-) Gruss Harald

Gut, ich bin da vielleicht vorgeschädigt, aber Fehler der Art "wenn du hier X machst, passiert Zeit t >> 0 bei Ereignis Y was böses" kenne ich schon :-). Der 533 hat einen ähnlichen Bug wie deinen (158), der aber eben vom Instruction DMA getriggert wird. Hat mich ein paar graue Haare gekostet, das im Bootloader zu umschiffen.

Toll auch, dass die Fehlerlisten munter Selbstverständlichkeiten mit echten Krachern mischen. "Wenn du den seriellen Port anmachst, während das externe Taktregime mitten im Wort ist, empfängst du ein Halbwort". JA WAS DENN SONST? (167).

227, 244, 245, 416. Und natürlich der Brüller schlechthin, 371 :-P

Stefan (heute mal nur in C++ unterwegs gewesen)

*C.P. Kurz* wrote on Mon, 09-01-05 12:48:

Natürlich - zu Hause. Mein Notebook habe ich fast immer dabei und es gibt oft so kleine "mal eben" Fragen, da ist ein Netz eine feine Sache. Große Up- oder Downloads verbieten sich unter anständigem Menschen selbstredend oder setzen voraus zu prüfen, daß der Eigentümer die Bandbreite gerade wirklich nicht selbst braucht.

Toll :-( Die schiere Vielzahl der Bugs wird langsam sehr lästig.

Was sagt AD eigentlich bei Euch zu der schieren Fehlerhäufung ?

Wohl wahr.

Die wären aber in einem Embedded System mit definierter Software alle noch halbwegs performant umgehbar, da braucht es NOP's, aber nicht bei jedem Ziel.

371 ist natürlich, ähnunja, peinlich, aber das ein Unterprogramm so kurz ist, das kommt selten vor, der Compiler kann das leicht abzählen und auffüllen.

Bei 428 gibt es in einem komplexen System leider keine halbwegs performante Möglichkeit, den Fehler zu umgehen. L2 ist zur Wahrung der Cache-Kohärenz unumgänglich, denn L3 wird gecached und da braucht es performanten Speicher, um die Locks etc. zu übergeben. Die L1 sehen sich bekanntlich nicht gegenseitig.

Im Grunde sagt 428:

- Vergesse L2 und damit schnelles SMP oder

- Vergesse Core 2 für komplexe Aufgaben oder

- Vergesse die Branch Prediktion und werde sehr langsam. Dafür brauch ich keinen Dual Core DSP.

Im Grunde müssten bei jedem Sprungziel mindestens ein NOP und hinter Branches drei NOPs stehen, wenn da irgendwelche L2/L3 Daten geladen werden, und das werden sie üblicherweise häufig, denn das erste, was eine CPU nunmal nach einem "if" macht, ist halt das Laden von Daten für den nachfolgenden Befehl. Die Pointer selber sind zumeist schon im Register.

Wir werden da wohl massiv Druck machen müssen, damit AD endlich die Fehler abstellt. Derart heftige Fehler sind echt nur noch peinlich. Wir stecken viel Mühe, Zeit und Geld in Blackfin Designs, ich bin langsam echt sauer und hätte gute Lust, denen eine Kompanie TÜV-Prüfer Marke Extrafieselnörgel zusammen mit einer Kompanie Feldwebel, Typ fieser Schleifer, nach USA zu schicken. Danach hätten die die fittesten Entwickler und Manager schlechthin und die V1.0 wäre sehr schnell fertig ;-/

Gut, der US Strassenverkehr würde zusammenbrechen, weil die TÜVies als Hobby nur noch Karren wegen schwerster Mängel sofort aus dem Verkehr ziehen ;-)

So langsam verstehe ich, warum die Fehler offiziell mit 05000428 statt nur 428 nummeriert werden, die drei Nuller deuten darauf hin, dass AD noch einiges vor hat ;-/ "Ein Produkt mit allen Schikanen, dies ist die 428te" ...

Gruß Oliver

--
Oliver Bartels + Erding, Germany + obartels@bartels.de
http://www.bartels.de + Phone: +49-8122-9729-0 Fax: -10

Am Mon, 5 Jan 2009 07:37:00 +0100 schrieb Axel Berger:

Lange machst du das nicht. Bei meinem ersten Kadett von der Firma 1991 waren nach einem Jahr Aussendienst auf den Strassen die Stoßdämpfer hinüber.

Ich musste mich dann erst mal bei der Dame von der Kfz-Verwaltung erklären ;-)

Lutz

--
Mit unseren Sensoren ist der Administrator informiert, bevor es Probleme im 
Serverraum gibt: preiswerte Monitoring Hard- und Software-kostenloses Plugin 
auch für Nagios - Nachricht per e-mail,SMS und SNMP: http://www.messpc.de
Neu: Ethernetbox jetzt auch im 19 Zoll Gehäuse mit 12 Ports für Sensoren

Oliver Bartels schrieb:

Offensichtlich ist aber der Punkt, an dem sich eine eigene Prozessorfertigung lohnt, noch nicht erreicht ;-)

Fr=FCher h=E4tt ich noch geschrieben, geh doch mal zu Siemens "r=FCber" ;=

-((

--=20 mfg hdw

Wenn da einige Chiphersteller auf dem hohen Ross sitzen sollten, kann ich nur davor warnen, schlechte Qualität schlägt über kurz oder lang immer auf Verkäufe, Margen, Firmengewinne usw. durch.

Mal eine Frage: Wäre so etwas denn interessant, General Purpose Signalverarbeitung aus EU Fertigung mit "Made in Germany" Qualität ?

Eigentlich wollten wir im Rahmen der Arbeirtsteilung nur IC's einkaufen, die einfach gut funktionieren, wir brauchen keine Key-Account-Sales/Marketing-Manager/Senior-Manager/VP Brigade und kein Händchenhaltesupport, Datenblätter können wir gerade noch selber lesen.

Nur _funktionieren_ gemäß Spec. sollten die Bauteile.

Man kann auch nicht alles selber machen, irgendwann verzettelt man sich, andererseits ist die Core-Signalverarbeitung schon eine Schlüsselkomponente, man sieht halt, wieviel Ärger da Schludrigkeit des Lieferers verursachen kann.

Und es wären wohl - trotz Finanzkrise - für derlei Projekt auch Mittel zu haben, ich bin jedenfalls schon mehrfach angesprochen worden, ob wir nicht irgendein tolles Projekt hätten, was man gemeinsam machen könnte, von VC bis "Scheichkohle" ;-) ist alles dabei, das ergibt sich, wenn man schon mal gezeigt hat, dass man komplexe Projekte ans Laufen bringt :-)

Ich werfe mal eine Erfindung für CPU's in den Ring: DE102005036605B4 Das könnte man in den Core integrieren, dann laufen manche Routinen schneller.

Stromsparend scheint mir auch sehr wichtig, das könnte man aber z.B. mit der o.g. Erfindung kombinieren, indem es ein globales Zustandsbit "Routine muss sparsam sein" gibt.

Projekte hätten wir wie bekannt auch einige.

Nur mal so, falls Jörg wieder ankommt und meint, nur US-Firmen könnten DSP's bauen und man müsste solche heftigen Fehler doch bittschön akzeptieren, weil man eh' keine andere Wahl hat ...

Again: Eigentlich wollen wir das nicht, aber langsam fängt diese Schludrigkeit der Lieferer wirklich an, solche Probleme zu verursachen, dass es eine Alternative sein könnte.

Es gibt auch andere schöne Töchter ;-)

Gruß Oliver

--
Oliver Bartels + Erding, Germany + obartels@bartels.de
http://www.bartels.de + Phone: +49-8122-9729-0 Fax: -10

Wie sagt man im Arbeitszeugnis? "Er war sehr bemüht."

Nein, sie geben sich eigentlich durchaus Mühe. Bei uns wird das ganze allerdings dadurch verkompliziert, dass wir nicht nur die Tools von ADI einsetzen, sondern auch die eines Drittanbieters, der aber von ADI promotet wurde. Und der schickt für Siliziumfehler-Workarounds gerne mal lart-by-invoice zu ADI.

Das ist relativ häufig, wenn du zum einen sowas wie Portzugriffe sauber abstrahierst, bool PollDSPRequest() { return (*pPORTA & (1 Im Grunde sagt 428:

Wir haben mit ein paar Anomalien der Art "Vergesse den Cache" angefangen. Danach hatten wir eine der Art "Vergesse SDRAM". Deswegen haut mich das jetzt nicht so vom Hocker :-> Inzwischen läuft's halbwegs.

(Wenn ich das richtig in Erinnerung habe, stammt 265 übrigens von uns. Das, was sie ein "noisy board environment" nennen, sind 3 cm Leiterzüge und 10 cm Folienkabel in einem Blechgehäuse.)

:-)

Stefan

Genau so kann man es sagen. Ich werde den Eindruck nicht los, dass man definiert Know How bei Intel eingekauft hat und nun nicht (mehr ?) die Leute hat, die wissen, wie geht.

Naja, den Support im Sinne von Händchenhalten haben wir nicht großartig in Anspruch genommen, insofern kann ich da nicht soviel dazu sagen.

Wir haben den BF561 auf zwei Boards, da bemüht er sich, Befehle auszuführen, so gut er das eben kann ... Wir haben uns dazu eine eigene Tool-Kette geschrieben, die z.B. Flash und FPGA über USB, wahlweise über JTAG oder schnell über die CPU lädt, ein kleines Filesystem darstellt usw., das ganze ist recht komfortabel und erleichtert die Entwicklung sehr. Aber es ist in C und es täte wohl auch bei anderen CPU's mit JTAG/BSDL spielen ;-/

Es ging bisher nur um Selbstverständlichkeiten wie die Lieferung der neuesten Maskenversion und der Entwicklungsumgebung. Ich bin auch ehrlich gesagt ganz froh, dass wir die ersten Chargen für die neuen Prototypen-Boards offiziell eingekauft haben, damit unterliegen die voll dem Gewährleistungsrecht.

Zum Support:

Einmal wurde etwas rumgemault ("wir können sie dann nicht mehr so gut supporten"), als ich einen etwas größeren Rundumwurf getätigt habe, nachdem man uns 1 Jahr nach Ankündigung der 0.5 wieder mit 0.3 beliefert hatte. Es kamen dann aber 0.5er, wobei wir zu dem Zeitpunkt noch nichts von dem gravierenden

0.5-only Bug 428 wussten.

Und dass ich den aus dem Internet über Weihnachten entnehmen durfte und nicht von MPS & Co informiert bzw. gewarnt wurde, dass hat dann auch dazu geführt, dass ich ziemlich angefressen bin und die Öffentlichkeit suche. So goes it not.

Weißt Du eigentlich, wer der war, der die Rev 0.5 vom BF561 nicht abnehmen wollte, AD durfte eine Zeit lang noch 0.3 fertigen ?!

Vermutlich werde ich jetzt wegen der Diskussion hier noch ein bisserl mehr Gemaule hören, das ist mir aber ziemlich egal, die sollen die Macken rausmachen und gut ist.

Toll ... :-(

Für komplexes Kommunikationsgerät (neue CIFDM Plattform) und Messtechnik (der BF561 ist für eine neue Serie eines durchaus nicht unbekannten Handheld- Spektrumanalysators gedacht) ist das Vorgehen nicht wirklich akzeptabel, wir stecken nicht viel Geld, Zeit und Mühe in eine CPU, bei der nur die Hälfte funktioniert.

Wir haben gottseidank eine eigene Zwischenebene in der Software, welche relevante Funktionen von der Hardware abkoppelt, so kann man zur Not wechseln.

=> Es ist recht simpel: Sollte AD sich nicht zu einer Maskenänderung mit klar definierter Zeitplanung entschliesen, welche zumindest die groben Fehler ausmerzt und keine neuen einbringt, dann ist der Blackfin im speziellen und AD als DSP-Lieferant im Allgemeinen für uns gestorben.

Dann lieber ein Ende mit Schrecken als ein Schrecken ohne Ende. Es gibt Alternativen. Und AD sollte sich doch gut überlegen, ob das eine wirklich gute Idee ist, dass wir hinwerfen, ich glaube sagen zu können, dass wir in der Branche nicht ganz unbekannt sind.

Und ob sie wegen dieser Aussage maulen, ist mir egal. Der Murks wird beseitigt oder wir lassen es bleiben.

Punkt und Endegelände.

Heftisch heftisch ...

Gruß Oliver

--
Oliver Bartels + Erding, Germany + obartels@bartels.de
http://www.bartels.de + Phone: +49-8122-9729-0 Fax: -10