FSFIan

The circuit will be able to work without any external power or clock source. But if you need more power than the board can provide on its own, you can power it from an external 400 Hz supply. To support that optional use case, it needs to be able to synchronize with the frequency of that external 400 Hz power supply.

Wenn du cygwin installiert hast, editier mal die Batchdatei und passe den Pfad zu socat an. Die mitgelieferte Batchdatei ruft "socat\socat" auf, benutzt also immer die mitgelieferte Version. Ansonsten kannst du den com-handler von ArturDCS benutzen, das ist eine C#-Anwendung, die den Job der Batchdatei übernimmt (und mehrere serielle Ports gleichzeitig ansteuern kann).

I take it you have not heard of my DCS Witchcraft project then. It does not do much, and it doesn't do it very well, but it would have saved you some frustration. Take a look at 09:30 in the tutorial video. (Note: AFAIK it still works with current versions of DCS, but I won't develop it further, because the Mission Editor in EDGE will have a proper solution to this problem.)

I like it. I am not that worried about saving input bandwidth here (after all, the pilot only has two hands), but it does not hurt either. It also decreases implementation complexity on the Arduino side and does not add any significant complexity on the Lua side.

Did you read my post above? It has example code to do exactly that and links to the relevant section of the official Lua documentation for further information...

Die Code-Schnipsel, die in einem "if"-Statement verpackt sind, gehören in die onDcsBiosWrite()-Funktion rein. Guck mal hier nach, Kelevra9987 hat mittlerweile die finale Version seines Fuel Flow-Display-Codes gepostet. In deinem Fall musst du nicht sprintf() verwenden, es sollte ausreichen, einfach lcd.print(vhfamFreq2Value) aufzurufen. Als ich DCS-BIOS ins Leben rief, hatte ich als Zielgruppe erfahrene C++-Programmierer im Kopf. Dass man jetzt mit Copy&Paste schon sehr weit kommt, ist kein Resultat genialer Planung, sondern kommt einfach daher, dass Programmierer faul sind und sich wiederholende Arbeit (Kopieren von drei Werten -- address, mask, shift -- pro Control) wegautomatisieren, wo es nur geht. Deshalb gibt es mehrere Stellen, wo Dinge inkonsistent sind (denn wenn man es bereits verstanden hat, ist der inkonsistente Weg nicht mehr Arbeit als ein konsistentes Design), und an anderen Stellen hapert es an der Dokumentation ("das ist doch offensichtlich, wo der Code-Schnipsel hingehört!"). Wie gesagt werde ich versuchen, das in der nächsten Version der Arduino-Library besser zu machen. Ich weiß jetzt mehr über meine Zielgruppe und durch das bisherige Feedback ist mir jetzt auch klar, wo die inkonsistenten und/oder schlecht dokumentierten Stellen sind.

Why do something illegal if there is no disadvantage (other than a bit of paperwork) doing it legally? Also, if you apply for BAföG (student loans, only half of which you have to pay back later), confidentiality in banking does not apply, so the authorities have the right to look at my bank accounts if they suspect something (and PayPal is just another bank). From my perspective, I trade some paperwork for the ability to order from all of the big electronics distributors (who will only deliver to business customers in Germany).

It's stored in an old church in San Francisco. To get a copy, click this link. I love archive.org's Wayback Machine!

Bei Werten, die bei 0 anfangen, gibt es keinen extra String-Export, weil du genauso gut den Integer-Wert an dein Display durchreichen kannst. Ausnahme: der Wert wird zweistellig (weil Arduino-Libraries i.d.R. kein printf() haben, mit dem man Zahlen direkt rechtsbündig ausgeben kann, stattdessen muss man einen temporären Buffer und sprintf() benutzen, aber trotzdem ist hier der extra String-Export eigentlich die falsche Design-Entscheidung). Ein Integer-Wert von 0 bis 9 braucht nur 4 Bits im Export-Datenstrom, ein String-Export braucht 8 Bit pro Zeichen. Jedes Byte, das ich nicht übertragen muss, muss der Arduino auch nicht verarbeiten. Die nächste Version der Arduino-Library wird Integer- und String-Exports ein bisschen konsistenter behandeln (es wird einen IntegerBuffer analog zum StringBuffer geben und onDcsBiosWrite() wird entfallen). Kann aber noch ein paar Monate dauern. lcd.print("Mein Text:") Das kannst du im "Hello, World"-Beispiel nachlesen, das mit der Arduino-IDE geliefert wird.

