Updates to make the FT4222 platform extender more usable.
Previous implementation opened libft4222.so and loaded symbols as
needed. This implementation removes dynamic loading of libft4222 in
favor of creating a new shared libary which links against libft4222.so.
The dynamic loading is now done in mraa.c. One C method is exposed in
libmraa-platform-ft4222.so for finding/initializing an FT4222:
mraa_platform_t mraa_usb_platform_extender(mraa_board_t* board);
Mraa.c attempts to open this platform library and calls the
mraa_usb_platform_extender method. If an ftdi4222 is connected, the
user gets added IO from the extender. If no FT4222 device is connected,
continue as normal.
* Create a new platform library for the FT4222
* Expose only 1 C method from the library -
mraa_usb_platform_extender
* libmraa-platform-ft4222.so contains CXX code (as well as previous
C code). All *allocs have been removed in favor of global
C++ stl containers.
* Previously, the FT4222 would only initialize correctly if 2 ftdi
devices existed. Now, initialize FT4222 devices based on the
device id.
* Many fixes for various problems with the FT4222
* Added unit test for platform extender (minimal functionality w/o hw)
* Updated to FindFtd4222.cmake module to handle standard arguments
* Removed CMAKE_C_FLAGS addition of -DFTDID2XX and -DFTDI4222 since
these are NOT used anywhere in source.
* Building the FTDI4222 shim requires libft4222.h which requires
ftd2xx.h. Updated CMakeLists.txt to require both when building
the shim.
Signed-off-by: Noel Eck <noel.eck@intel.com>
Went a bit too far with the previous commit. Added pointer to pointer
back to mraa_find_uart_bus_pci.
Tested leaks against valgrind and verified dev_path gets set with gdb.
Signed-off-by: Noel Eck <noel.eck@intel.com>
Unfortunately the device_path char* is dynamically allocated
and #defined and const char *'ed depending on how each platform provided the
uart device paths which makes cleaning it up more complicated.
Added a check for the IEI_TANK.
Removed the char** (in favor of a char*) for mraa_find_uart_bus_pci.)
Signed-off-by: Noel Eck <noel.eck@intel.com>
Mock platform allows one to use mraa without having any real HW.
This commit makes necessary foundational changes and implements
GPIO functionality as well as adds respective tests.
Signed-off-by: Alex Tereschenko <alext.mkrs@gmail.com>
Signed-off-by: Brendan Le Foll <brendan.le.foll@intel.com>
Imraa allows the automatic flashing and setup of arduino101 subplatforms as
well as the initial setup of GPIO/i2c devices
Signed-off-by: Longwei Su <lsu@ics.com>
Signed-off-by: Brendan Le Foll <brendan.le.foll@intel.com>
This is a re-design of commit 0041801. mraa_lang_func_t structure has been
added (similar in design to mraa_adv_func_t) that points to JNI functions
implemented in src/java/mraajni.c. Functions are set by libmraajava.so,
see wrapper entry in src/java/mraajava.i. As gpio.c now uses these
functions, language specific #ifdef code has been removed as JNI code
is only called if functions are defined (i.e. not NULL)
Signed-off-by: Henry Bruce <henry.bruce@intel.com>
Signed-off-by: Brendan Le Foll <brendan.le.foll@intel.com>
This means that a valid platform is no longer required for iio operations and
therefore this is now only a req for using USBPLAT
Signed-off-by: Brendan Le Foll <brendan.le.foll@intel.com>
Removed mraa_setup_uart from core mraa.c moved logic within init
function
Add more syslog output for easier debugging.
Signed-off-by: Thomas Ingleby <thomas.c.ingleby@intel.com>
Instead of trying to have an implementation that covers most platforms
Leave all mmap up to platform definition. Through function pointers.
gpio_mmap_setup sets up the mmap
Within the internal gpio context struct two more function pointers now
exist mmap_read & mmap_write. They exist there so each context can its
own function for handling a write and read.
Signed-off-by: Thomas Ingleby <thomas.c.ingleby@intel.com>
* Should allow for more platform quirks to be handled by mraa without
* massive conditional areas per platform.
Signed-off-by: Thomas Ingleby <thomas.c.ingleby@intel.com>
