Miniszámítógépek, SBC-k

python-kód 30% processzorhasználattal

Sziasztok.

Mezei Raspberry Zero el van látva egy gombbal, meg egy leddel. No meg ezzel, ami meghajtja a kettőt. Figyeli, be lett-e nyomva a gomb és ha igen, bekapcsolja a ledet, majd elindít egy scriptet BASH-ban. A led addig világít, míg ki nem kapcsol az rpi.
Valamiért azonban szerintem htop-ban nézve irdatlanul eszi a kód processzort, nem értem, miért.

Íme a kód:

import RPi.GPIO as GPIO
import time, os
GPIO.setmode(GPIO.BCM)
#switch_pin = 21
#led_pin = 17
switch_pin = 21
led_pin = 27


GPIO.setup(switch_pin, GPIO.IN, pull_up_down=GPIO.PUD_UP)
GPIO.setup(led_pin, GPIO.OUT)
led_state = False
old_input_state = True # pulled-up
while True:
 new_input_state = GPIO.input(switch_pin)
 if new_input_state == False and old_input_state == True:
  led_state = not led_state
  GPIO.output(27, True)      # led ON
  os.system("sudo fuss off")
  print("power OFF")
 old_input_state = new_input_state
 GPIO.output(led_pin, led_state)

Szerintetek ez így tényleg erőforrás-zabáló?

Raspberry Pi 3 openSUSE ARM64 (aarch64)

Hello,

A jelenlegi Factory image-ekben egy kis hackre van szukseg, hogy bootoljon az eszkoz. Sajnos nincs TTL kabelem, se HDMI-m, ezert kenytelen voltam ezek segitsege nelkul 'rajonni' a megoldasra. Koszonet az #opensuse-arm IRC csatornanak a tippekert! Mint kiderult, az nem sokat jelent, hogy ugyanaz az image mit muvel a QEMU-ban...

Ird ki az image-et:

# xzcat openSUSE-Tumbleweed-ARM-JeOS-raspberrypi3.aarch64-2016.11.23-Build4.37.raw.xz | dd bs=4M of=/dev/mmcblk0 iflag=fullblock oflag=direct

Mountold fel a ROOT es a BOOT labellel rendelkezo particiokat:

# df -T
Filesystem Type 1K-blocks Used Available Use% Mounted on
/dev/mmcblk0p3 btrfs 2194368 660216 1367272 33% /run/media/user/ROOT
/dev/mmcblk0p2 ext3 202173 80020 111504 42% /run/media/user/BOOT

Masold at a device tree file-okat, amik hianyoznak innen:

# ls -F /run/media/user/BOOT/boot/
0xbd84b952 boot.scr boot.script grub2/ initrd.vmx linux.vmx mbrid unicode.pf2

# cp -rp /run/media/user/ROOT/boot/dtb* /run/media/user/BOOT/boot/

Umountold a FS-eket es bootold az SD-rol az rpi-t.
Ami a Raspbianhoz kepest szokatlan, hogy az install alatt az ACT LED nem villog, nem vilagit. Kb 3 perc utan viszont eletre kel a LAN LED es be lehet jelentkezni a default root/linux user/jelszoval (!), ha van DHCP a halozaton es tudod, hogy mi lett az eszkoz IP cime.

En a JeOS image-et tettem fel, hat ez tenyleg eleg alap, pl nincs benne wpa_supplicant, igy a WiFi interface sem el, de szerencsere ami kellett, mind volt repoban.

udv
LGee

Orange Pi PC Plus SPI vezérlés

Sziasztok. Van egy hibátlanul működő OrangePi PC Plus, (armbian server image) amin különböző szenzorok vannak. Minden normálisan működik, ezekkel némi guglizás után sikerült zöldágra vergődni. A project része lenne egy PWM-es motorvezérlő is, ebbe viszont beletört a bicskám. A PWM egy áramkör, amivel "lágy indítást" lehet csinálni villanymotorokon, hogy a táp ne szálljon el a kezdeti nagy amper terheléstől. Ennek az áramkörnek a (kézi vezérlésű)potméterének a helyére került bele egy MCP41100-I/P IC, amit SPI interfészen keresztül lehet vezérelni. A terv az lenne, hogy ezen keresztül lehet változtatni a motor fordulatszámát. A PWM panel(plusz az IC) jó, másról vezérelve működik normálisan. Az orangepi tudja ezt kezelni (elvileg) de nekem eddig nem sikerült. Minden vezérlést a WiringOp nevű API-val csináltam, de ez nem akar működni. Néhány napnyi kínlódás után megpróbáltam ugyanezt Python programokkal is, az eredmény ugyanaz. A bekötés jó (pinek: MOSI, SCLK, CL0) ezt többször leellenőriztem. A programok lefutnak hiba nélkül, de ohmban mérhető változás nincs.
Az ls /dev/spi* kimenete:
/dev/spidev0.0
tehát van eszköz. A /sys/class alatt látszik az spi_master is. Az elsődleges gond, hogy az IC csak írható, így nem nagyon lehet ellenőrizni, hogy mi megy ki. A másik gond, hogy minden IC-nek más-más a használata, ezt például 0x11 küldésével lehet fogadásra állítani, más IC-knél ez másképp történik, vagyis az a néhány példa program, ami a neten megtalálható, ezzel az IC-vel nem működik.
Van valaki, akinek sikerült az SPI interfészt működésre bírnia? Tapasztalatok?

