Current Server Time: 05:40 (Central Europe)

#apertus IRC Channel Logs

2020/05/04

Timezone: UTC


02:23
mumptai_
joined the channel
02:26
mumptai
left the channel
02:45
rohit
joined the channel
02:45
rohit
left the channel
02:51
futarisIRCcloud
left the channel
03:05
futarisIRCcloud
joined the channel
05:46
BAndiT1983|away
changed nick to: BAndiT1983
06:40
se6ast1an
good day
06:44
BAndiT1983
hi
06:44
BAndiT1983
big GSoC day today ;)
06:50
se6ast1an
indeed, irc meeting & student slots announcement!
07:26
BAndiT1983
changed nick to: BAndiT1983|away
07:27
metal_dent[m]
Good day!
07:28
BAndiT1983|away
changed nick to: BAndiT1983
07:28
BAndiT1983
hi metal_dent[m]
07:29
se6ast1an
good day!
07:31
metal_dent[m]
The slots will be announced after the meeting, right? ':D
07:32
BAndiT1983
i think it's around 8pm german time
07:32
BAndiT1983
so yes
07:34
metal_dent[m]
Alright, good luck everyone! :D
07:35
se6ast1an
UTC 18:00 indeed
07:35
se6ast1an
which timezone are you in metal_dent[m]?
07:38
metal_dent[m]
IST, it will be 23:30 here :)
08:06
se6ast1an
right
08:09
bluez_[m]
(fingers crossed) ':D
10:47
BAndiT1983
metal_dent[m]: have you looked at the fixed values in ImageButton::Draw()?
10:48
BAndiT1983
smiley is showing on my side, again -> ImageButton :: Draw()
10:52
metal_dent[m]
> metal_dent: have you looked at the fixed values in ImageButton::Draw()?
10:52
metal_dent[m]
yes, and I think instead of adding the image_data from it's header file in the Screen file (like I did in WB), we should add that in the ImageButton
10:52
metal_dent[m]
> smiley is showing on my side, again -> ImageButton :: Draw()
10:52
metal_dent[m]
smiley?
10:56
BAndiT1983
because of colon : and capital D together
10:57
BAndiT1983
Screen, ImageButton, data? please explain a bit more, lost the track a bit
10:57
BAndiT1983
another example before confusion is big about UI structures -> https://digitalrune.github.io/DigitalRune-Documentation/media/Game.UI.Controls_Buttons.png
10:58
BAndiT1983
we are planning to add UML diagrams automatically, maybe they will help to keep our structure in sane boundaries, as inheritance can explode without proper handling
10:59
BAndiT1983
and this should also show quite some similarities to what we are targeting -> https://www3.ntu.edu.sg/home/ehchua/programming/java/images/Swing_JComponentClassDiagram.png
10:59
metal_dent[m]
I have added the home icon in the WBScreen like this -> https://github.com/MetalDent/AXIOM-Remote/blob/52769c2d877605c53ff57ee696d35b02d21d4cf1/Firmware/UI/Screens/WhiteBalanceScreen.cpp#L11
11:00
Bertl_zZ
changed nick to: Bertl
11:00
BAndiT1983
and where do you use it?
11:00
Bertl
morning folks!
11:00
BAndiT1983
hi
11:01
metal_dent[m]
here like this -> https://github.com/MetalDent/AXIOM-Remote/blob/52769c2d877605c53ff57ee696d35b02d21d4cf1/Firmware/UI/Screens/WhiteBalanceScreen.cpp#L14
11:02
BAndiT1983
ok, but i lack the passing of the icon width and height, how does the button handle it?
11:03
metal_dent[m]
here -> https://github.com/MetalDent/AXIOM-Remote/blob/454803c76023e0a7d2fabe62ddd10549c6675913/Firmware/UI/Widgets/ImageButton.h#L39
11:03
metal_dent[m]
as all the icons are 24x24 so i fixed the size here
11:04
BAndiT1983
this are fixed values, but i expect that they are dynamic, based on arguments, icons won't be only 24x24, e.g. knob icon will be much bigger, like 64x64
11:05
metal_dent[m]
yes that's why i said that here also i should take the size from the image header, right?
11:05
BAndiT1983
image button should be reusable, at the moment it's rather limited, what about the feature to have image button with icon and text?
11:05
metal_dent[m]
text as in a caption?
11:05
BAndiT1983
yes
11:06
BAndiT1983
like here -> https://3.bp.blogspot.com/-7jrljvsWVUA/VqCm_3GHliI/AAAAAAAACVE/eLkD9Izrlkw/w1200-h630-p-k-no-nu/android-button-with-icon-and-text.jpg
11:06
BAndiT1983
or here -> https://image.freepik.com/free-vector/colored-text-buttons_23-2147534884.jpg
11:07
BAndiT1983
as it's a struct, we can create Icon struct and pass it over to the button, then you don't need to pass single parameters around
11:07
metal_dent[m]
ohh, then need to add a draw text too in the ImageButton
11:08
BAndiT1983
not yet, just showing you examples where the ImageButton won't fit the task, it requires dynamic dimensions first
11:08
metal_dent[m]
yes, of course
11:12
se6ast1an
metal_dent[m]: maybe it would make most sense if you create a list of the next steps or open issues here: https://lab.apertus.org/T1172 and then we discuss it?
11:15
metal_dent[m]
Okay, I'll add comments under this about the progress so far and about the next steps
11:17
se6ast1an
great
11:17
se6ast1an
see the description of https://lab.apertus.org/T1177 for some inspiration with checkbox icons as text
11:22
metal_dent[m]
done!
11:23
metal_dent[m]
you also please add more relevant features :)
11:26
se6ast1an
looks good
11:27
se6ast1an
"having an icon with an image and text" you mean a button with icon and text right?
11:27
metal_dent[m]
yup
11:27
se6ast1an
good
11:28
se6ast1an
please start without the text, just the icon in the center of the button
11:28
se6ast1an
and setting width and height of button to eg 100x200
11:28
metal_dent[m]
yes yes, the step 1 is that
11:30
se6ast1an
great
11:44
BAndiT1983
quick reboot, manjaro likes to hide the window decorators after an update
11:44
BAndiT1983
changed nick to: BAndiT1983|away
11:45
BAndiT1983|away
changed nick to: BAndiT1983
11:49
BAndiT1983
Bertl: any news on the remote remote?
11:50
Bertl
preliminary tests of the new remote (with the new PIC32MZ) look good, still missing a display but I might be able to use a replacement for now
11:51
Bertl
so if all goes well, it should be operational in the next days
11:51
BAndiT1983
great!
13:08
lexano
left the channel
13:19
uberardy_
left the channel
13:21
uberardy
joined the channel
13:21
lexano
joined the channel
13:56
BAndiT1983
metal_dent[m]: regarding one of the last topics about anti-aliasing, we would have to use XPM format, at least form what i see at wikipedia, as XBM is only monochrome
13:57
BAndiT1983
but this could result in more steps involved in processing, as XPM is stored a bit differently
13:58
Bertl
hmm?
13:58
BAndiT1983
Bertl: do you think we can convert to 2-bit depth in XBM? or it doesn't matter in IM?
13:58
Bertl
let's take a step back and talk about the purpose :)
13:59
Bertl
anti-aliasing is the process of 'smoothing' edges when they get drawn on discrete pixels
13:59
BAndiT1983
se6ast1an has suggested 2bit depth or more, to get some sort of precomputed anti-aliasing, at least against predefined background (light/dark)
14:00
Bertl
if you want to 'bake' that into a bitmap, do it via an alpha channel
14:00
Bertl
(and compute the alpha blending operation when applying)
14:00
lexano
left the channel
14:01
Bertl
but you could also use some heuristics to generate the smoothing on the fly with a single bitmap
14:01
BAndiT1983
isn't it unnecesary additional operation? we know our buttons beforehand and they are usually black or white
14:01
BAndiT1983
if we do some fake anti-aliasing against white and/or black, shouldn't it be sufficient?
14:02
Bertl
what's the advantage?
14:02
BAndiT1983
no calculations involved on the pic32
14:02
Bertl
how so?
14:04
BAndiT1983
we compute the pixels while converting, so outer ones are turing lightgray on edges, depending on the background, which is not included in final data
14:04
BAndiT1983
http://dangerousprototypes.com/blog/2019/10/17/bus-pirate-2bit-anti-aliased-font-for-small-color-lcds/
14:05
BAndiT1983
as the screen is small, it's already difficult to keep the letters crisp
14:05
Bertl
so you want to drop the alpha interpretation completely and have 2bit gray images/fonts, yes?
14:06
BAndiT1983
yes, don't see the use case yet, where it's necessary to introduce alpha in the UI yet
14:07
BAndiT1983
*-yet 1x
14:07
Bertl
note that I still think that a proper bitmap font without anti-aliasing is better readable than any anit-aliased font
14:08
BAndiT1983
this is the second variant, as i'Ve actually stumbled upon an article how to avoid anti-aliasing with different font form
14:08
BAndiT1983
https://daringfireball.net/2003/03/anti-anti-aliasing
14:10
Bertl
in any case, to answer the original question: you probably have a bunch of options there and you should think hard about how you render the two bit images
14:11
Bertl
most likely you want to keep the four color values in the cache/registers and use two bits for every pixel to decide which one to actually write to memory
14:11
Bertl
depending on the character width, you probably want to get those bits in a stream
14:12
Bertl
so probably the best approach would be to pack the 2bit values per character into an array
14:12
BAndiT1983
first question is, if we can get such data from font generation tools
14:13
BAndiT1983
as they are targeting simple 1bit approach
14:13
Bertl
what 'font generation tool' are we talking about?
14:14
BAndiT1983
e.g. http://oleddisplay.squix.ch/#/home which does output GFXfont compliant ones
14:14
BAndiT1983
we are using adafruit GFXfont, so it's one of the requirements for now
14:14
Bertl
what is it with those online tools?
14:15
lexano
joined the channel
14:16
Bertl
why is it so appealing to integrate a tool in your workflow which can change any minute and might/will go away from one day to the other?
14:16
BAndiT1983
the fonts don't change much, but manual way is also there, but not very appealing -> https://github.com/adafruit/Adafruit-GFX-Library/blob/master/fontconvert/fontconvert_win.md
14:16
Bertl
anyway, if you get the proper 2bit depth output, you can use python (or similar) to rearrange the data
14:18
BAndiT1983
my link is showing windows build, but makefile is also there, haven't noticed prior posting
14:19
BAndiT1983
have to check what's possible there, could be that fontconvert can be adjusted with just few lines of code
14:25
BAndiT1983
ok, tried fontconvert, at least it converts to right format, will check if the font appears properly in the firmware UI, but anti-aliasing is another topic to take on, as this fonts are clearly 1bit
14:33
BAndiT1983
font appears, seems to work correctly
14:35
BAndiT1983
this guy had also trouble with missing antialiasing and create his own editor, but as always it's not usable for our purpose, as it uses C# -> https://forum.arduino.cc/index.php?topic=418598.15
14:58
metal_dent[m]
so finally are we thinking of a 2-bit depth or changing the conversion process and use XPM format?
14:59
BAndiT1983
have to check if IM converts also to 2bit for XBM, as it shouldn't matter the conversion process much, but drawing
15:01
BAndiT1983
if nothing helps, then we could think about alpha (2bit should also be enough), but i would like to avoid this gimmicks for now
15:02
BAndiT1983
as font conversion is another topic which kicks in and won't be that simple to solve, as we have to adjust the converter tool
15:11
futarisIRCcloud
left the channel
15:19
BAndiT1983
changed nick to: BAndiT1983|away
15:26
futarisIRCcloud
joined the channel
15:31
se6ast1an
back
15:32
se6ast1an
lets not focus on the 2bit/font topic for now as its nice-to-have but not essential
15:56
Oscar80
joined the channel
15:57
Oscar80
Hi everyone!
15:59
se6ast1an
hi Oscar80!
16:00
panintended
joined the channel
16:00
se6ast1an
good evening
16:00
se6ast1an
MEETING TIME!
16:00
se6ast1an
who wants to report? please message me now
16:01
panintended
left the channel
16:01
se6ast1an
Oscar how are things going for you?
16:03
Oscar80
Very difficult times, but fortunately we can reopen the gallery next week. And you?
16:03
se6ast1an
good to hear
16:04
se6ast1an
home work orders has boosted my avaiable time significantly :)
16:04
se6ast1an
first film shoot is resuming on Wednesday again though
16:04
se6ast1an
ok while others are still ariving or occupied
16:04
se6ast1an
quick updates
16:05
se6ast1an
panintended has another work meeting right now but messaged me with progress to share:
16:05
se6ast1an
<panintended> Here's what I worked on last week:
16:05
se6ast1an
<panintended> Worked together with BAndiT1983 and solved https://lab.apertus.org/T1181
16:05
se6ast1an
<panintended> Next for me is to finish with https://lab.apertus.org/T1184
16:05
se6ast1an
<panintended> Unfortunately I didn't have nearly as much time as I hoped this week.
16:05
se6ast1an
upcoming today is the gsoc deadline, in less than 2 hours the student slots will be released
16:06
se6ast1an
meaning we will know who we will be able to work with this year
16:06
se6ast1an
so that will be very exciting, stick around
16:06
se6ast1an
quick update from my personal development front:
16:07
se6ast1an
I have mainly worked on the AXIOM Remote recently - mainly
16:07
se6ast1an
https://lab.apertus.org/T1177
16:07
se6ast1an
we also applied for another google program that has the deadline today called google season of docs
16:07
se6ast1an
https://www.apertus.org/google-season-of-docs-calling-all-technical-writers-article-may-2020
16:08
se6ast1an
https://developers.google.com/season-of-docs
16:08
daFred
joined the channel
16:08
se6ast1an
hi manfred
16:09
daFred
Hello!
16:09
se6ast1an
any news on your front daFred?
16:10
daFred
Laser is in operation, I'll test cutting the rubber soon...
16:10
se6ast1an
hurray!
16:10
se6ast1an
I have received a 3m glue sample recently so I want to also test the glas-metal glueing once the factory hub is back in action (soon)
16:11
daFred
testesd cutting fabric for DIY facemasks :-)
16:12
se6ast1an
and did that work?
16:12
se6ast1an
ok anyone else here who wants to report? vup, anuejn, metal_dent[m]?
16:12
se6ast1an
BAndiT1983|away: seems away
16:12
se6ast1an
Bertl: will go last
16:13
vup
yeah I have some things to report
16:13
vup
give me a sec
16:13
se6ast1an
schmoggie: messaged saying: no news but wants to discuss 3.1V for lens control
16:13
se6ast1an
great vup
16:13
Bertl
schmoggie: great, I'm around ...
16:13
se6ast1an
so schmoggie I would suggest we do that right after the reports are done (which should be rather soon)
16:14
vup
ok
16:14
vup
So first (mostly worked on by anuejn):
16:14
vup
The high performance, multi buffer axi writer is working:
16:14
vup
It has two slight improvements over the current one use in the beta:
16:14
vup
1. you don't have to program fixed buffer sizes, instead the writer has a additional signals for when to switch buffers
16:14
vup
2. buffers don't have to be aligned to the maximum burst size
16:14
vup
A theoretical disadvantage is that the writer does not have multiple transactions at once inflight, this doesn't seems to cause any performance problems. (we get about 11.2Gbit/s, for more details, check the log from last tuesday: http://irc.apertus.org/index.php?day=28&month=04&year=2020#238 )
16:14
vup
Example code, that test the writer: https://github.com/apertus-open-source-cinema/nmigen-gateware/blob/master/src/axi_writer_test.py
16:14
vup
Additionally more high level abstractions were added (visible in the example code aswell), like `csr_for_module`, that takes a module and some register names and exposes these registers over axi.
16:15
vup
Second, I finished most of the micro r3 schematic
16:15
vup
pdf of the schematic can be found here: https://github.com/apertus-open-source-cinema/axiom-micro-mainboard/blob/r3/micro_rev3/micro_rev3.pdf
16:15
vup
There are still some open todo's: https://github.com/apertus-open-source-cinema/axiom-micro-mainboard/issues/1
16:15
vup
but most of them are minor. I think now would be a good time if somebody else wants to take a look at the schematic and point out all the obvious mistakes / problems :) (Bertl?)
16:15
vup
Also any feedback on the open todo's is appreciated (the ones without a checkmark).
16:16
Bertl
yep, will do
16:16
Bertl
I also have some test proposals for the AXI writers
16:17
vup
some general information on the r3 was also added here: https://github.com/apertus-open-source-cinema/axiom-micro-mainboard/blob/r3/README.md
16:17
vup
Bertl: nice
16:17
vup
Bertl: regarding the test proposals, do we want to discuss them after the meeting?
16:17
Bertl
yes
16:17
vup
sounds good
16:18
vup
so if nobody has questions / remarks, that would be it from me :)
16:19
se6ast1an
excellent, will read the links afterwards!
16:20
BAndiT1983|away
changed nick to: BAndiT1983
16:20
Bertl
vup: is there a 'better' (e.g. colored?) version of the schematic available, it is really hard to read with all the overlapping text and frames?
16:20
vup
Bertl: I don't think so, but I will look into it
16:21
vup
i can atleast make the labels smaller, so they don't overlap
16:21
Bertl
think that would definitely help a lot
16:21
vup
other than the labels I don't really see any overlapping stuff
16:21
Bertl
is there no color used at all in the schematic tool?
16:21
vup
doesn't seem like it
16:21
Bertl
strange decision ...
16:22
vup
yeah
16:23
se6ast1an
vup: "no LVDS connections to the plugin modules" -> can you drive the HDMI plugin module then?
16:23
vup
no
16:23
vup
the idea would be to output a video feed over the usb-c connectors
16:24
vup
(using just normal usb 3.1 data transfer, we thought about maybe doing display port alternate mode, but that has some technical difficulties)
16:24
Bertl
isn't the plugin module attached to the ECP5?
16:24
vup
only the gpio's
16:26
se6ast1an
the fosdem guys were very interested in a camera for their live stream setups for recording their talks, the beta was much too expensive though as they have up to 30+ rooms in paralell, but they require some kind of live video feed
16:26
se6ast1an
but a PC receiving USB3 video and displaying it would work just fine as well I assme
16:26
vup
Yeah I think so
16:27
se6ast1an
display in the sense of HDMI output of fullscreen framebuffer
16:27
Bertl
so where are the plugin LVDS pairs conencted to?
16:27
vup
to the z-turn lite / zynq
16:27
Bertl
okay, guess you lost me on the "no LVDS connections to the plugin modules" then
16:27
vup
this is without a z-turn lite
16:28
vup
the board is supposed to be usable with and without one
16:28
Bertl
ah, got it
16:28
vup
(The main problem with connecting the LVDS pairs of the plugin modules to the ECP is, that they only do 400MHz DDR, so 1080p60 HDMI would be very out of spec for them)
16:29
Bertl
yes, makes sense
16:29
se6ast1an
is there are reason to keep the plugin module slots then still?
16:30
vup
well if you only ever plan to use the board without a z-turn lite connected you can just not populate the plugin module slots (and the connector for the z-turn lite)
16:31
vup
however if you connect the z-turn lite, you gain the flexibility of the plugin modules (maybe you need HDMI, or even SDI?)
16:32
vup
but yeah building a minimal camera, with only usb-c and a ecp is a idea anuejn and I have been thinking about
16:32
vup
we might go into that direction after getting some experience with the ecp on this board I think
16:33
Bertl
makes sense
16:34
Bertl
did you do any of the PCB placement/routing yet?
16:34
vup
nope
16:35
Bertl
okay
16:35
se6ast1an
ah, so if the zturn is present the plugin module slots do get useable, that wasnt clear to me
16:35
vup
yes exactly
16:35
vup
any suggestions on how to reword it to make it clearer?
16:36
se6ast1an
just added a sentence to the readme
16:36
se6ast1an
sounds good, many thanks for the update, anything to add?
16:37
vup
nope I think thats it :)
16:38
se6ast1an
great
16:38
se6ast1an
metal_dent[m]: please give us your overview of last weeks progress?
16:38
metal_dent[m]
so last week I completed the ImageButton but still there many things to add/modify :
16:39
metal_dent[m]
1. the current implementation has the fixed icon/button size which needs to be flexible as the button can be of any size
16:40
metal_dent[m]
2. we also can have a button with image as well as text so need to incorporate that in the ImageButton
16:41
metal_dent[m]
se6ast1an has also assigned the checkbox task which I'll start soon :)
16:41
metal_dent[m]
I guess that's it from my side
16:42
Bertl
great!
16:42
se6ast1an
many thanks!
16:43
BAndiT1983
should i continue?
16:43
se6ast1an
BAndiT1983: please be so kind and charm us with your weekly progress update report
16:43
BAndiT1983
hi everyone, sorry for being late today
16:43
BAndiT1983
se6ast1an has already told a part of tasks from last week, e.g. the problems with the rendering in visualiser
16:44
BAndiT1983
additional tasks were create by me for it, like export screenshot button, so we can have quicker results when trying to identify problems or show final results
16:45
BAndiT1983
currrently planning to continue with bootloader and while looking at latest state, i'Ve understood that we can just simulate the communication from and to remote by using virtual serial loopback cable and small app which reprensets the server on the camera
16:46
BAndiT1983
no real emulation can be do so far as QEMU lacks pic32 support and the implementation of sergev is also missing some things which would require workarounds in our code or fixes in his, but his QEMU version is dated by now
16:47
BAndiT1983
so planning to add an example for serial communication, which should help development without hardware, this would also allow to reuse the visualiser instead of the board and later as remote for the board, e.g. via SSH
16:47
BAndiT1983
besides that tasks like GSoC preparation, guidance and managing the module were on the list
16:47
BAndiT1983
that would be it from me
16:48
Bertl
is there QEMU support for the Microchip SAM devices?
16:48
BAndiT1983
this is something i haven'T checked, as our focus wasn't on it yet
16:49
BAndiT1983
but it's arm, so i think yes
16:49
Bertl
would be nice to know I guess?
16:49
BAndiT1983
sorry, ARM
16:49
Bertl
well, the PIC32 is mips and mips support is in QEMU
16:49
BAndiT1983
example: https://github.com/intel/zephyr/tree/master/samples/net/echo_server
16:50
BAndiT1983
but not the special side of it, as far as i know the fork from sergev was never merged
16:50
Bertl
yes, the same is relevant for ARM though
16:51
BAndiT1983
zephyr is same70, so it looks like yes, from my link
16:51
BAndiT1983
https://docs.zephyrproject.org/1.11.0/boards/arm/sam_e70_xplained/doc/sam_e70_xplained.html
16:51
BAndiT1983
they emulate network interface and other periphery there
16:52
Bertl
okay, so that is a good argument to switch to the SAM E70 series then
16:53
BAndiT1983
tried to update sergev fork to newest version, but it requires a lot of time and knowledge about QEMU, pic32 and how to port the structures to new ones, as interfaces changed a lot in QEMU
16:54
BAndiT1983
as firmware is more or less agnostic, periphery needs can be circumvented, would still be interesting to have proper emulation
16:57
se6ast1an
anything else to add regardint this topic?
16:57
BAndiT1983
nope, we are alive and kicking, more progress happened tha expected, thanks to all contributors
16:57
se6ast1an
otherwise Bertl would you be so kind to round off the meeting with your report?
16:57
Bertl
sure
16:58
Bertl
first, a quick question from my side to all GSoC applicants: will you continue working with apertus even if you do not get a slot this year?
16:58
Bertl
...
16:59
Bertl
so, we did some testing with the Ultra96-v2, specifically on the USB 3 side
16:59
Bertl
and while the results were not _that_ great in the beginning (we got about 275MB/s sustained write throughput)
17:00
Bertl
we think that it is more a problem on the peripherial side than on the Ultra96-v2
17:00
Bertl
for this reason we are designing some more elaborate tests and will probably figure out the raw capabilities later this week
17:01
Bertl
there are some quite interesting aspects on the UltraScale+ architecture, for example, we could use the mini DP peripherial to do overlays on live streams
17:01
Bertl
even if we do not use the mini DP itself for output
17:03
Bertl
we might also be able to repurpose the mini DP lanes for e.g. PCIe/NVMe connections
17:03
Bertl
or maybe SATA 6G ... not sure about the options here yet but it looks promising
17:04
Bertl
we also did some preliminary tests on the SD card interface of the Axiom Beta (and why it doesn't boot when extended/muxed)
17:04
Bertl
the results were quite informative but are not conclusive yet
17:05
Bertl
we figured that it is likely that the Zynq SD controller is simply working out of spec and behaves a little picky on the signal side
17:06
Bertl
we also figured that the SD mux we used seems to have its own set of issues as it doesn't provide the full performance even when used with a different card interface
17:07
Bertl
we have a number of ideas to continue the tests there and I'm optimistic that we will find a suitable solution in the near future
17:07
Bertl
on the Axiom Remote side, the first remote was completed and preliminary tests show that it is working fine
17:08
Bertl
I didn't attach the Remote Remote yet as I want to test the LCD first and changing components later would be quite some work
17:08
bluez_[m]
> first, a quick question from my side to all GSoC applicants: will you continue working with apertus even if you do not get a slot this year?
17:08
bluez_[m]
I am willing to.... although there won't be any time limits so I would do it in my spare time...
17:09
Bertl
the Remote workplace progresses well too, we should have it up and running this week, including access to the Remote and at least two partial Betas for FPGA development
17:10
Bertl
I guess that's it from my side for this week
17:10
metal_dent[m]
> first, a quick question from my side to all GSoC applicants: will you continue working with apertus even if you do not get a slot this year?
17:10
metal_dent[m]
sure, I'm also willing to do it :)
17:12
Bertl
I guess that concludes the meeting for today?
17:12
se6ast1an
many thanks for the update
17:12
se6ast1an
anyone else with topics?
17:13
se6ast1an
otherwise I would suggest we discuss the power supply topic with schmoggie
17:13
Bertl
he asked me to ping him when the discussion with vup is over
17:14
Bertl
but I'm fine either way
17:14
vup
yeah me too
17:14
se6ast1an
right here right now :)
17:14
vup
i redid the pdf with smaller labels, should be alot less overlapping stuff now
17:15
vup
also looked into colored pdf export, but that doesn't seem possible yet
17:15
vup
that doesn't stop me from hacking it in though
17:15
Bertl
sounds good, looking forward to it ...
17:16
Bertl
how did you arrive at the TPS65400 as PMIC?
17:18
vup
it was the lowest $/channel i2c controllable pmic with about 2A current capability per channel
17:18
vup
that we found anyways
17:18
Bertl
so the price was the deciding factor, yes?
17:19
vup
after everything else looked resonable, yes
17:20
Bertl
what were the alternatives which lost price wise if I may ask?
17:21
schmoggie
i'm here.
17:22
Bertl
okay, then let's talk 3.1V :)
17:22
schmoggie
if i recap correctly, we have LENS_POWER = 5.0 or unregulated 7.4 . thru my traces i only found 5.0V ones.
17:24
Bertl
so as far as I understood, there are two aspects of the lens interface
17:25
Bertl
for one, we need to have a switchable supply to power/reset the lens
17:25
Bertl
this is probably fine with a 5V (???mA) supply which can be enabled and disabled under software control
17:26
schmoggie
The Logic VCC = 3.15V and the data lines as well. but they deliver 3.3V on the teensy.
17:26
Bertl
and then we have the communication interface which is working at 3.1V bidirectionally to communicate with the lens system
17:27
Bertl
now, do we know that the 3.1V (or 3.15V) is a thing or is that just what we (you) measured
17:27
Bertl
?
17:27
schmoggie
i recieved the module just today, so i mgiht try it with 3.3V on the cheaper lens and see the outcome.
17:28
schmoggie
if it get fried it's just $10 lens
17:28
Bertl
there are options to avoid even that, which we should discuss :)
17:28
schmoggie
lens is bit broken optically, so no reason not to try it out
17:28
Bertl
and note: testing it on a cheap lens doesn't mean that it will work for all :)
17:28
Bertl
anyway, where does the 3.1/3.15V come from?
17:29
schmoggie
from here: https://docs.google.com/document/d/1iw54nzrF0bzQgLINpcP9F8Odd0N5cd7LjlwCDPTNZK0/edit#
17:29
schmoggie
and from my measurements with the logic analyser
17:30
Bertl
okay, great!
17:30
Bertl
so, who provides the LOGIC_VCC?
17:30
Bertl
the camera?
17:31
schmoggie
LOGIC_VCC comes from camera body, yes
17:32
mumptai_
3.15V might just be a way to save a few percent of power consumption, while staying within psu toleance and 3.3V/+-10%
17:33
Bertl
okay, so we need to provide that voltage and use it for RXD/TXD as well as the two handshake lines, yes?
17:33
Bertl
the lens detect is a passive feature which basically just provides an input to the camera by connecting to ground
17:34
Spirit532
left the channel
17:34
schmoggie
yes, we need that for Pin 5 &9
17:34
Spirit532
joined the channel
17:34
Bertl
okay, so what is the board you got for testing?
17:36
schmoggie
lens detect is initially done with PIN 10. if is != GROUND no Pin 2 and comms
17:36
schmoggie
i have a Teensy 3.5
17:36
schmoggie
MK64FX512
17:36
BAndiT1983
changed nick to: BAndiT1983|away
17:38
schmoggie
ah crap. it seems it's the wrong one ("All digital pins are 5 volt tolerant."
17:39
Bertl
tolerant doesn't mean it is working at 5V
17:39
vup
-> afk, will come back later
17:39
schmoggie
but it says "3.3V signals, 5V tolerant"
17:39
schmoggie
now i am confused
17:40
mumptai_
its usually just a different ESD protection circuitry
17:40
Bertl
https://www.pjrc.com/store/teensy35.jpg
17:40
Bertl
this what it looks like?
17:41
schmoggie
exactly
17:43
Bertl
the ARM CPU seems to work from 1.71 to 3.6V
17:44
Bertl
so probably the simplest way would be to reduce the 3.3V to 3.1V for the entire board
17:45
Bertl
but I'm a little confused by the teensy 3.5 schematic
17:46
Bertl
to me it seems the MK64FX512 has a 3.3V regulator output (VREG_OUT) but it is probably used as imput in the design?
17:46
Bertl
the actual voltage regulation is done by the LP38691
17:48
felix_
vup: is it intended that the clock inputs of the gigabit transceivers are unconnected? at least on xc7* the dedicated gtp clock inputs have lower jitter
17:48
Bertl
schmoggie: so, depending on what you have available and how good you are with soldering :)
17:49
Bertl
my suggestions would range from disabling the VBUS (5V) which should be doable by removing a (solder?) jumper
17:49
felix_
vup: probably not relevant for the flash part you selected, but i'd add pull-ups to the two unconnected data pins that are !wp and !hold on other flash parts
17:49
Bertl
and providing 3.1V on the 3.3V pins
17:50
Bertl
(which would simply make the ARM work with 3.1V instead and you can directly conenct it to all I/Os without any problems)
17:51
Bertl
to adding two or three power diodes, either in the power supply path for the ARM or on each outgoing I/O pin
17:52
Bertl
each diode will typically give a voltage drop of 0.8V so two of them will put you at 3.14V
17:53
Bertl
the inputs will be fine as they are probably okay with 3.1V even on 3.3V I/O voltage
17:54
schmoggie
can i ship you the teensy and you did the modification & power test ?
17:54
schmoggie
i am not so good with soldering in little scale
17:55
Bertl
okay, then it is probably better we go a different route
17:55
schmoggie
then you can modify the teensy for our use and send it back
17:55
Bertl
yeah, probably would be easier to get one myself, modify it and send you that one
17:56
felix_
vup: i'd add some esd protection on the usb2 and super speed lanes of the type c connectors. esd on usb lines has already bitten me once... i'd use a usb2 phy instead of connecting the usb2 pairs to fpga io pins
17:56
Bertl
schmoggie: but I think we can do better than that it just takes more time (as would the send, modify, return) anyways
17:57
se6ast1an
guys quick interuption as gsoc results are about to go live in a few mintues
17:57
se6ast1an
I assume students will show up here on our org page: https://summerofcode.withgoogle.com/organizations/6367280998383616/
17:57
se6ast1an
in 2 minutes
17:57
Bertl
schmoggie: so, my suggestion would be to design a shield for the Axiom Beta which has the necessary parts to provide the switchable power supply for the lens (maybe with external 5V power, we'll see) as well as the 3.15V supply and logic interface
17:58
Bertl
we might also make it flexible enough to be connected to the teensy via some dupont cables
17:58
schmoggie
seems the best possible way.
17:59
schmoggie
and what do we use for programming / coding ?
17:59
felix_
vup: i find having linear regulators for the fpga core voltage a very odd choice. that poor ldo has to dissipate 3 times the power the fpga draws on that rail
17:59
Bertl
schmoggie: hmm?
18:00
felix_
vup: oh, wait, i looked at the wrong rail; that 1,2v rail seems to be for the gtp
18:00
felix_
vup: might be worth looking into having the ldos fed by the 3.3 or 2.5v rail to lower losses
18:01
schmoggie
okay, so day 1 we will use the teensy to connect to the shield.
18:01
schmoggie
but finally, which rtos platform do we want to use
18:01
schmoggie
that was my question
18:01
Bertl
ah, we are running Linux on the Axiom Beta
18:02
schmoggie
i know. whcih is great.
18:02
Bertl
and we have two FPGAs available for e.g. shield or similar
18:02
schmoggie
well. we'll find out.
18:02
schmoggie
i see 5 accepted projects
18:02
schmoggie
(summerofcode)
18:03
Bertl
yup, congratulations to our GSoC 2020 Students!
18:04
felix_
nice! congrats to the student whose projects got selected
18:04
Bertl
Sorry to those who didn't get selected, we requested more than five slots but five slots is what we got ...
18:04
se6ast1an
well done!
18:04
se6ast1an
we had 6 last year so that was a bit of concern at first
18:04
schmoggie
congratulations to the apertus' GSoC 2020 Students!
18:05
schmoggie
and nice projects as well.
18:05
metal_dent[m]
thank you so much everyone!! specially BAndiT1983 , Bertl and se6ast1an :-)
18:07
felix_
vup: did you check if there are some power sequencing requirements from the ecp5?
18:08
bluez_[m]
Thank you all! And also congrats to other participants! :)
18:14
felix_
vup: it is intended that the ensw* pins of the tps654000 are tied to ground and the rails are disabled by default and have to be enabled via the pmbus interface, right?
18:21
rahul_vinus
congratulations to GSoC 2020 Students..
18:21
felix_
vup: on the dram part, the zq reference resistor is probably missing. i find the data lane layout on the schematics symbol a bit unintuitive; i'd group the dqs pairs with the corresponding dq byte lane
18:40
BAndiT1983|away
changed nick to: BAndiT1983
18:53
vup
felix_: you are right, using a clock coming from the fpga core adds jitter according to the datasheet, but https://github.com/enjoy-digital/usb3_pipe is also using a clock coming from the fpga, so I was hoping to get away with with just that, what do you think?
18:53
vup
pullups for !wp and !hold sound good
18:56
vup
esd for usb sounds like a good idea, what would we gain by using a usb2 phy? just easier gateware development?
18:59
Bertl
vup: regarding MGT reflock: it would be good to plan for a small mems oscillator there, doesn't need to be populated in the end
18:59
Bertl
*refclock
19:01
vup
yeah seems reasonable
19:01
vup
felix_: yeah the two 1V2 LDO's are for the gtp
19:02
vup
feeding them by the 3V3 or 2V5 rail sounds like a good idea
19:05
felix_
uh, good question if jitter will be an issue there. it reduces the size of the eye of the signal, but it might be that it's still big enough. in combination with cheap cables this might be a problem
19:05
felix_
i'd be very wary of mems oscillators; those tend to jitter quite a bit
19:06
felix_
i think azonenberg had massive issues with a mems oscillator and a gigabit ethernet phy
19:06
vup
yeah I remember that
19:07
felix_
so i'd rather add a footprint for a proper crystal oscillator that connects to the gtp clock reference input
19:09
vup
the only power sequencing requirement of the ecp seems to be that VCCIO8 (the bank supply voltage used for configuration) should be ready before the fpga start its programming from the spi flash, which hopefully should workout with the PROGRAMN pullup being to the rail used to power the VCCIO8, but we could be safe and just add a pullup to 3V3 for the enable of the core supply
19:11
vup
felix_: yes the rails of the tps654000 are supposed to disabled by default (apart from the one used for the bank supply for the jtag configuration) to be able to set the voltage before enabeling them
19:12
vup
I fully agree that the dram symbol is unintuitive, I drew it before I knew what dqs were :)
19:19
vincentlenoir
joined the channel
19:21
vincentlenoir
left the channel
19:22
felix_
vup: did you also check if the fpga has some requirements how the dq/dqs pins have to be wired to the io pins? at least on xc7* devices there are certain limitations
19:22
vincentlenoir
joined the channel
19:22
vup
yeah ecp has that aswell
19:23
vup
If I didn't fuck anything up they should be ok this way
19:23
RexOrCine
Bertl this is Vincent (vincentlenoir). He's skilled with RTL. Also does some work on Zynq-7000/Ultrascale+ devices. He's wondering about how best to contribute if he ever has some spare time.
19:24
Bertl
hello vincentlenoir!
19:24
vincentlenoir
hello guys
19:24
se6ast1an
I recommended you two meet, great that it seems to work out right away, wonderful :)
19:24
felix_
oh and check if the dqs pairs are wired in a way that they connect to the pins near the corresponding byte lanes. i think currently the dqs pair and byte enable goes to the wrong dq byte lane
19:24
felix_
vup: ^
19:26
Bertl
vincentlenoir: kindly tell us a little bit about you ... what you've been working on and what brought you here ...
19:26
felix_
yeah, ldqs is for dq[0..7] and udqs for dq[8..15]
19:27
vup
yeah so much for not fucking something up :)
19:28
felix_
the pcb isn't manufactured yet, so no harm done ;)
19:29
vincentlenoir
I'm a digital hardware designer working on ASIC design, especially for low-power RF chips, so I'm use to develop with VHDL on a daily basis. On spare time I worked a bit on Zynq platform too but mainly for prototyping purpose.
19:29
Bertl
felix_: it is not even placed or routed, so good that somebody spotted it early
19:29
vup
felix_: yeah your feedback is very appreciated
19:32
vincentlenoir
And what brought me here, well I follow the project on Twitter for some time now, love the idea and the full design from electronics to mechanics.
19:33
Bertl
sounds great! any specific areas you would like to work on?
19:33
vup
A btw Bertl here are some of the pmics we looked at:
19:33
vup
low current ones: MC34704, LP8725, TPS65023, LP3907, NCP6924CFCHT1G
19:33
vup
more expensive one: TPS6594, LTC3589 (also rather low current)
19:33
vup
we also considered the ones on the powerboard 2.23
19:33
vup
non i2c ones we looked at: LTC3374
19:34
vincentlenoir
actually anywhere you need help, RTL design, documentation/translation (FR), electronics design review
19:35
Bertl
okay, we certainly can find something there :)
19:36
Bertl
vup: check out the Infineon IRPS5401 ... it is rather nice and has internal telemetry (voltage/current) as well
19:37
vup
will do
19:38
mumptai_
left the channel
19:38
mumptai_
joined the channel
19:39
RexOrCine
Translation would be me Vincent, but FPGA tasks should be a priority. Could probably work something out eventually, though. Kind of you to offer!
19:39
Bertl
vincentlenoir: there are a number of VHDL related tasks not addressed by this years GSoC, so you might be interested in looking into those and/or helping out with the future Axiom Firmware design which we should start in the near future ...
19:40
felix_
vup: https://github.com/azonenberg/pcb-checklist/pull/5
19:40
vup
:)
19:41
Bertl
vincentlenoir: for example T728 and T1131 (https://lab.apertus.org/project/view/20/)
19:42
Bertl
felix_: did you take a vacation? your github image looks so relaxed! :)
19:45
felix_
since march i'm an AMD employee working on coreboot
19:46
felix_
also spent 8 days in hospital last month after an emergency appendix removal surgery; currently still recovering from that. things were already pretty bad, but i've recovered well
19:47
vincentlenoir
Bertl: ok let me look at these and I get back to you
19:47
Bertl
sorry to hear, so the picture is from good old times then ...
19:47
Bertl
vincentlenoir: do not hesitate to ask questions here, you'll get answers if we have them :)
19:48
vincentlenoir
great, thanks :-)
19:49
felix_
the profile picture is from my trip to the bay area in 2018
19:51
vup
Bertl: the IRPS5401 doesnt support programmable Vref, right? so instead of external current sense we then need a i2c potentiometer or something like that
19:56
Bertl
not sure I follow ...
19:57
vincentlenoir
left the channel
19:57
Bertl
what do you use the adjustable VREF for exactly?
19:57
vup
to adjust the output voltages
19:58
vup
by vref i mean the voltage the voltage on the fp pins is compared to
19:58
Bertl
well, you do that on the IRPS5401 with the VOUT_MODE/COMMAND/TRIM
20:00
vup
oh
20:00
vup
interesting
20:03
Bertl
as far as I can tell, the only drawback would be the lower input voltage range (max 12V)
20:05
vup
yeah and maybe slightly higher price
20:05
vup
but I am seriously considering it
20:05
vup
good find
20:05
Bertl
if the telemetry is sufficient, that is probably the cheaper solution in the long run
20:06
Bertl
I found it in the Ultra96-v2 schematic among other nice parts
20:06
Bertl
(they use two of them :)
20:07
vup
yeah I think the telemetry should be sufficient
20:07
vup
Ah nice what other nice stuff did you find?
20:07
vup
(if we use them we will use two of them aswell :)
20:08
Bertl
for example the shottky diodes used as polarity protection
20:08
Bertl
unfortunately they have been discontinued by the manufacturer
20:08
Bertl
still available, but not suitable for new designs
20:10
Bertl
*schottky
20:11
Bertl
DB2F43100L1 from Panasonic
20:11
BAndiT1983
what about alternatives?
20:11
Bertl
unfortunately didn't find any yet
20:12
Bertl
the nice part there is 40V/5A in 1616 (metric)
20:13
vup
nice
20:15
BAndiT1983
cannot imagine that nothing exists that can replace it
20:16
Bertl
the next best part I found is the PDS1040CTL from Diodes
20:16
Bertl
which is way larger and twice as expensive :)
20:17
Bertl
(well, to be fair, it has two diodes)
20:18
Bertl
BAndiT1983: if you find an alternative, that would be quite interesting
20:19
BAndiT1983
it would be a kind of magic, as i'm not that deep into electronics yet
20:19
BAndiT1983
do you have some key data, like price and size?
20:19
Bertl
PMEG4050 is a good choice as well, but SOD128
20:20
Bertl
40V 5A Schottky Barrier Diode (or Rectifier) in a package below 2x2mm
20:21
Bertl
(well 30V would be more than enough)
20:24
Bertl
vup: the clock generator they used for the MGT clocks looks nice too
20:24
vup
already looking at it just this moment :)
20:26
vup
but I cant find a distributor
20:27
Bertl
not for this specific one, but there are more in the VersaClock family
20:28
Bertl
for example the 5P49V6975A000LTGI is readily available
20:28
Bertl
haven't figured out what the numbers mean in detail yet :)
20:29
vup
lol
20:29
vup
nice
20:31
vup
but $6.5 is still quite steep (atleast for using it in the micro)
20:31
Bertl
yeah, maybe make that part of the optional MGT circuitry
20:32
vup
yeah maybe
20:32
Bertl
in general for low cost it might make sense to make a lot of things 'optional' and have different assembly plans for different price ranges
20:34
vup
yeah thats already done a bit
20:34
vup
for example you could populate the 25F or the 45F ecp
20:34
vup
there are a lot of different pin compatible choices for the DDR RAM
20:34
Bertl
also, if you search for VersaClock, you'll find that they start at 2 EUR for single quantities
20:35
Bertl
specifically the VersaClock 3 and 5 series
20:35
BAndiT1983
Bertl: what about sod-323he package?
20:35
Bertl
sounds large, let me check :)
20:36
vup
hmm yeah 2 EUR sounds more like it :)
20:36
vincentlenoir
joined the channel
20:37
BAndiT1983
biggest pain is the package naming, at least for someone who has only seldom to do with it, still haven't continued the visualisation for PCB, otherwise i would know more
20:37
Bertl
BAndiT1983: 2.3x1.4 (3.2 footprint) not bad but still large compared to the 1.6x1.6mm
20:37
BAndiT1983
agreed
20:37
BAndiT1983
looking for smd package name for comparison
20:37
Bertl
what device did you find in sod-323he?
20:37
BAndiT1983
0606 it seems
20:38
Bertl
yes, 0606 (imperial) = 1616 (metric)
20:38
BAndiT1983
could be that it's only 1A, as 5A are for different category -> https://www.mouser.de/ProductDetail/ROHM-Semiconductor/RB168VYM-40FHTR?qs=sGAEpiMZZMtQ8nqTKtFS%2FE7Jc%252BkgrGbhjfhZi52GkkF8qKZUKoemEw%3D%3D
20:38
Bertl
yeah, that is 1A for normal operation
20:40
Bertl
yes, diode packages are terrible, I have to look them up every time as there seems to be no system behind the sizes
20:40
Bertl
and they happily mix all kind of different packages as well
20:40
BAndiT1983
yep, looking at the list and 0606 is not there, so trying to figure out something, looks like a puzzle
20:49
BAndiT1983
Bertl: what about such dimensions, mean also the maximum ratings, not only size? https://www.mouser.de/datasheet/2/308/NSR1020MW2T1-D-1813512.pdf
20:49
BAndiT1983
used this page to find suitable packages -> https://www.electrodragon.com/w/Diode
20:49
Bertl
1A again, 5A is only for pulsing
20:50
BAndiT1983
ah, again what learned ;)
20:51
Bertl
SOD-323 is about 2.85x1.25 from the footprint, so close, but still larger :)
20:51
BAndiT1983
you need sod-523 or so
20:52
BAndiT1983
https://www.electrodragon.com/w/File:Diodes-smd-packages.gif
20:52
Bertl
yes, that would be greatr
20:52
Bertl
*great
20:52
Bertl
but I doubt that you will find 5A/30V in SOD-523 or smaller
20:52
vincentlenoir
left the channel
20:52
Bertl
doesn't have the thermal contact required to dissipate the losses
20:54
BAndiT1983
ah, this is another useful onfo
20:54
BAndiT1983
*info
20:54
Bertl
yeah, I think the 1616 chip scale is really at the limit there
20:56
BAndiT1983
sod-123 has some sort of pad underneath, but higher ones not, at least according to google images
20:56
BAndiT1983
this is sod-523 -> https://www.mouser.de/images/marketingid/2019/df/188629876.jpg?v=050420.0930, wouldn't this pad be enough?
21:05
BAndiT1983
have to go off for today, work awaits tomorrow, but would like to know what the advantage of very small diode would be in comparison to slightly larger alternatives
21:05
BAndiT1983
good night
21:05
BAndiT1983
changed nick to: BAndiT1983|away
21:08
Bertl
in certain cases you want to minimize PCB space and diodes are notoriously big compared to other parts
21:09
Bertl
so having a viable solution in a small package makes it simpler to design small boards
21:11
Bertl
s/big/large/?
21:39
Bertl
vup: do you know, is there a suitable nMigen toolchain for the MachXO2?
21:40
vup
I have not tried it, but it support the diamond toolchain for the MachXO2
21:40
vup
s/support/supports/
21:41
vup
Bertl: ^
21:41
Bertl
okay, so it should work in theory :)
21:42
Bertl
can I get back to you to get started with a test there?
21:42
vup
sure
21:43
vup
there is even a platform definition for a MachXO2 board: https://github.com/nmigen/nmigen-boards/blob/master/nmigen_boards/tinyfpga_ax2.py
21:44
Bertl
ah, SG32, nice :)
21:49
vup
here are some getting started guides: http://blog.lambdaconcept.com/doku.php?id=nmigen:tutorial
21:49
vup
and https://github.com/RobertBaruch/nmigen-tutorial
21:49
vup
and you can always ask anuejn or me for help :)
21:52
Bertl
great! thanks!
22:10
Oscar80
left the channel
22:34
megora
joined the channel
22:35
Bertl
hello megora!
22:35
megora
Hi Bertl!
22:36
Bertl
how is it going?
22:42
megora
Good, thanks! How are you?
22:42
Bertl
all fine here, thanks!
23:47
lexano
left the channel
23:52
lexano
joined the channel