#apertus IRC Channel Logs

Hey everyone

let's hear ..

anyway i have just posted a very simple prototype for the fan controller project

i have posted this as a comment on the ideas page [https://lab.apertus.org/T732]

thanks

the second task is not clear for me, what i understood from yesterday's question was that an FPGA will be sending the temp. data to the slave

its unclear to me know where do the sensors exist and what does it mean to integrate them into the ctrl loop !

the second part of the task involves gathering those temperature data (probably via the control daemon) and making sense of it (in a C program or python script)

Okay so far what i understood || [temp. sensor] -> [software] -> I2C valid PWM values -> [PWM interface] -> fan || am i getting this correctly ?

aha great, thanks so much for taking the time to answer me really appreciate this

I had a quick look at the code and the testbench/simulation, looks nice, I especially appreciate the state diagram :)

as this is very likely to be connected to a virtual I2C bus (because of the FPGA to FPGA connection) it would be good to have _i, _o and _t ports for each SCL and SDA

finally, think about the PWM controller and how you plan to implement that, and if a single 8bit value will be enough for that

_i, _o are ins and out right ?

_t is tristate, i.e. taking the line high-z

but can also be simply 'combined' or 'mapped' inside the FPGA

yes

aha, i will be reading more about this interface, and maybe come up with more questions

also, consider putting your code under an open source license, so that others can reuse it and/or contribute

okay, i will put this under the MIT license

i.e. basically adding 'constants' to a counter and toggling state whenever it overflows

Hmmm, i am going to spend some time reading more about these techniques. Have always worked with PWMs from a mcu point of view. But once i implement a simple model, test and synthesize it i will post this at my repo. then discuss unclear things

awesome, i am just trying to get my hands dirty as early as possible in order to get the large picture here. Again thanks so much

se6astian|away: ping me when you are around?

off to bed now ... have a good one everyone!

morning, it's night time here in India, but yeah anyway have great a great day ahead :)

how are you? everything fine?

Hey Bertl, there are still a couple of things related to daemon we have to talk about

would it create too much traffic? especially unsure about it when i think about byte arrays

I think we should consider smart operations instead of read-modify-write or write-readback

so typically we have to work with words (or bytes) and bits in those words

we do not care much about the details of the registers though, als long as they can be easily modified without disturbing other pins

so that it can easily be processed regardless of the sensor or eeprom actually used

note that we also want to get metadata about those sensors and actors

like for example, what is the resolution of this temp sensor? what the initial accuracy? what's the location

not very well :)

this method will create a small database, in memory of course, no sql

some information will be hardware dependent, and can sometimes be probed, but sometimes needs to be specified in some kind of config file (device tree maybe?)

see, you are at the same point with the config file ;)

we could store the values with string keys, this keys would be pre-defined mostly as ranges are still defined by min and max, at least usually

but also because some interfaces might be extremely slow or very expensive resource wise

well, no point in polling a sensor if nobody is interested in its value :)

even better, as you already do the PWM thing

i'm lacking usage cases at the moment, because i'M developing it in blind mode without hardware

do you have a PC?

well, could be that you're a mac person, no?

no, i'm usual developer with win and linux

never dived in that area before

those are almost identical to what you typically find on the Beta

how so?

which information do we have at the moment after the change? address of the plugin?

there are several ways to detect a plugin change, but we have not addressed this specifically

had a quick look at lm-sensors, but the file with all possible sensors is huge, reall huge

have to restore my grub, so i can use my bare metal linuxmint on the second ssd again, then it would be easier to experiment

as we have just a small subset some description files for different revisiions/pluins etc.ould be a good solution

some kind of 'hardware database' based on addresses/uids would be a good idea IMHO

i will create a subtask in lab for usage cases, as we have to discuss it a lot it seems

http://pastebin.com/raw/VWxBw4GE

which shows a number of GPIO extenders (20-23) and a number of high side power sensors (28-2d,48-4d)

the eeprom shows up as several devices despite the fact that it is a single chip

how is the access done? you set a channel according to one of the numbers and read it?

http://pastebin.com/raw/5jbxezpg

