(11-11-2016, 12:55 PM)MarkHaysHarris777 Wrote: hi Artyom, whether any SBC will be a suitable controller depends on the characteristics of the control circuit, electrical dynamics and other things like security ( and others ).
[snip]
I believe you can build a reliable control system with the Pine ( I'm researching that the whole time I have had mine ) as long as you take POR into account, and have a good UPS or other system to handle power outages. BUT your system must not rely on any steady state during POR regardless of SBC; although, the RPi is ( in this instance ) may be more reliable in that situation. ( I'm just trying to be complete here )
TL;DR : Of the SBCs around, RPi is the best, but I wouldn't rely on any SBC in any system where reliability is desired - unless you want your garage door to do the Macarena dance every once in a while.
I'd be curious to know how quickly the RPi pins are in a 'reliable' state, as when fiddling around in the guts of my Cubietruck the other day, I realised that since it is based on fex files (not the new-fangled device tree), that until that file is processed, the default state of the GPIOs could be anything. And if my understanding of the device tree is right, the dts configs are parsed to the kernel, so that means that until uboot has passed control to the kernel (4-5 seconds from power on), and then whenever the device tree blob (DTB) is processed (lets say 2-3 seconds to give it a chance). So that means for the first 7 or or so seconds that the GPIO pins could be doing anything? I noticed one of the things the RPi did was enable all the GPIOs pins, but to turn them off unless the DTB requests them be on. Hence once the DTB has been processed, you know exactly what state the RPis pins will be.
Anyway, that is probably a discussion best for another thread. Getting back to the main topic of this thread, I'm in the same view as Marcus... you can make a reliable system (well, as reliable as any of these SBCs can be) with the pine64, as long as you take into account the initial GPIO power on/reset unreliability, the fact that is a computer - thus can crash, and make use of the fact that it can have a battery connected to it. Personally, I would be using it as a middle-man, with a PIC or AVR (Arduino) micro-controller doing the actual controlling/decision making. i.e. in Marcus's garage door example, the pine64 sees the signal from your cars rf chip, and sends a message to the Arduino to open the door. If the pine64 crashes, the Arduino simply waits until the pine64 starts communicating with it again before doing any door opening or closing. Although in that scenario, unless you were needing the processing power of the pine64, I'd be making a solely Arduino based system as that would be much-much more reliable... but you get the idea... the pine64 is best used as the middle-man directing other systems, or providing the processing power where needed.
Another real-world example is the Flux Delta 3D printer/laser engraver/scanner - it has three stepper motors that drive the print head, and all the temperature monitor, management and feedback for the printer. And it has a land-locked Raspberry Pi (meaning it isn't accessible externally) running the whole show. But there is a catch : the Raspberry Pi provides the wifi/usb interface, the processing power needed to interpret and run the programmed job, but there is is a custom control board there also which does the running of the stepper motors, temperature monitoring, monitors all the feedback systems, and will shut the whole system down should the RPi brain go non-responsive. And the system works... the microSD poped out of the RPi for some unknown reason, and the custom (AVR based) control board ensured that nothing failed or burnt out.
(11-11-2016, 07:02 PM)pfeerick Wrote: (11-11-2016, 12:55 PM)MarkHaysHarris777 Wrote: hi Artyom, whether any SBC will be a suitable controller depends on the characteristics of the control circuit, electrical dynamics and other things like security ( and others ).
[snip]
I believe you can build a reliable control system with the Pine ( I'm researching that the whole time I have had mine ) as long as you take POR into account, and have a good UPS or other system to handle power outages. BUT your system must not rely on any steady state during POR regardless of SBC; although, the RPi is ( in this instance ) may be more reliable in that situation. ( I'm just trying to be complete here )
TL;DR : Of the SBCs around, RPi is the best, but I wouldn't rely on any SBC in any system where reliability is desired - unless you want your garage door to do the Macarena dance every once in a while.
I'd be curious to know how quickly the RPi pins are in a 'reliable' state, as when fiddling around in the guts of my Cubietruck the other day, I realised that since it is based on fex files (not the new-fangled device tree), that until that file is processed, the default state of the GPIOs could be anything. And if my understanding of the device tree is right, the dts configs are parsed to the kernel, so that means that until uboot has passed control to the kernel (4-5 seconds from power on), and then whenever the device tree blob (DTB) is processed (lets say 2-3 seconds to give it a chance). So that means for the first 7 or or so seconds that the GPIO pins could be doing anything? I noticed one of the things the RPi did was enable all the GPIOs pins, but to turn them off unless the DTB requests them be on. Hence once the DTB has been processed, you know exactly what state the RPis pins will be.
Anyway, that is probably a discussion best for another thread. Getting back to the main topic of this thread, I'm in the same view as Marcus... you can make a reliable system (well, as reliable as any of these SBCs can be) with the pine64, as long as you take into account the initial GPIO power on/reset unreliability, the fact that is a computer - thus can crash, and make use of the fact that it can have a battery connected to it. Personally, I would be using it as a middle-man, with a PIC or AVR (Arduino) micro-controller doing the actual controlling/decision making. i.e. in Marcus's garage door example, the pine64 sees the signal from your cars rf chip, and sends a message to the Arduino to open the door. If the pine64 crashes, the Arduino simply waits until the pine64 starts communicating with it again before doing any door opening or closing. Although in that scenario, unless you were needing the processing power of the pine64, I'd be making a solely Arduino based system as that would be much-much more reliable... but you get the idea... the pine64 is best used as the middle-man directing other systems, or providing the processing power where needed.
Another real-world example is the Flux Delta 3D printer/laser engraver/scanner - it has three stepper motors that drive the print head, and all the temperature monitor, management and feedback for the printer. And it has a land-locked Raspberry Pi (meaning it isn't accessible externally) running the whole show. But there is a catch : the Raspberry Pi provides the wifi/usb interface, the processing power needed to interpret and run the programmed job, but there is is a custom control board there also which does the running of the stepper motors, temperature monitoring, monitors all the feedback systems, and will shut the whole system down should the RPi brain go non-responsive. And the system works... the microSD poped out of the RPi for some unknown reason, and the custom (AVR based) control board ensured that nothing failed or burnt out.
Hello. While this problem is not solved, it will not be used to automate fir. Today I tried to realize all you need on the board Raspberry Pi 2 ... Everything works fine. Thus it is possible to make a conclusion. Pine64 can not be used for the development of home automation systems, even at the level of the amateur electronics.
(11-12-2016, 03:12 AM)Artyom Wrote: (11-11-2016, 07:02 PM)pfeerick Wrote: (11-11-2016, 12:55 PM)MarkHaysHarris777 Wrote: hi Artyom, whether any SBC will be a suitable controller depends on the characteristics of the control circuit, electrical dynamics and other things like security ( and others ).
[snip]
Hello. While this problem is not solved, it will not be used to automate fir. Today I tried to realize all you need on the board Raspberry Pi 2 ... Everything works fine. Thus it is possible to make a conclusion. Pine64 can not be used for the development of home automation systems, even at the level of the amateur electronics.
Damn. I wished you'd made that conclusion and told me sooner... then, I would not be doing now.
... I apologize , but you appear to not understand. The Pine64 works very well for even industrial automation; BUT NOT AT THE LEVEL OF AMATEUR ELECTRONICS !!
If you want to develop an automation system with the Pine using amateur electronics, you are heading for a dissaster. On the other hand, if you add some sophistication to your research and final design, your automation system ( with Pine64 at the heart ) will be just fine.
marcushh777 
please join us for a chat @ irc.pine64.xyz:6667 or ssl irc.pine64.xyz:6697
( I regret that I am not able to respond to personal messages; let's meet on irc! )
My bubble just popped! I made an assumption without actually checking first. This random GPIO on power up is a game killer for me. Either I am going to have to design additional hardware in between the pine and the I/O port or control my I/O via SPI or I2C. I was hoping to use the Pine I/O as CS lines but will have to re-think this.
Love the Pine as far as processing power, memory, and display but this random GPIO on boot up makes it a no go for me.
|
