2-in-1: Moto-Mod doable on OSX (unix) and is there a simple step-by-step?

Are you asking if the firmware development tools work on macOS?

From an application/firmware standpoint, we do have a step by step for setting up a custom Raw channel.  There are also various examples here, as well as the blog posts here.

Yes. I am still going through the requirements list of steps to set up the initial example project.

So far it looks like the Blinky example default installed and I installed the android app.

Question is :

- do I have to install firmware or is the basic RAW channel pre-installed?

- can I do this from OSX or is the android app a better solution for simple data exchange setup between the electronics on the dev module and an android app?

Currently I need minimal data transfer I assume would be an UART comms from the microcontroller I am trying t power and make comms on the back to the app.

Does that make sense?

BTW the 'here' link has no link, will check the examples., not sure simple GPIO is enough for my data transfer. Is ther an UART example? I am surpsirsed the examples have different firmware uploads or are they? wouldnt teh firmware compensate for various data channel setups?

Marcus,

There really isn't a "basic Raw channel" since this is custom for whatever you need.  The Blinky firmware, for instance, uses Raw to pass essentially on/off.  Looking at the termapp example, we're actually using JSON to put some more structure around it and allow sending of commands and GPIO data.  Basically, what you do with Raw is completely up to you.  If you're using Example Mode and Personality Cards, you'll note that different firmware is downloaded as you swap cards (and each has their own application).

We do have OS X instructions that need some verification and documentation, but you can develop and debug your firmware on MacOS.

Given your ask, I definitely recommend looking at the termapp example since this talks/listens to a UART already.  Assuming you're doing custom data, you'll use the Raw channel to transfer data between your Mod and your apk.  Whether this is literal data, or debounced/filtered/fused with other data before transferring to your apk, is up to your design.  For instance, if you were fusing an accelerometer and a gyro, you might perform calculations in the MuC on the Mod and pass up state, rather than every piece of data for your apk to handle. 

"Here" from the previous note linked out just fine for me to: https://developer.motorola.com/build/examples

As for why we have different firmwares, these are embedded systems with limited RAM and flash.  Unlike Linux which contains the kitchen sink and auto-configures based on discovery, you are designing for a much more constrained environment.  There are certainly mechanisms for more dynamic firmware for instances where maybe you use a different part in different hardware revs.

We hope this helps.  Please let us know if there are further questions.

Marcus,

There really isn't a "basic Raw channel" since this is custom for whatever you need.  The Blinky firmware, for instance, uses Raw to pass essentially on/off.  Looking at the termapp example, we're actually using JSON to put some more structure around it and allow sending of commands and GPIO data.  Basically, what you do with Raw is completely up to you.  If you're using Example Mode and Personality Cards, you'll note that different firmware is downloaded as you swap cards (and each has their own application).

We do have OS X instructions that need some verification and documentation, but you can develop and debug your firmware on MacOS.

Given your ask, I definitely recommend looking at the termapp example since this talks/listens to a UART already.  Assuming you're doing custom data, you'll use the Raw channel to transfer data between your Mod and your apk.  Whether this is literal data, or debounced/filtered/fused with other data before transferring to your apk, is up to your design.  For instance, if you were fusing an accelerometer and a gyro, you might perform calculations in the MuC on the Mod and pass up state, rather than every piece of data for your apk to handle. 

"Here" from the previous note linked out just fine for me to: https://developer.motorola.com/build/examples

As for why we have different firmwares, these are embedded systems with limited RAM and flash.  Unlike Linux which contains the kitchen sink and auto-configures based on discovery, you are designing for a much more constrained environment.  There are certainly mechanisms for more dynamic firmware for instances where maybe you use a different part in different hardware revs.

We hope this helps.  Please let us know if there are further questions.