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 |