I've been working on a project that utilizes Edison as a central module for three other devices. Each device's sampled data must be processed and then streamed through Edison's Wi-Fi, Bluetooth or serial interfaces.

Since all three devices must communicate with Edison via SPI, I've decided to try and share the SPI bus (same MISO, MOSI and CLK lines) and bit-bang it (as I need frequencies that, according to this, are not viable using MRAA's SPI class).

In this context, I've managed to make the bit-banging SPI work with one of the devices following hints in the aforementioned guide, but have recently thought of porting the SPI code (which I made in C using the Intel System Studio IoT) to the MCU so that I can free the Atom for DSP and the server stuff that will be developed in the future.

So I don't get how exactly this MCU/host interface works. I've wrote simple, back and forth, conditional communication protocol (using pySerial on the host) tests but haven't been able to get consistency out of it. With the host_receive() function, I've tried to use memset() with the receiving buffer after checking conditions, but it messed up the communication.Is there any further documentation than this or examples like this? Any information on how fast can data be transmitted through this interface?

That is an interesting project, looking for information about MCU and I found this:

All information related to the MCU for the Intel® Edison board you can find it in the link that you share us in the previous post (this). According to that, the MCU doesn’t support SPI serial interface, this is mentioned in the section Creating applications with MCU SDK for the Intel® Edison board and the subsection Known limitations.

Additionally, could you please clarify this a little bit more: “I've wrote simple, back and forth, conditional communication protocol (using pySerial on the host) tests but haven't been able to get consistency out of it. With the host_receive() function, I've tried to use memset() with the receiving buffer after checking conditions, but it messed up the communication.”?

I tried to find more information and examples related to the MCU but unfortunately I didn’t find anything. Hope this information helps, I’ll be waiting for your reply.

Thank you for the reply.I've managed the situation and am currently testing the MCU performance.If you don't mind, I'll let this open and come back if I have any further questions. It should be related to the MCU/host interface anyway.

If you are getting stuff done that Intel states can't be done, that would certainly be worth posting as well.

Myself, I would be interested to know the speed of the communication between MCU and CPU. As I understand up to now it might be a UART at 115.2 kb/s. Or is it some nifty shared memory thing? Also I think I read the buffers used are a bit small?

I was considering this for the same reason: let some real time task run on the MCU and do the processing and tcp/ip on the CPU. But I thought it would not be feasible due to the non-real time behavior on the CPU side eventually stalling the MCU due to lack of buffering or otherwise too low speed between the two.

I hope you can tell a bit more about your results, without necessarily going into the details of the purpose of your project?

I ended up testing the gpio_write() function before implementing the bit-banging SPI and couldn't get a reasonable frequency for my project (got results around this using an oscilloscope on a few mini-breakout board ports), so I gave up on the MCU for now.Either way, there are a few tests you could try for the MCU/host interface. I suggest you send returned values from the time_us() function to the host: first get the time interval between calls of this function, then send a single byte in between two calls, and finally send a full buffer (255 bytes) in between two calls. Perhaps you would get a better idea on how fast it is.Also, I suggest you check how this communication interface can mess up both the MCU and the host. It is known that overloading the tty buffer that queues the messages from the host side (and I think from the MCU side too) can make the system unresponsive, but I don't know if simply calling transfer functions too much (like sending single bytes and actually reading it) could reproduce the same behavior.

About shared memory, all I found about it is this. There doesn't seem to be a lot of documentation on it and it probably won't be accessible. I believe the /dev/ttymcu2 interface might have something to do with it.

Not sure I could help you, but feel free to ask if you need.If you test and get any results, please, do share them.