Zockertown: Nerten News

In letzter Zeit überschwemmt ein China Gadget die Electronic Community. Mit dem Suchbegriff USB Charger Doctor findet man bei den üblichen Verdächtigen eine unübersehbare Anzahl ähnlicher Geräte. 

Wofür ist so was denn gut? Höre ich dich fragen. Nun einmal fällt mir zu allererst das überprüfen von Powerbanks ein, endlich weiß man genau, welche Kapazität denn nun wirklich drin ist. Die selbe Anwendung ist auch bei Smartphones praktisch, denn hier kann man leicht den Zustand des Akkus überprüfen.

Weiterhin sehr interessant ist das Leistungsverhalten des USB Ports zu überprüfen, bzw. des Ladeadapters.

Prima eignet es sich auch mal die Stromaufnahme von externe Festplatten zu messen. Wer sich wundert, das seine Festplatte an Gerät A und B, nicht aber an C läuft, findet hiermit auch sofort die Erklärung. Praktisch jede externe 2,5Zoll Harddisk ist beim anlaufen ausserhalb der Spezifikationen von USB 2.0, Fast alle Mainboard Hersteller haben darauf reagiert und können kurzzeitig diesen Mehrbedarf liefern. Aber eben nicht alle und verlassen kann man sich eh nicht darauf.

Auch kann man bei entsprechend vorhandenen Kabeln den Spannungsabfall an unterschiedlichen Varianten von USB Verbindungskabeln überprüfen.

Hier ist es in Aktion zu sehen beim Laden meines Handys. Hier kann man gleich mehrere Erkenntnisse gewinnen. Die Anzeige differiert um ein paar LSD (Last Significant Digits). Das Display ist blickwinkelabhängig, aber sehr gut lesbar. Als Interessierte Laie möchte ich natürlich wissen, ob die Angabe "Accuracy 1%" auch zutrifft, deshalb habe ich es mit einem genauen Multimeter verglichen.

(Das Bild ist nicht ganz scharf, ich musste einige Klimmzüge veranstalten, um überhaupt beide Anzeigen gemeinsam abbilden zu können)

Hier erkennt man eine Differnez von 5,36 - 5,289 Volt = 71 mV

Bezogen auf den Messwert von 5,289V sind das weniger 1,5%.

Das ist beeindruckend. Die Angabe von Genauigkeiten werden meistens auf den Endwert bezogen, das sind bei meinem Gerät 20V, Hier wäre ein Fehler von 0,2Volt gerade noch akzeptabel.

Laut Hersteller wird behauptet, dass die Eingangspannung bis 20 Volt betragen darf, damit verläßt man die USB Spezifiaktion bei weitem, hierzu habe ich mir noch keine Gedanken gemacht, ich frage mich auch wo der Anwendungsfall wäre. Vielleicht weiß ein Leser mehr?

Aber auch bei reiner Verwendung an 5V Systemen ist dieses Meßgerät wirklich seine 5 €‚- wert, eine klare must have Auszeichnung von Zockertown!

Ergänzung: Um den Charger Doktor so wie eigentlich gedacht als Akku Kontrolleur zu benutzen, muß ein Mindestladestrom fliessen, den Akku in meiner Pebble kann man jedenfalls damit nicht messen. Also ein Strom von ca. 80mA ist zu wenig, um Zeit und Kapazitätsmessung zu starten

Ist hingegen ein schnellladefähiges Gerät (Samsung A5) dran, dann erkennt man die höhere Ladespannung und Strom.

(Ok, das Phone war fast voll, deshalb nur 560mA, das tut hier jetzt nichts zur Sache)

sondern: ... das, obwohl das Typenschild der "Ladestation" behauptet, es wäre ein USB Output 5V ...

Sachen gibt's

Nach ein paar Jahren ist es normal, dass die Lüfter voller Staub sind. Die Abwärme konnte nur noch mit Mühe hinreichend abgeführt werden. Beim zocken von XCOM2 WotC rauschte es schon ganz schön kräftig, Die Temperatur der Grafikkarte erreichte schonmal 78°, also habe ich mal die Rückwand mal abgenommen und den Staub entfernt.

Fast komplet saß der Staub direkt vor den Lamellen.

Nur mal kurz angemerkt.

Bisher war das updaten von owncloud eine Plage --, möglich, aber halt aufwändig.

Nun, mit ownCloud 10.0.9 (stable) ist das Geschichte! Den neuen Release.key musste ich noch aktualisieren und nun funktionierte es.

