11-11-2016, 08:54 AM
(This post was last modified: 11-11-2016, 08:55 AM by Artyom.
Edit Reason: incorrect translate to english
)
(11-09-2016, 01:16 PM)MarkHaysHarris777 Wrote:(11-09-2016, 07:52 AM)Artyom Wrote:(11-08-2016, 05:47 PM)pfeerick Wrote:(11-08-2016, 08:00 AM)Artyom Wrote: Thank you for your kind words. But I still need help in this matter. Technically possible to accomplish this task on the current generation of the board? Can anyone suggest? I'm new to the internet of things and programming.
As Marcus said, the pine64 board is not reliable or robust enough on that front at this point in time. It could be as simple as changes needing to be made to the device tree settings, or it could be a issue that we can't work around until the OS has fully loaded. If your goal is reliability, it is probably better to use the serial or I2C bus to talk to another microcontroller like a Arduino or PIC, which does have reliable power-on states.
Marcus: What do you think of external pull downs (say 10K) with a 74HC7014 (hex non-inverting Schmitt-trigger) - do you think that would buffer the output enough? Are there any particular pins that are more random/noisy than others during bootup?
It should at least make sure that the majority (or all, if possible) gpio pins were off (logic zero) immediately after the operating system is loaded. You can certainly make them like raspberri PI.
Well, again, the Raspberry PI defaults to "inputs" on all gpio pins; this is hugely different than defaulting to "off". The fact that the pins can be "input" with either pull-up or pull-down internal resistors; the pin can be technically HIGH or LOW and still be an input state!
The problem that we have when developing control ciruits is knowing what happens during POR (power on reset) and what happens during abnormal power-down. Personally, I don't feel like *any* control SBC at the moment has the reliability to be trusted in a single level installation; although, some are notably better than others ( the Raspberry PI is better than the Pine in this regard ).
POR must be controlled in 'stages' and the entire system must be protected against accidental power-off. This is obviously going to be more than a signle level control board attached to relays. Multiple level control and redundancy are required, and final power control is required. Things would be a lot easier if SBC(s) could be made reliable enough that ALL gpio pins would remain in the input state ( pullup or pulldown ) throughout the POR --- but, its not there yet.
Good evening. I correctly understand that this problem can not be solved, and for automation purposes it is suitable Raspberry PI?