Slashdot Mirror
Ubuntu Core Gets Support For Raspberry Pi 2 GPIO and I2C
An anonymous reader writes: Ubuntu Core is a tiny Ubuntu distribution aimed at the Internet of Things, using a new transactional packaging format called Snappy rather than the venerable Debian packaging format. It recently gained support for I2C and GPIO on the Raspberry Pi 2, and a quick demo is given here. Ubuntu's Core support site says that the support for Raspberry Pi 2 isn't yet official, but provides some handy tips for anyone who wants to try it out.
How does snappy work?
The raspberry hardware i2c implementation is broken. Don't try to communicate with microcontrollers, it will fail due to the broken clock stretching....
I had to do SW bitbang i2c, what a mess !!
aaaaaaa
It's slow on my new 24-core Xeon servers. I can't imagine how bad it is on a Pi.
At least with a Pi, you're not going to be running as many services, which systemd makes very difficult to troubleshoot since it swallows stederr, ignores exit statuses, and discards a lot of syslog messages.
I was also wondering this.
Is Bad To The Bone.
Bad.
Bad.
Bad To The Bone.
At least that is what I saw the first time I glanced at the post.
Why is Snark Required?
Unless they improved on the historically dodgy USB sw/hw, there's little to be done.
I'll stick to my cubieboard2... which also has sata.
Looking for people to chat about multicopters, coding, music. skype: gtsiros
I ask a simple question then get voted as a troll. Seriously, does it use systemd?
I never saw the BIG announcement that they fixed the USB-Ethernet problem, so maybe you can find me the link.
Then again, don't bother. I wasted half year trying to get the RPi working stably and never succeeded. In the mean time the RPi name has left a foul taste in my mouth and it still lingers. As gTsiros said: give me a Cubieboard any day of the week and twice on Sundays. Running my weather station 24/7 for the past two years without any problems.
Whats GPIO, whats I2C and why should normal people care?
If "normal people" means people who buy a computer at Best Buy and aren't sure what OS it runs, they don't care about the Raspberry Pi.
GPIO means general purpose input/output - pins that you can turn on and off, or read, in order to connect motors, servos, lights, sensors, etc.
I2C is how chips such as microcontrollers communicate. It's kind of like a lower-level USB. You'd use it to connect your Raspberry Pi to an Arduino, Picaxe, LCD display, or some advanced sensors like GPS modules, or perhaps a cell phone module.
Snappy is Cannical's attempt to get rid of apt because it doesn't work for paid apps. They've abandoned the Ubuntu Software Center (and the developers there) and are now pushing this crap. Whatever claim they make about 'sandboxing' and 'security', the end goal is to monetize apps to phone and tablet users. This might not even be so bad if it worked. But Snappy is not ready for primetime. It is cumbersome and buggy.
I also question the usefulness of an 'app-store' style package management system to a platform that is geared to education. The Raspberry Pi Platform's strength is in its openness and community support. It's gonna suck to see step 4 in EVERY pi project article be 'Go install Core on your pi, then buy my app'.
So really who cares if Core/Snappy has GPIO. So does Windows 10 IOT. Having tried both images out, WIndows IOT might actually be more useful than Ubuntu Core on the Pi right now. (At least is runs Node.js)
I'll take apt or pip (or mercurial or Github for that matter) over Snappy any day.
> connecting two micro controllers together is going to be trouble whenever one is significantly faster than the other.
The Pi is a Linux computer. Sometimes, it makes sense to connect peripherals or add-in cards to a computer. For example, a RS-485 card, or more specialized, a DMX controller.
An Arduino makes a good DMX controller. If you want to run DMX under Linux, it makes sense to connect a DMX controller (Arduino) to your Linux system (Pi). It's not about pin count, it's about building and connecting components that each do something. Just like you'd use PCI to connect a board (with a micro) to a PC running Linux or Windows.
An Arduino makes a good DMX controller. If you want to run DMX under Linux, it makes sense to connect a DMX controller (Arduino) to your Linux system (Pi). It's not about pin count, it's about building and connecting components that each do something. Just like you'd use PCI to connect a board (with a micro) to a PC running Linux or Windows.
Its funny you should mention DMX, we use DMX extensively where I work, and we actually built an ethernet/wifi to DMX bridge. Its an RPI, a wipi and the associated connectors. no need for an arduino.
There isn't any use case where a PI+arduino makes any sense. Even for the hobbyist, if its simple enough for an arduino, but you need the OS / USB / ethernet of the Pi, just skip the arduino and use a Pi by itself. No problem. If it is complicated enough to need more than the Pi alone can handle, then the arduino is most likely NOT what you want. You would be better served with one of the PSOCs I mentioned. its cheaper, and far more versatile. The arduinos day has come and gone. The Pi and beaglebone fill that need far better than the arduino ever did. If you need more, use the PSOC+ Pi / beaglebone.
Trust me, I do this for a living. what the arduino brings in terms of simplicity is decimated when you have to connect it to a Pi. at that point, get a real embedded SOC, and at least you have the peace of mind that your system has the horsepower you will need for your project.
I wish I had a good sig, but all the good ones are copyrighted
I'm not sure why you think there would be something to gain from throwing away a perfectly good DMX controller, just to redesign a new one to run inside a Pi, which is already busy doing other things. Then keep doing that every time you want a different UI or function. I've got a real nice DMX controller, why exactly should I build a new one inside of every different computer I want to use DMX with, rather than simply connecting a controller that already works well? Or maybe you didn't get the point that the DMX controller is a separate thing from whichever computer happens to be using it at the moment.
> if its simple enough for an arduino, but you need the OS / USB / ethernet of the Pi, just skip the arduino and use a Pi by itself.
Which is the same as saying:
> if one part simple enough for a microcontroller, but you need the OS / USB / ethernet of a computer, just skip the microcontroller and use a PC by itself.
Which means no add-in cards or USB peripherals, ever. After all, your Core i5 COULD be used to bit-bang ethernet. Therefore it should, right - no use case for an ethernet controller.
As another example, the Pi can connect directly to a wifi chip, so it would be stupid use a separate wifi module like the wipi, right? You'd never do that, because you COULD skip module and integrate everything onto one board.
If you take the cover off of your computer, you'll see a buttload of microcontrollers. The CPU _COULD_ do all of those functions, just like the RPi could be a bunch of different things simultaneously. Everyone (but you, apparently) thinks it makes sense to have sound cards, RS-485 cards, SAS cards, an network cards as separate, interchangeable items, which can be used with different CPUs.
I got one use case.
3d printers controlled by arduino derivatives.
though, then you would probably just connect it with usb..
(and why wouldn't you just drive the 4+ synced steppers from the raspi? RT is hard. nobody has gotten it to work well on it. you can do a concept printer but they're just that, concepts barely functioning(when compared to a friggin atmel ran bot). there's a kickstarter thats supposedly shipping now..)
world was created 5 seconds before this post as it is.
> if its simple enough for an arduino, but you need the OS / USB / ethernet of the Pi, just skip the arduino and use a Pi by itself. Which is the same as saying: > if one part simple enough for a microcontroller, but you need the OS / USB / ethernet of a computer, just skip the microcontroller and use a PC by itself.
The two two are not identical. The difference is immediately obvious to a professional embedded system engineer. Cost. For an engineer, cost is the second and third most important factors. Second is unit cost, and third is development cost. Replacing a Pi with a PC fails the unit cost test, and using an arduino and Pi together when only one is necessary fails both tests. The key difference between an amateur designer and a professional engineer, is that typically the amateur is on a constrained budget which dictates that development cost is paramount. For an engineer, the equation is a lot more complex, which is why an engineer can justify spending $1,500 for an anual Orcad license, and an amateur can't.
Which means no add-in cards or USB peripherals, ever. After all, your Core i5 COULD be used to bit-bang ethernet. Therefore it should, right - no use case for an ethernet controller.
Full speed ethernet can't be bit-banged. There are too many timing related issues that would make a bit-banged solution unreliable. Audio on the other hand can and is done by bit banging with a little DMA. That is why CPU based "sound cards" are a thing. Ethernet and USB by contrast use different voltages from CPU core voltage requiring external hardware anyway. In modern PCs, this hardware also handles the protocol, so there is no cost advantage to using a phy only chipset and bit-banging USB.
As another example, the Pi can connect directly to a wifi chip, so it would be stupid use a separate wifi module like the wipi, right? You'd never do that, because you COULD skip module and integrate everything onto one board.
Depends on the unit cost vs engineering cost. If the total cost of development of the chip version is $X, and the unit cost difference $Y times the total estimated unit sales Z is less than $X, then there is no point in using the chip version, the USB wifi has the greater ROI, and should be selected.
I could continue, but apparently /. doesn't like long posts anymore...
I wish I had a good sig, but all the good ones are copyrighted
(and why wouldn't you just drive the 4+ synced steppers from the raspi? RT is hard. nobody has gotten it to work well on it. you can do a concept printer but they're just that, concepts barely functioning(when compared to a friggin atmel ran bot). there's a kickstarter thats supposedly shipping now..)
I agree, a dedicated microcontroller is the right ticket for that application, but The arduino isn't it. The arduino system is not well suited to fine grained real time control. What you want is the PSOC I mentioned. It has built in hardware for precise control of the printer. Given the PSOCs capabilities, you can get faster 3D printer performance and better precision that the arduino will ever be capable of handling, and the PSOC costs less, communicating between the PSOC and the PI will be simpler, as the PSOC can do USB, or even ethernet (with the right PHY).
I wish I had a good sig, but all the good ones are copyrighted
> If the total cost of development of the chip version is $X, and the unit cost difference $Y times the total estimated unit sales Z is less than $X, then there is no point in using the chip version, the USB wifi has the greater ROI, and should be selected.
And "I already have the Arduino DMX controller in the drawer" means the unit cost is zero. The development cost of doing real time on a Pi is quite a bit higher than zero. Therefore, it makes sense to use the zero cost option (attach the Arduino you already have) rather than the higher cost, higher complexity option (use the Pi as a DMX controller along with everything else it's doing).
Btw, your calculation also missed the big point. If you don't want or need feature X in 99% of cases, it's probably stupid to include it. It should be implemented via a separate, optional attachment. That's why RPis, and PCs, don't have RS-485 built-in, because hardly anyone wants it. You use a separate component in that case, not build it in. Similarly when reliability and security are important- complex things that try to do a lot of different stuff at once tend to break. Simple components that do just one thing are more reliable.
And "I already have the Arduino DMX controller in the drawer" means the unit cost is zero. The development cost of doing real time on a Pi is quite a bit higher than zero. Therefore, it makes sense to use the zero cost option (attach the Arduino you already have) rather than the higher cost, higher complexity option (use the Pi as a DMX controller along with everything else it's doing).
Unit cost doesn't mean what your post indicates you think it means.
I wish I had a good sig, but all the good ones are copyrighted
And "I already have the Arduino DMX controller in the drawer"
That is the worst possible reason for selecting components unless you are a hobbyist with no real prospects for commercial application of your project. The proper way to select parts is to do a complete cost benefit analysis of a couple of different options to determine which one will have the overall best ROI. The company I work for has several products where the analysis was not done, and the engineer simply went with what they were familiar with in the face of overwhelming disadvantages. That one decision has cost our company over half a million dollars a year in excess unit costs. It is so large that we have hired two more engineers just to redo all of the designs that he had done. (When they found out how much money he had cost the company, he was let go).
If you are trying to make a commercially viable product, and you don't do the analysis, it can mean the difference between life and death for a startup. I can understand the use of the arduino possibly, if time to market is critical and all you know is the arduino. Even then, it might be in your best interest to bring in someone who is capable to do your engineering work, as doing it yourself could very well ensure failure...
I wish I had a good sig, but all the good ones are copyrighted
> That is the worst possible reason for selecting components unless you are a hobbyist with no real prospects for commercial application of your project. The proper way to select parts is to do a complete cost benefit analysis of a couple of different options to determine which one will have the overall best ROI.
Are you under the impression that the Raspberry Pi and Arduino are designed as OEM parts to go into mass-market products? If so, you might want to glance at the project web pages and see what they ARE.
Regardless of what they are intended to be, the Raspberry Pi and Beaglebone *are* commodity OEM parts and are being used in mass production systems. That is the entire impetus behind the compute module. The BBB is a better option as it is an open board. Our BBB supply house has 4 major customer who between them use more than 100K units per month, and they are just one supply house. Element14 is rumoured to be selling over 1M units per month now. Our designs are made to be flexible, and we can use either the Pi, the compute or the BBB. In the event that someone decides to stop making the RPI, we can switch to the BBB. The BBB already has 3rd party manufacturers who make the system specifically for the OEM market. Even the RPI guys *want* people to buy the RPIs for OEM use because they make money on them, and the more they sell, the better their margins get. Simply put, there is no compelling reason to spin your own processor board unless you need to fit mechanical constraints that the PI / BBB cant meet. Unless you are making 10M+ units per year, you wont be able to be cost competitive with those parts.
I wish I had a good sig, but all the good ones are copyrighted