Unmittelbar danach sollte man seinen ownload Service besuchen und einmal klicken, dann läuft das update.

(Klar, geht auch auf der Console, hatte halt gucken wollen, ob der Service down ist, war er aber nicht )

Schön.

Ich bin ja ein Fanboy von Fritz. Besonders gut finde ich auch die Fritzphones.

Wegen eines ISP wechsels mußte ich  mir einen neuen Router aussuchen. 

Ich habe mich für den 7590 entschieden. Vorher hatte ich Fritz!box 6390 Cable.

Mit dem 7590 hatte ich so meine Schwierigkeiten, Wlan verbinden klappte sehr gut, aber nach dem mein Notebook im Suspend to ram war, war ein reconnect unmöglich. Nur mit Fritzbox restart bzw. mit der WLan Taste aus/ein, konnte das behoben werden.

Auch eines meiner Android Spmartphones hatte Probleme, es behauptete immer Authentifizierungsproblem.

Der Softwarestand der 7590 war FRITZ!OS: 06.92. Ich habe mir die Labor Software fritzbox-7590-labor-59298 installiert, denn im Readme stand einiges in dieser Richtung.

Das Resultat mit dieser FRITZ!OS: 06.98-59298 BETA geradezu sensationell.

Endlich wieder rattenschnelles reconnect nach dem aufwachen des Laptops und auch das Android Smarphone meckert nicht mehr.

(Das war früher mit Debian Jessie auch schon mal so schnell, mit meinem Buster war es schon immer etwas langsamer)

Ist schon interessant, welchen Einfluß der Wifi Sender haben kann, es liegt nicht immer an den Clients, wie ich hier bemerken durfte.

Jetzt warte ich, bis die Preise für das 7590 runter gehen und hole mir eine zweite, damit hätte ich das Haus perfekt ausgeleuchtet.

Heute ist mir was merkwürdiges passiert.

Mein Notebook Tuxedo X1506 läuft mit Debian Buster eigentlich problemlos.

Nun bin ich gerade dabei etwas neues  (neuer Controller [Hardware]) auszuprobieren und musste deshalb auch mal rebooten. Oh Schreck, kein Login mehr möglich. Offenbar versuchte systemd das grafische Login (gdm3) zu starten und erlitt damit Schiffbruch. Immer und immer wieder wurde es versucht.

Nur wildes rumhacken auf ALT-F9- F1 F2 F3 STRG-ALT-F9 F1 F2 F3 STRG-D STRG-C führte dann mal zum Erfolg.

Dann funktionierte das Login und das System wieder einwandfrei -- bis zum nächsten Reboot.

Also Ursache suchen und beseitigen war angesagt.

ein dmesg -HTw brachte segfaults zum Vorschein. Ein Ausschnitt gefällig? 

Bitte sehr:

Jul 11 20:10:56 tuxedo kernel: [  245.931762] gnome-shell[6921]: segfault at 20 ip 00007fa6d5c93aed sp 00007ffdb88d4330 error 4 in libmutter-2.so.0.0.0[7fa6d5b96000+165000]
Jul 11 20:10:59 tuxedo kernel: [  249.770883] gnome-shell[7027]: segfault at 20 ip 00007f4627e2faed sp 00007fff112a8360 error 4 in libmutter-2.so.0.0.0[7f4627d32000+165000]
Jul 11 20:11:03 tuxedo kernel: [  253.668634] gnome-shell[7159]: segfault at 20 ip 00007f16f21cbaed sp 00007fff073068c0 error 4 in libmutter-2.so.0.0.0[7f16f20ce000+165000]
Jul 11 20:11:07 tuxedo kernel: [  257.467717] gnome-shell[7239]: segfault at 20 ip 00007f1523bd1aed sp 00007ffc4e207870 error 4 in libmutter-2.so.0.0.0[7f1523ad4000+165000]
Jul 11 20:11:11 tuxedo kernel: [  261.281186] gnome-shell[7319]: segfault at 20 ip 00007f28e6099aed sp 00007ffe6cb884c0 error 4 in libmutter-2.so.0.0.0[7f28e5f9c000+165000]
Jul 11 20:11:15 tuxedo kernel: [  265.076490] gnome-shell[7399]: segfault at 20 ip 00007fdd9631aaed sp 00007ffeb8107990 error 4 in libmutter-2.so.0.0.0[7fdd9621d000+165000]
Jul 11 20:11:19 tuxedo kernel: [  268.836405] gnome-shell[7479]: segfault at 20 ip 00007f8fd0ee4aed sp 00007ffd74d1a760 error 4 in libmutter-2.so.0.0.0[7f8fd0de7000+165000]
Jul 11 20:11:22 tuxedo kernel: [  272.671850] gnome-shell[7559]: segfault at 20 ip 00007f4eed3fcaed sp 00007ffc26024ee0 error 4 in libmutter-2.so.0.0.0[7f4eed2ff000+165000]