Du mappst auf das Intervall [0, 9], nimmst also an, dass 0 = (0/9)*65535 = 0, 1 = (1/9)*65535 = 7281, ..., 9 = (9/9)*65535 = 65535. Wenn du dir mal die Chrome-Extension installierst und den Wert beobachtest, wirst du feststellen, dass 0 = 0, 1 = 10%, 2 = 20%, ..., 9 = 90% ist, d.h. wenn im Display "9" steht ist der Wert nicht bei 65535 sondern erst bei 58981. Warum? Weil noch "Luft nach oben" sein muss, wenn du jetzt weiterdrehst und das Ding wieder von 9 auf 0 überläuft. Versuch mal folgendes: if (address == 0x1086) { unsigned int altPressure0Value = (value & 0xffff) >> 0; altPressure0Value += 3276; // 0.5 offset, damit schon bei "1,5" und nicht erst bei "2,0" auf "2" gewechselt wird (der nächste Schritt rundet wegen der Ganzzahl-Division(Integer-Datentyp) immer ab!) unsigned int altPressure0ValueMap = altPressure0Value / 6553; lcd.setCursor(0,0); lcd.print(altPressure0ValueMap); }

Guck dir mal diesen Beitrag an. Wenn da deine Frage nicht beantwortet wird, dann brauchen wir ein paar mehr Informationen (diese drei Fragen sollte jeder Bugreport beantworten): Was hast du gemacht? (z.B. der Code deines Arduino-Sketches, je nach Problem weitere relevante Infos wie Versionsnummern der verwendeten Software) Was ist passiert? (Du sagst, die Werte werden "nicht richtig formatiert angezeigt" -- aber wie werden sie denn jetzt angezeigt? Gar nicht? In römischen Zahlen? ...) Was sollte statt dessen passieren? (Ist doch klar, "die Werte sollen richtig formatiert angezeigt werden". Aber wir wissen nicht, was für dich "richtig formatiert" bedeutet!)

On the Leonardo, the USB connection is handled by the same chip that runs your sketch. That means if you manage to program a buffer overflow somewhere and mess up the rest of the memory, it also interferes with the code that communicates with the PC. Welcome to the world of embedded systems development, where sometimes your only way to debug stuff is to stare at your code until the error jumps out at you... EDIT: The good news is that your Leonardo board is not broken.

If you have a big job that you want to execute infrequently, you should read up on coroutines. They won't help if the combined work of the simulation and your scripts is too much for one thread, but if your scripts do very little most of the time but then block for a whole second every 15 seconds, you can split the work up into smaller chunks and spread it out over the whole 15 seconds. It's basically what I assume you are already doing now by processing smaller tables instead of one big one, but it's easier to use so you can use it in more places. Here's a quick example which you can try in the DCS Witchcraft Lua console. First execute this snippet: a = 0 bigjob = coroutine.create(function() for i=1,10 do a = a+1 coroutine.yield() end end) Let's assume that counting 'a' up from 1 to 10 takes a really long time. We use coroutine.create() to wrap the task of counting up 'a' into a coroutine, which gets stored in the 'bigjob' variable. Now execute this second snippets a few times and watch what happens: return {coroutine.resume(bigjob), coroutine.status(bigjob), a} Just by inserting coroutine.yield() statements, you can interrupt your big task to give DCS time to take care of other things. The coroutine mechanism will take care to preserve local variables, etc. until coroutine.resume() is called. Of course you have to assume that the game state will change "behind the back of your task" when you call yield(), but that synchronization problem is inherent in any method of concurrent programming. Look at the Lua docs to find out what you can do with coroutines, what the various return values mean and how error handling and reporting works in coroutines. EDIT: Obviously you'd want to use mist.scheduleFunction() or similar to call coroutine.resume() on all your coroutines regularly.

The reason for the "'CS' was not declared in this scope" error message is that you put your ButtonCS class into DcsBios.cpp/.h. Each .cpp file is compiled separately from everything else (this is called a "translation unit" in C++), so when compiling the ButtonCS class, it does not know about the 'CS' variable. Solution: revert changes to DcsBios.cpp/.h and put your ButtonCS class into the same file where you declare the CS variable, so the beginning of your A10C-CDU.ino looks like this: #include <Centipede.h> Centipede CS; // create Centipede Object #include <DcsBios.h> #include <Servo.h> #include <Wire.h> // order of these includes seems no matter - tried different [color=red] // declaring the ButtonCS class here ensures that it has access to 'CS' namespace DcsBios { class ButtonCS : PollingInput { private: void pollInput(); char* msg_; char pin_; char lastState_; bool reverse_; void init_(char* msg, char pin, bool reverse); public: ButtonCS(char* msg, char pin, bool reverse) { init_(msg, pin, reverse); } ButtonCS(char* msg, char pin) { init_(msg, pin, false); } }; void ButtonCS::init_(char* msg, char pin, bool reverse) { msg_ = msg; pin_ = pin; CS.pinMode(pin_, INPUT_PULLUP); lastState_ = CS.digitalRead(pin_); reverse_ = reverse; } void ButtonCS::pollInput() { char state = CS.digitalRead(pin_); if (reverse_) state = !state; if (state != lastState_) { sendDcsBiosMessage(msg_, state == HIGH ? "0" : "1"); } lastState_ = state; } } [/color] /**** Make your changes after this line ****/ #include "BIOS_calls.h" // here includes (to pull error-relevant code not too far) copy-and-pastes from the DCS-BIOS/doc/contr$ Alternatively, at the top of DcsBios.cpp (or your own Arduino library .cpp file), make a promise to the compiler that 'CS' will be defined in some other translation unit: #include <Centipede.h> extern Centipede CS; In general, you should avoid modifying DcsBios.cpp/.h, because that means that you cannot compile sketches for panels that don't make use of a Centipede shield.

Correct. Start by reading through the code for the existing SwitchMultiPos class. You need to adapt the readState() method to something along these lines: // assume pins_ is an array of size 4 unsigned char switchPos = 0; unsigned char i; for (i=0; i<4; i++) switchPos |= (digitalRead(pins_[i]) << i); switchPos = switchPos / 2; // only using every second position // you could instead ignore the least significant bit in the first place and save a pin return switchPos;

Your CS object is not declared in DcsBios.cpp. Start by putting the new class at the top of your Arduino sketch, right after the #include statements and the declaration of the CS object. Once you get it working, you can read up on how #include works, the difference between .cpp and .h files, and make the whole thing reuseable as a separate Arduino library. You probably want to call "CS.pinMode" instead of the normal "pinMode", too.

I am pretty sure this is not possible without modifications (i.e. completely self-contained in the mission file). If you are willing to install additional things (other than the .miz file) on the server, you have the following options right now: Find or write a multithreading library for Lua 5.1 (there seems to be one called "Lua Lanes"), place it somewhere in package.cpath and "require" it. If you manage to make this work, don't use any DCS Lua functions from another thread, it would very likely mess something up because the rest of the DCS code does not expect it. Connect to an external application over a TCP connection and pass long-running computation tasks to it. This application can be written in whatever language you like, including Lua. Bonus points: it can run on another computer, too. It could also run inside another DCS process, so you could, for example, use the "land" and "world" objects to make line-of-sight calculations. I doubt that we will ever see multi-threaded Lua support as a core DCS feature, because it would be hard to implement. What might be reasonable to implement would be something like web workers in JavaScript, where you pass a task off to another thread that will only have access to a limited set of API functions which don't depend on current simulation state (such as the terrain stuff), but before that I'd like to see a lot of other features. And before you think about multithreading or multiprocessing, think about optimizing your existing implementation. Can you achieve the same effect with less computation? Do all of those triggers really need to be checked once every second? etc.

Dann sollte es eine Datei C:\Windows\system32\mode.com geben, und die sollte er finden, da system32 im Suchpfad (Umgebungsvariable PATH) ist. Ich verwende Windows 7 Professional (MS Dreamspark-Lizenz über die Uni). Entweder es gibt Windows-Versionen, bei denen mode.com warum auch immer nicht dabei ist, oder irgendwas ist seltsam an deinem System. Wenn bei dir C:\Windows\system32\mode.com existiert, guck mal, ob die PATH-Variable richtig ist: Rechtsklick auf "Computer", "Eigenschaften" "Erweiterte Systemeinstellungen" (linke Seitenleiste) Unter "Systemvariablen" gibt es eine die "PATH" heißt PATH auswählen, "Bearbeiten", den Inhalt bei "Wert der Variablen" in die Zwischenablage kopieren, "Abbrechen" In ein neues Dokument in Notepad++ einfügen Strg+H ("Suchen und ersetzen"-Funktion), "Find what": ";", "Replace with:" ";\n", "Search mode": "Extended", OK. Das ersetzt das Semikolon durch Semikolon+Zeilenumbruch, um das Ganze besser lesen zu können. Jetzt sollte ein Wert pro Zeile stehen. Einer davon sollte "C:\Windows\system32;" lauten. Wenn nicht: wieder die Variable PATH in den Systemeinstellungen bearbeiten, "C:\windows\system32" am Ende anfügen (ggf. noch ein Semikolon davor -- das Semikolon trennt verschiedene Pfade voneinander ab).

Take a look at the implementation of DcsBios::Switch2Pos, especially the pollInput() method which will be executed once every loop(). We use digitalRead to check the current button state, and if it has changed, we use sendDcsBiosMessage() to update the switch state in DCS. That is what you have to implement in your sketch, but instead of digitalRead(), you use whatever piece of code you need to read the pin state from your centipede shield. The CDU backlight is controlled by the "Console Lights" rotary. In the "Advanced" view of the control reference, you can see that this control has an output. The code snippet is meant to be incorporated into your onDcsBiosWrite() method (future versions of the Arduino library will handle this in a more consistent way): void onDcsBiosWrite(unsigned int address, unsigned int value) { if (address == 0x1150) { unsigned int lcpConsoleValue = (value & 0xffff) >> 0; /* your code here */ } } The value will probably range from 0 to 65535. Translate that to a brightness (0..255) with map(), use analogWrite() to output it to a PWM-capable pin connected to the MOSFET that switches your LED backlight, and there you go.

Der Befehl soll dafür sorgen, dass die verwendete serielle Schnittstelle auf die richtige Geschwindigkeit eingestellt ist. Benutzt du vielleicht Windows 10 oder so und Microsoft hat den entfernt? Die Rx-LED blinkt, weil Daten ankommen. Die werden aber mit der falschen Geschwindigkeit gesendet, so dass der Arduino nur Müll daraus interpretiert. Die Tx-LED sollte blinken, wenn du die Taste am Arduino drückst, aber auch hier gilt: der PC wird die gesendeten Daten nicht richtig interpretieren. Versuch mal, vor dem Start der Batchdatei die Geschwindigkeitseinstellung selbst vorzunehmen. Wenn ich bei mir (Windows 7) im Gerätemanager auf einen seriellen Anschluss rechtsklicke und die Eigenschaften aufrufe, gibt es einen Tab "Anschlusseinstellungen". Bits pro Sekunde muss dann auf 500000. Die anderen Einstellungen sind wahrscheinlich schon richtig eingestellt (Datenbits: 8, Parität: Keine, Stoppbits: 1, Flusssteuerung: Keine). Achtung: Wenn du mit der Arduino-IDE neuen Code auf das Board lädst, werden diese Einstellungen wahrscheinlich wieder verstellt. Alternativ kannst du auch den "com-handler" von ArturDCS benutzen. ArturDCS hat eine C#-Anwendung geschrieben, die dir alle seriellen Ports anzeigt; einfach auf den Button klicken und der Port wird mit DCS-BIOS verbunden. GitHub-Seite "Download ZIP" anklicken, entpacken, bin/DcsBiosCOMHandler.exe starten. Du brauchst dafür ein aktuelles .NET Framework (ich glaube 4.5).

This is great! I didn't know there was a callback function for this. Where did you find out about it? Is there some resource about DCS internals I have been missing all along?

Richtig, die Pakete verlassen deinen Rechner nicht (außer ein anderes Gerät in deinem Netzwerk baut eine TCP-Verbindung auf oder du weist DCS-BIOS explizit an, die Daten per UDP an eine bestimmte externe IP-Adresse zu schicken, z.B. weil du einen Arduino mit Ethernet-Shield verwenden willst). Mit deinem Router hat es auf jeden Fall nichts zu tun. DCS-BIOS benutzt Multicast-UDP, weil das der einzige Weg war, den ich gefunden habe, um unter Windows mehreren Programmen das gleichzeitige empfangen des Export-Datenstroms zu ermöglichen. (Die TCP-Unterstützung kam erst später.) Ich hab DCS-BIOS unter Win7 Professional mit aktivierter Windows-Firewall entwickelt. Keine Ahnung, warum das bei dir nicht funktioniert. Du kannst es mal mit "normalem" (Unicast-)UDP versuchen, das hat gegenüber TCP den Vorteil, dass die Reihenfolge, in der du das Skript und DCS startest, egal ist. In der BIOSConfig.lua: BIOS.protocol_io.connections = { -- BIOS.protocol_io.DefaultMulticastSender:create(), BIOS.protocol_io.TCPServer:create(), BIOS.protocol_io.UDPSender:create({ port = 5010, host = "127.0.0.1" }), BIOS.protocol_io.UDPListener:create({ port = 7778 }) } (Kommentarzeichen vor Zeile 4 entfernt, IP-Adresse auf localhost gesetzt) Batchdatei: REM Specify the number of the COM port your Arduino is connected to: set COMPORT=5 set /A TTYNUM=%COMPORT%-1 mode COM%COMPORT% BAUD=500000 PARITY=N DATA=8 STOP=1 TO=off DTR=on socat\socat -v UDP4-RECV:5010!!udp-sendto:localhost:7778 /dev/ttyS%TTYNUM% pause

As I suspected, the A-10C CDU's Export.lua file does not respect previously installed callback functions. If you can, report this as a bug to the author.

Versuch mal, das Senden von Multicast-UDP-Paketen ganz abzuschalten, indem du in der BIOSConfig.lua die zweite Zeile auskommentierst, so dass die so aussieht: BIOS.protocol_io.connections = { -- BIOS.protocol_io.DefaultMulticastSender:create(), BIOS.protocol_io.TCPServer:create(), -- BIOS.protocol_io.UDPSender:create({ port = 7777, host = "192.168.1.177" }), BIOS.protocol_io.UDPListener:create({ port = 7778 }) } Vielleicht stürzt DCS dann ja auch nicht mehr ab, wenn die Mission vorbei ist. PS: Welches Betriebssystem und welche Firewall/Antivirus-Software benutzt du?

Da scheint irgendwas mit dem Export-Datenstrom schiefzugehen. Wenn es keine Fehlermeldung irgendwo gibt, ist es schwierig herauszufinden, warum das nicht geht, aber du kannst es mit folgender Batch-Datei mal über TCP statt Multicast-UDP versuchen (in dem Fall musst du erst DCS starten, dann das Skript): REM Specify the number of the COM port your Arduino is connected to: set COMPORT=5 set /A TTYNUM=%COMPORT%-1 mode COM%COMPORT% BAUD=500000 PARITY=N DATA=8 STOP=1 TO=off DTR=on socat\socat -v TCP4:127.0.0.1:7778 /dev/ttyS%TTYNUM% pause Der Inhalt der "dcs.log"-Datei wäre da mal interessant, die findest du in %USERPROFILE%\Saved Games\DCS\Logs. Hast du außer DCS-BIOS noch irgendwas anderes laufen, das eine Export.lua mitbringt (Heliios, TacView, etc.)? Immer schön Öl aufs Feuer gießen! Was wäre das cool gewesen, damals, als man noch so viel Zeit hatte, Zugriff auf vernünftige Informationsquellen zu haben. Internet hatten wir nicht, die Stadtbücherei hatte nichts brauchbares in Sachen Programmierung, also habe ich die ersten Jahre meines Programmiererlebens mit Batch-Dateien und danach Visual Basic verschwendet (wir hatten ein Buch namens "DOS Power Tools" im Regal und in der PC-WELT 11/97 war eine Einführung in Office-Makros drin) :smartass: