Okay, I'll take the trolls bait...
What are you trying to do with the board? Have you at least upgraded the firmware to the latest version? Have you tried installing the debian distribution on it? With debian you get a wealth of packages that are just an apt-get away.
You say "I do not mean to rant", but that's all you did. You didn't any any (non rhetorical) questions.
BTW, this is not a general purpose Linux computer. It's an embedded module. Maybe you should buy an RPi, or a Beaglebone Black instead if you just want to see what USB devices you can plug in.
I'll bite again, what is your background - I mean I come at the Edison -- with mini breakout board -- from the angle of a programmer. I have my micro servers running on it, connecting data sources -- pumping that over the net to another Edison. And I am having fun. No, I might not have all the electronic engineering, so I have someone on my team assist in that area, and the help from the awesome group here on the forum. Also using the tools provided by Intel, I am all but limited to what I can dream up. faceplant a general purpose Linux server is pretty much what I have going on so far, adding "smarts" to the projects.
there is a lot of help through out the forums,
Did you upgrade the firmware?
Did you go through the Getting started guide
what have you tried so far? how far did you get?
and coding? Did you know the gcc compiler is on board - access it via the console? Make any programs you want.
And I don't do _any_duino_ coding when I program mine (Pascal with Kylix3 and C/C++)
Sorry, I just can't see a Nano being able to do all the Edison does No offense intended to the Nanos
If you pose your position in the form of a Question, the guys on the forum can answer most of your questions.
However, are you really looking for answers? And then maybe the sophistication of Edison isn't for everyone.
Mini Breakout board contains:
power button reset/sleep button
J1 and J2 - Lipo battery goes in J2, thermal goes to J1
J21 for external power 7V-15V DC
J3 for console over microUSB B
J16 for power over microUSB B or using the OTG port requiring a microUSB A
Direct 1.8V pins of the Edison module exposed through 56 pins on the bottom.
1 of 1 people found this helpful
For a maker, the Edison w/Breakout board is a good starting point, however there are a few caveats. In an effort to be completely fair and unbiased, I'll address the OP's points below.
I will yield that the documentation is lackluster. The information provided is indeed enough to get most people bootstrapped with designing a project, those amongst us who have any modicum of experience know that developing a real product centered around the Edison is a dangerous game at the moment. While I am more than willing to tinker with the device and build some prototypes, I will in no way expend financial resources, or even time, on designing a board to send off to a fab prior to intel clearing up some of the fog on the battlefield.
While you do need to dig around on the intel site to find schematics and user/programming guides, they aren't exactly hidden. A more polished product would have included documentation WITH the product. I feel that in today's market, this is an expectation for most folks. A maker should be used to digging around for datasheets and whatnot, but a packaged product like this should ship with enough information to get the future maker's nerves tingling. But instead of providing the budding maker with a veritable nerdgasm, intel just pulls out and leaves the user with an "empty box".
Verdict: coitus interruptus
I don't mean to bash the intel folks here, especially since they have provided us with a very interesting product, but I must be fair to the community. Intel changed the spec of the Edison recently to accommodate the IoT crowd with the inclusion of a dedicated MCU on board. This was the feature that grabbed my attention and set off my nerd-radar. For a vast majority of my projects, I need realtime control, and sometimes even an RTOS isn't good enough, so the first revisions of the Edison was out of the picture. But what of this MCU? Where is the documentation on the intel site? *spoiler alert* it doesn't exist *spoiler alert*
I can fully understand if intel is somehow under some NDA with regards to the MCU. I cannot imagine how, since intel wouldn't likely license the tech from anyone such as ARM, but still, it might happen. What I cannot understand, however, is how intel is refusing to provide the community with the basics. How does the MCU interface with the CPU? Does the MCU share the memory with the host system? Are the GPIO pins somehow muxed to allow configurable access to the MCU and CPU? Without this critical information, a hardware designer cannot move forward with design since it is impossible to determine how the MCU will be broken out to the Hirose DF40 connector on the module. I suppose one COULD throw the IO into an FPGA and remap the pins via software if/when software is ever released, but what is the use of building hardware that cannot currently be tested? We simply cannot access the MCU at the moment, and there isn't even enough documentation online to explain why.
Example: I have TWO Edison modules in my possession. They have different markings. I have ZERO way to tell which, if either, has the MCU core.
Verdict: MCU composed of dark matter.
This is where things get painful to watch. I've seen intel representatives provide incorrect information via the forums that can, and has, resulted in damage to the product. I'm not talking about incorrect memory specs or clock frequencies... I'm talking about the basics: DC input polarity. While the representatives have been responsible enough to remove the offending posts, such mistakes should have been avoided in the first place. Granted, it is prudent to always verify polarity by checking ground continuity with a DMM, some folks will just take an answer from an authoritative source and run with it. But seriously intel, would it have killed you to put silkscreened polarity on the breakout board? Pin 2 is marked for J21 and J2, but it would have been just as easy to mark the correct pin with a '+' to eliminate all confusion.
In other matters, it is evident that the intel representatives moderating the Edison section of the forums have limited experience with the device. I cannot count the number of times that I have seen "I don't know the answer to this, but will look into it" posted as a response to a question that should be answerable via basic datasheets (going back to documentation). In other cases, "We cannot answer this question at the time" is the response. At least provide a "why" as to the "cannot". Is it due to legal/NDA, or is it because the representatives attempting to answer such questions have access to the same limited documentation that the rest of us do?
Verdict: Consult your Magic 8-ball for more reliable information.
Once you have digested the vitriol expounded above, you'd be apt to assume that I would steer people well clear of this product. You'd be partially correct. While I would tell a person of questionable skills to treat the Edison as the iceberg to their Titanic, I would tell a skilled and inquisitive person to take off their life jacket and dive right in... sharks and all. The saving grace when it comes to the product is the build quality, features, and cost.
The build quality of the Edison module itself is great. Intel was kind enough to provide links to the mating connector needed to design a board to work with the Edison. The pinout of this connector is documented on Intel's site. There is no confusing silkscreen to lead people down the road of hooking a battery up backwards in a futile attempt to run the system clock backwards and send the module back in time to fix the horrific decision to not properly document the product at release time. The inclusion of WiFi, 5GHz at that, and bluetooth was a great decision. The inclusion of an external WiFi antenna connector is a huge plus. The incredibly small size is a turn-on. The fact that the device is dual core AND x86 compatible is amazeballs. The realization that the tiny module also has 1GB of RAM and 4GB of flash connected via an eMMC interface caused my brain to explode. The ultra low power consumption fueled by 22nm lithography means happy batteries everywhere. In short, if you want a wearable linux computer to cram into some inconspicuous place for your next wearable project, this is the most attractive product out there at the moment.
Verdict: Amazing wearable linux computer.
The price tag on this thing is quite reasonable. The Edison has more GPIO than a Raspberry Pi. The Edison uses much less power than a Raspberry Pi, and even includes a 1-cell LiPo charging circuit. The Edison is much smaller than a Raspberry Pi. Compared to the Raspberry Pi, the Edison has built in 4GB flash for the O/S, and twice as much RAM. This is all offset by the loss of audio and video output, as well as the loss of a wired ethernet jack. But considering that the RPi's ethernet jack is a USB peripheral and limited to 100mbps, this is hardly a loss. Is this all worth the $15 increase in price, if you buy the BreakoutBoard with the Edison? I certainly think so.
Verdict: Intel could probably jack the price up a bit and still attract people to the product.
The OP hinted on this topic, and it does need to be addressed. Even with a breakout board, one must deal with the 1.8V logic of the Edison module. Difficult? Sure. End of the world? Probably not.
The need for using logic level shifters for just about everything kinda sucks. I'll concede that point. Not only does it increase the cost of boards that are designed to run with the Edison module, it increases the complexity of troubleshooting. Is your level shifter I2C compatible? This can get tricky, especially for peripherals requiring pullup resistors on the GPIO. That said, there is a trend towards 1.8V logic in the community, so things will only get easier in time.
Verdict: Mosfets... mosfets everywhere...
The breakout board provides a USB OTG connection. While this is great if you are using the device powered by a DC input source exceeding 5V, it sucks hard that intel did not put a boost IC onto the board to provide USB support while running from a LiPo connected to the built-in charging circuit. Provided that input power is sufficient, however, there should not be any issue with connecting USB devices as long as the kernel supports the device. Now as for compiling the kernel to add device support, that may or may not be a difficult task. I have not attempted it. USB keyboard/mouse should work just fine though, as should USB storage.
Verdict: Compiling kernel may be needed for communication with some USB. But hey, try getting that device to work with an Arduino Nano...
Regarding packages in general, I've had no issues grabbing packages with the debian-based ubilinux installation on my Edison. As a gentoo user, I prefer compiling from source and using the portage package manager, so compiling packages from source, where needed, hardly puts me off. As for the intel-shipped Yocto image, I never tried adding software to it.
Verdict: Lots of packages available to debian. Yocto: YMMV.
This gets kinda fun. I never had an issue with using the Yocto image which shipped with functional wpa_supplicant installation. I connected to 2.4 and 5GHz APs and never once had an issue.
The debian install, however, left much to be desired. Tossing the wifi credentials into the /etc/network/interfaces file worked, but that only allows you to connect to a single AP. Boring... Once wpa_supplicant was installed in Debian, stuff got exceedingly frustrating. The device never connected automagically on bootup. If I issued an ifup --force wlan0 after the device was booted, it always connected just fine. Eventually I gave up on wpa_supplicant from within the debian image and settled with installing wicd-curses. Since doing so, the Edison has connected to WiFi every time after reboot, although it takes a full minute after coming up before IP connectivity is established.
Verdict: Hardware good. Debian WiFi derp...
The OP has a point regarding documentation and support. The hardware, however, is feature rich and offered at a decent price point. The Edison should excel in the IoT world for a while, provided that intel can grow a healthy online community that backs the product. The lack of support and documentation, however, is salting that earth instead of fertilizing it. Short-term forecast: clear and sunny. Long-term forecast: hazy and uncertain, with a chance of extended drought.
1 of 1 people found this helpful
I'll toss a piece of info, if you'd like to add a correction to your article. The Quark, though it seem shrouded in mystery on the Edison, is not an Arm. If I read the specs, it is a 100 MHz Pentium class, single core, single threaded processor reduced to the 22 nm level, complete with the nostalgic floating point bug. So for those of us that have been programming for desktops for an era, there is less mystery surrounding the chip. Also noteworthy is the massive amounts of Arduino like code for this Quark. ... again, I'll toss a hint ... Galileo!
So in my opinion, the yet to come interesting aspect of Edison, which I see has already attracted an arduino based maker crowd as well as the traditional desktop and server programming crowd to the same item .. is how do they unveil the platform that allows the Quark part of the System On Chip to play with the Atom portion. And as you have seen, we are getting better as Makers in dealing with the Atom portion without tripping over a multi processor, multi operating system Edison.
I realize that the Quark is not an ARM device. I only mentioned ARM because ARM doesn't make chips, they license the designs. The lack of information from intel on the Quark within the Edison is disturbing, but could be attributed to an NDA if intel had licensed the tech. Your clarification kinda eliminates that possibility if it is true, that being that it is simply a pentium class part that was shrunk from the original (and defective) die. The floating point bug doesn't really put me off, there are ways around that problem.
My concern is that, as a maker, I cannot design boards for this thing because there is no way to know how the GPIO is muxed between the CPU and MCU. I could, for instance, assign GPIO 8 through 13 for my boards, hoping that they are tied to the MCU, but if intel later releases information stating that only pins 1 and 2 are tied to the MCU directly, then I am screwed. Ideally we would have documentation by now indicating which GPIO pins are tied to specific peripherals of the MCU, but from your description of it being a Pentium, there really aren't any peripherals to speak of.
As pointed out in other threads on the forum, Intel is looking to provide the access to Quark in an upcoming release, "hopefully before the end of the year", so I am confident that it is forth coming and appreciate the amount of effort to test and then document well so that it satisfies the many facets of this group.
ARK | Intel® Quark™ SoC X1000 (16K Cache, 400 MHz) ... and the Galileo forums clearly show that once accessed, it is a very powerful component already included on the Edison SoC.
As a maker, I could say that I also faced a similar type of concern of the unknown, so I can relate. The realization of board designs change. Myself, I will probably implement v1 with the capabilities I have now, and v2 with extended capabilities I'll have later. And if I am at a point where my mass production relies so heavily on me knowing, I am sure I would have already signed any NDAs required and possibly selected other chips and components to suit. You begin to worry about board design, that is a level where the designers (including your embedded engineers at Intel) are more than capable of working those things out.
I don't see gravemind post as trolling, but I have to admit he looks like he gave up (not really interested in answer to his questions/problems). I feel some of the concern people expressed here, but I'm pretty excited with Edison capabilities anyway, I had an SmartFusion2 SOM from Emcraft (with ucLinux) and it was really a pain compared to the Edison, which is working really well for me so far. I hope Edison future will be bright and I would be happy it it's still around in 3-5 years. Module like this one takes some time to understand fully and I would really like in the next year to be able to create my own PCB and embed an Edison on it. Also, it's nice that the module is being updated regularly with software updated and that Bluetooth support will keep getting better and that we will have Quark access sooner or later. I like it because I'm sure it will make me come back to work with the Edison each time that there is a new feature for me to try. *sorry if some of you have difficulties understanding what I mean, English is my second language.
speccy88 I haven't given up but I simply don't have the time to debug the board just to get started with it. And also I have done everything I could including upgrading firmware, trying different flavors of linux, etc. I am already in the finishing steps of my project using PI compute module. I chose the Edison because of its form factor. I just feel that Intel should change their strategy and make boards that are prototype friendly and people don't have to go reinventing the wheel just because Intel wants to do things differently. I am more happy working on my project than to probe the capabilities and functions of Intel's design. Intel should realize that designers don't really need 1GB LPDDR3, 4 GB EMMC, and dual-band WiFi and BTLE just to blink a few Leds or communicate hello sigs over wifi.
Intel should realize that designers don't really need 1GB LPDDR3, 4 GB EMMC, and dual-band WiFi and BTLE just to blink a few Leds or communicate hello sigs over wifi.
I think they realize exactly what is needed.
As we step into the next few years, there will be a massive proliferation of IoT devices. You cannot have IoT without the 'I', and let's face it, using ethernet cables to connect every gadget in your house is just plain retarded. WiFi is a must. At least intel gave us an ABGN device, and we can talk to 5GHz APs to leverage that bandwidth.
1GB LPDDR3? That is a massive overkill for an MCU for most cases, but the Edison is a linux device with a CPU and an embedded MCU that is yet to be rendered accessible via software. 1GB is absolutely needed for linux, and I've slammed right into the 512MB wall of the RPi so many times that I'm beginning to think that I'm the Kool-Aid man. But hey, if swapping to flash media is your thing, the Pi is cheap and omnipresent.
4GB eMMC? So much faster than SDIO. Not to mention more reliable. I can't count the number of times my RPi devices have barfed when trying to do I/O with a class 10 card... I've popped these same class 10 cards into my AriaG25, a device with much less power than the Pi, and holy ****, they have been working fine for over a year. I've never gotten over 23.8MB/s sustained writes from the Pi. My Aria G25 has gotten 49.3MB/s sustained writes onto an SD card that the Pi won't even recognize or boot from. The Pi is cheap and available, but it has serious limitations.
My only gripes right now with the Edison are:
- intel doesn't even seem to know their own product. There is ongoing debate as to whether the device is a 32bit or 64bit part. This is epic hilarity in my book.
- intel hasn't documented the product to the extent that they should have. We SHOULD have complete schematics for the breakout and arduino boards, especially for troubleshooting. Eagle BRD files, or equivalents would be amazing, but one thing at a time.
- 4GB eMMC really should have been 16GB or more. 4GB will eventually force many projects to use an external SD card or network based storage.
- That bloody MCU. We should know how it will be leveraged once the software is available, but right now, no one appears to know anything at all. I've done similar things with my AriaG25, where i've attached an STM32F4 family MCU via GPIO, and I can definitely speak to the capacity of a hybrid system with a CPU and an MCU. The fact that the Edison product was put to market prior to exposing the MCU is kinda derp, in my opinion.
- Ancient kernel. We should have a github repo made available with the current WIP kernels.
@faceplant I have ordered the ARIETTA-G25-256 myself today just to check if I am somehow able to replace the PI compute. But my earlier comment meant to say to Intel if you are providing such massive specs on a SoM then make sure that programmers and designers get access to that processing power with ease. And as you said about IOT proliferation but the same case can be made about USB proliferation. If a device truly wants to be at the forefront of IOT a USB host mode is a must in my opinion.