Current Server Time: 17:42 (Central Europe)

#apertus IRC Channel Logs

2017/03/10

Timezone: UTC


00:47
intracube
changed nick to: intracube_afk
00:57
Elbehery
joined the channel
00:57
Elbehery
Hey everyone
00:57
Elbehery
I do have a question !
01:00
Bertl_oO
let's hear ..
01:02
Elbehery
I thought you are afk
01:02
Elbehery
anyway i have just posted a very simple prototype for the fan controller project
01:02
Elbehery
and still do have many questions but i am waiting for your feedback
01:03
Elbehery
i have posted this as a comment on the ideas page [https://lab.apertus.org/T732]
01:03
Bertl_oO
okay, will check it shortly
01:04
Elbehery
thanks
01:04
Bertl_oO
any specific questions in the meantime?
01:05
Elbehery
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
01:06
Elbehery
but the second point says "task says Integrate temperature sensors into control loop"
01:08
Elbehery
its unclear to me know where do the sensors exist and what does it mean to integrate them into the ctrl loop !
01:11
Bertl_oO
the sensors exist throughout the AXIOM Beta, on different busses and readable via different mechanisms
01:12
Bertl_oO
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)
01:12
Bertl_oO
then calculate the appropriate pwm settings and transmit them to the PWM controller
01:16
Elbehery
Okay so far what i understood || [temp. sensor] -> [software] -> I2C valid PWM values -> [PWM interface] -> fan || am i getting this correctly ?
01:16
Bertl_oO
yes, sounds about right
01:18
Elbehery
aha great, thanks so much for taking the time to answer me really appreciate this
01:18
Bertl_oO
sure, no problem!
01:19
Bertl_oO
I had a quick look at the code and the testbench/simulation, looks nice, I especially appreciate the state diagram :)
01:20
Bertl_oO
a few comments here:
01:21
Bertl_oO
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
01:21
Bertl_oO
also note that I2C allows clock stretching on SCL, which probably might not affect the design at all but should be considered
01:22
Bertl_oO
finally, think about the PWM controller and how you plan to implement that, and if a single 8bit value will be enough for that
01:23
Elbehery
aha, great. few question
01:24
Elbehery
_i, _o are ins and out right ?
01:24
Bertl_oO
_i is in, _o and _t is out
01:24
Bertl_oO
_t is tristate, i.e. taking the line high-z
01:24
Bertl_oO
this interface is relatively easy to connect to an actual I/O buffer
01:25
Bertl_oO
but can also be simply 'combined' or 'mapped' inside the FPGA
01:25
Elbehery
so the module interface should have 6 pins !?
01:25
Bertl_oO
yes
01:26
Bertl_oO
well, actually 6 ports, they will still get mapped to two (physical) pins
01:27
Elbehery
aha, i will be reading more about this interface, and maybe come up with more questions
01:29
Bertl_oO
excellent! good work so far!
01:30
Bertl_oO
also, consider putting your code under an open source license, so that others can reuse it and/or contribute
01:31
Elbehery
thanks so much, the next thing i will try to spend some time on now is the PWM interface then get a feedback, then another look at the I2C slave module
01:32
Elbehery
okay, i will put this under the MIT license
01:36
Bertl_oO
for the PWM controller, consider fractional numeric synthesis as an option to get better resolution without the need for high frequencies (lower power, less EMI)
01:38
Bertl_oO
i.e. basically adding 'constants' to a counter and toggling state whenever it overflows
01:39
Bertl_oO
(with two different constants, based on the state, you can get very fine control without the need for high resolution and frequency)
01:44
Elbehery
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
01:45
Bertl_oO
great! do not hesitate to ask if serious questions arise
01:47
Elbehery
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
02:18
Elbehery
left the channel
02:22
jucar
left the channel
03:26
jucar
joined the channel
04:04
arpu
left the channel
04:08
Spirit532
left the channel
04:18
arpu
joined the channel
04:31
jucar
left the channel
06:03
mithro
se6astian|away: ping me when you are around?
07:46
se6astian|away
changed nick to: se6astian
07:51
sebix
joined the channel
08:36
LordVan
joined the channel
08:56
Bertl_oO
off to bed now ... have a good one everyone!
08:56
Bertl_oO
changed nick to: Bertl_zZ
09:58
Roopal08
joined the channel
10:01
Roopal08
left the channel
10:02
sebix
left the channel
10:21
Roopal08
joined the channel
10:50
ItsMeLenny
joined the channel
11:01
Roopal08
changed nick to: Roopal08|away
11:05
sebix
joined the channel
11:46
sebix
left the channel
11:48
ItsMeLenny
left the channel
12:32
Guillaume_Chooks
joined the channel
12:36
Guillaume_Chooks
left the channel
12:57
Spirit532
joined the channel
13:19
sebix
joined the channel
13:19
sebix
left the channel
13:19
sebix
joined the channel
13:55
LordVan
left the channel
13:58
sebix
left the channel
14:05
se6astian
changed nick to: se6astian|away
14:05
se6astian|away
changed nick to: se6astian
15:08
sebix
joined the channel
15:23
arpu
left the channel
15:29
pusle
left the channel
15:30
pusle
joined the channel
15:35
intracube_afk
changed nick to: intracube
15:42
jucar
joined the channel
15:43
jucar
left the channel
15:54
se6astian
changed nick to: se6astian|away
15:57
jucar
joined the channel
16:18
jucar
left the channel
16:28
anuditverma
joined the channel
16:32
Bertl_zZ
changed nick to: Bertl
16:32
Bertl
morning folks!
16:40
anuditverma
morning, it's night time here in India, but yeah anyway have great a great day ahead :)
16:41
Bertl
thanks, it's early evening here ... :)
16:43
Bertl
how are you? everything fine?
16:51
anuditverma
I am fine Bertl, thanks for asking
17:04
slikdigit
joined the channel
17:17
sebix
left the channel
17:20
davidak
joined the channel
17:21
Roopal08|away
left the channel
18:17
se6astian|away
changed nick to: se6astian
18:21
sebix
joined the channel
18:26
anuditverma
left the channel
18:35
RexOrCine
joined the channel
18:54
d0
joined the channel
18:55
BAndiT1983|away
changed nick to: BAndiT1983
19:10
sebix
left the channel
19:12
sebix
joined the channel
19:41
slikdigit
left the channel
19:42
slikdigit
joined the channel
19:51
slikdigit
left the channel
19:52
slikdigit
joined the channel
19:52
slikdigit
left the channel
19:52
slikdigit
joined the channel
20:22
BAndiT1983
Hey Bertl, there are still a couple of things related to daemon we have to talk about
20:24
BAndiT1983
yesterday i've added read/write mode to the schema, but today i thought that it can be replaced by sending variables/data which has to be set, afterwards the daemon will send back the data of the same variables which was read after setting it
20:25
BAndiT1983
would it create too much traffic? especially unsure about it when i think about byte arrays
20:25
BAndiT1983
another thing is FPGA bitstreams, what is your requirement?
20:31
slikdigit__
joined the channel
20:34
d0
left the channel
20:34
slikdigit
left the channel
20:35
slikdigit__
changed nick to: slikdigit
20:36
davidak
left the channel
20:44
Bertl
hey BAndiT1983!
20:45
Bertl
I think we should consider smart operations instead of read-modify-write or write-readback
20:45
BAndiT1983
what is your vision of smart operations
20:45
Bertl
so typically we have to work with words (or bytes) and bits in those words
20:46
Bertl
so for example, if we have a GPIO extender, we want to set a bit or configure a pin to input/output/pullup
20:46
Bertl
we do not care much about the details of the registers though, als long as they can be easily modified without disturbing other pins
20:47
Bertl
we also want to represent sensor data (mostly temperature) and eeprom data in an abstract way
20:47
Bertl
so that it can easily be processed regardless of the sensor or eeprom actually used
20:48
BAndiT1983
different parts like i2c, gpio etc. will be covered by some related adapter which will provide something like read or write method
20:48
Bertl
note that we also want to get metadata about those sensors and actors
20:48
BAndiT1983
in general it's some interface which has read/write method and adapters, i call them so at the moment, will do the right job
20:48
Bertl
like for example, what is the resolution of this temp sensor? what the initial accuracy? what's the location
20:49
BAndiT1983
how is it done at the moment?
20:49
Bertl
not very well :)
20:49
BAndiT1983
alright, then we need some init method which retrieves it from the parts in the camera
20:50
BAndiT1983
this method will create a small database, in memory of course, no sql
20:50
BAndiT1983
it could be reinitialized if something changes, but overall it would gather related data
20:51
Bertl
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?)
20:51
Bertl
keeping a cache or similar won't hurt, as long as it is simple
20:51
BAndiT1983
see, you are at the same point with the config file ;)
20:52
Bertl
note that we also want to limit the amount of hardware polls for certain sensors
20:52
BAndiT1983
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
20:52
Bertl
mostly because it doesn't make much sense to poll a temp sensor 20 times a second for example
20:52
Bertl
but also because some interfaces might be extremely slow or very expensive resource wise
20:53
BAndiT1983
we can add auto polling, e.g. every 1s or 5s
20:53
Bertl
well, no point in polling a sensor if nobody is interested in its value :)
20:53
BAndiT1983
but at the moment it would be sufficient to get basic communication done, so Malte can start with REST API GSoC task
20:53
BAndiT1983
even better, as you already do the PWM thing
20:54
BAndiT1983
was just an idea, if there are sensors which the user wants to output to graph, but then the user can poll it through reading out related setting
20:55
BAndiT1983
i'm lacking usage cases at the moment, because i'M developing it in blind mode without hardware
20:55
BAndiT1983
even my raspi is not at home currently
20:57
Bertl
do you have a PC?
20:57
BAndiT1983
no, i'M chatting through dove post :D
20:58
Bertl
well, could be that you're a mac person, no?
20:58
Bertl
anyway, on a PC, you will find a number of sensors and even some actors on various I2C busses
20:58
BAndiT1983
no, i'm usual developer with win and linux
20:59
Bertl
including the eeproms (mostly on DDR memory)
20:59
BAndiT1983
never dived in that area before
20:59
BAndiT1983
but looking forward of course
20:59
Bertl
those are almost identical to what you typically find on the Beta
21:10
Bertl
another aspect I almost forgot to mention is that the hardware can and often will change dynamically
21:10
BAndiT1983
how so?
21:10
Bertl
i.e. when a new plugin is inserted or one is removed, then the hardware will change
21:10
BAndiT1983
which information do we have at the moment after the change? address of the plugin?
21:11
Bertl
for example, each plugin provides an eeprom with information about that plugin (simplest case a unique id)
21:12
Bertl
there are several ways to detect a plugin change, but we have not addressed this specifically
21:12
BAndiT1983
would such eeprom hold the info about plugins actors also or should we just have some description files?
21:12
BAndiT1983
had a quick look at lm-sensors, but the file with all possible sensors is huge, reall huge
21:12
Bertl
the eeproms vary in size and will not be very large (256 bytes can be assumed)
21:13
BAndiT1983
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
21:13
Bertl
yeah, there are a lot of sensors out there :)
21:13
BAndiT1983
as we have just a small subset some description files for different revisiions/pluins etc.ould be a good solution
21:14
Bertl
yes, we should consider (and probably list/note) our options there and see what fits best
21:15
Bertl
some kind of 'hardware database' based on addresses/uids would be a good idea IMHO
21:16
BAndiT1983
could you provide me some info on this, i mean sensor addresses etc. then i could think of something
21:16
BAndiT1983
i will create a subtask in lab for usage cases, as we have to discuss it a lot it seems
21:18
BAndiT1983
https://lab.apertus.org/T762?workflow=757
21:18
Bertl
http://pastebin.com/raw/VWxBw4GE
21:18
Bertl
this is an example (the central I2C bus on the Beta)
21:19
Bertl
which shows a number of GPIO extenders (20-23) and a number of high side power sensors (28-2d,48-4d)
21:19
Bertl
as well as a temperature sensor (4f seen as UU) and an eeprom (50-57)
21:19
Bertl
the eeprom shows up as several devices despite the fact that it is a single chip
21:19
dimaursu16
left the channel
21:20
BAndiT1983
how is the access done? you set a channel according to one of the numbers and read it?
21:21
Bertl
here is an example of the GPIO pins provided by those extenders:
21:21
Bertl
http://pastebin.com/raw/5jbxezpg
21:22
BAndiT1983
seems like first 2 bytes are the address according to eeprom and last 2 the location to read out
21:22
Bertl
the I2C bus devices can be handled by the kernel, like for example the temp sensor (4F)
21:22
BAndiT1983
port a and port b if i'm not mistaken
21:22
Bertl
(that's why it is marked as UU)
21:23
Bertl
in this case, the values will show up in sysfs or procfs
21:23
BAndiT1983
i've prepared adapters for that case, so they can read it depending on the case
21:23
Bertl
unhandled devices can conform to a number of protocols (within the I2C specification)
21:23
Bertl
they can have a single register, or many registers
21:23
Bertl
some registers can we read only, others can be write only
21:24
Bertl
some registers form pairs to select an address
21:25
BAndiT1983
how does gpio recognize I and Othem
21:25
BAndiT1983
*I and O?
21:33
slikdigit
left the channel
21:35
sebix
left the channel
21:37
Bertl
it doesn't ... each pin can be configured as input or output
21:37
Bertl
depending on the actual purpose
21:37
Bertl
so that is something which is setup by one of the scripts
21:38
Bertl
(it is hardware version/revision specific)
21:40
BAndiT1983
alright, so no hassle there, it's simplifies a bit
21:41
BAndiT1983
ah, now i've found it -> https://github.com/apertus-open-source-cinema/beta-software/blob/master/beta-scripts/gpio.py
21:42
Bertl
so I would propose to solve this similar to how lm_sensors and the kernel solves it
21:43
Bertl
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
21:43
BAndiT1983
that's what was on my mind
21:44
Bertl
those drivers can have their own 'config' sections where revision details or similar can be recorded
21:44
BAndiT1983
i just need to wrap my head around what are the common things between them, then i would have some clean interface (c++ is meant), afterwards it can be extended
21:44
Bertl
they also provide some kind of 'probe' function, which allows it to figure out hardware conditions and the presence of the device in question
21:45
BAndiT1983
i suppose we should handle i2c, gpio, uart etc. as separate protocols, so we need different description files per protocol and revision
21:47
Bertl
I'm not sure we should care about the low level interfaces at all
21:48
BAndiT1983
i'm talking about OOP interface, it'S not hardware related, just something which simplifies developers life, or makes it worse, depends on many factors :D
21:48
Bertl
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
21:48
BAndiT1983
so it should be configured as UART in the description, just trying to dissect the things to make it simpler
21:48
Bertl
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
21:49
BAndiT1983
exactly
21:49
BAndiT1983
which script file should i look at as starting point?
21:49
BAndiT1983
it would be preparation for descriptions, so the daemon replaces it at some point in time
21:49
Bertl
i2c is mostly handled by shell scripts (all those including i2c*.func)
21:50
Bertl
mainly because I haven't gotten to rewrite them in python
21:50
BAndiT1983
by the way, what are the func files? is it something special for bash?
21:50
Bertl
those are just includes, nothing special in the extension
21:50
BAndiT1983
python is not my favorite, still c/c++ developer
21:50
Bertl
I just decided to name them .func as they contain functions :)
21:50
BAndiT1983
so you'Ve just collected common methods there
21:51
se6astian
off to bed
21:51
Bertl
kind of, yes
21:51
se6astian
good night
21:51
Bertl
nn
21:51
se6astian
changed nick to: se6astian|away
21:51
BAndiT1983
night
21:52
BAndiT1983
you do get and mask a lot there, is it because of shortcomings of bash for that?
21:53
BAndiT1983
looking at i2c.func currently, but the included bit.func is not in the repo or i'M blind
21:53
Bertl
should be, if not, for certain it's in the SD image
21:54
Bertl
get/set is retrieving/setting an i2c register value
21:55
Bertl
as usually the bits are packed and each has specific meaning, those need to be masked out
21:55
Bertl
i.e. read a register, mask unrelevant bits, change relevant bits, write back that register
21:55
BAndiT1983
already supposed that, but the file was not there
21:58
BAndiT1983
is it still actual? -> https://wiki.apertus.org/index.php/Axiom_beta_power_board_v0.23
22:21
Bertl
we are currently at v0.29 on the verge to v0.30
22:22
BAndiT1983
just trying to gather some information, don't know where it's usually stored
22:23
Bertl
http://vserver.13thfloor.at/Stuff/AXIOM/BETA/
22:23
BAndiT1983
although this page shows some things, which could be interesting for daemon usage -> https://wiki.apertus.org/index.php/AXIOM_Beta/AXIOM_Beta_Software
22:29
BAndiT1983
so, any points to start with? as there are a lot of scripts and i have a hard time to wrap my hand around it just poking around
22:29
BAndiT1983
maybe plain memory accessw and i2c first?
22:31
Bertl
why not, we have to start somewhere :)
22:32
BAndiT1983
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
22:32
Bertl
the power board is a good start, it contains many different sensors which are rather central
22:33
Bertl
sensors and actors that is
22:34
BAndiT1983
which software have you used for brd and sch?
22:34
BAndiT1983
eagle or kicad?
22:36
Bertl
everything is still Eagle, if you need a pdf, just let me know
22:36
BAndiT1983
pdf would be nice
22:39
Bertl
http://vserver.13thfloor.at/Stuff/AXIOM/BETA/axiom_beta_power_board_v0.30.sch.pdf
22:41
BAndiT1983
many thanks
22:41
Bertl
you're welcome!
22:46
BAndiT1983
have also installed eagle, still don't know why you are using it, or do you rely on some pre-autodesk version?
22:47
Bertl
I've been using it since decades, and when we started with the AXIOM, KiCad was almost unuseable
22:47
BAndiT1983
let me guess, they are also lacking people with knowledge
22:47
Bertl
we have been planning to convert to KiCad for a more than a year now, but the conversion is painful and nobody wanted to do it yet
22:48
usman
joined the channel
22:48
Bertl
since about two years, KiCad was adopted by CERN, which means there is steady progress and it is getting really usable
22:48
BAndiT1983
oh, nice that they get CERN support
22:48
Bertl
welcome usman!
22:49
usman
Hello, nice to be here!
22:49
Bertl
did my email reply motivate you to come here? :)
22:49
usman
Yeah, I just read your message.
22:50
Bertl
well, glad it did ...
22:51
usman
Ok, so I spent some time yesterday and today to implement a convolution filter: https://github.com/usmanwardag/sobel
22:52
usman
But, I am also interested in the 'Smart Switching Regulator' idea. So I am wondering if you can provide some details
22:52
Bertl
glad you say that ...
22:53
Bertl
btw, code for the CF looks nice
22:53
Bertl
so, regarding the smart switching regulator
22:54
Bertl
in the AXIOM Beta, we have quite a number of power rails
22:54
Bertl
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)
22:55
Bertl
now the problem here is, as the sensor can be swapped out (more precisely the entire sensor board)
22:55
usman
Alright
22:55
Bertl
those voltages are not fixed and need to be adjusted according to the sensor
22:56
Bertl
but even with a given sensor, the voltages are often within a certain range, which allow some fine tuning
22:56
Bertl
We've looked at existing PMIC solutions and they are typically geared toward CPU supply or high power backplanes
22:57
Bertl
both do not really fit our requirements very well
22:57
Bertl
so the idea was born to create a custom power controller which can be reprogrammed
22:58
Bertl
as FPGAs are rather cheap nowadays, especially in the 'lower' clock range, they are probably well suited for the task
22:59
Bertl
we still need the typical MosFET power stage with inductor and capacitor but we can probably do all the rest in the FPGA
22:59
Bertl
(some comparators and DACs will be required of course)
22:59
Bertl
sounds interesting?
23:01
usman
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?
23:08
Bertl
yes, typically we will almost always work in buck mode, so the focus is probably there
23:08
Bertl
the idea is to create a reference voltage (via DAC) which is basically 'presented' to the sensor frontend for validation
23:09
Bertl
i.e. we get feedback for over/under voltage from there
23:09
usman
Ok got it
23:10
Bertl
and the FPGA implementation should steer a number of buck converters (8+) to follow those voltages and provide the actual power to the sensor
23:11
Bertl
it needs to coordinate all the switchers properly to avoid oscillation and disruptive power surges
23:11
Bertl
it also needs to react quickly on over/under voltage conditions and 'log' or report them somehow
23:12
Bertl
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
23:13
Bertl
the iead behind the task is that we desing the electronics for such a controller (in a modular way, which allows to test a single buck first)
23:13
Bertl
*idea
23:13
Bertl
and then test out a bunch of strategies and try to optimize them for the given task
23:14
Bertl
so it would be more a research project which if successful, will replace the current Power Board
23:15
usman
Alright, this makes a lot more sense now. I will look into each of these points and let you know if I have any questions
23:15
Bertl
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
23:16
Bertl
(of course, e-Mail is an option too)
23:16
usman
Sure
23:16
usman
By the way, I have a question about simulation. How do we simulate the switcher without outside sensors?
23:17
Bertl
we probably can do some mixed mode simulations with ngspice or gnucap if that is what you are asking
23:17
BAndiT1983
vivado has analog stimulus support if i'm not mistaken
23:18
Bertl
yeah, but that sucks and I'm not sure we will decide on a high end Xilinx device for this purpose
23:18
Bertl
to me it looks more like a task for a power efficient Lattice, like the MachXO2 or XO3 or a spartan/cyclone
23:21
Bertl
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
23:22
Bertl
but I guess, the real testing we will have to do on actual hardware, which we can design and provide for this
23:24
BAndiT1983
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
23:28
Bertl
both are on page 6, U29 and U30
23:28
Bertl
you can search for the names
23:29
BAndiT1983
i know, but this damn thing has no visible text search
23:29
BAndiT1983
found temp sensor, now looking for the other one
23:29
Bertl
CTRL-F?
23:29
BAndiT1983
nope, it goes to parameter entry and i don't know the commands yet
23:30
Bertl
Tools->Search is the other way
23:30
Bertl
(but works fine here)
23:30
BAndiT1983
ah, tools->search is more helpful, very well hidden
23:36
BAndiT1983
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?
23:38
BAndiT1983
ah, no wonder u30 was not there, layer was just hidden, was wondering that eagle pointed me to some emtpy space
23:59
RexOrCine
left the channel