Installieren von systemd-coredump stellte das tool coredumpctl zur Verfügung.

Also installiert und erneut gebootet. jetzt mit coredumpctl die generierten Coredumps gesehen und mit coredumpctl gdb untersucht

z.B.: gnome-shell[5021]: segfault at 20 ip 00007f97ad0bfaed sp 00007ffc38165c20 error 4 in libmutter-2.so.0.0.0[7f97acfc2000+165000]

Aha. Die Ursache hat evtl. mit  libmutter und gnome-shell zu tun.

Ok, dachte ich, googelste mal, ob das bereits ein bekanntes Phänomen ist, ja es gibt elend viele Treffer.

Allerdings nicht direkt dasselbe, mit Einschränkung der Aktualität auf letzte Woche wurd ich dann fündig.

Das Problem ist ein Bug, der mit dem Wayland Support zusammen hängt. Ich habe im Notebook eine Nvidia Karte, Wayland Support kann ich daher eh nicht nutzen, also den Support im GDM3 explizit abgeschaltet.

Die Option   WaylandEnable=false  in /etc/gdm3/daemon.conf entkommentieren, also das # wegnehmen.

Nun gehts wieder. Puh!

Gefunden habe ich das bei den Leuten von Archlinux.

Was hatte Zockertown lange nicht?

Richtig eine Besprechung eines coolen rundenbasierten Games.

Nun, da gibt es richtig gute Neuigkeiten.

Einer der Schöpfer und Hauptdesigner der originalen XCOM-Spiele, Julian Gollop hat im Rahmen einer Croud Gründungskampagne die Entwicklung von Phoenix Point begonnen. Erscheinungstermin wird wohl erst im Juni 2019 erscheinen.

Da ich erklärter XCOM Fanatiker bin, habe ich natürlich auch meinen Obulus geleistet. Als kleinen Dank kann ich seit dem 15.5. 2018 das sogenannte Backer Build 1.2 spielen. Und zwar nativ unter Linux.

Das Original ist ja von 1994, es lief noch mit DOS, Linux war da in etwa bei dem  Stand 1.0 und an eine Emulation von DOS war damals noch nicht zu denken, obwohl ich es bereits nutzte.

Doch nun zum Backer Build 1.2:

Es ist eine Mission "Fort Freiheit" spielbar, in ein paar interessanten Varianten.

Natürlich ähnelt das Spielgefühl dem der XCOM Reihe von Fireaxis, es gibt aber einen großen Unterschied.

Das Ziel/Schaden System ist neu erfunden, obwohl man sowas bereits in anderen Spielen gesehen hat, gab es das in dem Sinne nicht bei Xcom.

Man kann, wenn man will, frei zielen und einen Schwachpunkt in der Rüstung / Verteidigung des Gegners finden.

Neu (bzw. erneut wie im Original) gibt es Friendly Fire, wenn man nicht aufpasst, schiesst man seinem Kameraden in den Rücken, was der sicher nicht witzig findet, oder er bekommt einen Querschläger ab.

Ein zweiter Unterschied zum Original sind die Bossgegner, die aufzuhalten gelingt nur, wenn man gezielt Schwachpunkte aufspürt.

Munition ist ziemlich knapp, man findet aber Nachschub auf der Map

Im Netzt gibt es zu Hauf Videos, die ihr euch ansehen könnt, damit will ich euch nicht langweilen. Ich möchte nur ein paar Teilaspekte darstellen.

Ich bin über das aktuelle Marketing, wenn man es denn so nennen will positiv überrascht.

Es ist gestern der 2te Backer Build gewesen, der erste allergings mit einem Linux und Mac Client.

Es ist vorgesehen ca. alle 2 Monate oder auch häufiger einen neuen Build zur Verfügung zu stellen. Im Game kann - und soll- man bei aufgefallenen Bugs das Entwickler Team benachrichtigen.

Die hören allerdings nicht nur über diesen Kanal von den Spielern, sondern auch über ein eigens eingerichtetes Forum, wo die Spieler ihre Kritik und Vorschläge zum Game mitteilen und diskutieren.

