Current Server Time: 18:24 (Central Europe)

#apertus IRC Channel Logs

2017/03/10

Timezone: UTC


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