JNA: Mehrdimensionale Arrays

Anders als in C liegen Javas mehrdimensionale Arrays nicht in einem Stück im Speicher. C kennt (intern) gar keine mehrdimensionalen Arrays, bzw. unterscheiden sich diese (intern) nicht von eindimensionalen. Und so muss man das dann auch beim Zugriff aus Java heraus nachbauen:

// pseudo-mehrdimensional
byte[] oneDimensional = new byte[rowCount * colCount];

// ...

// Transformation in ein echtes mehrdimensionales Array:
byte[][] twoDimensional = new byte[rowCount][colCount];
for (int i = 0; i < rowCount; i++) {
  for (int j = 0; j < colCount; j++) {
    twoDimensional[i][j] = oneDimensional[i * colCount + j];
  }
}

// pseudo-mehrdimensional

byte[] oneDimensional = new byte[rowCount * colCount];

// ...

// Transformation in ein echtes mehrdimensionales Array:

byte[][] twoDimensional = new byte[rowCount][colCount];

for (int i = 0; i < rowCount; i++) {

for (int j = 0; j < colCount; j++) {

twoDimensional[i][j] = oneDimensional[i * colCount + j];

}

JNAerator und time_t

Nachtrag zu neulich: JNAerator macht aus einem time_t in etwa Folgendes (schon an Java Naming Conventions angepasst):

public class MyTimeStamp extends PointerType {
  public MyTimeStamp(Pointer address) {
    super(address);
  }

  public MyTimeStamp() {
    super();
  }
}

public class MyTimeStamp extends PointerType {

public MyTimeStamp(Pointer address) {

super(address);

}

public MyTimeStamp() {

super();

}

Damit kann man fast nichts anfangen; insbesondere bekommt man den Eigentlichen Timestamp nicht da raus. Das “Pointer” ist außerdem irreführend, denn C liefert an der Stelle keinen Pointer, sondern die Sekunden seit Epoch. Funktionieren tut:

public class MyTimeStamp extends Structure {

  public int value;

  public MyTimeStamp() {}

  public MyTimeStamp(int value) {
    this.value = value;
  }

  @Override
  protected List<String> getFieldOrder() {
    return Collections.singletonList("value");
  }

  public LocalDateTime asLocalDateTime() {
    ZonedDateTime dateTime = ZonedDateTime.ofInstant(Instant.ofEpochSecond(value), ZoneId.systemDefault());
    return dateTime.toLocalDateTime();
  }
}

public class MyTimeStamp extends Structure {

public int value;

public MyTimeStamp() {}

public MyTimeStamp(int value) {

this.value = value;

}

@Override

protected List<String> getFieldOrder() {

return Collections.singletonList("value");

}

public LocalDateTime asLocalDateTime() {

ZonedDateTime dateTime = ZonedDateTime.ofInstant(Instant.ofEpochSecond(value), ZoneId.systemDefault());

return dateTime.toLocalDateTime();

}

Quelle, hth

UPDATE: long durch int ersetzt, das ist wichtig.

JNAerator?

Das ~~Anstrengende~~ Fehleranfällige an JNI ist das Mapping von (komplexen) Datentypen. Nun gibt es aber auch noch JNA,

a community-developed library that provides Java programs easy access to native shared libraries without using the Java Native Interface.

(Wikipedia), und dafür insbesondere den “JNAerator“, der komplexe Datentypen “automatisch” mappt. Die Idee liegt nahe, statt JNI(-Strukturen) JNA(-Strukturen) zu nutzen. Im Folgenden ein Versuch.

Die Installation ist so weit klar:

$ git clone http://github.com/nativelibs4java/JNAerator.git
$ cd JNAerator
$ mvn clean install

$ git clone http://github.com/nativelibs4java/JNAerator.git

$ cd JNAerator

$ mvn clean install

Der Aufruf allerdings schon nicht mehr so sehr (“0.13” und den Pfad zum lokalen Maven-Repo ggf. anpassen):

$ java -jar ~/.m2/repository/com/nativelibs4java/jnaerator/0.13-SNAPSHOT/jnaerator-0.13-SNAPSHOT-shaded.jar /path/to/some/HeaderFile.h -mode Directory -f -runtime JNA

1	$ java -jar ~/.m2/repository/com/nativelibs4java/jnaerator/0.13-SNAPSHOT/jnaerator-0.13-SNAPSHOT-shaded.jar /path/to/some/HeaderFile.h -mode Directory -f -runtime JNA

Wichtig ist nämlich -runtime JNA, mit den default Einstellungen handelt man sich Abhängigkeiten zu org.bridj (laut Doku “faster runtime that supports C++”) und damit die Notwendigkeit ein, die dll darüber zu laden. Und das will man zumindest dann nicht, wenn man plain JNI möchte.

Das JNAerator Studio (hier) scheint das übrigens per default anders zu machen, aber das nur am Rande. Trotzdem für die Akten: Den Pfad zur dll würde man BridJ so bekannt machen:

System.setProperty("bridj." + DLL_NAME_WITHOUT_EXTENSION + ".library")

1	System.setProperty("bridj." + DLL_NAME_WITHOUT_EXTENSION + ".library")

Aber zurück zu den so kompilierten Klassen. -mode Directory erzeugt sie als .java-Dateien, nicht als .jar. Das ist hilfreich, denn man muss sie editieren, siehe unten. Sie enthalten (übrigens neben Kommentaren mit dem vollen Pfad der Quelldatei, im Beispiel also /some/path/to/some/HeaderFile.h, evt. will man den nicht öffentlich machen) dann alle structs in ihrer Java Version. Das eigentliche Interface, das die Methoden der Header-Datei bereitstellt, muss man trotzdem selber schreiben und wie folgt laden:

static {
  // loads MyDll.dll from C:\dll\
  NativeLibrary.addSearchPath("MyDll", "C:\\dll\\");
  INSTANCE = Native.loadLibrary("MyDll", MyInterface.class);
}

static {

// loads MyDll.dll from C:\dll\

NativeLibrary.addSearchPath("MyDll", "C:\\dll\\");

INSTANCE = Native.loadLibrary("MyDll", MyInterface.class);

}

In MyInterface deklariert man die Methoden, auf die man in der dll zugreifen möchte. Primitive Übergabe-/Rückgabeparameter sind dabei ziemlich selbsterklärend (int=int, bool=boolean, etc.), Strings sind char-Arrays, Pointer bringt JNA mit (bsplw. IntByReference, IMHO ein Vorteil gegenüber JNI), structs hat man sich ja eben in Java-Klassen übersetzt. Also alles gut? Tatsächlich gibt es Probleme mit den erzeugten Klassen:

Einige sind offensichtlich, bsplw. überschreiben sie

protected List<String> getFieldOrder()

1	protected List<String> getFieldOrder()

mit

protected List<? > getFieldOrder()

1	protected List<? > getFieldOrder()

, was natürlich nicht kompiliert. Globales Suchen-und-Ersetzen, fertig.

Anderes ist schon komplexer: Structures (also die Java-Klasse jetzt) haben ein Alignment, im Konstruktor zu übergeben. Wenn ich das richtig verstehe, korrespondiert das mit der entsprechenden Compiler-Option in VS und sollte automatisch erkannt werden? Oder es hängt an der Plattform? Wie auch immer: Wenn man eine struct hat, die, sagen wir, 22 Byte belegt, dann ist es nicht hilfreich, wenn der default von 4 Byte großen Blöcken ausgeht. Entweder werden dann nämlich zwei Byte abgeschnitten, oder zwei unnötige Bytes angehängt, was zu Verschiebungen in der Folgestruktur führt!

Beispiel: In Arrays von structs beginnt der zweite Eintrag dann zwei Bytes zu spät (es fehlen zwei Bytes zu Beginn) oder zu früh (der Eintrag beginnt mit den letzten zwei Bytes aus dem ersten Eintrag). Nicht unbedingt einfach zu debuggen m( Hilfreich ist es, das System-Property jna.dump_memory auf true zu setzen, und die Ausgabe in einen Hex-Editor zu kopieren. Man sieht die beschriebenen Byte-Offsets dann wenigstens (Danke, Nils!).

Ich habe dazu eine eigene Zwischenschicht eingezogen:

import com.sun.jna.Pointer;
import com.sun.jna.Structure;

abstract class MyStructure extends Structure {

  private static final int STRUCTURE_ALIGNMENT = ALIGN_NONE;

  WvStructure() {
    super(STRUCTURE_ALIGNMENT);
  }

  WvStructure(Pointer peer) {
    super(peer, STRUCTURE_ALIGNMENT);
  }
}

import com.sun.jna.Pointer;

import com.sun.jna.Structure;

abstract class MyStructure extends Structure {

private static final int STRUCTURE_ALIGNMENT = ALIGN_NONE;

WvStructure() {

super(STRUCTURE_ALIGNMENT);

}

WvStructure(Pointer peer) {

super(peer, STRUCTURE_ALIGNMENT);

}

Zusammenfassung

Ja, JNAerator erzeugt einem Java-Klassen aus Headerdateien. Und das ist bei sehr großen Headern auch hilfreich. Aber es ist auch sehr fehleranfällig – und teilweise sogar fehlerhaft. Es kann nur eine Basis für eigenen Code sein.

Update

Nachtrag zu time_t

C++ println

Dem nächsten, der mir erzählt, Strings wären in Java nicht ganz selbsterklärend (was sich im Wesentlichen darauf beschränkt, dass es keine Primitives sind), dem lach ich ins Gesicht und verweise ihn auf diese gewachsene String/char/…-Welt in C++.

Also. Modulo weiterer Anwendungsfälle, die ich dann ergänze, scheint Textausgabe wie folgt ganz gut zu funktionieren. Ich wollte an der Stelle kein printf verwenden, weil ich jede Ausgabe (zentral) prefixen wollte. Vermutlich könnte man printf einfach wrappen, indem man dessen Signatur kopiert, egal:

#include <iostream>
#include <sstream>

void println(std::string s) {
  std::cout << "[cpp:] " << s << std::endl;
  std::cout.flush();
}

template <typename T>
std::string str(const T & t) {
  std::ostringstream os;
  os << t;
  return os.str();
}

// ...

println("The answer is " + str( 42 ) + ".");

#include <iostream>

#include <sstream>

void println(std::string s) {

std::cout << "[cpp:] " << s << std::endl;

std::cout.flush();

}

template <typename T>

std::string str(const T & t) {

std::ostringstream os;

os << t;

return os.str();

}

// ...

println("The answer is " + str( 42 ) + ".");

Aber bitte auch an den Anfang der Datei, sonst werden die Funktionen nicht gefunden m(

Update: Schön (wenn auch ohne Prefix) ist auch

#include <iostream>

void println() {
  std::cout << std::endl;
  std::cout.flush();
}

template<typename T, typename... Args>
void println(T t, Args... args) {
  std::cout << t;
  println(args...);
}

// ...

println("The answer is ", 42, ".");

#include <iostream>

void println() {

std::cout << std::endl;

std::cout.flush();

}

template<typename T, typename... Args>

void println(T t, Args... args) {

std::cout << t;

println(args...);

}

// ...

println("The answer is ", 42, ".");

Java: C/C++ über JNI einbinden

Neulich musste ich eine DLL aus Java heraus ansprechen. Zur Wahl stehen JNI und JNA, wobei JNA “nur” ein Wrapper für JNI ist – und bei mir nicht funktioniert hat. In der Theorie ist JNI aber auch nicht schwer, allerdings legt Visual Studio ~~einem~~ mir Steine in den Weg. Ein Grund mehr, bei Java zu bleiben.

Der Java-Teil ist dann auch denkbar einfach:

public class DllBridge {
  static {
    // loads file MyDll.dll:
    System.loadLibrary("MyDll");
  }

  // declare all functions you want to use as "native":
  public native String hello(String input);
  // ...
}

public class DllBridge {

static {

// loads file MyDll.dll:

System.loadLibrary("MyDll");

}

// declare all functions you want to use as "native":

public native String hello(String input);

// ...

}

Diese DllBridge wird dann in eine Headerdatei übersetzt:

// erzeugt DllBridge.h; Achtung: ohne .java:
$ javah DllBridge

1 2	// erzeugt DllBridge.h; Achtung: ohne .java: $ javah DllBridge

Und diese Header-Datei dann in “das” C/C++-Projekt kopiert. An “das” Projekt kommt man wie folgt:

Visual Studio installieren; ich habe Visual Studio Community 2017 mit den Standardkomponenten genommen
Neues C++/Win32-Projekt anlegen, im Dialog unter “Anwendungseinstellungen” den Anwendungstyp “DLL” wählen
Ich habe das Projekt testweise MyDll genannt, die entstehende .dll heißt später genauso

Nachdem man die DllBridge.h in das Projekt kopiert und über Rechtsklick > Include In Project eingebunden hat, kann man ihre Methoden implementieren. O.g. Code erzeugt genau eine Methode Java_DllBridge_hello, siehe DllBridge.h. Deren Implementierung in der .c-Datei:

#include "stdafx.h"
#include <jni.h>
#include "DllBridge.h" // !

JNIEXPORT jstring JNICALL Java_DllBridge_hello(JNIEnv *env, jobject thisObj, jstring input)
{
  const char *name = (*env).GetStringUTFChars(input, NULL);
  char msg[60] = "Hello ";

  strcat(msg, name);
  (*env).ReleaseStringUTFChars(input, name);

  MessageBoxA(NULL, msg, "", MB_OK | MB_SYSTEMMODAL);

  return (*env).NewStringUTF(msg);
}

#include "stdafx.h"

#include <jni.h>

#include "DllBridge.h" // !

JNIEXPORT jstring JNICALL Java_DllBridge_hello(JNIEnv *env, jobject thisObj, jstring input)

{

const char *name = (*env).GetStringUTFChars(input, NULL);

char msg[60] = "Hello ";

strcat(msg, name);

(*env).ReleaseStringUTFChars(input, name);

MessageBoxA(NULL, msg, "", MB_OK | MB_SYSTEMMODAL);

return (*env).NewStringUTF(msg);

}

Alleine die Importe und die korrekte Version von MessageBox herauszufinden, hat sicher eine Stunde gedauert 😡 Oh, Stichwort “Importe”: jni.h wird vom JDK mitgebracht, die entsprechenden Ordner muss man in VS bekannt machen. Das funktioniert nicht über einen Symlink, sondern über die Projekteinstellungen, indem man unter Configuration Properties > C/C++ > General > Additional Include Directories diese drei Verzeichnisse hinzufügt (Rekursion wäre ja auch zu einfach.):

C:\Program Files (x86)\Java\jdk1.8.0_121\include
C:\Program Files (x86)\Java\jdk1.8.0_121\include\win32
C:\Program Files (x86)\Java\jdk1.8.0_121\include\win32\bridge
PS Ja: Das ist ein 32-Bit-Java, weil ich letztlich eine 32Bit dll ansprechen will.

Das Ganze sollte jetzt bauen (Build > Build solution, oder STRG+Shift+B) und eine <Projektname>.dll erzeugen, siehe Konsolenausgabe. Der Name der .dll muss dem im initialen Java-Code entsprechen.

Ein Aufruf von

DllBridge dll = new DllBridge();
String s = dll.hello("moto");
System.out.println("dll says: " + s);

DllBridge dll = new DllBridge();

String s = dll.hello("moto");

System.out.println("dll says: " + s);

öffnet dann die MessageBox:

Sowie die erwartete Ausgabe auf der Konsole. Für reine C-Anbindung könnte man hier aufhören.

Interessant wird es nun, wenn man langlebigere C++-Objekte von Java aus referenzieren möchte. Idee:

Eine Klasse auf Java-Seite, die die dll lädt, sowie die nativen Methoden bereitstellt, und eine Klasse auf C++-Seite, die diese implementiert
Die C++-Klasse wird initialisiert, ihren Pointer gibt man in Form einer long an Java zurück (bzw. jlong, vgl. hier), vermutlich ist das die Speicheradresse
Über diese long kann Java dann das Objekt referenzieren
Braucht man das C++-Objekt nicht mehr, wird es deleted.

(via, längeres Beispiel, Danke Nils!)

Hier sieht das so aus:

@SuppressWarnings({"SameParameterValue", "unused", "WeakerAccess"})
public class DllBridge {

  static {
    System.loadLibrary("MyDll");
  }

  private native long initNative();

  private native void destroyNative(long ptr);

  private native void incrementCounter(long ptr);

  private long nativePtr;

  public DllBridge() {
    nativePtr = initNative();
  }

  public void incrementCounter() {
    incrementCounter(nativePtr);
  }

  public void destroy() {
    destroyNative(nativePtr);
    nativePtr = 0L;
  }

  @Override
  protected void finalize() {
    destroy();
  }
}

@SuppressWarnings({"SameParameterValue", "unused", "WeakerAccess"})

public class DllBridge {

static {

System.loadLibrary("MyDll");

}

private native long initNative();

private native void destroyNative(long ptr);

private native void incrementCounter(long ptr);

private long nativePtr;

public DllBridge() {

nativePtr = initNative();

}

public void incrementCounter() {

incrementCounter(nativePtr);

}

public void destroy() {

destroyNative(nativePtr);

nativePtr = 0L;

}

@Override

protected void finalize() {

destroy();

}

Bzw. in C++:

#include "stdafx.h"
#include <jni.h>
#include "DllBridge.h"

class DllBridge {
  private:
    int counter;

  public:
    DllBridge();
    void incrementCounter();
};

DllBridge::DllBridge() {
  counter = 0;
}

void DllBridge::incrementCounter() {
  counter++;
  printf("increased counter to %d\n", counter);
}

JNIEXPORT jlong JNICALL Java_DllBridge_initNative(JNIEnv *env, jobject thisObj) {
  return (long) new DllBridge();
}

JNIEXPORT void JNICALL Java_DllBridge_incrementCounter(JNIEnv *env, jobject thisObj, jlong ptr) {
  DllBridge* bridge = (DllBridge*) ptr;
  bridge->incrementCounter();
}

JNIEXPORT void JNICALL Java_DllBridge_destroyNative(JNIEnv *env, jobject thisObj, jlong ptr) {
  // TODO? What about the DllBridge's counter? I want my garbage collector
  delete (DllBridge*) ptr;
}

#include "stdafx.h"

#include <jni.h>

#include "DllBridge.h"

class DllBridge {

private:

int counter;

public:

DllBridge();

void incrementCounter();

};

DllBridge::DllBridge() {

counter = 0;

}

void DllBridge::incrementCounter() {

counter++;

printf("increased counter to %d\n", counter);

}

JNIEXPORT jlong JNICALL Java_DllBridge_initNative(JNIEnv *env, jobject thisObj) {

return (long) new DllBridge();

}

JNIEXPORT void JNICALL Java_DllBridge_incrementCounter(JNIEnv *env, jobject thisObj, jlong ptr) {

DllBridge* bridge = (DllBridge*) ptr;

bridge->incrementCounter();

}

JNIEXPORT void JNICALL Java_DllBridge_destroyNative(JNIEnv *env, jobject thisObj, jlong ptr) {

// TODO? What about the DllBridge's counter? I want my garbage collector

delete (DllBridge*) ptr;

}

Aufruf in Java dann:

DllBridge dll = new DllBridge();
dll.incrementCounter();
dll.incrementCounter();
dll.incrementCounter();
dll.destroy();

DllBridge dll = new DllBridge();

dll.incrementCounter();

dll.destroy();

Last but not least die andere Richtung, also C++ nach Java. Die Methode

// in DllBridge.java:
public void callback(String payload) {
  System.out.println("C++ says " + payload);
}

// in DllBridge.java:

public void callback(String payload) {

System.out.println("C++ says " + payload);

}

lässt sich von C++ aus aufrufen über

// might be env->GetObjectClass(thisObj) as well; use full qualified path if class has package:
jclass javaClass = env->FindClass("DllBridge");

// syntax is "(parameter type)return type" (plus semicolon if not a primitive)
// see https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/types.html#type_signatures
jmethodID callback = env->GetMethodID(javaClass, "callback", "(Ljava/lang/String;)V");

// use CallStaticVoidMethod and pass javaClass, if static method is called
env->CallVoidMethod(thisObj, callback, env->NewStringUTF("hi"));

// might be env->GetObjectClass(thisObj) as well; use full qualified path if class has package:

jclass javaClass = env->FindClass("DllBridge");

// syntax is "(parameter type)return type" (plus semicolon if not a primitive)

// see https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/types.html#type_signatures

jmethodID callback = env->GetMethodID(javaClass, "callback", "(Ljava/lang/String;)V");

// use CallStaticVoidMethod and pass javaClass, if static method is called

env->CallVoidMethod(thisObj, callback, env->NewStringUTF("hi"));

Weiterführendes dazu hier.

hth

Windows Phone 8 Apps: “The name MainViewModel does not exist in the namespace”

Windows 8 Pro frisch installiert, das Windows Phone SDK heruntergeladen, installiert und gestartet, quasi-leere Demo-App erstellt, “Emulator WVGA 512MB” gestartet – folgende Fehlermeldung (plus drölf weiteren) bekommen:

Error 1 The name “MainViewModel” does not exist in the namespace “clr-namespace:MyApp”.

Vermutung im Internet: Irgendwelche “Assemblies” seien nicht “korrekt” verlinkt. Aha. Kann sein, schließlich habe ich gar nichts verlinkt. Finde ich auch nicht nötig, um ein vorgegebenes Hello-World-Programm zu starten. Was für ein bekackter Bug soll das sein??

Lösung (Schritt 6, Achtung, extrem hässliche Seite): Das Projekt muss auf einer anderen Partitition als Visual Studio abgespeichert sein. WTF. Würde aber zu o.g. Vermutung passen – evt. kommt VS nicht mit relativen Pfaden klar?

Arduino mit Eclipse als IDE

Das ist leider einfacher gesagt als getan, siehe unten 🙁 Eclipse muss man natürlich nur einmal einrichten. Da das deutlich umfangreichere aber das Einrichten des Projektes ist, würde ich empfehlen, ein einmal lauffähig eingerichtetes Projekt als Template zu nutzen.

Anmerkung #1: Was momentan noch nicht funktioniert, ist die Ausgabe nach Serial 🙁 Ich habe bisher nur ein sehr rudiemntäres “Blink”-Projekt kompilieren können… offenbar fehlen da irgendwelche Includes, wobei die HardwareSerial eigentlich da ist. Ich bleibe dran.

Anmerkung #2: Im Folgenden werden OS X Lion und ein Uno verwendet

Einrichten von Eclipse:

Eclipse IDE for C/C++ Developers installieren
Das AVR-Plugin installieren
Das AVR “Crosspack” installieren
Sicherheitshalber die Pfade unter Preferences -> AVR -> Paths checken:
AVR-GCC: /usr/local/CrossPack-AVR20100115/bin
GNU make: /usr/local/CrossPack-AVR20100115/bin
AVR Header Files: /usr/local/CrossPack-AVR20100115/avr-3/include
AVRDude: AVR-GCC: /usr/local/CrossPack-AVR20100115/bin
Dein(e) Arduino(s) unter Preferences -> AVR -> AVRDude einrichten. Anmerkung: Der default Port ist der, den man auch in der Arduino-IDE nutzt – und den man unter /dev/ findet (ls -la /dev/)
Configuration Name: <irgendwas>
Programmer Hardware: Arduino
Override default port: /dev/tty.usbmodemfa131
Override default baudrate: 115200

Einrichten eines ersten Projekts (dieses kann man hinterher kopieren, um diese Einstellungen nicht immer wieder vornehmen zu müssen):

Neues “C” Projekt anlegen:
Project name: <irgendwas>
Project type: AVR Cross Target Application -> Empty
Finish
In den Project properties -> AVR -> AVR Dude -> Programmer -> “Programmer configuration” die Konfiguration von oben, Punkt 5, auswählen
Das Arduino anschliessen
In den Project properties -> AVR ->AVR Dude -> “Target Hardware” entweder “Load from MCU” versuchen, oder für den Uno “ATmega328P” auswählen. Anmerkung: Auch, wenn arduino.cc als Microcontroller für den Uno den ATmega328 angibt, so ist es in Wirklichkeit doch der ATmega328P
Die Arduino IDE öffnen, ein neues Projekt anlegen, und kompilieren (“Verify” genügt) (es geht darum, einmal die Core Library anzulegen)
“Irgendwo” unter /private/var/ die Datei core.a finden – bei mir war es /private/var/folders/8f/0zf3pf294rvbrybmwh7mq1bm0000gn/T/build1871947640038466426.tmp/core.a 🙂 – und in den Projektordner kopieren
Diese “neue” core.a in libcore.a umbenennen
Unter den Project properties -> C/C++ Build -> Settings -> Tool Settings -> “Additional Tools in Toolchain”: “Generate HEX for Flash Memory”, “Print Size” und “AVRDude” müssen angewählt sein; “Generate HEX file for EEPROM” und “Generate Extended Listing” müssen abgewählt sein
Unter … -> AVR Compiler -> Command von “avr-gcc” in “avr-g++” ändern
Unter … -> AVR Compiler -> Directories den Pfad /Applications/Arduino.app/Contents/Resources/Java/hardware/arduino/cores/arduino (oder analog) eintragen. Anmerkung: Rechtsklick auf die Arduino-App -> Paketinhalt anzeigen hilft 😉
Unter … -> AVR Compiler -> Debugging -> “Generate Debugging info” “No debugging info” auswählen
Unter … -> AVR Compiler -> Optimization -> “Optimization Level” “Size Optimization (-Os)” auswählen
Unter … -> AVR Assembler -> Debugging -> “Generate Debugging Info” “No debugging info” auswählen
Unter … -> AVR C Linker -> Libraries eine neue Library mit dem Namen “core” anlegen. Einen neuen Library Path mit “${workspace_loc:/${ProjName}}” anlegen – damit sollte er jetzt im aktuellen Projekt nach der corelib aus Schritt 6 und 7 suchen
Eine neue Datei mit Namen main.c anlegen
coden 😉

Kompilieren und flashen tut man das Projekt dann mit dem “Hammer”-Button in der Menüleiste – es muss dabei im Dropdown “Release” ausgewählt sein.

Mit Hilfe von, und, und, und.

crusy.net

♪ Commit ins Abenteuerland ♫

Tag Archives for C

JNA: Mehrdimensionale Arrays

JNAerator und time_t

JNAerator?

Zusammenfassung

Update

C++ println

Java: C/C++ über JNI einbinden

Windows Phone 8 Apps: “The name MainViewModel does not exist in the namespace”

Arduino mit Eclipse als IDE