EEVblog #883 - Orange Pi One vs Raspberry Pi 2

[knks]

What's next? Apple Pi? 

[NiHaoMike]

I am not talking about hand assembly - I am talking about building the whole product with genuine parts here in the USA. Even with volumes of 50k (which seems high, but I don't really know) - there is no way I could build it for $10 much less make any profit. The assumption here is that they are building it for less than what they sell it for.

Fake parts and slave labor is the only way to make this happen. Honorable mentions: No QC, bad software support, mediocre sales chain, etc. If I had time, I would love to estimate the BOM cost and assembly labor using real parts. Is paying as little as possible so important to people that they are willing to support shitty companies like this?

If you can wait for a deal, you can get a basic quad core smartphone for $10. Basically 1/4 the cost of a Pi 3 for more or less the same CPU capabilities.

[samnmax]

What's next? Apple Pi? 

http://hackaday.com/2016/04/01/apple-introduces-their-answer-to-the-raspberry-pi/

 

[Athanasis]

What's next? Apple Pi? 

Nerds don't bother with Apple crap because they like hacking, modifying, adding, and be marketable as well. So no, don't expect an Apple pi to establish itself. We already have Linux which is fully opened source and customizable. Apple crap is only for crappy assholes like dead Steve Jobs and soon all his history will end up with him in his grave.

[jancumps]

I take it you're not a fan?

[Artlav]

I guess what you are seeing here is the effect of Interconnects on RPi you have no way of connecting the nodes in a really efficient way,

Not exactly. I mostly use it for explicitly parallel problems, where there is no communication between nodes, and the results are kinda sad once you get over the coolness factor.

[Athanasis]

What's next? Apple Pi? 

Nerds don't bother with Apple crap because they like hacking, modifying, adding, and be marketable as well. So no, don't expect an Apple pi to establish itself. We already have Linux which is fully opened source and customizable. Apple crap is only for crappy assholes like dead Steve Jobs and soon all his history will end up with him in his grave.

It was only a joke. Don't do yourself any injury.

It was a joke but the Apple pi exists like u see above in alink

--------------------------
I keep track of your replies with my android devices using the app "Tapatalk".

[steverino]

What's next? Apple Pi? 

Nerds don't bother with Apple crap because they like hacking, modifying, adding, and be marketable as well. So no, don't expect an Apple pi to establish itself. We already have Linux which is fully opened source and customizable. Apple crap is only for crappy assholes like dead Steve Jobs and soon all his history will end up with him in his grave.

Count me as a crappy asshole. (actually, aren't assholes supposed to be crappy?)

[drussell]

What link?

The one from April 1, 2016 in post number 28

[Athanasis]

What's next? Apple Pi? 

http://hackaday.com/2016/04/01/apple-introduces-their-answer-to-the-raspberry-pi/

 

that link

--------------------------
I keep track of your replies with my android devices using the app "Tapatalk".

[f4eru]

..., so it cannot talk to a microcontroller.

And UART or SPI is not a valid way to talk with an MCU?
Never had any problems with communication between RPI and an MCU.

SPI does not have a properly ACKed handshake.
UART does not have proper handshake either.

So you have to make the communication as slow as your slowest interrupt on the micro.
And if you fail that timing, you don't have a warning of the corruption.
That's bad.

It can be avoided with i2C, but only if the master handles the handhake properly. The raspberry doesn't.

Conclusion : there is no safe way to transfer a bit more data from raspberry to a micro.

[Franz Zinn]

Though the data sheets are available which is more than can be said of the Broadcom equivalent, Allwinner is not Open Source compliant either. Please see http://linux-sunxi.org/GPL_Violations .
This is not to detract from any of the merits of the Orange Pi. It is just a statement of fact about the unfortunate state of affairs that there is as yet no fully open source, embedded board with a modern GPU. Though the situation is improving as there are open source video drivers being developed for both VC4 and Mali-400.

[Fungus]

Conclusion : there is no safe way to transfer a bit more data from raspberry to a micro.

No safe way ... apart from programming the micro correctly so it can keep up with the data stream.

UART does not have proper handshake either.

You could always send a special character to say "I'm getting full!" and a different character to say "OK, start sending again". 

[apelly]

UART does not have proper handshake either.

You could always send a special character to say "I'm getting full!" and a different character to say "OK, start sending again". 

Oh ^S it! You're killing me.

[4gent5mith]

If you go to the Orange Pi site and try to download the Kali image for the Orange Pi one it takes you to a mega. co. nz folder. Which has all images/md5. Strange part is that it has images they don't list on their site. I downloaded all images (6.81GB worth); this might be very interesting.

I ordered one so we'll see how it goes. I'll likely post my discoveries (if any) on the forum.

[arekm]

That board have much more features available in form of ... pads:

http://forum.armbian.com/index.php/topic/755-orange-pi-one-adding-analog-audio-out-tv-out-mic-usb-and-ir-receiver/

Data lines for USB #3: points 1,2
Data lines for USB #2: points 3,4
1 - IR receiver RX line
2,3,4 - MIC1P/MIC1N/MIC-MBIAS
5,6 - LINEOUTR/LINEOUTR
TVOut signal and MUTE

[f4eru]

No safe way ... apart from programming the micro correctly so it can keep up with the data stream.

Yeah.
Shure.
Ensure that a 20 MHz micro reacts fast enough compared to a 500 MHz SOC.
I plan to do more useful things with my micros than to wait for data from the host.
Especially when servicing time critical tasks like multiple regulation loops in the 1000-2000 interrupts/seconds range.
 

You could always send a special character to say "I'm getting full!" and a different character to say "OK, start sending again". 

Suuure.
Yeah.
Does not work here.
The micro cannot react and do SW handshake before corruption happens, because it has no Hardware buffer, so it needs to service each byte with an interrupt....


So the conclusion is still : i2C is the only option for a communication with a host including a positive hardware ack.... as long as you don't use a RPI

[NiHaoMike]

The microcontroller supports real time programming. You can limit the data rate on the Pi side so the buffer never overflows.

[Fungus]

No safe way ... apart from programming the micro correctly so it can keep up with the data stream.

Yeah.
Shure.
Ensure that a 20 MHz micro reacts fast enough compared to a 500 MHz SOC.
I plan to do more useful things with my micros than to wait for data from the host.
Especially when servicing time critical tasks like multiple regulation loops in the 1000-2000 interrupts/seconds range.

Ummm... last time I checked RS232 had baud rates plenty slow enough for a 20MHz micro to respond to and still have time left over for other things. It's all down to good programming.

You could always send a special character to say "I'm getting full!" and a different character to say "OK, start sending again". 

Suuure.
Yeah.
Does not work here.
The micro cannot react and do SW handshake before corruption happens, because it has no Hardware buffer, so it needs to service each byte with an interrupt....

I don't know what 'micro' you're referring to. The micros I use (AVR based) have a one byte buffer in hardware which gives you plenty of time to respond to an interrupt. I believe this is a common in other chips, too.

If your micro doesn't have a 1-byte hardware buffer you could toggle a data pin in the interrupt handler when, that lets the sender know you're ready for the next byte and would hardly slow things down at all (what's the interrupt response time on a 20MHz micro? Less than a microsecond?).

Give me a few seconds and I could come up with half a dozen other ways to make it work, too. It's all down to what I call "good design and programming".

So the conclusion is still : i2C is the only option for a communication with a host including a positive hardware ack.... as long as you don't use a RPI

Or... you can use I2C and rely on clock stretching for flow control (assuming your 'micro' can do clock stretching in hardware).

I don't get your assertion that a Raspberry Pi can't do I2C. "I2C master" is one of the easiest protocols to do in software.

[hukuzatuna]

Than there is then the software side of which i'm sot an expert but i know it has to be aware he's running on a cluster and acting accordingly and i don't know if raspbian has this kind of support

I have a 128-core cluster of Adapteva Parallella boards, Raspberry Pi 2s, and Raspberry Pi 3s. I use this for developing prototype distributed AI code. Raspbian supports MPI, though I don't use the Debian package. I install MPICH-3.2 and use that. I've also gotten Apache Spark to run on the cluster with a lot of customizing the Java runtime environment to squeeze the heap into that tiny 1 Gig chip. It's an interesting experiment, but not particularly performant because of the Java ecosystem running on limited hardware. MPI, however, does have reasonable performance (within the limitations of the hardware). Once I get things working on this cluster I'm pretty comfortable moving it into a distributed environment using much larger machines.

Cheers,
Phil

[Okabe]

We should make a EEVblog SETI group XD

[System Error Message]

if you're interested in many core clusters TILE has an interesting one which facebook uses as PCIE cards in their servers to handle the processing bits such as firewall and web server. Their dev machines arent cheap but you can get one with 8x36 cores in a 1U config with the usual stuff you find in servers like lots of ram slots and also even has its own PCIe slot too just like a regular x86 server. I have one of these many core CPUs in the router i've  been using, never goes beyond 4% under the worst case (internet + firewall + filtering and proxy + unoptimised management + network services, no hardware acceleration used) and much cheaper than any consumer router in the price/performance, beats ARM A7s and A9 by a large margin in per core and per clock throughput. Best part is the TILEs tend to come with 10Gb/s NICs while the raspberry pi or pi clones have 100Mb/s, only 1Gb/s for some and thats only on the usb2 interface rather than PCIe.

As far as SETI computing power goes if it ever became available for these routers it would be a huge improvement as ISPs have been buying them so it is quite funny when you tell your ISP you have the same router they use in their edge gateway or router.