Current Server Time: 06:26 (Central Europe)

#apertus IRC Channel Logs

2017/03/11

Timezone: UTC


00:09
usman
left the channel
00:15
Bertl
the lm75 is one example of devices handled by the kernel
00:16
Bertl
the address can be configured with A0-A2, in our case (all high) it is configured at 0x4F
00:17
Bertl
the device tree has an entry for that sensor and thus the kernel driver takes over
00:18
Bertl
[ 1.408890] lm75 0-004f: Config 00
00:18
Bertl
[ 1.411124] lm75 0-004f: hwmon0: sensor 'lm75'
00:18
BAndiT1983
alright, then which device would be suitable to build a chain to access it
00:18
Bertl
[root@beta ~]# cat /sys/class/hwmon/hwmon0/temp1_*
00:18
Bertl
31500
00:18
Bertl
80000
00:18
Bertl
75000
00:18
Bertl
this is one category of devices we are dealing with
00:18
BAndiT1983
i have to brush up a lot of things, as i'Ve studied a mix of software development and electronics, but the latter is not used in my regular job
00:20
Bertl
there is an eeprom driver for Linux but I haven't used it yet, so I don't know what it does
00:21
Bertl
for the GPIO extenders, I know that there is a driver, but that didn't work out as expected when I last tried it
00:21
BAndiT1983
are the drivers open source?
00:21
Bertl
yes, there are basically no I2C specific drivers which are not open source/already in the kernel
00:22
BAndiT1983
trying to get an idea, so reading a bit -> http://www.netzmafia.de/skripten/hardware/RasPi/RasPi_I2C.html
00:22
Bertl
i.e. chip vendors do not care about 'drivers' and motherboard manufacturers do not care about linux :/
00:22
BAndiT1983
i know, so i use also windows, partially for steam
00:23
Bertl
because Microsoft Windows heats up your CPU/GPU so much? :)
00:24
BAndiT1983
very funny ;) but it's a pity that not much of game developers use linux
00:24
Bertl
all the good games were developed on Linux :P
00:26
Bertl
I'm feeling a little tired now ... so I'll head to bed (at least for a nap) ...
00:26
BAndiT1983
have a good night
00:26
Bertl
if you have more questions, do not hesitate, I'll answer them when I get back
00:26
Bertl
@good-night you too!
00:26
Bertl
changed nick to: Bertl_zZ
00:39
intracube
changed nick to: intracube_afk
01:10
dimaursu16
joined the channel
02:07
dimaursu16
left the channel
02:23
BAndiT1983
changed nick to: BAndiT1983|away
03:36
jucar
joined the channel
04:14
Spirit532
left the channel
04:33
jucar
left the channel
06:02
IldarValiev
joined the channel
06:06
Roopal08|away
joined the channel
06:15
usman
joined the channel
06:45
usmankhan
joined the channel
06:45
usmankhan
left the channel
06:46
usmankhan
joined the channel
06:48
usmankhan
left the channel
06:57
usman
left the channel
07:12
usmankhan
joined the channel
07:12
usmankhan
left the channel
07:15
usmanwardag
joined the channel
07:16
usmanwardag
left the channel
07:17
usmankhan
joined the channel
07:17
usmankhan
changed nick to: usmanwardag
07:17
usmanwardag
left the channel
07:17
usmankhan
joined the channel
07:18
usmankhan
left the channel
07:18
usmankhan
joined the channel
07:18
usmankhan
left the channel
07:23
usmankhan
joined the channel
07:23
usmankhan
changed nick to: usmanwardag
07:24
hey
joined the channel
07:24
usmanwardag
left the channel
07:28
hey
left the channel
07:40
usmankhan
joined the channel
07:51
usmankhan
Oops, sorry for the spamming. Was doing some experimentation with the irc
08:02
usmankhan
left the channel
08:17
BAndiT1983|away
changed nick to: BAndiT1983
08:53
BAndiT1983
changed nick to: BAndiT1983|away
09:36
BAndiT1983
joined the channel
09:42
BAndiT1983
left the channel
09:43
BAndiT1983
joined the channel
09:45
BAndiT1983
left the channel
09:55
BAndiT1983
joined the channel
09:57
dimaursu16
joined the channel
09:57
dimaursu16
left the channel
09:57
dimaursu16
joined the channel
10:02
usmankhan
joined the channel
10:05
usmankhan
Hi @Bertl, I did some research on PID controllers for DC/DC buck converters and found this paper very relevant: http://manuscript.jpe.or.kr/ltkPSWeb/pub/pubfpfile.aspx?ppseq=979
10:06
usmankhan
It adjusts the control parameters based on an adaptive algorithm and claims to have better steady-state and transient performance. We could implement this as a starting point and then modify/refine it based on the simulation results
10:07
usmankhan
If you have some other tuning approach in mind, I am open to it too.
10:10
usmankhan
However, I am a little unsure about the power calculations that you talked about yesterday. Is it based on some kind of mathematical model of the sensors?
10:10
Bertl_zZ
changed nick to: Bertl
10:10
sebix
joined the channel
10:10
Bertl
morning folks!
10:10
BAndiT1983
hi
10:10
usmankhan
Good morning!
10:12
danieel
Bertl: what is the drawback of just using a DAC reference and highpower op-amps as followers?
10:13
Bertl
usmankhan: @paper nice find
10:13
Bertl
danieel: you mean an LDO regulator as follower?
10:13
danieel
no, a regular opamp
10:14
Bertl
well, similar to an LDO, it will burn half the power
10:14
danieel
e.g. the DDR VTT power supplies are like that, as they need push/pull source, LDO is usually doing just charge, not discharge
10:15
Bertl
i.e. if we have 5V supply and output 2.5V at 1A, then we will burn the same amount 2.5V*1A on the regulator
10:15
danieel
i see
10:15
Bertl
it works, but it is not great
10:15
danieel
i try to avoid these configurables, until the point where they are really necessary (e.g. they are needed for the BAE sensor between RS and GS variation)
10:15
danieel
otherwise my designs prefer local sensor-specific psus
10:17
Bertl
fair enough
10:18
Bertl
usmankhan: @power-calculations I was thinking of a mathematical model which calculates the power consumed and the power drawn from the switching cycles
10:20
Bertl
so basically we measure the supply voltage to the switcher (external) and we 'know' the target voltage (set via DAC) and we get information from one or two comparators to implement the regulator
10:21
Bertl
this all together with a calibration (passive components, coil, capacitance, Ron) should allow to model the power consumption and efficiency
10:22
Bertl
the model does not need to be implemented on the FPGA, the implementation there just needs to provide the necessary information about the switching
10:22
danieel
there are some features going against each other: fixed frequency for better filtering / low noise VS. variable frequency for higher efficiency
10:23
usmankhan
Alright
10:23
Bertl
danieel: most high efficiency switchers select the mode depending on the power drawn, i.e. they have at least two modes they can operate on
10:24
niemand1
joined the channel
10:24
Bertl
usmankhan: but note that the power calculations are the cherry on top :)
10:24
danieel
i was rather refering to forcing the choice because of use (analog vs. digital)
10:26
usmankhan
Right
10:27
sebix
left the channel
10:28
Bertl
okay, have to pick up a package from the post office ... bbs
10:28
Bertl
changed nick to: Bertl_oO
10:31
IldarValiev
left the channel
10:58
intracube_afk
changed nick to: intracube
11:10
BAndiT1983
left the channel
11:10
BAndiT1983_
joined the channel
11:12
sebix
joined the channel
11:15
niemand1
left the channel
11:22
sebix
left the channel
11:24
davidak
joined the channel
11:49
BAndiT1983_
left the channel
11:57
BAndiT1983
joined the channel
12:00
se6astian|away
changed nick to: se6astian
12:00
Spirit532
joined the channel
12:03
Bertl_oO
changed nick to: Bertl
12:03
Bertl
back now ...
12:10
se6astian
good day!
12:33
BAndiT1983
left the channel
12:33
BAndiT1983_
joined the channel
12:38
RexOrCine
joined the channel
12:44
dimaursu16
left the channel
13:17
dimaursu16
joined the channel
13:17
dimaursu16
left the channel
13:17
dimaursu16
joined the channel
13:33
_florent_
left the channel
13:52
Bertl
off for now ... bbl
13:52
Bertl
changed nick to: Bertl_oO
13:54
Rex0r
joined the channel
14:24
usmankhan
left the channel
14:25
BAndiT1983_
left the channel
14:28
RexO
joined the channel
14:28
Rex0r
left the channel
14:43
usmankhan
joined the channel
14:49
danieel
left the channel
14:50
danieel
joined the channel
14:54
dimaursu16
left the channel
15:07
jucar
joined the channel
15:25
davidak
left the channel
15:27
jucar
left the channel
15:34
davidak
joined the channel
15:39
gk-
joined the channel
15:41
gk-
left the channel
15:53
Elbehery
joined the channel
16:00
usmankhan
left the channel
17:35
se6astian
Should the AXIOM Beta Full Enclosure feature a Flash Hotshoe at the top side or rather a 1/4" threaded hole?
17:35
se6astian
vote here: https://lab.apertus.org/V10
17:36
RexO
Can both options be offered?
17:37
RexO
Eventually maybe?
17:38
se6astian
would also be possible
17:38
slikdigit
joined the channel
17:39
RexO
So this will tell us what needs to be done first basically.
17:59
slikdigit
left the channel
18:00
Elbehery_
joined the channel
18:00
Elbehery
left the channel
18:00
slikdigit
joined the channel
18:08
BAndiT1983
joined the channel
18:13
BAndiT1983
left the channel
18:14
BAndiT1983|away
changed nick to: BAndiT1983
18:15
anuditverma
joined the channel
18:24
BAndiT1983
Bertl_oO, i've investigated i2c access in linux and it works through ioctl and read/write, at least i could get access to some eeprom on my motherboard, next step is to think about description file, probably in JSON format so we can handle special cases/tags
18:25
BAndiT1983
what about aliases, would it simplify some things? like "LM75_PB" (PB=power board), so it would be something like this client->AddSetting("LM75_PB", Mode::Read, buffer);
18:26
slikdigit__
joined the channel
18:26
BAndiT1983
i would let the client collect all the settings and then do Execute() to push them as package
18:26
BAndiT1983
daemon would sort read and write requests and do write first of course, afterwards read requested settings and send response back to client
18:29
slikdigit
left the channel
18:45
anuditverma
left the channel
18:47
davidak
left the channel
18:50
slikdigit__
changed nick to: slikdigit
19:08
slikdigit
left the channel
19:21
davidak
joined the channel
19:24
slikdigit
joined the channel
20:05
davidak
left the channel
20:22
BAndiT1983
changed nick to: BAndiT1983|away
20:22
BAndiT1983|away
changed nick to: BAndiT1983
20:33
anuditverma
joined the channel
20:40
Bertl_oO
changed nick to: Bertl
20:40
Bertl
back now ...
20:40
Bertl
BAndiT1983: what do you want to put in those description files?
20:41
Bertl
@alias what would the canonical reference be?
20:41
BAndiT1983
for example address of the i2c slave and of course address of the sensor
20:42
BAndiT1983
i'm trying to approach it in small steps, so we can adjust the direction of the whole thing
20:42
Bertl
okay, well, no problem with aliases here, but I do not consider them very important :)
20:42
BAndiT1983
i think of following properties first: alias name, address of i2c slave, address of the device, data position, data length
20:43
BAndiT1983
it's just for comfort, i would also try to allow to supply addresses directly
20:43
Bertl
no idea what that means :)
20:43
BAndiT1983
?
20:43
Bertl
address of the device, data position, data length
20:43
BAndiT1983
i played around with i2c-tools in ubuntu
20:44
Bertl
well, that's not a bad thing per se :)
20:44
BAndiT1983
device address is the one from i2cdump
20:44
BAndiT1983
you've shown me similar data yesterday
20:45
BAndiT1983
my eprom was on port 14 and at location 0x57
20:45
BAndiT1983
i mean at location was some device which held data for my motherboard like name, but i had no further info on what it holds precisely
20:46
Bertl
okay, so what would data position and data length be for an lm75?
20:46
BAndiT1983
lm75 is another case, it's handled by kernel, so it would belong to sysfs
20:46
BAndiT1983
then i would create sysfs adapter which reads it from /sys/....
20:46
Bertl
let's say it isn't handled by the kernel (just humor me)
20:47
BAndiT1983
then we get /dev/i2c-XX for device port
20:47
BAndiT1983
and of course some address inside it like 0x74
20:47
Bertl
e.g. 0x4F
20:48
BAndiT1983
int file = open("/dev/i2c-14", O_RDWR);
20:48
BAndiT1983
std::cout << strerror(errno) << std::endl;
20:48
BAndiT1983
unsigned long funcs;
20:48
BAndiT1983
int result = ioctl(file, I2C_FUNCS, &funcs);
20:48
BAndiT1983
result = ioctl(file, I2C_SLAVE, 0x57);
20:48
BAndiT1983
std::cout << strerror(errno) << std::endl;
20:48
BAndiT1983
uint8_t buf[256] = {0};
20:48
BAndiT1983
read(file, buf, 256);
20:48
BAndiT1983
std::cout << strerror(errno) << std::endl;
20:48
BAndiT1983
this is my test code, it's a bit longer as i've put some debug things in it for first tries, afterwards it will be much shorter
20:49
Bertl
yeah, but doesn't make any sense for the LM75 for example
20:49
BAndiT1983
it shows the port i2c-14 for my motherboard chip
20:49
Bertl
besides, are you sure you want C++ (just curious)
20:49
BAndiT1983
yes, as C is outdated and if i have C++ then it's much more comfortable to write and read
20:50
BAndiT1983
at least conversions are easier and less error-prone by times
20:50
Bertl
okay, I disagree on the read part, and I don't think C is outdated
20:51
Bertl
but in any case, double check, because last time I used C++ it was quite bloated (library and memory wise)
20:51
BAndiT1983
if compiled with optimizations it can be very slim
20:51
Bertl
and we definitely don't want huge memory footprints getting 'cloned' every time a connection is made
20:52
BAndiT1983
i hope to include systemd socket activation, so the biggest part is handled by it
20:52
BAndiT1983
but the info has to be researched as the docs give a glimpse at it and one has to search for examples
20:53
BAndiT1983
so, what it wrong with the approach for lm75?
20:53
BAndiT1983
*is
20:53
Bertl
that there is no block to read, there are registers with various bits
20:53
Bertl
they have different sizes, and different functions
20:55
BAndiT1983
this can be defined by description file, so they are grouped logically
20:55
Bertl
as I suggested yesterday, you should not try to make 'one' I2C device handler which does it all or is so generic that it can accomodate almost any device
20:56
Bertl
this is a lot of work with little gain, and probably a ton of bugs
20:56
Bertl
define a common metadata format which can describe the data and the functions a device provides
20:57
Bertl
then create a single device 'class' for each device we have
20:57
BAndiT1983
why won't generic one fit, if you can define data to be read or written together with masks and so on?
20:57
Bertl
trust me, you can't
20:57
BAndiT1983
just thinking of the scripts which do the same thing
20:58
Bertl
well, you can, but you need to make your description language turing compatible
20:58
BAndiT1983
problem is, i don't know how many device classes we have
20:58
BAndiT1983
sometimes it is possible with simpler things, my professional experience
20:58
Bertl
doesn't matter, if we find one you do not have yet, it needs to be implemented
20:59
Bertl
make it simple to add new devices, but leave the low level stuff to a programming language
21:01
BAndiT1983
just trying to avoid if/else for revisions in code
21:02
BAndiT1983
i remember some siemens code from a conference it was a christmas tree of such nested ifs
21:03
Bertl
so how do you plan to handle e.g. a sensor moving from one bus to the other and becoming a different device (lm78 instead of lm75) due to a revision change in your config?
21:04
BAndiT1983
description files would have revision appenden -> e.g. SysFS_rev29.json, I2C_rev33.json
21:04
Bertl
so you make it worse by duplicating the information
21:04
BAndiT1983
daemon should read the revision from somewhere and load reight files for it, so the address cahnges are done dynamically
21:05
Bertl
you are aware that each board has a separate version and revision?
21:05
BAndiT1983
not duplicating, if the files does not exist for the revision it would load the latest one
21:06
Bertl
anyway, if you don't believe me, go ahead, try to solve it with config files
21:07
BAndiT1983
still don't understand what should be so worng with it
21:07
BAndiT1983
every alias can get some part assigned to it, like LM75_config, which writes or reads the bits for that case
21:08
Bertl
silicon is buggy as hell, mainly because nobody can afford a second or third run on a chip (at least not without selling the first version)
21:08
Bertl
most devices have bugs and errata and 'special' requirements
21:09
Elbehery__
joined the channel
21:09
Bertl
sometimes it is a register which requires another register to be set or a bit to be cleared before it works as intended
21:09
Bertl
bits are sometimes spread over a number of registers
21:09
Bertl
and so on and so forth ... this is not something you can handle with a json config file
21:10
BAndiT1983
i can nest many things in such file, also such sequences of settings
21:10
Bertl
so be it ...
21:10
RexO
left the channel
21:10
BAndiT1983
just let us try, i'm looking at it as software developer, you as electronics engineer
21:11
Rex0r
joined the channel
21:11
BAndiT1983
mx problem is, that i've not followed electronics part of my study
21:11
BAndiT1983
*my
21:12
Elbehery_
left the channel
21:12
Elbehery__
left the channel
21:13
anuditverma
left the channel
21:21
BAndiT1983
changed nick to: BAndiT1983|away
21:22
BAndiT1983
joined the channel
21:51
se6astian
changed nick to: se6astian|away
22:09
intracube
changed nick to: intracube_afk
22:36
Bertl
off for a nap ... bbl
22:36
Bertl
changed nick to: Bertl_zZ
22:42
dimaursu16
joined the channel
22:42
dimaursu16
left the channel
22:42
dimaursu16
joined the channel
22:43
slikdigit
left the channel
22:44
slikdigit
joined the channel
23:21
dimaursu16
left the channel