HI and welcome to the forum.
Edison on mini-breakout board will be a good choice.
The easiest way to get started is as follows:
Use 2 x Mini USB cables to connect your Mini Breakout Board to a computer.
One of them will appear as a Serial (COM) Port
The other will appear as various devices while the Edison boots, and eventually settle down to being an external drive that you can read/write to.
Using the connection that comes up as a serial port you can "Log on" to your edison using a terminal emulator - On windows something like terraterm or Hyper Terminal or similar.
The user name is "root" and there is no password to begin with.
Once you get logged on, enable wifi and set a password. By using these commands:
Once you've done that you can login across a network using PuTTY or ssh or similar.
As for programming, you can use various languages including, but not limited, to:
C / C++
One thing you should understand from the outset - all I/O Pins on the edison work at 1.8 V not the more usual 3.3 V or 5 V
If you are interfacing to other devices, make sure you use a level shifter, or that they can work at 1.8 V
Finally - don't struggle on your own! Come back here and ask questions!
Hi, thanks, I have setup and got my Edison running. I need help though on the MCU which is the quark core, that requires different setup. Anyone know if the guide from intel correlates to the mini breakout board.
I'm not sure I understand what you mean.
The Edison is a compute module - ie a Full Computer, with processor, Ram, Flash, an operating system, peripherals and IO.
The breakout board is purely passive, it has no active components (other than a Serial-To-USB convertor to make it easier to access the console).
Can you give an example of what kind of task you need help with?
The SoC have 3 cores, dual core atom(2x500mHz, OS) and a quark core(100mHz, real time) which is a MCU. Problem is that quark guide on the intel guides only show it being used with the arduino breakout board, while I have the mini breakout board. So i am wondering if the setup is the same as using it with the arduino board or are there differences. Thanks.
P.S: Here the link to their guide(Creating applications with the MCU SDK for the Intel® Edison board | Intel® Software ).
Hi that the documentation I referred to but I am not sure if it works the same for the mini breakout board as it shows using the arduino board.
This message was posted on behalf of Intel Corporation
Thank you for your interest in the Intel® Edison Breakout Board.
The document that you refer to is intented for creating applications with the MCU that is present in any of the Edison boards, which means that you can use your Mini Breakout Board.
I hope you find the previous information useful.
Have a nice day.
Instead of using the MCU, you might try installing a real time linux kernel. That should give you about < 1ms latencies.
I have tried to make that as easy as possible GitHub - htot/meta-intel-edison: Here is the meta-intel-edison that builds, tries to stay up to date and provides a PREE…
thanks will try it out.
Hey you got me interested, how does this differ from Preempt-RT patch?(sorry didn't read the description properly, exam week lack of sleep)
I am currently working with the latest image of yocto image provided by intel and I am using python to control my sensor and 4 Arduino on an i2c bus. The thing is I need it to be able to read data from my sensor and get them to my pro mini as soon as possible without the OS or python interrupting it in between. I am also planning to either do machine learning on it or stream the data from the sensors out to a computer and do it and have it send back once it done. Which would you recommend, using the SoC or using a RT kernel?
Thanks in advance,
Actually the 'SoC' contains a MCU and a dual core CPU. SO you will always be using the SoC. But I think you mean use the MCU with functionally limited RTOS or use the CPU with linux RT.
I don't know for your project, but we concluded that the data eventually needs to be communicated from the MCU to the CPU and this creates a new RT bottleneck (the channel is slow and the CPU still has the same latency). So, instead we tried the rt_preempt patch.
Yes, I mean the MCU, and thanks for the detail explanation.
For my project, I kind of needed to get the about 8 current sensor's reading from the i2c slaves to the respective Arduino pro mini while their control their own set of servos at a timely manner. I was trying to make not implement multi-master into the project as it may further complicate the project, or should I?
For me, my most important deadlines are synchronizing the 4 Arduino pro mini on their control over the servos i control, getting their respective current sensor reading back to the Arduino pro mini to process and read from other sensors variable that may be store on the pro minis at a timely manner, streaming data to a higher level processing unit(like a computer) to do machine learning and get the results back to the intel Edison so that appropriate controls over the servo can be taken. Does the above requires a separate MCU handling some of the load while the main dual core does handles something else or would RT-kernel do just fine?
Does the rt-layer you link requires yocto 1.6.x or can it be done with the newest yocto image given by intel?
Thanks in advance,
It hard to say what is the best solution for you.
The layer I provide currently is just the modified layer that Intel created to build ~ the image 2.1. The image 3.5 that is currently provided by Intel will not build without modifications, you can find that elsewhere on this forum.
You need yocto (or should I say poky) 1.7.2 (dizzy), the same as with the original Intel layers. I am working to move to morty , but that needs testing.
Or, if you don't want to flash the whole image, you could just build the kernel, boot that with the old rootfs.