|
Perhaps I can provide some constructive feedback. I picked up a pair of Zero-512MB units a couple of months ago. I've tested the ethernet & wifi with good initial success. I was stunned to discover the OTG port doesn't appear to have a serial or network profile associated with it. I think that is a software deal. But having come from C.H.I.P.s I expected to be able to power up the device and access the Linux console through the OTG port. But then maybe support is left off because the power draw of the SBC is >0.5A, making it prohibitive to plug into a USB host? As the specs say I've made sure to power it with at least 2A so I'm not sure what the real amp requirements are ... yet.
But that is yet another issue I'm running into with the OrangePIs. Documentation is woefully lacking. The main website says essentially the same thing about every model, other than specs and photos and the accuracy of the specs is suspect. It looks like someone started a good framework on the wiki and then simply stopped. Many sections are left blank. Many models aren't covered.
Last night (US PDT) I attached a DS3231 RTC to the TWI0 bus on the 26pin connector and then went to read it... Um. No i2c bus devices in /dev. Looks like /sys/.../12c shows two i2c busses but no drivers, just "dummy". Checked the wiki. Nope, no info there, just a heading. So I'm still digging around to figure out what I need to install the drivers... and yes, I checked the fex file to make sure they are enabled. Others on the forum seemed to have success communicating with the bus so the drivers must have been present at some point in the past.
This speaks to the "usefulnes" of the images provided by OrangePI. I've tried two images so far (deb server & desktop) and neither support the i2c busses out of the box. Network, i2c, spi & gpio are probably the primary things people will want to manipulate on your boards. After all you provide connectors to export those signals. Heck there are people who will want to use the camera too! Bottom line: the images should be able to support ALL peripherals that the SBC makes available without the end user having to build custom kernels and/or images. That should only be necessary for people who need some specific functionality, like trimming things down to conserve RAM/uSD for their specific needs.
And then there is the funky LF. It seems to invarriably rise to the number of cores on the board. Not sure what that is about. But I've seen enough artificially high LFs in my time it really doesn't bother me. Sure seemed to bother the other guy though. And it would be nice to have an accurate
Well... I'm out of time but that should be anough to think over.
|
|