one of these for user use and so when this is the case, libmraa will always use
the bus in the pinmapper. For example edison uses i2c #6 but since there is
only one, libmraa will try to be helpful and everything is treated as 6 when
-doing a mraa_i2c_init and so when this is the case, libmraa will always use the
-bus in the pinmapper. For example edison uses i2c #6 but since there is only
-one, libmraa will try to be helpful and everything is treated as 6 when doing a
-mraa_i2c_init(). The _raw functions will override the pinmapper and can be
-accessed without a valid board configuration. This can be helpful either in
+doing a mraa_i2c_init(). The _raw functions will override the pinmapper and can
+be accessed without a valid board configuration. This can be helpful either in
development of platform configurations for mraa or when modifying kernels
-etc... The mechanism is used heavily internaly.
+etc... Internally the mechanism is used heavily.
In libmraa, all code is split into 7 modules, src/{i2c, spi, gpio, uart, pwm,
aio and common}. These should be fairly self explanatory in goals/purpose but a
The mraa_pininfo_t structure needs to be set for the board pincount (set in a
macro in the platform configuration header. Every pin will have a
-mraa_pincapabilities_t which will define what it can do. The doxygen doc
-explains how this works but it's essentially a bitfield which needs to be set
-for every capability the pin can have. Gpios can have multiple muxes which will
-be set at the gpio init before it can be toggled.
+mraa_pincapabilities_t which will define what it can do. The doxygen
+documentation explains how this works but it's essentially a bitfield which
+needs to be set for every capability the pin can have. Gpios can have multiple
+muxes which will be set at the gpio init before it can be toggled.
### i2c ###
conditions that can arrise when writing on i2c buses. Essentially the API is
fairly simple consisting of writes & reads.
-Careful - on alot of platforms i2cdetect will often crash, for finding your i2c
-addresses please look at your sensors datasheet!
+Careful - on alot of platforms i2cdetect will often crash. To findi your i2c
+addresses please look at your sensor's datasheet! If using i2cdetect most
+platforms do not support SMBus quick write so use the '-r' flag.
### spi ###
spidev5.2. Typically on a micro using a random gpio as a chip select works
well, and on some platforms if one is careful with threads this can work well
with mraa. However when a kernel module shares the same bus as spidev (but on a
-different CS) this behaviour is *very* dangerous. Platforms such as galileo
-gen2 & edison + arduino breakout work this way. Mraa will not help you in using
-a non HW chip select, do so at your own peril!
+different CS) this behaviour is *very* dangerous. Platforms such as Galileo
+Gen2 & Edison + Arduino breakout board work this way. Mraa will not help you in
+using a non hardware chip select, do so at your own peril!
### gpio ###
GPIOs are typically interfaced via sysfs because that's easier for us but we
can also work with fast gpio. This is typically preffered to do mmap gpio
access. This is however trickier and typically relies on lots of platform
-hooks. We do support by default to go hit /dev/mem or another device at
-specific addresses to toggle gpios which is how mmap access works on some
-boards.
+hooks. By default we support hitting /dev/mem or another device at specific
+addresses to toggle gpios which is how mmap access works on some boards.
Note that in Linux gpios are numbered from ARCH_NR_GPIOS down. This means that
if ARCH_NR_GPIOS is changed, the gpio numbering will change. In 3.18+ the
### aio ###
-AIO pins are numbered after GPIO pins. This means that on arduino style boards
+AIO pins are numbered after GPIO pins. This means that on Arduino style boards
pin 14 is A0. Typically mraa will only support an ADC if a platform ships with
-one and has a good kernel module for it. extra i2c/spi ADCs can be supported
+one and has a good kernel module for it. Extra i2c/spi ADCs can be supported
via something like UPM but are unlikely to receive support in mraa at the moment.
Note that giving mraa_aio_init(0) will literally query the pinmapper for
board->gpio_count + 0 so you must place your aio pins after gpio_count. This is
the default behaviour but can of course be overriden by advance function
pointers. Whilst maybe not the sanest of defaults, most of the hobbyist boards
-we deal with follow a similar naming pattern to arduino or have no ADC so for
+we deal with follow a naming pattern similar to Arduino or have no ADC so for
now we have considered this sensible.
### Initialisation ###
mraa_init() needs to be called in order to initialise the platform files or
'pinmap'. Because calling this is tedious libmraa uses a C constructor to run
mraa_init on library load. This means that it is not possible to stop this
-running and all functino calls like mraa_set_log_level() will not work during
-mraa_init(). This feature is supported by most sane compilers & libcs but you
+running and all function calls like mraa_set_log_level() will not work during
+mraa_init(). This feature is supported by most sane compilers and libcs but you
can turn off CTORS in uclibc, though I've yet to find a configuration with
someone doing that. mraa_init() can be called multiple times if you feel like
being 'safe'.
-In the SWIG modulse mraa_init() is called during the %init stage of the module
+In the SWIG modules mraa_init() is called during the %init stage of the module
loading. This is simply to avoid mraa_init() running 'too' early, though I've
never seen an issue in running it in a CTOR.
At the time when libmraa was created (still the case?) the only - working -
API/wrapper generation tool that supported nodejs was SWIG. For more general
-information on swig please see the swig documentation.
+information on SWIG please see the SWIG documentation.
The src/{javascript, python} & src/mraa.i folders contain all the files for the
-swig generation. The C++ headers in api/mraa/ are given as input sources to
+SWIG generation. The C++ headers in api/mraa/ are given as input sources to
SWIG. SWIG modules do not link to libmraa (although maybe that would be a good
idea...)
Typemaps are used heavily to map uint8_t* pointers to bytearrays and
-node_buffers. These are native python & nodejs types that represent uint8_t
+node_buffers. These are native python & node.js types that represent uint8_t
data the best and are very well supported in both languages. Argument
conversions and memory allocations are performed so the performance of using
these functions compared to the C/C++ equivalent will likely be a little lower,
src/javascript. Because we don't expect most NPM users to have SWIG we
precompile the src/mraajsJAVASCRIPT_wrap.cxx. The src/version.c is already
known since this is a static tarball so we write that too. These files are
-placed not in a build/ dir but in the main mraa dir. You can then tar the dir
-up and send it to NPM. This is done automatically on every commit by our
-automated build system.
+placed not in a build/ directory but in the main mraa directory. You can then
+tar the directory up and send it to NPM. This is done automatically on every
+commit by our automated build system.
projects / contrib / mraa.git / blobdiff