soros kommunikáció: stty

Sziasztok.

Raspberryn szeretnék olvashatóan olvasni soros portról, a /dev/ttyAMA0-ról.
Néha idióta karakterek jelennek meg, nem tudom miért, de sejtem, hogy összefüggésben van azzal, hogyan állítom be az stty paramétereit.

Jelenleg ez megy:

#!/bin/bash

stty -F /dev/ttyAMA0 4800 8N1 -cstopb -parenb -icanon min 1 time 1
#stty -F /dev/ttyAMA0 115200 8N1 -cstopb -parenb -icanon min 1 time 1

while true; do
cat -v < /dev/ttyAMA0
done
# igen am, de hogy iranyitom fajlba oly módon, hogy azert a terminalban is lassam, mit fogad a cat?

exit 0

Egyelőre hibátlanul pörög. Kérdés az, számíthatok-e anomáliára, azaz értelmezhetetlen karakterek megjelenésére, amitől a cat is kiakad, azaz leáll?
(Négyzetek, téglalapok, cirádás karakterek, cirádás négyzetek, egyebek. Meg sok-sok space jelenik meg anomália esetén)

Arch on Rpi -- raspikonfig nélkül

Sziasztok.

Hegeszteni tanulok, mert az haladó gondolkodásra vall mai rohanó világunkban.

Azt szeretném megoldani, hogy egy Arch linuxon az spi és az i2c engedélyezve legyen, a debianokon megszokott inittabot sem találom, melyben a
ttyAMA0 115200 ut100
sort le kellene tiltanom. Lila gőzöm sincs, Arch-on ezt hogyan csinálom meg.

A cél egy soros lábakra kötött L86-os GPS üzemeltetése. Jelenleg cat /dev/ttyAMA0-ra nincs válasz, lábak jól vannak bekötve, a ttyAMA0 létező fájl...

Az RTC óra már működik, de ott is vannak anomáliák, pl. a /dev-ben 2 db óra van, egyik nem megy:

/dev/rtc # ez symlink az rtc1-re
/dev/rtc0 # ez nem megy és nem tudom minek van itt, kilőni sem tudom az űrbe
/dev/rtc1 # ez megy, hwclock már írja, de csak akkor, ha az rtc symlink erre mutat

Találkozott már ilyesmikkel valaki?

Költői kérdés egy régi-régi fájlrendszerről

Sziasztok.

Mesebeli talány előttem mind a mai napig.

Amióta Raspberryt használok, a kérdés egyre élesebben rajzolódik ki előttem.
Ha adott bármilyen linux disztribúció, aminek van egy külön 6boot partíciója, miért pont fat16-os fájlrendszerre íródik mindez? Csak azért, hogy vadul sérülhessen, vagy valami mély technikai oka van?

Másik kérdés, ami szintén vad:
fényképezőgépeknél, videokameráknál miért csak egyféle fájlrendszert használ a szerkezet, pláne olyat, ami szintén sérülékeny?

Nem feltétlenül várok választ, éppen a dühömet vezetem le írással, mert álmomban nem gondoltam volna, hogy egy upgrade-megszakadás szétgyilkolhat egy raspberryre tervezett oprendszert. Természetesen van backup, mint mindig. De hát mégis...

Na, ez egy szép topiknyitó.

----------
Topiknyitó oka: leállt a distribfrissítés, áramszünet, sérült a /boot partíció, és a júzer (én) azt hitte, meghalt az RPI, mert nem villogott bootoláskor a led. Dühlevezetés a fájlrendszer mibenlétén zajlik, pohárdobálás helyett.

Mikorvezérlő, de milyet? (Arduino...)

Üdv!
Milyen mikrovezérlőt javasoltok? A hoszt gép RPi lenne és szenzorokat tennék majd a mikorvezérlőre, amiket a hoszt lekérdez időnként. Pl. DHT22
Arduino-ból melyiket javasoljátok? Tudom, van aki nem az Arduino-t javasolná. Érdekel más megoldás is természetesen, de az Arduino is!

Milyen kommunikációt javasoltok a RPi és mikrovezérlő között? I2C?
A tapasztalatok érdekelnek.

(A nemrég indított és kitárgyalt téma miatt kérdezem.)

Raspberryhez, megmurdált kijelzőmhöz alkatrészt vennék

Sziasztok.

Ilyenem van nekem, bizony:
A1601 PiTFT 320x240 2,8 inch Touchscreen TFT

Sajnos megmurdált, beszakadt az érintőpanel rajta. A kijelző működik, az a fólia tartja össze, amit vételkor ráragasztottam.

Nem szeretnék újat venni mert kevés a keretem, így ha van ilyesmije valakinek és érintőpad nélkül használja, szívesen megveszem tőle, vagy akár az egész kijelzőt is, ha tényleg nem köl' neki.
Bevált eszközömhöz ez a kis kacat nélkülözhetetlenné vált, enélkül csak egérrel működik, de egérrel meg sajnos nem vízálló ugye...