The Edison 'module' contains both a dual core Atom processor and a single core quark (that can be used as a mcu).
Good, I've seen conflicting documentation on that. (P.S. The Hardware guide HG_331189-001 makes no mention of the MCU.)
How do the two communicate? It appears that the CPU has the ability to directly affect the GPIO, but is there a currently a method to exchange data between the two?
Wait, this doesn't jibe with what I saw in the ordering guide. They list two different models of Edison on Mouser.
One is the EDI1.SPON.AL.S and the other is EDI1.LPON.AL.MP . These are the intel part numbers, I think someone on intel needs to figure out what is up... I don't seem to understand why one board needs 8 part numbers.
So my question is, if there are two devices, how do they communicate? How does the Quark get its firmware loaded?
My understanding is the Quark processor and the Atom processor are on the same die. A bit like some processor from TI with cortex A15 and cortex M4, or Vhybrid from Freescale with Cortex A5 and Cortex M4. May be someone from Intel can confirm this ?
We need the Z34XX datasheet to know how to use this architecture efficiently, I saw on another thread this datasheet would be available "soon". I understand Intel rushed the output of the Edison module, some documentation is still in the pipe. But the sooner it's available the better.
I guess some people would also like to program this bare metal without a Linux in the way, it may be difficult to use the wifi module like that but I can see few cases where the lower latency would be benificial.
If that is the case, then they should not have it as two separate bullet items on their page.
Ultimately it doesn't matter. There should be something to clear this up.
It would be a good decision to do this, especially if the Quark was tasked with GPIO and nothing else. This would put the whole device as an actual competitor to the arduino. With no video, and a more expensive price tag, it is a non competitor to the pi.
Better try on this version at least. I still would like to have one, its just too bad the PCIe, ethernet and video got tanked.
Now they should release the CPU to the world for review.
A ton of documentation is still in the pipeline, as you mention. The team that develops Edison isn't very big, but we react pretty quickly. If there are specifics around what you'd like, we can probably answer in the thread - but we'll get it documented too. Feedback helps us do this well - please be vocal.
I'm no expert on the part numbers, but this appears to be two of the SKU's I'm familiar with: one for wearables, and one for IoT applications. I'm not as intimate with the wearable feature set, but I seem to remember it operating in a lower connected power envelope. Let me clarify with the team and I'll get back to you.
Also, I'm pretty sure they're on the same die - but I'll confirm with HW team (I'm more of a SW guy on this project).
in the Merriefield SOC there are:
3. Dual core Silvermont.
The Puinit is internal and a big mystery ever around here.
The SCU is and interface that starts the system and controls some the the internal interfaces and starts the BIOS or equivalent.
The Silvermont is the real processor. It may make I/O requests to the SCU (we use IPC calls, I believe there is a mialbox in ram). The SCU may ore may not process the request depending on sercurity policies or other things.
John Kabat (Intel)
Amazingly as we get more information it becomes less clear, or is it just me ?
What I'd like to know and I suspect many other potential users is :
Is there a quark processor on the same die as the atom processor Yes  No
Is it possible to program the potential Quark processor Yes  No
Will the complete datasheet with enough information for bare metal programming be available Yes No
Is there a quark processor on the same die as the atom processor: It's part of the same SoC
Is it possible to program the potential Quark processor: I'm not sure if support for this is integrated - I will check with the team.
Will the complete datasheet with enough information for bare metal programming be available: Yes, I started this work in another thread and the team is generating it now.
I had made the (possibly bad) assumption that the "Arduino" programming was in the quark. Is that not the case?
The Arduino stack sits on top of the Yocto Linux layer - it's just an application living in user space.
When you push a sketch, you're actually just pushing a binary into Yocto for execution.
Thanks for the answers, this cleared a lot up for me.
Does the arduino stack have special priority? The reason I was hoping you could program the quark is because things like control sytems (robotics/drones/etc). Should I go RTOS for the edison in this case, or will this arduino stack handle timing critical components?