Ich habe den Eindruck, dass dort auch auf die Strömungen reagiert wird und sie sich Mühe geben ein umfassendes großartiges Spiel abzuliefern.

Ein Screenshot utility ist für das Bug Meldesystem integriert, leider nicht für normale Screenshots, deshalb habe ich das Game im Fenstermodus gestartet, um leichte Screenshots zu machen. Das Game läuft aber in Fullscreen Mode einwandfrei.

Zum konkreten Backer Build schreibe ich noch später etwas mehr....

Update 4.7.2018 (ups, habe ich ja doch nicht.)

Egal, es gibt ein weiteres Build.

Im Telegrammstil kann der geneigte Leser es hier lesen, was ich dazu geschrieben habe.

https://www.linuxgaming.de/neuigkeiten-f6/phoenix-point-t6413.html

Ich hätte da ein Anliegen:

Wo sind denn meine Spielartikel besser aufgehoben?

Wie bisher hier im Blog, schliesslich habe ich hier keine Begrenzungen, was Grafiken betrifft und was ich schreibe, der Mod bin ich selber

Oder aber bei linuxgaming.de: Da seid ihr ja auch und warum 2 Quellen abgrasen, wenn man es an einer prominenten Stelle tun kann?

Ich freue mich auf Antworten

Nein, keine stärkere Feder, oder stärkere Akkus, sondern eine kleine elektronische Spielerei.

Eingebaut wird der Mod in ein rein mechanisches NERF Scharfschützengewehr Longshot CS-6.

Es wird die verbliebene Munition angezeigt und ein LED Blitz ausgelöst, wenn die Schaumstoff Patrone durch den Lauf geschossen wird.

Umgesetzt wurde das mit Great Cow Basic. Einem Compiler, der Basic frisst und Assembler für PIC und AVR ausspuckt.

Ich habe an anderer Stelle bereits einen Artikel über Great Cow Basic geschrieben und einen Bericht über ein damit realisiertes Projekt angekündigt. Nun, hier kommt der Bericht.

Die Anzeige erfolgt auf einem  128x32 Pixel Display (Suchbegriff I2C SDD1306 0.91 128x32 OLED)

Die Anzeige ist nur ca. 2.31 cm groß, das komplette Display hat ungefähr 3,5cm, damit eignet es sich ideal zum Einbau in das Zielfernrohr.

Funktionsbeschreibung der Software:

Die Bilder sind von einem frühen Prototyp, die Qualität der Bilder bitte ich zu entschuldigen. Von der endgültigen Version werden hoffentlich schärfere nachgereicht. Allerdings hat auch das Grenzen, denn das Display hat nur kleine Abmessungen. In Natura sieht das Display erhelbich besser aus, es ist eine Freude, dieses Display in Aktion zu sehen.

Einschalt Screen

Nach dem Initialisieren wird ein Begrüßungsbildschirm gezeigt, der die aktuelle Spannung des verwendeten Li Ion Akkus anzeigt. Basis der Berechnung ist die Betriebspannung von 5 Volt, welche konstant gehalten wird. In Abhängigleit von der Akkuspannung wird ggfs. ein anderer Text ausgegeben. Bitte beachten.

Man kann nun einfach warten, bis zur Hauptanzeige gewechselt wird, oder aber die UP Taste drücken, um direkt zur Hauptanzeige zu springen.

Main Screen

Die Hauptanzeige zeigt in großen Ziffern die Anzahl der verbliebenen Munition. Rechts daneben ist die Füllstandsanzeige der Akku Spannungsversorgung angezeigt. Wenn die Spannung unter dem Schwellwert von ca. 3V gesunken ist, wechselt der Schriftzug "UP-DOWN->Setup " mit dem Hinweis auf "charge!". Die Funktion ist noch eine Weile sichergestellt, jedoch sollte der Akku bald geladen werden. Wenn die Spannung des Akkus unter 2.5 V gefallen ist, wechselt die Anzeige zu "Alert!". Nun muss unbedingt das System ausgeschaltet und der Akku geladen werden, sonst wird der Akku beschädigt. Im Sourcecode sind die Schwellen individuell einstellbar, so dass man auch Batterien, oder einen anderen Akku Typ verwenden kann und trotzdem etwas von der Kapazitätsanzeige hat

Wenn die verbliebene Munition nur noch 3 Patronen oder weniger beträgt, beginnt die Ziffer zu blinken und die Anzeige in der Helligkeit zu pulsieren.