the I2C bus devices can be handled by the kernel, like for example the temp sensor (4F)

(that's why it is marked as UU)

i've prepared adapters for that case, so they can read it depending on the case

they can have a single register, or many registers

some registers form pairs to select an address

*I and O?

depending on the actual purpose

(it is hardware version/revision specific)

ah, now i've found it -> https://github.com/apertus-open-source-cinema/beta-software/blob/master/beta-scripts/gpio.py

have a special 'driver' code which handles the low level details and provides a high level data and metadata record as well as certain functions

those drivers can have their own 'config' sections where revision details or similar can be recorded

they also provide some kind of 'probe' function, which allows it to figure out hardware conditions and the presence of the device in question

I'm not sure we should care about the low level interfaces at all

what I mean is, if there is an implementation which does I2C over UART and that's used by a driver which represents a temp sensor on I2C, then that's fine

the interface presented to the control daemon should look the same, the only difference would be some meta data which tells us where the sensor is

which script file should i look at as starting point?

i2c is mostly handled by shell scripts (all those including i2c*.func)

by the way, what are the func files? is it something special for bash?

python is not my favorite, still c/c++ developer

so you'Ve just collected common methods there

kind of, yes

nn

night

looking at i2c.func currently, but the included bit.func is not in the repo or i'M blind

get/set is retrieving/setting an i2c register value

i.e. read a register, mask unrelevant bits, change relevant bits, write back that register

is it still actual? -> https://wiki.apertus.org/index.php/Axiom_beta_power_board_v0.23

just trying to gather some information, don't know where it's usually stored

although this page shows some things, which could be interesting for daemon usage -> https://wiki.apertus.org/index.php/AXIOM_Beta/AXIOM_Beta_Software

maybe plain memory accessw and i2c first?

it's just i don't know where to look first, i would also study the schematics, but first i have to know which one

sensors and actors that is

eagle or kicad?

pdf would be nice

many thanks

have also installed eagle, still don't know why you are using it, or do you rely on some pre-autodesk version?

let me guess, they are also lacking people with knowledge

oh, nice that they get CERN support

Hello, nice to be here!

Yeah, I just read your message.

Ok, so I spent some time yesterday and today to implement a convolution filter: https://github.com/usmanwardag/sobel

glad you say that ...

so, regarding the smart switching regulator

and some of them are provided for the sensor, specifically we reserve 8 power rails for sensor usage with slightly different amperage (between 500mA and 1.5A roughly speaking)

Alright

but even with a given sensor, the voltages are often within a certain range, which allow some fine tuning

both do not really fit our requirements very well

as FPGAs are rather cheap nowadays, especially in the 'lower' clock range, they are probably well suited for the task

(some comparators and DACs will be required of course)

Yeah, it does. So, if I am understanding it correctly, is the idea to implement a PID controller in FPGA and then switch to boost, buck modes depending on the output?

the idea is to create a reference voltage (via DAC) which is basically 'presented' to the sensor frontend for validation

Ok got it

it needs to coordinate all the switchers properly to avoid oscillation and disruptive power surges

finally if we manage to do proper power measurements (or more precisely 'calculations') in the FPGA, we could safe a bunch of external sensors as well

*idea

so it would be more a research project which if successful, will replace the current Power Board

please do not hesitate to ask, even if I'm not around or asleep, I will answer as soon as I read up on the questions

Sure

we probably can do some mixed mode simulations with ngspice or gnucap if that is what you are asking

yeah, but that sucks and I'm not sure we will decide on a high end Xilinx device for this purpose

one option to combine the FPGA part with the analog outside would be to use a model for our analog hardware and combine it with a simulator, e.g. GHDL

trying to find the eeprom and temp sensor on the board, but eagle is still not very user friendly, although i'm an engineer, but some software is a riddle to me

you can search for the names

found temp sensor, now looking for the other one

nope, it goes to parameter entry and i don't know the commands yet

(but works fine here)

so, if we focus on lm75 first, how is it wirde and what addresses are involved? can i find it in some script file, so i don't have to bother you about it every time?