If we already have a subplatform present with the same type, return success
when trying to add it again. We don't check that the tty is the same because
that is hidden inside the t_firmata* structure but we should do at some point
Signed-off-by: Brendan Le Foll <brendan.le.foll@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>
Make better use of unsigned/signed ints, signed ints are preffered unless there
is a good reason not to.
Signed-off-by: Alexandru Timohi <alexandru.timohi@intel.com>
Signed-off-by: Brendan Le Foll <brendan.le.foll@intel.com>
Enum was deprecated in 0.10.x and causes issues with strict C89 compliance so
is now removed
Signed-off-by: Brendan Le Foll <brendan.le.foll@intel.com>
This commit introduces support for Dallas Semiconductor (DS) 1-wire
compliant device support using an available UART device.
The principle of operation is described in the following Application
note by Maxim Electronics:
https://www.maximintegrated.com/en/app-notes/index.mvp/id/214
with help (1-wire search) from:
https://www.maximintegrated.com/en/app-notes/index.mvp/id/187
It has been tested on Galileo 2 and Edison, with 2 DS 1-wire devices,
the DS18B20 and DS2413 connected to the bus. A UPM driver for the
DS2413 is already complete and a PR will be submitted after this one.
It is important that you use a UART with CMOS/TTL level voltages
(3.3v/5v) RX and TX lines. DO NOT use standard RS232 level voltages
or you are going to have a bad day.
In order for this to work, a simple interface circuit, using a single
diode must be constructed:
(forgive my "Asciihematic" :)
-|
U|
A| TX---|<--+
R| |
T| RX-------o--------o 1-wire data bus
-|
The diode on TX is a 1N4148 (cheap and common), with the cathode
connected to TX, and the anode connected to RX and the 1-wire data
line.
The 1-wire data line requires a pull-up resistor, as the DS 1-wire
spec requires. 4.7-5K is typical for DS 1-wire buses.
NOTE: DHT-type (temp/humidity sensor) 1-wire devices ARE NOT DS 1-wire
compliant, and will not work with this code/circuit unfortunately.
Also note, this will use up one of your UARTs, which cannot be used
for any other purpose (ie: to access true UART-type serial devices).
You can however, connect as many DS 1-wire devices as feasible to this
UART, as it will function as a DS 1-wire bus master.
Signed-off-by: Jon Trulson <jtrulson@ics.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>
Add pin commands. Old mraa_setup_mux_mapped style is used for other boards
(pincmd = PINCMD_UNDEFINED) where pincmds are not defined.Remove useless
pullup_enable code, Galileo Gen2: review all pin mux and add commands Galileo
Gen2: remove doubled functionality: mraa_intel_galileo_gen2_i2c_init_pre and
mraa_intel_galileo_gen2_uart_init_pre. Galileo Gen2: fix "Invalid AIO pin
specified - do you have an ADC?" error. Galileo Gen2: pullup/pulldown
resistors are disabled during UART/GPIO/SPI/I2C/UIO initialization. Use
mraa_gpio_mode to enable resistors.
Signed-off-by: Eugene Bolshakov <pub@relvarsoft.com>
Signed-off-by: Brendan Le Foll <brendan.le.foll@intel.com>
To ensure backwards comptability MRAA_ERROR_PLATFORM_ALREADY_INITIALISED
remains as member of mraa_result_t but now has same code as MRAA_SUCCESS
Signed-off-by: Henry Bruce <henry.bruce@intel.com>
This is a partial replication of firmata branch commit 2f25468
as that patch would not apply to the javacheck2 branch
Signed-off-by: Henry Bruce <henry.bruce@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 fix only affects USBPLAT=ON which would cause mraa_init to return
uninitialised if we had detected a platform. Whilst the initialisation had
actually been done correctly the results would be that platform_name was
unfilled and no iio initialisation was done
Signed-off-by: Brendan Le Foll <brendan.le.foll@intel.com>
Switch to using calloc on all calls to malloc where the memory isn't
initialized. For things like the mraa_board_t, not allocating all to zero
causes issues such as with the sub_platform member, where if that's not zero
mraa_get_platform_type will try to dereference a random memory location for the
sub_platform->platform_name, which can result in segmentation faults and other
issues.
Note that in some places where immediately after the malloc call is a copy
operation, there is no need for calloc, as all the memory gets overwritten
anyways, but in cases where there may or may not be memory written to (such as
in mraa_file_contains, with reading from a file), even though in most cases the
memory is overwritten, it could be the case that the read operation does
nothing, but the memory still has non-zero values, by virtue of the fact it
wasn't overwritten.
Signed-off-by: Ian Johnson <ijohnson@wolfram.com>
Signed-off-by: Brendan Le Foll <brendan.le.foll@intel.com>
E.g. on Edison they have LFs and that may cause problems
with downstream consumers of this data.
Signed-off-by: Alex Tereschenko <alext.mkrs@gmail.com>
Signed-off-by: Brendan Le Foll <brendan.le.foll@intel.com>
We now take into account only "iio:device*" files to filter out
fake devices like triggers.
Closes#299.
Signed-off-by: Alex Tereschenko <alext.mkrs@gmail.com>
Signed-off-by: Brendan Le Foll <brendan.le.foll@intel.com>