Nach Wechsel des Magazins (Reed Kontakt Magazin) geht die Anzeige wieder auf den Standardwert von 30.

Die Helligkeit der Anzeige kann mit dem Poti beeinflußt werden. Die Tasten UP und Down dienen zur Bedienung des Einstellmenüs.

Flashtime Screen

Beide Tasten gleichzeitig gedrückt, lassen das Einstell Menü erscheinen. Hier kann mit den Tasten der Flash Timer eingestellt werden, also die Dauer eines Lichtblitzes. Während dieses Einstellmenü gezeigt, wird, kann trotzdem der Trigger betätigt werden, man ist also nicht wehrlos! Der von Links nach Rechts immer länger werdende Balken zeigt die Restzeit an, bis das Menü automatisch verlassen wird.

Rounds Screen

Durch erneutes gleichzeitiges Drücken von UP und Down gelangt man in das Einstellmenü für die Munition

Hier kann man die Anzahl der Patronen einstellen, die beim Magazinwechsel als "Voll" geladen eingestellt werden. Der von Links nach Rechts immer länger werdende Balken zeigt die Restzeit an, bis das Menü automatisch verlassen wird. Wenn man UP und DOWN gleichzeitig drückt, wird die eingestellte Munition dauerhaft gespeichert.

Weitere Beschreibung und auch neue Fotos wie z.B. dieses, auf der englischsprachigen Seite

Nach Pfingsten wird es hoffentlich dort auch endlich ein Action Video geben, vorausgesetzt, die Waffe überlebt den F.A.T.E Con

Mann, ist das lange her.

Mein letzter Eintrag hier in Zockertown, der mit Kernel Compilierung zu tun hatte, ist ca. 9 Jahre her.

Seit dem bin ich offenbar immer mit dem Standard Kerneln von Debian ausgekommen.

Komme ich immer noch, aber im aktuellen Testing "Buster" habe ich zwei kleine Ärgernisse, die ich untersuchen bzw. beheben möchte. Zum Beispiel funktioniert seit dem Debian linux-image-4.15.03-amd64 das einstellen der Hintergrundhelligkeit auf meinem Tuxedo XC1506 nicht mehr per Fn Tasten, sondern nur noch mit xbacklight.

Die Ursache ist die fehlende Infrastruktur unter /sys/class/backlight/ 

Deshalb dachte ich, ich probiere mal einen neuen Kernel und gucke mir die .config genauer an, was übrigens in heutigen Zeiten nicht ohne ist, man kämpft sich durch mehr als 8000 Zeilen....

Der von Buster bereitgestellte und installierte Kernel ist: linux-image-4.16.0-1-amd64

Mein compilierter Kernel ist der derzeitige Stable 4.16.8

Die Fehlermeldung:

 *** Keine Regel vorhanden, um das Ziel „debian/certs/test-signing-certs.pem“, 
  benötigt von „certs/x509_certificate_list“, zu erstellen.  Schluss.
Makefile:1060: die Regel für Ziel „certs“ scheiterte

wird durch die Config Optionen CONFIG_SYSTEM_TRUSTED_KEYS="" und auskommentieren / entfernen von CONFIG_SYSTEM_EXTRA_CERTIFICATE vermieden

#Kernel compilieren

time make-kpkg -j 8 --initrd --revision 100.0 kernel_image modules_image

real 29m53,385s

user 180m22,725s

sys 15m53,992s

Die Namensgebung ist ungeschickt, aber für meine Zwecke ausreichend, wichtig ist, dass ich die gebauten Kernel auseinander halten kann.

So. Neuer Kernel läuft nun, Helligkeitseintellung mit den Fn Tasten geht wieder, das zweite Ärgernis, nämlich die Fn Taste für Flugmodus geht immer noch nicht wieder, das ist mir aber erstmal nicht so wichtig, hat bestimmt ähnliche Ursachen.. 

Mich hat interessiert, in wie fern sich die Compiler von gcbasic zwischen Wine und natives Linux unterscheiden. Mit wineconsole steht ein Tool zur Verfügung um Windowsprogramme, die ein Commandline Interface haben, direkt aufzurufen ohne den Umweg über die Windows GUI zu benutzen.

Rufe ich also

time winesconsole --backend=curses exit

​auf, kommt man auf eine Ausführungszeit von

wineconsole: 
real 0m0,223s 
user 0m0,024s 
sys 0m0,024s

Dies ist also der Overhead des Wine Systems und muß beim Ergebnis der Untersuchung berücksichtigt werden.

