One of the first controllers I played around with was the BASIC stamp, by Parallax.
There is no single word for the horrible, utterly disgusting, nasty setup that these things required. There is some sort of tokenizer for Linux that kind of makes the required upload. The GUI is BAD. And when they had serial interfaces, you had to buy a USB-RS232 from them because they did screwy shit.
Thank the gods for the Arduino. Working with that cheap microcontroller is pleasant.
Actually, at the time the original BASIC Stamp was released (early 90s), programming a microcontroller directly from your serial port was a huge improvement. Most microcontrollers back then required a separate, expensive programming board, in addition to non-free programming software. You also had to remove most microcontrollers from your circuit to program them.
I agree that by today's standards, programming via serial port is cumbersome, but it's actually a good thing that the STAMPs are still available because they are used in a _ton_ of embedded applications that are still in use and need maintenance and replacement parts.
My dad had a few of these. One I distinctly remember was a 2 part combo. To write, you put the chip in a ZIF socket (he changed this from a socketed to ZIF) in a huge metal box, and what looks like a parallel port to the computer. Then, you realize that wasnt a parallel socket, but something going to an 8bit ISA card.
To erase, you had to untape the window and put the chip in a UV box for a few hours.
Newly-minted video game prototype collectors over the past decade have found themselves wondering why one-of-a-kind games in their collection kept coming up unreadable although they were perfectly usable when they first purchased the cartridge. In most cases, it's because they found themselves fiddling with the EPROM window and/or carelessly storing the cartridge until bit rot ran its course.
There was plenty of benefit to EPROMs back in the day to a developer, but long-term data retention was certainly not one of them.
This reminds me a lot of programming EPROMs for the BBC Micro back in the 80s. Several people (including me) brought one of their ROM sockets out to a ZIF socket on the side of the keyboard.
Very cool. I'm building a new HW project, based on the Raspberry Pi, and I'm always looking for options that are similarly sized, but pack a bit more power ;)
The thing I wonder for things like this, though, is at what quantity I can get them, and what the reliability looks like.
One of the things I like about the Pi is that it's well tested - Even if it's a bit slower, they're making 4K of them per day, and everyone's using one, helping map out the gotchas, etc.. If you go with a lesser known board, you're a lot more on your own..
The rpi is far more than a bit slower, more than the cores and clock counts imply. The pi is a slower microarch and is cache deprived too.
For somethings this doesn't matter but many of those things should probably be done on a proper microcontroller.
The odroid stuff appears to have a lot of users too, and these devices are less 'weird' than the rpi— they're more like the pandaboard and beagleboard— so there are less sharp edges to figure out.
That's why I'm hoping the next-gen Raspberry Pi will be 64-bit based on Cortex A53. They should skip the ARMv7 architecture and jump from ARMv6 to ARMV8. It should make things easier for the people maintaining the Raspbian OS,too, if they didn't have to support 3 architectures at once.
I have been assuming that it's most likely they won't make another board - or at least not another design.
I assume that, because in that case - they'd be fanfaring a lot more about how their newer design is being worked on. I'm seeing that they're more focusing on developing the userbase and utilities of the current board.
ie. with expansion cards, refining the software stack and such.
It's only 10/100 Ethernet, I can't see it being limited too much by the Bus speed. I've tested an apple-branded USB 10/100 Ethernet adapter at ~98Mbit on a beaglebone.
Right. USB 2.0 is already packetized with a MTU larger than ethernet already. The net overhead for the USB stack is near zero. It's true that fancy ethernet devices can do things like TCP or encryption offload, scatter-gather DMA for zero-copy transfers, etc... And clearly this isn't going to do that stuff. But if all you want is to get packets on and off the wire, there's nothing wrond with USB 2.0 Hi-Speed.
(FWIW: that apple-branded adapter is almost certainly an ASIX part -- the same chipset is sold under dozens of brands and works quite well in my experience.)
This one caught my eye. I'm not sure if the i.MX 6 quad is as capable as the exynos and there's only 1GB of RAM, but the board has SATA (there's a controller built into the SoC AFAICT) and Gigabit ethernet on an RGMII interface. Not that I really know what that means, other than I'm guessing a dedicated, gigabit-capable interface on the SoC. There's also PCIe which they're apparently going to release a breakout daughter-board for at some point.
Of course this board is not all that cheap compared to the ODROID.
I received mine about a month after I backed the indiegogo campaign. They shipped mine using DHL and it arrived before they sent me the tracking number.
Shouldn't be a big deal so long as it's got a decent USB controller. The reason the Raspberry Pi has so many issues with USB and excessive CPU usage is that the onboard USB controller is really dumb and mostly implemented in software.
I've got a Linaro build running on mine. (It arrived on the 24th, so I had a good Christmas!) it's actually stable overclocked to 2GHz and the Mali in it is also stable at 800MHz.
Could you comment on getting Linux up and running with the ODROID boards? I'm thinking of using one of them for a hardware project and even though I haven't really looked into it yet, it seemed to me that a full blown distro was not ready yet.
Well, I had a bit of a fuss as they are using ARM TrustZone, so the 3.0.15 kernel didn't want to compile with a newer gcc than the one that Hardkernel uses by default (CodeSourcery 2010q1 - which translates to roughly GCC 4.4.1 with their extras.) - through the help of a friend that is patched up (but sadly breaks it building with CodeSourcery (heh) - patch is at https://gists.github.com/4395518 - that will let you build with GCC 4.6.3 (Linaro/Ubuntu defaults) - if you want to build with 4.7.2, you will also need to edit line 234 of drivers/video/samsung/s3cfb.h and remove the inline.
After that, it's just like every other rootfs. I focus on Gentoo, so other distros... I don't know, but they will have an Ubuntu image up soon.
There are no graphics until X though, so you're stuck with ssh or serial console until then.
Kernel sources come from the BSP download on hardkernel's site. Should be a tarball in there named kernel_4412.tar.gz
The problem with all those board - except rapsberry pi is that there are no proper gpu hardware drivers for them - at least under linux. So one can't build linux based XBMC media centre on them to play HD movies :(
When it comes tocheap boards only r-pi can do this, other boards can only do this when you use Android on them :(
Depends on what you mean by "proper" drivers. The GPU drivers for the Raspberry Pi, like the drivers for most other development boards, consist of an open-source shim and a closed-source userspace blob [1].
HD decoding on these boards is performed using a digital signal processor (DSP) integrated into the SOC, the CPU (even with GPU support) is too slow for 1080P h264 Content. This is not specific to Android, for example TI supports use of the DSP of the Pandaboard on Linux as well [2] (it is still not very stable, at least on the OMAP 4430 version of the Pandaboard).
yes - but for exynos or allwinner 10 you dont even have that shim :( - thats what i meant - you basicly cant run XBMC on linux on those with acceptable performance as of today.
Im hoping this situation will change soon, but it looks like there is no interest by soc vendors to provide necessary tools.
I know this works on pandaboard and some others, but those boards are about 150$ range if i remember correctly.
Hmm Allwinner A1X and Exynos 4412 both have integrated Mali 400 GPUs, so there should be at least some GPU support on Linux [1].
There is an unofficial XBMC port for A1X devices which supports the HW Video Decoder of the SOC [2]. I have an A10 device at work, but unfortunately won't be in the office to play around with it for some time.
My project is a tiny box in the living room that copies Blu-ray discs over NFS to a multi-TB fileserver. The difference between 100Mbps and 1Gbps when copying a 40GB image is 55 min vs. 5 min...
I should add that with DMA and checksum offloading, even a (relatively) slow CPU can handle 1Gbps data transmission rate easily.
Last I knew, and I'll admit I haven't looked recently, the gigabit was actually limited to something like 480M. The only other one I can think of that is armv7+ (that isnt mx6) with gigabit is the OpenBlocks which has 2 or 4 gigE ports but there is no video on it.
This is the latest update it seems http://boundarydevices.com/i-mx6-ethernet/ but that is decent for a consumer type ARM device (I presume some of the server options do better).
i dont think it makes too much sense as the CPUs cant handle the throughput anyway. There are alot of older NAS with Gigabit ethernet that hardly come near those speeds because the CPUs are just too slow. I am not sure where the current ARM CPUs are performance wise in relation to that, but i dont think you would get much more than 100Mbit out of it anyway.
It allows you to move the computer to your data. There are lots of places where power can be an issue (solar collection only), a full 'computer' would take up a lot of power and space. A micro like this would allow you to process signals on site and only send back 'important' information over potentially limited bandwidth. The device is inexpensive and generic, so you can program it do to what you need, there are many custom devices that do what this board can, but they are either expensive or fixed function.
Not only that. Imagine tying a ton of these together, with a hundred of them, say, you would spend as little as ~9k and have a supercomputer on your hands. Or, suppose you want to create some sort of small device that relies on existing software like an MP3 player or some sort of video player. This would allow you to build it, without a lot of trouble having to do things from scratch. Or this could power a laptop sans screen... it goes on and on.
The 10 watt power supply is so that the USB ports can have full power. The board alone probably doesn't use much more than 6 watts or so at maximum load (the similar ODROID-X draws about 7 watts maximum on the AC side of the power adapter)
Being able to power the RPi off USB is, unexpectedly, one of my favorite features. Wall warts just plain suck. You won't be able run 6w off USB 3.0 for a while yet.
More efficient, though depending on what your plan is efficiency will be less important than power consumption. Battery power would be a good deal harder with those.
Like anything, you've got to pick the right tool for the job.
I've been thinking of building Linux From Scratch [1] as an effort to better understand the workings of GNU/Linux. Would this be a good machine to build it on? It certainly seems to fit the bill!
I'd do LFS in a VM first. If you try doing it on one of these devices, then either you're cross-compiling (which can be somewhat finicky), or you're compiling on this device (which will be slow).
I would try it on an x86 device first, just to get your feet wet. There's enough ways to trip yourself up with LFS without trying to do it on unusual hardware.
I think it is still expensive, manufacturers in China ship Android HDMI-usb dongles for samples at 55$ featuring 1.6GHz A9 dual core, quad core GPU, builtin 802.11n, BT 2.0 and HDMI output featuring Android 4.1 and more..
Cool to see this on HN. We're sticking this board on our little legged robots for vision processing.
Power consumption is the issue though, even 3W is going to tank our battery life. I've looked around, but can anyone come up with something that is better in terms of a 'processing power to power consumption' ratio?
Does anyone happen to know of any MIPS-based things like this? I'd seen quad and 16 core MIPS packages earlier--anybody know of attempts to put them on a board like this?
EDIT: Also, did anyone else notice the full credit-card number on the picture...? I hope they fix that. :(
Looks like a good upgrade to an xmbc on raspberry pi.
This might be a stupid question but does anyone know if HDMI-CEC would work on it? I want to be able to use my tv remote just like on rpi.
This looks pretty cool, with plenty of power, and coming with the case. Adding the Wifi built-in would be better. Now it needs to add the bulky USB based wifi piece.
caveat emptor with development boards, the term implies it might not be product quality. eg the sheevaplugs I bought died within a few months of purchase.
There are a gazillion of these. (Most of these are dual, there are a few quad cores mixed in. For XBMC, the dual core is more than powerful enough. The quad core won't fix software rendering, it's up the OEMs to get CedarX working (it's close) or Pivos to push out more amlplayer updates for utilizing the Mali GPU for accelerated playback.)
http://www.alibaba.com/trade/search?fsb=y&IndexArea=prod...
It's like the AMLogic-M3 f16ref. There are a dozen different flavors of these and the roms are interchangeable but there's no community around them to get continuous integration and good builds of XBMC setup. There should be an effort to get a distro that will generate nightly builds to target these devices with Linux/Android and optionally XBMC.
I keep rehashing this and everytime I do I say I should start a blog or set of resources for this... I need to follow through but my other projects are more immediately exciting :S
Nope there aren't, not at this price. Even the pandaboard ES is more expensive (and TI is discontinuing OMAP :-(( ). Sure there are quite a lot Allwinner and Rockchip based boards, but these don't compare to a Samsung Exynos. Not yet.
TI is not discontinuing OMAP. They are discontinuing the tablet-oriented chips and refocusing on embedded. What that means for the hobbyist SBC market remains to be seen.
For video encoding, things like OMAP/et al already give you hardware video encoding next to the ARM, usually based on an arm "DSP" like cortex m3/m4.
Given this is infinitely cheaper than using general purpose cores, why wouldn't you just build yourself an army of cortex m3/m4's and use them for video encoding now.
ARM doesn't really need to do anything here to make this happen. Since they give you all the chip related stuff necessary to build your own, just go and do it. If you want 64 m3's, go make it.
All the architecture documentation is available. The instruction set is custom. There's a gcc port. The OS is hosted on the ARM, but several of their demos involve calculations offloaded to the Epiphany chip, otherwise there wouldn't be much point.
It is not SIMD. Each core is totally independent of the others. Basically the cores are structured in a grid, and all cores have 32KB in-core static RAM, but can also access the memory of all the other cores (at the cost of a few cycles delay), or main memory.
You could certainly use them as much like a SIMD if you wanted to, but then you'd likely get better performance out of a GPU.
We'll see when they deliver on their kickstarter project what type of performance people get out of it in reality...
Nvidia intends to do that with Project Denver/Boulder (2014) with 64 bit chips, and supposedly a new Maxwell-based GPU. I think they will be making 16-core on die, but they'll also help their customers make 512-1024 core racks. They already did it with Tegra 3 with some customer from Barcelona.
Applied Micro also intends to introduce a 128 core SoC in 2014:
Actually, video encoding for most codecs is a task which doesn't lend itself to parallelism due to temporal encoding. Because each frame depends on the last one, you really don't gain much from going to multiple cores (at least yet).
To start encoding at different times with each core you would need a really fast (read: expensive) storage (every core will need a steady stream to compress, if you have 64 cores you need a storage that can handle 64 parallel requests really fast or a lot of RAM to cache everything) and the chips have to handle really heavy I/O. The current many-core ARMs only have a small amount of dedicated RAM for each core.
Also, keyframes are not known from the start in many encodings. A keyframe is inserted when the difference between a frame and the next one is big; this can only be detected when encoding, or with a multi-pass encoding.
Also, plug computers like FreedomBox: http://en.wikipedia.org/wiki/Plug_computer
And single board microcontrollers like the arduino boards, make controller, basic stamp, etc.: http://en.wikipedia.org/wiki/Single-board_microcontroller
I personally would like to see a build-your-own tablet type of thing that can run android or ubuntu. Of course there already is the nexus 7 though.