Hirdetés
-
SMITE 2 - Napokon belül indul a zárt alfa teszt
gp Több mint egy tucat karaktert próbálhatnak ki a szerencsésebbek, a teljes listát a május első napján esedékes streamben árulják el.
-
AMD Radeon undervolt/overclock
lo Minden egy hideg, téli estén kezdődött, mikor rájöttem, hogy már kicsit kevés az RTX2060...
-
A személyre szabott reklám lehet a streaming következő slágere
it A jobb célzott hirdetések érdekében adatplatformot indít a Warner Bros Discovery.
-
PROHARDVER!
Arduino hardverrel és szoftverrel foglakozó téma. Minden mikrovezérlő ami arduinoval programozható, és minden arduino program, board, és hardverrel kapcsolatos kérdések helye.
Új hozzászólás Aktív témák
-
zsolti_20
senior tag
Szep napot emberek.
Egy eszkoz felfogatasat a falra szeretnem megoldani. Talalhato ott egy fem alatamasztas, arra gondoltam hogy csinalok egy burkolatot amibe magneseket raknek es igy siman fellehetne tapasztani oda.
Aztan eszembe jutott hogy lehet megsem lenne olyan jo otlet, mert az eszkozben van egy NRF24L01 modul, arduino nanoval, TP4056-al.
Van valakinek tapasztalata a magneses ter mennyire befolyasolja ezeket a modulokat?
Ti hasznalnatok ilyesmit ebben a helyzetben?
Ha nem, akkor marad a duppla oldalu ragaszto aztan remenykedjunk hogy megtartja. -
robertka
tag
.
[ Szerkesztve ]
-
robertka
tag
.
[ Szerkesztve ]
-
robertka
tag
Sziasztok, sajnos véletlenül kitöröltem egy projektemet de egy vissza állító programmal elvileg meg tudtam menteni a fájlt viszont nem értelmes karaktereket tartalmaz. Amikor megnyitom a fejlesztő programban az automatikus formázás felismeri a sortöréseket meg hasonlókat de nem értelmes a szöveg.
Lehetséges ezzel valamit még kezdeni vagy valamilyen helyreállítási metódus?
Köszönöm szépen.
Iyenek a sorok:
���l)=��uz����?m^���ߴ#�_tZ���ض�5{w5��Vi��N
Vagy TXTben:
ÅZ\ÐóÖé}— ùÖyëÃÍsÑó?ØR^þŠ}«šk¤´[ Szerkesztve ]
-
gyapo11
őstag
-
-
gyapo11
őstag
válasz Tankblock #13412 üzenetére
Igen, volt már rá példa. Inkább az a kérdés, hogy észreveszem-e ha meghal a hdd, igen, és mekkora a valószínűsége annak, hogy a munka hdd és a mentésre használt hdd egyszerre hal meg. Ez nagyon kicsi esély, mindig van időm az egyik meghalt wincsit cserélni, és a másikról a mentést újra létrehozni. Bár mostanában már olyan gyorsak a flash-ek is, hogy akár pendrive, akár microsd kártya is megfelel a lokális mentésre. Sokkal egyszerűbb és gyorsabb, mint felhőbe szinkronizálni. Ha programot írok, akkor én akár percenként is mentek egyet, általában sorszámmal megkülönböztetve a mentéseket, aztán addig megyek vissza ameddig akarok, mind ott van. Egy 32 GB-os drive-ra 32 millió db 1 kB-os program változat fölfér.
A githubot nem használom, egyszer néztem valami verziókövető programot lokális változatban, az nem tűnt túl egyszerűnek, nyilván időt kell rá szánni és megtanulni. De nekem jól bevált a helyben mentés sorszámmal.menyország -> mennyország, akadáj -> akadály, jótálás -> jótállás, Iphoneal > Iphone-nal, kisuly > kisujj, csővet > csövet
-
lmaresz
aktív tag
válasz gyapo11 #13413 üzenetére
Ha nem szeretnél felhőt használni semmiképpen, akkor is ajánlatos a GIT (nem github) használata, ugyanis ekkor offline tudsz commitokat készíteni a programod jelenlegi állapotáról és később visszatérni azokhoz. Verziókövetés szempontjából mindenképpen hasznos lehet.
[ Szerkesztve ]
-
Tankblock
aktív tag
-
Gergosz2
veterán
válasz Tankblock #13418 üzenetére
Local GITnek nem sok értelmét látom, mert oké hogy valamilyen szinten verziót követsz, de a remote nyújtotta lehetőségeket pedig nagyon szépen bukod. Nem is kell beszélni róla hogy ez a távoli, más gépen lévő backup, másrészt remote/masterben rendszerint a tényleg forduló verziót szoktuk tartani, localban meg a kismillió branchen lehet fejleszteni amit kell. Jómagam egy rasberry pin hostolom a saját GIT szerveren, egy minőségi SD kártyát használva. Igen, sajnos ugye az utóbbi sem triviális, volt vele tapasztalat (szivás) anno.
[ Szerkesztve ]
Nokia 6030 Hardcore User // I Panic Restaurant by Taito
-
Tankblock
aktív tag
válasz Gergosz2 #13419 üzenetére
Pont ezt mondom én is...
igen azt ki kell tapasztalni, hogyan működik jól. Masterben működő verziót, vagy Release branchekben a működő verziót erre vannak stratégiák....
Az biztos h minnél több helyen van akkor diverzifikáltad az adatvesztést mint rizikófaktort.
sd kártyára még 1x semmit se bíznék, a raspimen is csak a rossz tapasztalat van vele... Én ezért szeretnék olyan mini pc-t amibe SSD/HDD lesz....
Release the Beast....
-
gyapo11
őstag
Nekem volt XP-m ssd-n, és nem volt trim, mert az oprendszer nem támogatta. Win7 már igen. Nem lehet, hogy a Raspberryn futó oprendszeren múlik a dolog?
Másrészt a trim csak az írást gyorsítja, inkább a wear levelinget kellene megoldani sd-re, és akkor annyit bír mint az ssd.menyország -> mennyország, akadáj -> akadály, jótálás -> jótállás, Iphoneal > Iphone-nal, kisuly > kisujj, csővet > csövet
-
atesss
addikt
Üdv !
Használt már itt valaki PCF8574 alapú I2C-s I/O modult ?
Azon belül is a különálló Interrupt Pin működése érdekelne.
Én ugyan most Raspberry Pi-n használom, Python kóddal, de ez a probléma nem úgy néz ki hogy ettől függene, a modul működésében lehet valami hiba vagy furcsaság.Ez az Interrupt pin arra szolgálna, hogy ha történik bármelyik PIN-en változás, akkor ez a pin megváltozik. A fő kontroller így elég ha csak annyit csinál, hogy ezt a pin-t figyeli (akár interrupt-al, de akár csak polling-al). És csak akkor állok neki az I2C-n keresztül kiolvasni a bemenetek állapotát, ha ez a pin jelzi hogy változás történt.
Az hátrány, hogy egy külön pin-t fel kell használni hozzá.
Cserébe a kód gyorsabb tud lenni, meg kevesebb erőforrást használ (nem használom folyamatosan az I2C buszt). Egy Arduino-n ez szerintem még inkább fontos tud lenni.Én konkrétan ezt a modult használom: [link]
Ahogy láttam, nem mindegyik modulnál van sajnos kivezetve ez az Interrupt pin.
Az IC adatlapja [link] elég részletesen leírja a működését (az INT működése részletesen: 11.old).
A 15. oldali példakapcsolás alapján kötöttem be (10 kOhm pullup VC-re). Annyi, hogy nálam nem rögtön megy a fő kontrollerre, hanem még van ott egy 330 Ohm ellenállás is sorosan (ezt biztonsági okból a Raspberry-nek minden használandó GPIO pinjére felraktam, kapásból, fixen).
Én úgy vettem ki a leírásból (meg ez is lenne a logikus), hogy ahogy csinálsz a modulról egy kiolvasást, akkor az INT pin rögtön "nullázódik" is. Ez elvileg mindössze 4us kéne legyen (adatlap: 5.old).
Amikor változás van, rendben 1-be vált az INT pin. Utána kiolvasom az összes bemenetet, rendben látszik is hogy a PCF8574-nek melyik bemeneti pinje változott meg.
De az INT 0-ban marad ez után is, nagyon sokáig.
Direkt beraktam sleep-et, hogy teszteljem ezt, és még 0.1s után is maradt.
A programkódom ennek ellenére jelenleg ellátja a feladatát, és épp a következő gomb-megnyomáskor vagy elengedéskor mégis újra meghívja a kiolvasó függvényt. Ezt még nem teljesen értem hogyan, most próbálom kideríteni
De attól még a modul nem működik úgy ahogy kellene.
Multiméteren is felugrik az érték az INT pin-t mérve (ha pár msec lenne, akkor ezt nem mutatná ki), de szkóppal sajnos most pont nem tudom megnézni pár napig.
Van valakinek ötlete ?[ Szerkesztve ]
-
And
veterán
válasz atesss #13426 üzenetére
A bemenetek mindegyikére tettél felhúzó ellenállást? Nincs prell a bemenet(ek)en? Egyáltalán: csak adatot olvasol a PCF-ből, vagyis minden portot bemenetnek alkalmazol?
Ennek a port extendernek az előnye - nem kell külön belső regisztereket konfigurálni - egyben hátrány is lehet. Egy jobban beállítható extender, pl. az MCP230xx esetén portonként be lehet lőni az adatirányt, maszkolni a megszakítást (adott input eredményezzen-e olyat), és az INT-kimenet működése is elég részletesen befolyásolható. -
atesss
addikt
Hát igazából felhúzó ellenállást nem raktam fixen a Raspberry GPIO pinekre, csak egy soros 330 Ohm-os ellenállást.
Mondjuk belegondolva ez - ha a GPIO bemenet Mosfet-es, amire jó esély van - akár okozhatna is problémát. Bár eddig még sehol nem fordult elő ebből problémám.
De ha pont ez okozná a gondot, akkor miért lesz a "GPIO-nullázódás" ideje pont ilyen "emberi léptékű" tized-másodperces időtartományban ?
Igen, mind a 8 pin bemenetként van használva.
Illetve pontosabban a 8-ból 2 nincs is használva, azt én nem is kötöttem be sehova.
Ugyan nem tudom a modulon belül van-e bárhova kötve, de igazából nem nagyon kellene. Főleg nem VCC-re.
Igen, azt néztem is hogy ezt "quasi-bidirectional" -nak írták. De eddig még nem mentem bele, hogy ez pontosan mit is jelent elektronikai szempontból.
"maszkolni a megszakítást (adott input eredményezzen-e olyat)" - Ez is hasznos mondjuk.
Hát ezek tényleg nagy előnynek hangzanak azért így együtt már. Utánanézek részletesen akkor ennek az MCP230xx-nek is.
Csak persze az is kérdés, hogy mennyivel drágább ez a modul...
Meg mennyivel nagyobb a modul nyákja, stb. -
Tankblock
aktív tag
válasz gyapo11 #13422 üzenetére
Egy normális SSDben van támogatva a wear leveling figyelése és nem ugyanoda irogat vissza, plusz a cachelése is jobb. SD nél meg max ha az oprendszer figyel rá....
Nálam SD kártyából több hallt már meg mint ssd/hdd ből...
Igen lehet RPi4 is SSDről futtatni/bootolni.
Attól én még hiszek a különböző lokációkon tárolt adatokban, azok nehezebben sebezhetőek... Bármely gépről hozzáférehetőek.[ Szerkesztve ]
Release the Beast....
-
And
veterán
válasz atesss #13429 üzenetére
"Hát igazából felhúzó ellenállást nem raktam fixen a Raspberry GPIO pinekre, csak egy soros 330 Ohm-os ellenállást."
Nem is a RasPI GPIO-pinjeire gondoltam, hanem a PCF8574-re: ha a portjait csak inputnak használod (másképp fogalmazva: az I2C-busz csak olvassa a chip-et, sosem írja), akkor a portok mindegyikére illik 1-1 felhúzót tenni, lásd a rajzot a 15. oldalon, amire korábban hivatkoztál. Lebegve hagyni csak akkor lehet a Px-portok bármelyikét, ha kimenetként írod azokat (a többivel együtt).
"Utánanézek részletesen akkor ennek az MCP230xx-nek is. Csak persze az is kérdés, hogy mennyivel drágább ez a modul..."
Maga az MCP23008-as chip (ez a 8-portos, a PCF8574-hez hasonló kivitel) nettó 300 Ft körül kapható a hazai forgalmazónál, szóval van rá esély, hogy ha valaki nagy tételben veszi a gyártótól és modulra építi, akkor nem lesz veszett drága a PCF-es modulhoz képest. Ha nyákot is tervezel a kész kivitelhez, akkor meg mindegy, maga a chip is elegendő.
Emlékeim szerint volt már említve ebben a topikban az MCP23..-as I/O-extender, és mások is jó véleménnyel voltak róla. Létezik belőle SPI-buszos kivitel is, MCP23S08 típusjellel. Elég jól felépített, valódi kétirányú portokkal rendelkezik, 11 belső regisztere van és szanaszét konfigurálható. -
atesss
addikt
Ahha, látom, igazad van.
100kOhm-ot ajánl felhúzónak. Most csak 10kOhm van itthon (már ha egyáltalán megvan az a maradékom még 8db), az esetleg jó lehet ?
A bemenetek közül 4db mikrokapcsoló, 2db meg mikronyomógomb. Ezek most egy-egy 2,2kOhm-os ellenálláson keresztül húzzák földre a pineket, amikor átkapcsolom a kapcsolót/lenyomom a gombot.
Így is jó lehet még a 10k ?Mondjuk azt még mindig nem annyira értem, ez hogyan okoz ilyen hibát. A - felhúzóellenállás hiányában - ha pl. a mosfet feltöltődik, akkor hogyhogy pont ilyen tizedmásodperc nagyságrendű idő lesz mire visszaáll ?
Illetve nem is. Ha az Interrupt Pin 1-es, akkor ez azt jelenti, hogy változott a bemenet.
Vagyis akkor lebeg a Pin, azaz 0 és 1 között ugrál folyamatosan ?Hát hozzávetőleges támpontnak jó az IC ára.
De igazából az a kérdés, a kínaiak mennyiért építettek rá kész modult.
Azt meg nem mindig lehet ilyen egyszerűen magyarázni. Pl. volt hogy néztem, hogy egy teljes modul ára a nagy(1000+) db-os tételben kapható IC áránál is jelentősen olcsóbb volt...MCP230xx-ból amúgy van 16 portos, vagy akár még annál is nagyobb kivitel ?
[ Szerkesztve ]
-
And
veterán
válasz atesss #13432 üzenetére
"2,2kOhm-os ellenálláson keresztül húzzák földre a pineket, amikor átkapcsolom a kapcsolót/lenyomom a gombot."
A bemenettel soros ellenállás nem igazán kell, de ha maga a port nincs elhúzva a Vcc felé, az nem oké. Lehet 10kΩ is a felhúzó, az csak annyit eredményez, hogy aktív (alacsony) inputnál, megnyomott gombnál a rajta átfolyó áram nagyobb lesz. Nagyimpedanciás inputot amúgy sem szokás szabadon hagyni: extrém alacsonyra tervezett nyugalmi áram (pl. telepes táplálásnál) helyett megnövekedett nyugalmi áramfelvétel, határozatlan szint az eredménye.
16 portos MCP-verzió: MCP23017 (I2C) vagy MCP23S17 (SPI). -
nagyúr
Nem kell külső felhúzó ellenállás, az MCP23017-ben például van belső felhúzó (asszem 100k).
atesss:
"Amikor változás van, rendben 1-be vált az INT pin. Utána kiolvasom az összes bemenetet, rendben látszik is hogy a PCF8574-nek melyik bemeneti pinje változott meg.
De az INT 0-ban marad ez után is, nagyon sokáig.
Direkt beraktam sleep-et, hogy teszteljem ezt, és még 0.1s után is maradt."Elolvastam vagy 5x, de nem értem. Amikor változás van, miért vált 1-be az INT pin? A PCF8574 INT kimenete active low, vagyis az alaphelyzet az 1, és akkor vált 0-ra, ha van interrupt.
Szerintem fordítva ültél fel a lóra.[ Szerkesztve ]
-
atesss
addikt
Pedig nagyon úgy néz ki hogy kell külső felhúzó ellenállás a PCF8574-nél.
Legalábbis az adatlap 15. oldalán a "Typical Application" ábrájára gondolom hogy nem véletlenül rakták fel.
De most megint átnézve az adatlapot, igazából olyan infót viszont nem találtam leírva, hogy "muszály" tenni.
Az MCP23017 az könnyen lehet hogy más, simán lehet hogy abba viszont már építettek be. (Ez akkor még egy - nem is kicsi - előnye lenne akkor annak az IC-nek, illetve a rá épülő moduloknak.)Na ezt elírtam. Javítva így néz ki:
Amikor változás van, rendben 0-ba vált az INT pin. Utána kiolvasom az összes bemenetet, rendben látszik is hogy a PCF8574-nek melyik bemeneti pinje változott meg.
De az INT 0-ban marad ez után is, nagyon sokáig.És a multiméteres mérést is pontatlanul írtam:
"Multiméteren is felugrik az érték az INT pin-t mérve (ha pár msec lenne, akkor ezt nem mutatná ki), de szkóppal sajnos most pont nem tudom megnézni pár napig."
Ebben az esetben az INT pin-t a VCC-hez (3,3V-hoz) képest mértem.
Vagyis alapból 0-t mutat a multiméter (1-esben, azaz 3,3V-on van az INT). És ha Interrupt van akkor pedig a felugró érték egy negatív lesz (nem megy el -3,3V-ig, de kb. olyan -1,5V-ig igen).
De a lényegen ez igazából nem változtat. Az a probléma, hogy olyan hosszú időre megváltozik az Interrupt pin, hogy ezt még egy mezei multiméter is simán kimutatja.[ Szerkesztve ]
-
And
veterán
A kötelező felhúzót a PCF8574-re írtam, az MCP-kben valóban van 100k-s belső kapcsolható ellenállás. A PCF INT-polaritásában igazad van, de ez eddig nem is tűnt fel . Az adatlapon első blikkre kicsit megtévesztő. Még jó, hogy az MCP-k esetén az INT-jel polaritása is megszabható, meg az is, hogy csak open-drain kimenet legyen, vagy push-pull.
-
atesss
addikt
Hát a kódom elég gyorsan fut (kb. pár msec lehet egy teljes ciklus), ennyi időnként pollingolja a Raspberry-nek azt a GPIO bemenetét, amire rákötöttem a PCF8574-nek az INT pinjét.
Amint azt érzékeli a fő programszám, hogy 0-ban van ez a GPIO, rögtön meg is hívja a PCF8574-et I2C-n kiolvasó függvényt. A PCF8574 pedig a kiolvasás után magától, rögtön (adatlap szerint, ha jól olvastam ki, 4usec-en belül) alaphelyzetbe (azaz 1-esbe) állítja az INT Pint.
Tehát elvileg pár msec időre kellene csak megváltoznia az INT pinnek. Amit pedig egy multiméter észre se venne.
Szerintem - maximális eltérésként, de ez tényleg csak egy pillanatra (a multiméter-kijelzőt szemmel olvasva) - az a -1,5V körüli érték azt jelenti, hogy ennél jóval több időre megváltozott.
Nem tudom pontosan mekkora egy mezei multiméter sebessége, milyen ADC van benne, de kb. pár tized sec lehet a mérési illetve átlagolási ideje. A -1,5V kb. azt jelenti, hogy a megváltozott érték időtartama nem éri el az átlagolási időt, de közelít hozzá (nagyon durva becsléssel fele körül van).
De hát sokkal pontosabb lenne ezt szkóppal kimérni
Most már kíváncsi vagyok, asszem inkább várok, és nem is forrasztom be fixre a felhúzó ellenállásokat mielőtt letesztelném szkóppal.Nincs bekapcsolva a pulldown a raspberry-n.
[ Szerkesztve ]
-
atesss
addikt
Adatlap 11.oldala:
Resetting and reactivating the interrupt circuit is achieved when data on the port is changed to the original setting or data is read from, or written to, the port that generated the interrupt. Resetting occurs in the read mode at the acknowledge bit after the rising edge of the SCL signal, or in the write mode at the acknowledge bit after the high-to-low transition of the SCL signal.
...
This device does not have internal configuration or status registers. Instead, read or write to the device I/Os directly after sending the device address (see Figure 16 and Figure 17).
By sending an interrupt signal on this line, the remote I/O can inform the microcontroller if there is incoming data on its ports without having to communicate by way of the I 2C bus. Therefore, PCF8574 can remain a simple slave device.Úgy néz ki ez nem tud ilyet, nem tudom felülírni az INT regisztert, mert nincs olyan neki (vagy legalábbis ha van is valami belső, kívülről nem hozzáférhető).
[ Szerkesztve ]
-
atesss
addikt
A kódba beraktam debug-nak plusz lekérdezéseket, ami lekérdezi az INT lábat, és kiírja a terminalra.
Közvetlenül az I2C-s kiolvasó függvény elé is raktam be, illetve közvetlenül utána is.
Plusz kipróbáltam azt is, hogy az I2C-s kiolvasó függvény után beraktam még sleep()-et. Először egészen rövidet (0.0001 sec asszem), gondolva hogy oké, alapból akkor "túl gyors" a Raspberry, de ha berakom a sleep()-et, utána már tényleg újra HIGH-ban lesz.
Aztán utána, hogy láttam hogy még mindig LOW maradt, növeltem ezt a sleep()-et. Elmentem egészen 0.1 sec-ig, és még akkor is LOW maradt. -
atesss
addikt
Hát én erősen kétlem.
A PCF8574-hez ezt a python library-h használom: [link]
Most közben frissítettem a kódomat, és az INT pin-t most már nem pollinggal, hanem interrupttal kezelem le.
De a problémás résznél nem történt semmi változás.
Bemásolom akkor az összes releváns részét a kódomnak.
Bár ez már így kicsit OFF kezd lenni, mert az Arduino miatt általában C vagy C++-t szoktatok írni a topicba.import RPi.GPIO as GPIO
I2C_IO_INTERRUPT_GPIO = 26 # Board (physical) Pin Number 37
GPIO.setmode(GPIO.BCM)
GPIO.setup(I2C_IO_INTERRUPT_GPIO, GPIO.IN)
from pcf8574 import PCF8574
I2C_PORT_NUM = 1
I2C_IO_ADDRESS = 0x20
i2c_io = PCF8574(I2C_PORT_NUM, I2C_IO_ADDRESS)
def i2c_io_reader():
io_interrupt_flag = GPIO.input(I2C_IO_INTERRUPT_GPIO)
print("Interrupt pin állapota - olvasás előtt: ", io_interrupt_flag)
i2c_io_readed_array = i2c_io.port
time.sleep(0.001)
io_interrupt_flag = GPIO.input(I2C_IO_INTERRUPT_GPIO)
print("Interrupt pin állapota - 0.001 sec-el olvasás után: ", io_interrupt_flag)
return i2c_io_readed_array
def i2c_io_interrupt_handler(channel):
i2c_io_readed_array = i2c_io_reader()
i2c_io_readed_array_reversed = i2c_io_reverser(i2c_io_readed_array)
i2c_io_state = i2c_io_namer(i2c_io_readed_array_reversed)
i2c_io_evaluator(i2c_io_readed_array_reversed, i2c_io_state)
i2c_io_printer(i2c_io_readed_array_reversed, i2c_io_state)
GPIO.add_event_detect(I2C_IO_INTERRUPT_GPIO, GPIO.FALLING, callback=i2c_io_interrupt_handler)
[ Szerkesztve ]
-
atesss
addikt
Na most próbálkoztam tovább még más sleep időtartamok megadásával.
Illetve a main függvénybe (ami másodpercenként kb. 70-80x lefut) is beraktam egy kiiratást.
Nekem úgy tűnik, hogy hiába adok meg kb. bármilyen időtartamot...Viszont a main függvényben lévő kiiratás meg már az első alkalommal is HIGH-nak írja az INT pint. Mindegy, hogy ez az előbbi sleep idő most éppen néhány msec volt, vagy 400msec...
Lehet hogy amint kilépek ebből a i2c_io_reader() függvényből, akkor frissülhet csak a GPIO pin állapota ??[ Szerkesztve ]
-
gyapo11
őstag
válasz atesss #13448 üzenetére
A multiméter másodpercenként 2-3 mintát vesz, és azt kijelzi 0.5-0.33 másodpercig. Nem tudom a konkrét mintavétel meddig tart, de ha rövid ideig, és a tárolt mintát méri meg, akkor ha egy 1 ms-os 5 V-os impulzusba éppen belemér, akkor akár fél másodpercig mutathatja, hogy 5 V, ez szemmel már jól észlelhető. Az analóg műszer más, de azt nem hívjuk multiméternek.
menyország -> mennyország, akadáj -> akadály, jótálás -> jótállás, Iphoneal > Iphone-nal, kisuly > kisujj, csővet > csövet