Das kleine Demo Programm 040_Rotate_the_LEDS.gcb, das für das Board StartPic18 im Demo Ordner beretgestellt ist, dient hier als nicht repräsentive Basis.

time wineconsole --backend=curses GreatCowBasic/gcbasic.exe 040_Rotate_the_LEDS.gcb 
real 0m2,182s 
user 0m0,032s 
sys 0m0,040s

time gcbasic 040_Rotate_the_LEDS.gcb 
real 0m0,430s 
user 0m0,368s 
sys 0m0,020s

​Den Overhead abgezogen, dauert also das compilieren eines kleinen Basic Programmes mit wine ziemlich genau 2 Sekunden. Das compilieren mit dem nativen Basic Compiler unter Linux dauert weniger als 0.5 Sekunden.

Der Compiler in der nativen Linux Ausprägung ist also ca. 4 mal so schnell. 

Der wine normalerweise keine so großen Einbußen hat, stellt sich die Frage, woran liegt das?

Ist jetzt keine große Sache, dennoch möchte ich zu (selbst)dokumentarischen Zwecken aufschreiben, welche Einstellungen notwendig sind, um ein bequemes und komfortables Arbeiten zu ermöglichen.

Vorweg gesagt, man kann natürlich mit Hilfe von wine auch die mitgelieferte GCB@Syn IDE benutzen.

Bei mir allerdings führte das zu einer erheblichen (Faktor 10-11) längeren Compile- und Flashzeit. Da ich sowieso nicht der wine Fan bin, habe ich mir mit Geany, der Universal IDE eine Möglichkeit geschaffen. (Nachtrag; vermutlich einer der Gründe ist, dass die GCB@SYN IDE mehrere Tools über die Command.com Schnittstelle auffruft, auch native Windows hat da Performance Einbußen)

Damit beim Laden eines Great Cow BASIC Programmes das Syntax Hilighting aktiviert wird, wie hier gezeigt den Freebasic Eintrag ergänzen. Zur Info, die Syntax von Freebasic ist praktisch identisch zu der von Great Cow BASIC, nur die Spezial Befehle, wie z.B. #chip werden nicht hervorgehoben, aber das kann ich verschmerzen.

Damit man mit F8 und F9 direkt das Compilieren und Flashen lostreten kann, sind die folgenden Einträge notwendig. Bitte beachten, dass eine *.gcb Datei geladen ist und der Tab auch aktiv ist, denn Geany hat für jeden Datei Typ unterschiedliche Werkzeuge.

Die Dritte Zeile hatte ich als ersten Ansatz, hier musste ich immer den PIC Typ anpassen, was nerven kann, wenn man mit zwei oder mehr verschieden Modellen arbeiten will.

Das im Screenshot genannte Programm test-flash.sh habe ich gestrickt, um die #chip Zeile zu finden und dem Java Programm den PIC Typ mitzugeben. Es ist noch in einem experimentellen Stadium, scheint aber einigermassen zu funktionieren. Fehlerhinweisen werde ich natürlich möglichst zeitnah nachgehen.

Ein dritter, nicht ganz so kritischer Punkt ist das reformatieren vom Quellcode. Dafür bietet Geany eine universelle Schnittstelle nämlich das senden einer Auswahl an ein externes Programm. Ich habe mich für FBeauty entschieden. Es ist ein in Freebasic geschriebenes Programm, welches das reformatieren durchführt. Da der FreeBasic Compiler ohnehin installiert werden muss um den nativen Great Cow BASIC Compiler zu compilieren, ist der ohnehin vorhanden, also wirklich kein Ding.

Hier der Quelltext von test-flash.sh

# to set the correct Path to ipecmd.jar execute the following line:
# find /opt -name ipecmd.jar
# this will print out one or more lines, choose the one you want use
# and edit the next line
IPECMD="/opt/microchip/mplabx/v4.05/mplab_ipe/ipecmd.jar"
# simple test for Typo
if [ -e "$IPECMD" ]
then 
	# finding the filename
	BASENAME="$(basename $1)"
	GCBNAME="$(echo $BASENAME|cut -f1 -d.)"
	#echo "Basic Source=$GCBNAME.gcb"
	BASICFILE="$(dirname $1)/$GCBNAME.gcb"
	CHIPLINE="$(grep -i '#chip ' $BASICFILE)"
	TARGET="$(echo $CHIPLINE|sed 's/#chip//I' |sed 's/ \+//g'|cut -d, -f1)"
	echo "Flashing Target:$TARGET"
	echo "using java -jar $IPECMD -TPPK3 -P$TARGET -M -F\"$1\""
	java -jar $IPECMD -TPPK3 -P$TARGET -M -F"$1"
