Current Server Time: 04:33 (Central Europe)

#apertus IRC Channel Logs

2017/03/11

Timezone: UTC


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