Martin Vajnar [Sun, 21 Jul 2013 08:25:50 +0000 (10:25 +0200)]
JORTE: remove unused code
Since the domain is started (receiving and sending threads) either by
calling ORTEDomainAppCreate() or ORTEDomainMgrCreate(), there is no need
to have DomainStart() on the Java side.
Martin Vajnar [Fri, 19 Jul 2013 09:37:04 +0000 (11:37 +0200)]
ROBOT_DEMO: completely rewritten
This adds complete rewrite of the demo application. Buttons are now removed
from views and are instead placed to a menu. At the start a domain manager
and an application domain are created under which every subscriber
and publisher is launched. Support for hokuyo_scan is added.
Martin Vajnar [Fri, 19 Jul 2013 09:20:39 +0000 (11:20 +0200)]
JORTE: fix subscription destruction
Destroy subscription first, then destroy references to objects
in subscription callback. This prevents SEGFAULTs from the receiving
thread, that tries to save received instance to a non-existent object.
DeleteLocalReference was replaced with DeleteGlobalReference, since we are
destroying a global reference. This prevents dvmAbort() being called
on Android. This also fixes a memory leak (the ctx->msg reference was not
deleted).
Martin Vajnar [Tue, 16 Jul 2013 09:48:07 +0000 (11:48 +0200)]
JORTE: don't use finalizers in Java classes
This replaces finalizers with explicit destroy() functions, because the
order in which objects with no reference in the VM are garbage-collected
is not guaranteed. This caused trouble with finalization of DomainApp
and Publisher (or Subscriber). If the DomainApp was destroyed before
the Publisher (or Subscriber) the Publisher's finalizer would have been
stuck (eventually leading to TimeoutException to be thrown).
Martin Vajnar [Sun, 14 Jul 2013 18:08:07 +0000 (20:08 +0200)]
JORTE: switch to direct ByteBuffer
This commit significantly changes the way new issues are sent and received
both on the Java side and on the C side.
In the past there was one Java instance of HeapByteBuffer in the
MessageData class. ByteBuffer is used to perform serialization and
deserialization of received and sent issues in Java. It is compatible with
the CORBA standard that is used in the main ORTE library.
The HeapByteBuffer has one significant drawback. It allocates memory
on the heap managed by Java VM's garbage collector and when accessing
the backing array from C it has to copy the entire array to new space
in memory outside the VM. Added to that the backing array wasn't accessed
as an array object from the C code, but rather every byte from the Java
buffer was copied to a C byte array or vice versa (publisher x subscriber
part). This adds a lot of overhead (calling JNI functions to obtain new
values).
Instead the DirectByteBuffer is now used which allocates memory directly
(outside of Java VM) through malloc() and stores the pointer in such a way,
that it is easily accesible from C code using GetDirectBufferAddress,
that returns (void *). The Java part behaves much the same as normal
(Heap) ByteBuffer. The allocated byte array could be used like any other
C array and the VM ensures that the memory region allocated by direct
ByteBuffer is contiguous. This is very useful, because normal Java arrays
are not guaranteed to be contiguous which makes them difficult to handle,
because JNI functions must be called that make copies of them in a
contiguous space and that adds another overhead.
As a bonus the C code for both publisher and subscriber Java wrappers
is much shorter and simpler than it used to be.
Martin Vajnar [Sun, 14 Jul 2013 12:57:21 +0000 (14:57 +0200)]
JORTE: fix endianness the proper way
Use the GNU C compiler macro __BYTE_ORDER__ to set data_endian on the C
side and ByteOrder.nativeOrder() function to set ByteBuffer's order
in the MessageData class on the Java side.
Martin Vajnar [Sat, 13 Jul 2013 16:50:14 +0000 (18:50 +0200)]
ROBOT_DEMO: decrease CPU usage
Now there are 2 major threads on the Java side. The first one is main which
takes care of drawing GUI and receives callbacks from accelerometer.
The second one computes and sends values to the robot's motors.
Martin Vajnar [Sun, 7 Jul 2013 17:24:59 +0000 (19:24 +0200)]
ANDROID: add support for Android
Add preliminary Android library.
Note: Current Android NDK doesn't allow libraries to have assets folder,
but we place the ortemanager in there. At current point it is necessary
for applications using this library to either manually copy the compiled
ortemanager over to their own assets folder or to create a symlink.
Martin Vajnar [Sun, 7 Jul 2013 17:10:53 +0000 (19:10 +0200)]
MANAGER: prepare for Android
Android doesn't support sigwaitinfo, instead it offers only sigwait.
Since we don't use the information about which signal is being triggered
we can safely switch to sigwait.
Martin Vajnar [Sun, 7 Jul 2013 16:50:01 +0000 (18:50 +0200)]
JORTE: prepare for Android (fix class loader problems + add logging)
This fixes class loading problems on Android.
As per the Android Documentation (http://developer.android.com/training/articles/perf-jni.html#faq_FindClass):
Android's Dalvik VM uses the loader associated with the method
at the top of the interpreted stack, or if there isn't one
(because the thread was just attached), it uses the "system" class
loader, for FindClass calls.
To overcome this the JNI_OnLoad function is used. Any FindClass calls made
from there will happen in the context of the class loader used to load
the shared library. So from there one class that will always be present
in the JORTE Java package is chosen (org.ocera.orte.JOrte) and it's
class loader is stored as a global reference inside the VM (thus shared
by all processes attached to the VM) and as a static variable (accesible
only by functions from the onLoad.c file) on the C side.Also the findClass
and findLoadedClass method IDs are cached. To simplify the class loading
process inside C functions the findClass functions is written.
Android also doesn't implement the printf function. However it does have
a logging capability, so a variadic macro replacing occurences of printf
with __android_log_print is used.
ppisa [Thu, 11 Jun 2009 19:55:47 +0000 (19:55 +0000)]
The ORTE demo can be compiled by OMK Makefiles now.
The directory orte/contrib/shape can be build by regular
make process if orte/contrib/shape/Makefile is replaced
by regular OMK Makefile helper - i.e. orte/Makefile
or omk build stript is run with USE_LEAF_MAKEFILES=n
echo CONFIG_OC_ETH_ORTE_DEMO_SHAPE=y >>config.omk
cd orte/contrib/shape
omk USE_LEAF_MAKEFILES=n
wentasah [Wed, 20 May 2009 12:20:43 +0000 (12:20 +0000)]
Corrected termination of ortemanager
Sometimes I've realized that it was not possible to terminate ortemanager
by pressing Ctrl-C. It seems it was the case when I disconnecte from the
network and wanted to finish ortemanager later.
Since it is not safe to call pthread_mutex_lock() from signal handlers,
I've reworked termination to use sigwaitinfo() to wait for termination
signals.
wentasah [Wed, 20 May 2009 12:20:10 +0000 (12:20 +0000)]
Better error handling in ORTEDomainCreate()
Previous implementation did not check for errors in bind() and when
ortemanager was run two times, the second instance did not fail and
instead consumed 100% of CPU.
Virgil Ansems:
If the call to inet_addr fails, the value INADDR_NONE is returned, which usually is -1. Therefore the call to ntohl will return a large number (the return type is unsigned) instead of 0.