else
	echo "$IPECMD was not found"
fi

test-flash.sh (oder unter einem besser passenden namen) an eine beliebige Stelle kopieren, ausführbar machen und den Pfad wie oben gezeigt in Geany eintragen.

Wer das IPECMD in einer anderen Version und oder an einer anderen Stelle installiert hat, muß die erste Zeile natürlich anpassen.

und nicht nur das, sondern auch ein neues Maskottchen. Und ein news- feed und und und.

Die Site habe ich mit Typersettercms erstellt. Typesetter ist der modernisierte Nachfolger von GPEasy, einem Flatfile CMS System, welches ich selbst für einige private Seiten eingesetzt habe. Ich fand, so ein großartiges Produkt wie Great Cow BASIC hat einfach mal eine moderne "responsive" Webseite verdient. Weil sich kein anderer fand, habe ich es umgesetzt und weil die Typesetter Community sehr hilfbereit ist, ist mir das auch ganz gut gelungen, ohne selber die höheren Weihen der CSS Stylerei zu verstehen oder vollständig begriffen zu haben.

Um auf Great Cow BASIC zurück zu kommen, es geht gewaltig voran, mittlerweile ist der Hersteller Microchip auch unterstützend an der Seite. Da kommen noch ein paar Überraschungen in naher Zukunft. Wer schon immer mal mit den kleinen Controllern arbeiten wollte, sollte definitiv Great Cow BASIC in die engere Wahl ziehen.

Für mein aktuelles Projekt verwende ich einen saubilligen Stepup Wandler. Als Eingang wird momentan ein 3xAA Pack verwendet, also 4.5V. am Labornetzteil zeigt sich, dass die Schaltung selbst bei 0.9V Eingangspannung noch funktioniert, der Ausgang ist dann aber nicht mehr 5V. Solange die Eingangsspannung über 3V liegt ist der Ausgang konstant bei 5V.

Somit ist diese Modul ideal für kleinere Spielereien, bei denen man konstante 5V benötigt und frei von der gewählten Batterie sein möchte.

Für ca. 50 Cent kann man einen Selbstbau vergessen. Der Wirkungsgrad wird übrigens mit bis zu 85% angegeben. Vielleicht etwas übertrieben, vor allem wenn die Eingangsspannung niedrig ist, aber im oberen Bereich komme ich sogar auf ca. 90%.

Mit 4.4V am Eingang zieht die Schaltung 40mA, ohne Wandler sind es 36mA.

Suchbegriffe für dieses Modul: DC DC Boost Step UP Converter 1.5 3V 3.7V 4.5V to 5V Voltage Regulator Power supply Module for 18650 Li-ion battery

Original Hersteller http://www.canton-electronics.com/power-converter-modules-c-4/booster-power-modules-c-4_5/output-dc5v-c-4_5_12/600ma-15v-3v-33v-37v-to-5v-boost-stepup-dcdc-converter-module-voltage-pfm-regulator-board-p-974.html

Hör ich hier jemanden lachen und sagen: "Jetzt macht der Kerl was mit Basic, sowas unprofessionelles, kann er es ja gleich mit Arduino machen!"?

Ich gebe zu, mit Arduino noch nie in Berührung gekommen zu sein, deshalb liegt mir fern mich dazu zu äußern. Eine ähnliche Geschichte ist allerdings energia für msp430, das habe ich genutzt und mit C verglichen. energia ist schön einfach, hat aber auch Overhead, der sich direkt auf die runtime des Projektes auswirkt.

Ich bin eigentlich seit dem C64 kein Basic Fan mehr, aber unbestritten ist, dass es ähnlich wie mit Fahrrad fahren ist. Einmal gelernt, verlernt man es nicht.

Warum ausgerechnet Great Cow BASIC? Hier fiel mir beim ersten Testprogramm gleich das kleine erzeugte HEX File auf. Der Compiler vergleicht sich selbst direkt mit Assembler, nicht mit anderen Compilern, da steht dann folgendes.

Great Cow Basic hat drei Hauptziele.

