<oliv3r>
let me see if mnemoc has put it up allready
<oliv3r>
this isn't much prettier :)
<oliv3r>
mnemoc: how much work is it to put lichee-3.4 up on your github? i think we have nothing now at all; so can't use it easily and qujickly as reference
<gzamboni>
steev i think mnmoc implemented a soc detect so all the ARCH_SUN4I [=n] || ARCH_SUN5I [=n] || ARCH_SUN7I [=y] dependencies are broken
<steev>
er
<steev>
hmm
<steev>
commit 03960552f is incorrect - i mean, the commit message is missing a signed-off-by, by whomever that russian guy is
<steev>
gzamboni: i don't see anything like that in the commit messages
<steev>
hmm, a few commits are like that. and ssvb did one! ssvb you bad! signed-off-by!
<oliv3r>
"but it's only 3.4"
<gzamboni>
i saw it somewhere, maybe here in IRC or on the ML
<mnemoc>
oliv3r: where is this lichhe-3.4? does it have history or a.known base?
<steev>
oliv3r: idgaf
<steev>
nak all the patches!
<tgaz>
jukivili: (musb sunxi) it seems FADDR is only usable when EPIND==0. i get 0 read back if not so. seen that before?
<Montjoie>
Do you know why I detect only the first I2C bus on cubieboard2 with sunxi3.4 ?
<oliv3r>
Montjoie: good question :(
<tgaz>
Montjoie: seems controlled by twiX_para in the fex (unless you concluded yesterday it's not used anymore)
<oliv3r>
mnemoc: it was with the latest SDK drop for a20; but i can't find it on builder either; and i'm prety sure i thought i downloaded i
<oliv3r>
mnemoc: haven't you had 2 tree's for lichee/ one only whitespace/utf-8 cleanup branch
<oliv3r>
and one more heavily sanitized one?
<oliv3r>
i forgot
<mnemoc>
import/ are sanitized
<mnemoc>
lichee*/ are raw.... but from trees that come with history
<mnemoc>
SDKs usually don't come with proper .git .... just symlinks to a mutilated .repo
shineworld has joined #linux-sunxi
<oliv3r>
yeah
<oliv3r>
ok so that plan won't fly
<mnemoc>
so sanitize the tree, and then find which commit in android-3.4 produces the smallest diff
<mripard>
oliv3r: that the gpio/pinctrl driver was not probed yet, and that it will retry later
<mripard>
(hence why it works)
<mnemoc>
and then commit the sanitized dump upon it, and then try to rebase upon the latest android-3.4, and finally upon reference-3.4
<mnemoc>
but the first commit is mostly only that's needed for initial reference
FR^2 has joined #linux-sunxi
Soru has quit [Ping timeout: 240 seconds]
CoSM0 has joined #linux-sunxi
Soru has joined #linux-sunxi
<oliv3r>
mnemoc: yeah, someone who has done that or is better at that should do that :)
<mnemoc>
oliv3r: I'll do it tonight :)
<mnemoc>
doing it from connect bot is not fun
<oliv3r>
haha no it's not :)
<oliv3r>
mripard: ok; then i won't pay too much attention to it for now ;)
<steev>
oliv3r: fyi, the signed off by is to cya, in case some company swoops in and says, hey that's our code
<oliv3r>
i know :)
<oliv3r>
hence the qutoes
<steev>
heh
<steev>
mnemoc: juice ssh
<steev>
> connectbot
<mnemoc>
steev: still tiny keyboard :<
<mnemoc>
but i'll install it
<steev>
oh, right, on the phone
<steev>
i like juice far more than connectbot, but yeah, on a phone it would still suck
<oliv3r>
mnemoc: k9 doesn't do threading; i can't find it :)
<mnemoc>
oliv3r: already uninstalled it :p
<mnemoc>
it's even more annoying than google's... and all my publicly reachable imap accounts are controlled by G anyway
<jukivili>
tgaz: MUSB_FADDR seems to be only used with ep0 in musb
<tgaz>
jukivili: i couldn't find anything in the musb docs about that requirement, so i was a bit surprised.
<oliv3r>
mnemoc: it's a really nice email app thouh; and as it does imap-idle saves battery + notifies you without polling
<oliv3r>
though the 4.0 default e-mail app seems to have threading, so i'm thinking of giving that a try
<tgaz>
jukivili: trying to port the sunxi driver to u-boot for usbtty.
<oliv3r>
mnemoc: how is it annoying? specifyt
<mnemoc>
oliv3r: notifies me of mails each half a second :(
<oliv3r>
lol that's imap-idle :D
<jukivili>
tgaz: ok.. I don't have musb documentation.. only reference I have is the allwinner driver
<mnemoc>
oliv3r: the google app handles the "important" flag
<oliv3r>
i have my lists account on my tablet, and disabled push and poll; manually checking
<oliv3r>
ah, i never used that, so don't know
<tgaz>
jukivili: the PSPG is on baidu and docin. search for "musbmhdrc_pspgusb" and you can browse it.
<tgaz>
jukivili: anyway. did you have any specific issues with the driver when you stopped working on it? (i gather you're busy with other stuff)
<jukivili>
tgaz: allwinner driver defines FADDR register same as TXFUNCADDR/TXFADDRx
<tgaz>
yeah, i noticed. are those registers indexed in sunxi?
<tgaz>
(as opposed to flat access)
<jukivili>
tgaz: getting otg working is problematic since I don't have working reference hw and allwinner driver does host-mode<=>device-mode switching quite differently than is done with musb
<tgaz>
jukivili: i got a usb console working.
<jukivili>
aw driver has manager module that detects id-pin changes, unloads host/device-mode driver and then loads device/host-mode driver
<tgaz>
i'm still not sure what OTG implies on the protocol level, though.
<tgaz>
ah, yes. that thread...
<tgaz>
coldplugging works, at least
<tgaz>
(after i added FADDR=0 to undo what BROM does during FEL boot)
<jukivili>
registers are indexed
<tgaz>
ok
<jukivili>
(atleast that's how they are used in aw driver)
<tgaz>
jukivili: do you still think using the musb framework is the way forward? or is it too different?
<jukivili>
absolutely, most of the things work already
<tgaz>
jukivili: *nod* will you have any time working on the hotplugging? would you like some help (after the u-boot porting)?
<jukivili>
otg requires more work.. I have mode detection working, just have not yet figured out how to reset musb-core and hw from host-mode to periherial and other way around
<jukivili>
after that work, mode detection/usb-phy stuff probably needs to be moved to new usb-phy driver as is done with other musb hw drivers
<jukivili>
I don't have much time but I'll try to look in to it when I have
<tgaz>
ok
iamfrankenstein has quit [Ping timeout: 240 seconds]
iamfrankenstein has joined #linux-sunxi
tzafrir_laptop has quit [Read error: Operation timed out]
notmart has joined #linux-sunxi
notmart has joined #linux-sunxi
notmart has quit [Changing host]
<speakman>
any suggestions how to debug interrupts in the kernel in a modern proper way? any support in debugfs for such things?
mcbrick has quit [Remote host closed the connection]
<tgaz>
jukivili: i updated the Linux mainlining effort page with your "status update". i hope you don't mind.
<Turl>
speakman: /proc/interrupts
<speakman>
Turl: thanks! :) Also found trace_printk. Interesting stuff traces! :)
<speakman>
Seems like there is some trouble with interrupts on GPIO on A20...
<Turl>
speakman: how did you define the pins you're going to use?
<Turl>
yeah that
<Turl>
sec
<Turl>
speakman: replace <0> with <5>
<speakman>
Turl: ok, but what does it do really?
<speakman>
Looking in the Fex guide but can't reallt figure out those values
<Turl>
speakman: that number is the muxing
<speakman>
ok, 2 = MUX2 and so on?
<Turl>
first two are always gpio in/out (or out/in, never remember)
<Turl>
speakman: yes
<Turl>
the user manual has tables with the possible muxings
<speakman>
according to A10/PIO MUX6 is EINTx.
<Turl>
speakman: hm, my copy of the A20 manual lists them on mux 5
<speakman>
Ok
<Turl>
speakman: the A10 one does on 6
<Turl>
if it doesn't work with one, just try the other
ykchavan has quit [Quit: Leaving]
<speakman>
Weird direction can't be set by gpio_set_direction()?
FDCX has joined #linux-sunxi
tzafrir_laptop has joined #linux-sunxi
<speakman>
interrupt's working! :)
wingrime has quit [Ping timeout: 248 seconds]
shineworld has quit [Remote host closed the connection]
<oliv3r>
Turl: you are good add reading backtraces right? :) http://sprunge.us/ZRRf i obviously recognize the function names and it's from my driver i'm pretty sure, but how do I tell which function causes the crash exactly?
<oliv3r>
Turl: hmm, i seem to have 1c18000.sata and ahci there :S
<Turl>
oliv3r: ahci is probably some standard name
<oliv3r>
my github isn't updated yet with all latest chagnes, and i'm actually using his tree of my code as he got 'some' output whereas i didn't even get a serial console, missing clocks etc
<libv>
wingrime: you mean, it is not in the same command queue as the mali, and you would have to actually do some work and get some synchronization working?
<steev>
wingrime: actually, the timesys version only comes with the x11 stuff
<libv>
wingrime: we cannot afford to be lazy and incompetent wankers like the rest of them, we actually have to deal with separate blocks
<oliv3r>
synchronization is a bitch to get right :( but worth it in the end! :)
<Turl>
oliv3r: maybe, dunno
<libv>
(yes, the intellectual midgetery of megadrivers is getting to me :p)
<oliv3r>
:p
<Turl>
oliv3r: one lock to rule them all
<oliv3r>
lol
<oliv3r>
Turl: only let probe run once?
<Turl>
then lock contention is what you need to deal with
<oliv3r>
might be a little over my head for now
<Turl>
oliv3r: it was an answer to your sync msg
<oliv3r>
Turl: ohhh
<Turl>
oliv3r: dunno why it's registering twice (or if that's the case)
<Turl>
oliv3r: try adding a print on the start and see how many times probe gets called
<oliv3r>
lets sprinkle some printk's
<wingrime>
libv: I prefer deal with d2 on mali
<wingrime>
*2d
<oliv3r>
wingrime: but mali does not have a 2D engine
<oliv3r>
wingrime: you have to use glamour or the like,to emulate 2D on 3D
<wingrime>
oliv3r: not acctualy emulate
<wingrime>
oliv3r: normal driver can do it normal
<oliv3r>
shippment has left the import parcel center in destination country!
<oliv3r>
that was last night; so delivery HOPEfully today
<libv>
wingrime: feel free to explain me how.
<libv>
wingrime: i have some idea on how to do some things of it, but i still find it wholly inefficient, lazy and dumb.
<mnemoc>
oliv3r: congrats!
<oliv3r>
Turl: yep double probes, between the two i get platform sunxi-ahci: Driver ahci requests probe deferral also :S *sigh*
<libv>
wingrime: i really rather doubt that you have understood how the mali works, and what its biggest bottleneck is, especially on allwinner hw
<oliv3r>
oh no, 3 probes
<oliv3r>
the 3rd one happens after the oops
<mripard>
oliv3r: bad error path ?
<Turl>
oliv3r: ahh it's a deferral
<Turl>
oliv3r: let me have a second look
<oliv3r>
mripard: i mostly copy/pasted the code, i took the imx platform ahci approach, and added the secret ahci init from AW
<oliv3r>
mripard: so would this go better/easier with a platform_ahci_register()?
<oliv3r>
mripard: as it appears i'm doing a lot of that manually in the probe
\\Mr_C\\ has joined #linux-sunxi
<mripard>
I don't know, but your error definitely looks like you're leaking something in the first probe
<Turl>
oliv3r: try platform_device_del instead of _put on the error path
<mripard>
and then called a second time, with your error.
<oliv3r>
mripard: then searching will be harder :)
<mripard>
oliv3r: but again, search for some leaked resource
<mripard>
you can try to load/unload your driver as a module for example.
<oliv3r>
mripard: oh that's a good one
<oliv3r>
i'll modularize it
<Turl>
mripard: we have the fastest boot of the multiv7 bunch :)
<oliv3r>
and sprinkle more printk's
<oliv3r>
maybe i should try to write a platform_ahci_register first :D
<mripard>
Turl: we have less features as well :)
<Turl>
mripard: shh :P
<Montjoie>
Does someone have doc/datasheet about internal thermal sensor of A20, I found nothing.
<oliv3r>
ahci soon! :p
<oliv3r>
Montjoie: check the usermanual of a20
<oliv3r>
Montjoie: read the touch-panel section; same for a10 manual
<oliv3r>
Montjoie: tonight we can link you sunxi-temperature.c
<Montjoie>
ok thanks, but confirm that TP != internal sensor of A20 please
<Montjoie>
because I found the doc about TP
<oliv3r>
Montjoie: the touch panel has the temperature register inside it
<oliv3r>
Montjoie: very strange place yes, but on the other hand, it's just a bunch of ADC's and you can use them as ADC if you wish to do so, so it's not entirly weird that the temperature diode is connected to one of those adc's :)
<Montjoie>
I believed that there are another sensor different than TP
<mnemoc>
ask eva :)
<mnemoc>
maybe eventually they decide to release all the documentation.... at least for A1x
<mnemoc>
even if it's in chinese
<n01>
not a strange place at all actually. almost all uC have internal temp sensor
<oliv3r>
well we have 2 adc's i think, the LRADC's and the TP adc's
<oliv3r>
so it makes sense to have it in one of those places
<Montjoie>
I need to resend a better patch to the mailing list, how to send all patch since a commit as a single patch ?
Black_Horseman has quit [Remote host closed the connection]
rz2k has joined #linux-sunxi
Gerwin_J has joined #linux-sunxi
<n01>
git rebase -i
<n01>
its better if you squash all the commits
<oliv3r>
git send-email -4
awafaa has joined #linux-sunxi
<speakman>
this FEX thing, is it an Allwinner construction?
<mnemoc>
yes
<mnemoc>
it was their way to implement multi-board support ages before DTS
<Montjoie>
with git-send-email -x, all patch are sended one by one, I want a big merged one
<mnemoc>
make a branch, and squash them
<oliv3r>
not AGES, dts is far older then their fex approach :)
<oliv3r>
Montjoie: then you have to squash your commits :)
<oliv3r>
git rebase -i HEAD~X; then use 'fixup' or whatever you prefer to merge them :)
<mnemoc>
oliv3r: well.... multiplatform is a 3.8 thing. and they used those .fex before 2.6.36 and probably in their RTOS too
<mripard>
mnemoc: DTS has been introduced for ARM in something like 2.6.39 or 3.0
<mnemoc>
ah, ok
<mnemoc>
I thought it came with the multiplatform initiative
<mnemoc>
after linus' explosion of rage against ARM vendors
<libv>
then fex is probably older, as we have a 3.0 kernel with full fex support
<libv>
not that it is the way forwards, but fex is there for historical reasons, period.
<mnemoc>
2.6.36 imported from an undefined older kernel sun[34]i support, already .fex based
leowt has joined #linux-sunxi
<mripard>
mnemoc: nah, it was the other way around, multiplatform has been built-up on top of DT
JohnDoe_71Rus has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
<mripard>
and indeed, multiplatform has been introduced in 3.8
<mripard>
libv: I'm not saying otherwise.
<oliv3r>
well PPC used DTS before that didn't it
<oliv3r>
i'm pretty sure i read on the lkml flame thread fex vs dts; that dts was quite older, albeit not for arm
<libv>
it isn't the worst thing that an SoC maker reinvented
<mnemoc>
anyhow, .fex was designed for single-soc, .dts was designed for allowing different ones
<oliv3r>
and my dts is broken :S
<mnemoc>
and for single-soc .fex is not that bad
<libv>
.fex is historic, dts is the future. .fex gives us mostly functioning allwinner today, dts conversion still needs a lot of work
<mnemoc>
and very cheap to parse.... the same can't be told about dts
<ssvb>
wingrime: a single CPU core with software rendering runs circles around any 2D hardware "acceleration" attempt in X11, only Intel SNA is the exception
ykchavan has joined #linux-sunxi
<mnemoc>
libv: that's the goal of the 3.10 stable branch, push the crap drivers into dts and get a fully functional dts-based env long before the drivers are mainline ready
<mnemoc>
turning 3.4 into legacy
<mnemoc>
it would be awesome if u-boot spl was able to read the dram and led data from the .dts....
<mnemoc>
not only having single kernel, but also single bootloader
<libv>
ssvb: but rules out using that cpu for anything else :p
<ssvb>
wingrime: and G2D in A10/A20 is rather feature crippled, G2D in A31 is supposed to be a nice upgrade, but unfortunately we are not interested in A31 hardware
<ssvb>
libv: who cares when we have octacores? ;)
<libv>
ssvb: on the N9, i ended up making all blits smaller than a given size, not use the pvr
<libv>
getting pvr going on anything took ages, and ate 8mb of mem
<mnemoc>
A80 could become a good motivator for people to start digging into pvr
<speakman>
Any one knows whether A20 is 5V tolerant on IO pins (attached through at least 100KOhms resistor)?
<mnemoc>
speakman: 3.3v only I believe
heffer has quit [Ping timeout: 246 seconds]
<ssvb>
libv: didn't they rip out xrender extension support in n9? at least iirc they seriously wanted to do this
<ssvb>
libv: but yeah, that's how it worked in n900
<speakman>
mnemoc: datasheet seems to follow you there. "High-Level Input Voltage" MAX=3.6V
<mnemoc>
\o/
<speakman>
:/
<mnemoc>
3.3+10% tolerance
<speakman>
I've got 5V signalling from a device. I could of couse divide it into 3.3v but that would require the device to not have any resistors in serie. It depends on the output impedance.
<mnemoc>
aren't there cheap i/o boards to deal with 12V from 3.3V devices?
<mnemoc>
"up-to"
<mnemoc>
you can set the output level in the .fex line
<mnemoc>
but don't remember the meaning of the numbers
<mnemoc>
it's probably documented in the mainline gpio driver docu
<slapin>
speakman: only 3.3v +a little
<slapin>
speakman: just use voltage converter
<speakman>
slapin: "voltage converter"? I'm looking into a simple level shifter atm
Tsvetan has quit [Read error: Connection reset by peer]
* atsampson
would ignore that "simple" project -- that's ridiculously complicated!
<speakman>
"Due to problems we have encountered recently"
<speakman>
atsampson: ^
popolon has quit [Quit: Quitte]
<speakman>
slapin: thinking of adding a dual not gate on a separate board.
<slapin>
speakman: I think mosfet approach is better, anyway, all these voltage convertors are actually a mosfet, 2 diodes, 2 resistors
popolon has joined #linux-sunxi
<oliv3r>
i don't get it; exact same driver, fails to get probed on turls kernel, but loads sorta fine on ianc's kernel
<Montjoie>
oliv3r, I got temperature from TP, but it is relative to something but what...
jemk has joined #linux-sunxi
Soru has joined #linux-sunxi
<oliv3r>
the SoC? :p
<oliv3r>
Montjoie: tonight we'll have a proper driver that you can compare against
<Montjoie>
ok, It could help because the sun4i-ts give me 1885 as temp value
<mnemoc>
1885 what?
ganbold_ has joined #linux-sunxi
<Montjoie>
good question
<Montjoie>
If it is the same conversion as the AXP209 it is (1885 - 1446) / 10 degrees
<Montjoie>
43.9°C
<mnemoc>
do you have something to measure the real temp and compare?
<Montjoie>
But the user manuel is empty about the conversion of the value
<Montjoie>
I have nothing
<mnemoc>
44C sounds kind of high....
<mnemoc>
1885/100 ? :p
<Montjoie>
since it is a 12bits wide value, 4096 step of 0.1degrees is probable (like AXP209)
<jemk>
Montjoie: that's a diode voltage, not a temperature
ganbold_ has quit [Remote host closed the connection]
<Montjoie>
ok:)
<jemk>
Montjoie: the diode voltage depends on temperature witch ~2mV/K
<Montjoie>
The user manual is very bad
geecko has joined #linux-sunxi
<mnemoc>
V to K conversion??! what's next? a relation between energy and mass? .... oh God... what went wrong in this world
<jemk>
Montjoie: to get a the right conversion you would have to measure at least two different known temperatures. the "/ 10" could be pretty right, but the offset could be different
<Montjoie>
yes I know, I hope to find some info for that
<ssvb>
Montjoie: I'm not a big expert in this stuff, but in my experiments with exynos4210 and cpuburn, if I touched the chip with my finger, the temperature reported by the thermal sensor was instantly dropping by 10C or so
<jemk>
mnemoc: 1J = 1kg m^2 / s^2 xD
<ssvb>
Montjoie: if the thermal sensors in a20 do not behave in a similar way, then they are probably not measuring the correct a20 temperature
<mnemoc>
Montjoie: can you get an IR temp gun and find the relation?
<mnemoc>
jemk: :D
<Montjoie>
lol
<oliv3r>
mnemoc: never worked with temperature sensors and adc's have you
<oliv3r>
i have a fluke IR thermometer
<mnemoc>
oliv3r: not at all. but enjoying the conversation and leanring from it
<oliv3r>
ah ok well
<ssvb>
oliv3r: have you measured something interesting with this IR thermometer?
<mnemoc>
and joking a bit. because this office is boring as hell
<n01>
same here ... I barely say three words in 9 hours
<oliv3r>
mnemoc: an ADC reads a difference in voltage. a diode/resistor value changes depending on the temperature. so you simply connect a diode to an ADC and a power source, you start reading a volage from the adc
<oliv3r>
ssvb: well i bought it way back to measure temperatures on my motherboard etc when doing overclocks :) I didn't have an IR camera :(
<oliv3r>
ssvb: now it's just stupid stuff :) but it cna be used to measure die temp on the outside
<ssvb>
oliv3r: it would be very interesting if you could get the temperature measurements for the cpuburn run
<ssvb>
oliv3r: I only have a thermocouple, and I'm not sure how reliable are the measurements done with it
<oliv3r>
i know, i also wanna hook up my oscilosscope to measure power draw
<oliv3r>
but, need time time time
<oliv3r>
but yes, it is high on my todo
<mnemoc>
oliv3r: thanks for the explaination.... somehow I even had the idea that ADCs were keypad related :\
hipboi has joined #linux-sunxi
<mnemoc>
wb hipboi
<oliv3r>
mnemoc: heh, well what they do there is, they use they have various resistors 'connected' to each key. Each key generates a different resistance, which, when a voltage applied to it, can be measured (the voltage is measured). Then you have a simple lookup table 'voltage 1-2 = key0'
<mnemoc>
oliv3r: :D
<oliv3r>
one major reason this is often done, is to save MCU pins
<oliv3r>
adc takes 1 pin for quite a few keys
<oliv3r>
dissadvantage is the constant measuring of the adc
<hipboi>
mnemoc, good evening
<oliv3r>
so code gets more complex etc
<hipboi>
hipboi, we are on the National Holiday now
<oliv3r>
Turl: i figured out why i couldn't get your cpio to give me a console
<oliv3r>
Turl: if I use it 'built in' as a full cpio, it's fine, when I exract it to a dir, and include the dir, i get nothing
<Montjoie>
thanks for the finger tip ssvb , I will try it after work
shineworld has joined #linux-sunxi
hansg has joined #linux-sunxi
geecko has quit [Quit: Quitte]
naobsd has joined #linux-sunxi
<Montjoie>
On the A20 datasheet I see the presence of the gsensor BMA250, does someone could confirme its presence ?
<buZz>
-inside- the A20?
<buZz>
are you sure?
<Montjoie>
present on a20_pad_std_v1_1.pdf
Tartarus_ has joined #linux-sunxi
<Montjoie>
wired via i2c
Tartarus_ has quit [Remote host closed the connection]
<n01>
Turl: is it ugly to setup the mutexes for a device in the driver?
HeHoPMaJIeH has quit [Remote host closed the connection]
<oliv3r>
but cubies won't work wkth that, they only take 5V
<oliv3r>
arokux2: but a PC PSU you can get from the bin, connect the plugs you need and you have TONS of 5V :)
<arokux2>
oliv3r: yeah.. and olimex needs between 6 and 16 V
<oliv3r>
though that 12V brick is really nice for olimex boards
<oliv3r>
so if you have a lot of them; that's awesome
<arokux2>
oliv3r: this was just an example, I do not want it to be loud and my place is limited, I want it to be neat and nicely packaged
<arokux2>
oliv3r: as far as I understand only voltage is important and the more amperage the better, right?
<arokux2>
oliv3r: how can I have tons of 5V from a PC PSU?
notmart has quit [Quit: notmart terminated!]
n01 has quit [Read error: Operation timed out]
<oliv3r>
mnemoc: around?
<oliv3r>
arokux2: i think it has like 15 amps ? :p
<oliv3r>
arokux2: but yeah psu has 5V and 12V so serves you well
<oliv3r>
arokux2: there's silent (fanless) ones, but unless you want 20 olimen running, then a brick like that (or an old laptop adapter) will be fine too
<oliv3r>
just split the cable amongst your boards
<oliv3r>
ideally with a diode for safety
<oliv3r>
(per board)
<arokux2>
oliv3r: splitting is a problem, no standard solutions available. ideally I want nice connectors
<arokux2>
oliv3r: why olimex uses this strange DC plug.... :(
<arokux2>
and why 6-16V..
<oliv3r>
it's a bigger plug for more power
<oliv3r>
and 6-16V because they use a 5V regulator, the regulator needs +5V to work.
<oliv3r>
so that's why you start at 6
<oliv3r>
it's the minimum required voltage
<arokux2>
the regulator needs 5, that is why you start at 6? where is logic?
<oliv3r>
now i'm no expert in voltage regulators, but the closer you are to the output voltage, the more efficient it is. Extra voltage gets turned into heat mostly
<oliv3r>
or partially
<oliv3r>
then there's current draw, bigger input voltage, means less input current, for the same wattage going out
<Turl>
arokux2: hm, I don't recognise the symbol nor see any mention of P10 anywhere else
<Turl>
arokux2: it may just be a test point
<arokux2>
thanks Turl
<Turl>
arokux2: why do you need to know btw?
<arokux2>
Turl: I want to understand why battery voltage is enough to be 3.7V where is power supply voltage must be between 6V and 16V
<Turl>
arokux2: that's just because that's the way it was designed to be :)
<Turl>
arokux2: the AXP handles the battery
<arokux2>
Turl: 3.7V seems to be untypical, digikey doesn't have such voltages. i'm struggling to find a shop which will have all the components I need. it is interesting to me if something different than 3.7V will do
<Turl>
arokux2: I'm pretty sure the typical li-ion cell voltage is 3.7V