#apertus IRC Channel Logs

the lm75 is one example of devices handled by the kernel

the device tree has an entry for that sensor and thus the kernel driver takes over

[ 1.411124] lm75 0-004f: hwmon0: sensor 'lm75'

[root@beta ~]# cat /sys/class/hwmon/hwmon0/temp1_*

80000

this is one category of devices we are dealing with

there is an eeprom driver for Linux but I haven't used it yet, so I don't know what it does

are the drivers open source?

trying to get an idea, so reading a bit -> http://www.netzmafia.de/skripten/hardware/RasPi/RasPi_I2C.html

i know, so i use also windows, partially for steam

very funny ;) but it's a pity that not much of game developers use linux

I'm feeling a little tired now ... so I'll head to bed (at least for a nap) ...

if you have more questions, do not hesitate, I'll answer them when I get back

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

If you have some other tuning approach in mind, I am open to it too.

morning folks!

Good morning!

usmankhan: @paper nice find

no, a regular opamp

e.g. the DDR VTT power supplies are like that, as they need push/pull source, LDO is usually doing just charge, not discharge

i see

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)

fair enough

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

the model does not need to be implemented on the FPGA, the implementation there just needs to provide the necessary information about the switching

Alright

i was rather refering to forcing the choice because of use (analog vs. digital)

back now ...

off for now ... bbl

vote here: https://lab.apertus.org/V10

Eventually maybe?

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

daemon would sort read and write requests and do write first of course, afterwards read requested settings and send response back to client

BAndiT1983: what do you want to put in those description files?

for example address of the i2c slave and of course address of the sensor

okay, well, no problem with aliases here, but I do not consider them very important :)

it's just for comfort, i would also try to allow to supply addresses directly

?

i played around with i2c-tools in ubuntu

device address is the one from i2cdump

my eprom was on port 14 and at location 0x57

okay, so what would data position and data length be for an lm75?

then i would create sysfs adapter which reads it from /sys/....

then we get /dev/i2c-XX for device port

e.g. 0x4F

std::cout << strerror(errno) << std::endl;

int result = ioctl(file, I2C_FUNCS, &funcs);

std::cout << strerror(errno) << std::endl;

read(file, buf, 256);

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

it shows the port i2c-14 for my motherboard chip

yes, as C is outdated and if i have C++ then it's much more comfortable to write and read

okay, I disagree on the read part, and I don't think C is outdated

if compiled with optimizations it can be very slim

i hope to include systemd socket activation, so the biggest part is handled by it

so, what it wrong with the approach for lm75?

that there is no block to read, there are registers with various bits

this can be defined by description file, so they are grouped logically

this is a lot of work with little gain, and probably a ton of bugs

then create a single device 'class' for each device we have

trust me, you can't

well, you can, but you need to make your description language turing compatible

sometimes it is possible with simpler things, my professional experience

make it simple to add new devices, but leave the low level stuff to a programming language

i remember some siemens code from a conference it was a christmas tree of such nested ifs

description files would have revision appenden -> e.g. SysFS_rev29.json, I2C_rev33.json

daemon should read the revision from somewhere and load reight files for it, so the address cahnges are done dynamically

not duplicating, if the files does not exist for the revision it would load the latest one

still don't understand what should be so worng with it

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)

bits are sometimes spread over a number of registers

i can nest many things in such file, also such sequences of settings

*my

off for a nap ... bbl