• Die Notwendigkeit sich wiederholende Assembler Befehlssequenzen zu vermeiden,
• effizienten Code zu produzieren und um es einfach zu machen Code, der für einen Chip-Typ geschrieben wurde, auf einen anderen Chip-Typ auszuführen.
• Es verbirgt viele der verwirrenderen Teile der Mikrocontroller-Programmierung, so dass es für Anfänger geeignet ist und diejenigen, die Assembler nicht mögen, oder die Assembler-Sprache lernen möchten.

Zitat von Evan, einem der Entwickler:

Die Leute glauben nicht, dass BASIC optimierten Code produzieren kann.
Aber jede Sprache für einen Compiler ist die reine Digitalisierung von
Wissen und Einsichten von den Menschen, die den Compiler erschaffen.

Ich bin jedenfalls sehr positiv überrascht, über die riesige Auswahl an schlüsselfertigen Lösungen, im Great cow Basic Jargon Demos genannt.

Zusätzlich gibt es eine Top aktuelle, gut gepflegte Sammlung unter https://github.com/Anobium/Great-Cow-BASIC-Demonstration-Sources/

Die Liste der unterstützen Hardware, also Displays, Sensoren, RTC , eeproms usw. ist hier beeindruckend. Wer sich ernsthaft mit dem Programmieren von Controllern beschäftigen möchte, sollte definitiv einen Blick auf Great Cow Basic werfen!

Für Windows gibt es eine beeindruckende IDE mit allem möglichen an integrierten tools, z.B. auch für unterschiedliche Programmer.

Es gibt einen Apple Port und natürlich ebenfalls einen Linux Build. Hier muss man sich eine eigene IDE schnappen und mal ein wenig anpassen, das ist im Falle von Geany aber wirklich einfach. Ich nutze Geany und bin damit sehr glücklich bis jetzt.

In der Vergangenheit gab es auch Portierungen der Windows Ide nach Linux, die habe ich mir jetzt nicht angesehen, weil die scheinbar nicht mehr weiter gepflegt wurden.

Meine eigenen Gehversuche habe ich übrigens mit StartPIC18 gemacht, wer das auch möchte, kann mich gerne nach einer Platine fragen, noch habe ich ein paar davon übrig.

Ich habe mit Great Cow BASIC ein erstes Projekt umgesetzt, welches ich in Kürze hier vorstelle.

Richtige Fallen gab es gar nicht, kleinere Schwierigkeiten liessen sich im Forum schnell klären, davon ab ist das Hilfesystem wirklich glänzend und immer auf dem neuesten Stand. (Im installierten Build ist ebenfalls viel an Dokumentationen enthalten.)

Das ist für ein Opensource Projekt gar nicht so selbstverständlich, oftmals leiden geniale Tools an einer aktuellen und ausführlichen Dokumentation

Für weitere kleine Projekte habe ich bereits konkrete Ideen.

Ich hoffe, ich habe bei dem Einen oder Anderen das Interesse geweckt.

Ich bin quälfest.

Seit ca. 6 Wochen ärgere ich mich, dass Chromium immer einen neuen Browser aufmacht, wenn ich auf einen Link in einer Email klicke, oder so.

Heute habe ich mich per neu angelegten testuser "stretch" angemeldet, um zu checken, ob da ein grundsätzliches Problem vorliegt, könnte durchaus sein, ich fahre ja Debian Stretch, zwar kurz vor Stable, aber ....

Weit gefehlt, als "stretch" ist's kein Problem, nur mit meinem Hauptuser. Kurz daran gedacht mit einem 

diff --suppress-common-lines ./.config/chromium ../stretch/.config/chromium/

dem Problem auf die Schliche zu kommen, doch die Differenzen sind dermassen riesig, dass das aussichtslos erscheint.

Eigentlich etwas genervt, kommt mir der Gedanke doch mal in die Tweak-Utlilities reinzuschauen und was finde ich da?

Richtig, ich habe die Option "Launch new Instance" angeschaltet. Da muß ich mich ja nicht wundern!

Ich dachte vor einigen Wochen, das wäre eine gute Idee, wenn immer ein neues Terminal aufgemacht wird beim draufklicken, hatte aber nicht bedacht, dass man ja mit der Einstellung alle Favouriten beeinflußt.

Na gut, halte ich eben die Strg-Taste fest, wenn ich eine neue Instanz brauche

Seit heute habe ich mein Blog auf Serendipity 2.1.1 aktualisiert.

Sollte es Probleme geben, bitte mitteilen.

Mir ist bis jetzt nichts aufgefallen.

Das Upgrade ist ein Witz, auspacken, eine Frage beantworten, fertig

Tja, ich liebe die Software.

NOT MAINSTREAM SINCE 2002