#apertus IRC Channel Logs

hi

indeed, irc meeting & student slots announcement!

Good day!

hi metal_dent[m]

The slots will be announced after the meeting, right? ':D

so yes

UTC 18:00 indeed

IST, it will be 23:30 here :)

(fingers crossed) ':D

smiley is showing on my side, again -> ImageButton :: Draw()

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

smiley?

Screen, ImageButton, data? please explain a bit more, lost the track a bit

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

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

and where do you use it?

hi

ok, but i lack the passing of the icon width and height, how does the button handle it?

as all the icons are 24x24 so i fixed the size here

yes that's why i said that here also i should take the size from the image header, right?

text as in a caption?

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

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

not yet, just showing you examples where the ImageButton won't fit the task, it requires dynamic dimensions first

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?

great

done!

looks good

yup

please start without the text, just the icon in the center of the button

yes yes, the step 1 is that

quick reboot, manjaro likes to hide the window decorators after an update

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

great!

but this could result in more steps involved in processing, as XPM is stored a bit differently

Bertl: do you think we can convert to 2-bit depth in XBM? or it doesn't matter in IM?

anti-aliasing is the process of 'smoothing' edges when they get drawn on discrete pixels

if you want to 'bake' that into a bitmap, do it via an alpha channel

isn't it unnecesary additional operation? we know our buttons beforehand and they are usually black or white

what's the advantage?

how so?

http://dangerousprototypes.com/blog/2019/10/17/bus-pirate-2bit-anti-aliased-font-for-small-color-lcds/

so you want to drop the alpha interpretation completely and have 2bit gray images/fonts, yes?

*-yet 1x

this is the second variant, as i'Ve actually stumbled upon an article how to avoid anti-aliasing with different font form

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

depending on the character width, you probably want to get those bits in a stream

first question is, if we can get such data from font generation tools

what 'font generation tool' are we talking about?

we are using adafruit GFXfont, so it's one of the requirements for now

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

my link is showing windows build, but makefile is also there, haven't noticed prior posting

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

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

have to check if IM converts also to 2bit for XBM, as it shouldn't matter the conversion process much, but drawing

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

back

hi Oscar80!

good evening

who wants to report? please message me now

Oscar how are things going for you?

good to hear

first film shoot is resuming on Wednesday again though

quick updates

<panintended> Here's what I worked on last week:

<panintended> Next for me is to finish with https://lab.apertus.org/T1184

upcoming today is the gsoc deadline, in less than 2 hours the student slots will be released

so that will be very exciting, stick around

I have mainly worked on the AXIOM Remote recently - mainly

we also applied for another google program that has the deadline today called google season of docs

https://developers.google.com/season-of-docs

hi manfred

any news on your front daFred?

hurray!

testesd cutting fabric for DIY facemasks :-)

ok anyone else here who wants to report? vup, anuejn, metal_dent[m]?

Bertl: will go last

give me a sec

great vup

so schmoggie I would suggest we do that right after the reports are done (which should be rather soon)

So first (mostly worked on by anuejn):

It has two slight improvements over the current one use in the beta:

2. buffers don't have to be aligned to the maximum burst size

Example code, that test the writer: https://github.com/apertus-open-source-cinema/nmigen-gateware/blob/master/src/axi_writer_test.py

Second, I finished most of the micro r3 schematic

There are still some open todo's: https://github.com/apertus-open-source-cinema/axiom-micro-mainboard/issues/1

Also any feedback on the open todo's is appreciated (the ones without a checkmark).

I also have some test proposals for the AXI writers

Bertl: nice

yes

so if nobody has questions / remarks, that would be it from me :)

Bertl: I don't think so, but I will look into it

think that would definitely help a lot

is there no color used at all in the schematic tool?

strange decision ...

vup: "no LVDS connections to the plugin modules" -> can you drive the HDMI plugin module then?

the idea would be to output a video feed over the usb-c connectors

isn't the plugin module attached to the ECP5?

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

Yeah I think so

so where are the plugin LVDS pairs conencted to?

okay, guess you lost me on the "no LVDS connections to the plugin modules" then

the board is supposed to be usable with and without one

(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)

is there are reason to keep the plugin module slots then still?

however if you connect the z-turn lite, you gain the flexibility of the plugin modules (maybe you need HDMI, or even SDI?)

we might go into that direction after getting some experience with the ecp on this board I think

did you do any of the PCB placement/routing yet?

okay

yes exactly

just added a sentence to the readme

nope I think thats it :)

metal_dent[m]: please give us your overview of last weeks progress?

1. the current implementation has the fixed icon/button size which needs to be flexible as the button can be of any size

se6ast1an has also assigned the checkbox task which I'll start soon :)

great!

should i continue?

hi everyone, sorry for being late today

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

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

besides that tasks like GSoC preparation, guidance and managing the module were on the list

is there QEMU support for the Microchip SAM devices?

but it's arm, so i think yes

sorry, ARM

example: https://github.com/intel/zephyr/tree/master/samples/net/echo_server

yes, the same is relevant for ARM though

https://docs.zephyrproject.org/1.11.0/boards/arm/sam_e70_xplained/doc/sam_e70_xplained.html

okay, so that is a good argument to switch to the SAM E70 series then

as firmware is more or less agnostic, periphery needs can be circumvented, would still be interesting to have proper emulation

nope, we are alive and kicking, more progress happened tha expected, thanks to all contributors

sure

...

and while the results were not _that_ great in the beginning (we got about 275MB/s sustained write throughput)

for this reason we are designing some more elaborate tests and will probably figure out the raw capabilities later this week

even if we do not use the mini DP itself for output

or maybe SATA 6G ... not sure about the options here yet but it looks promising

the results were quite informative but are not conclusive yet

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

on the Axiom Remote side, the first remote was completed and preliminary tests show that it is working fine

> 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?

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

> 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?

I guess that concludes the meeting for today?

anyone else with topics?

he asked me to ping him when the discussion with vup is over

yeah me too

i redid the pdf with smaller labels, should be alot less overlapping stuff now

that doesn't stop me from hacking it in though

how did you arrive at the TPS65400 as PMIC?

that we found anyways

after everything else looked resonable, yes

i'm here.

if i recap correctly, we have LENS_POWER = 5.0 or unregulated 7.4 . thru my traces i only found 5.0V ones.

for one, we need to have a switchable supply to power/reset the lens

The Logic VCC = 3.15V and the data lines as well. but they deliver 3.3V on the teensy.

now, do we know that the 3.1V (or 3.15V) is a thing or is that just what we (you) measured

i recieved the module just today, so i mgiht try it with 3.3V on the cheaper lens and see the outcome.

there are options to avoid even that, which we should discuss :)

and note: testing it on a cheap lens doesn't mean that it will work for all :)

from here: https://docs.google.com/document/d/1iw54nzrF0bzQgLINpcP9F8Odd0N5cd7LjlwCDPTNZK0/edit#

okay, great!

the camera?

3.15V might just be a way to save a few percent of power consumption, while staying within psu toleance and 3.3V/+-10%

the lens detect is a passive feature which basically just provides an input to the camera by connecting to ground

yes, we need that for Pin 5 &9

okay, so what is the board you got for testing?

i have a Teensy 3.5

tolerant doesn't mean it is working at 5V

but it says "3.3V signals, 5V tolerant"

its usually just a different ESD protection circuitry

this what it looks like?

the ARM CPU seems to work from 1.71 to 3.6V

but I'm a little confused by the teensy 3.5 schematic

the actual voltage regulation is done by the LP38691

schmoggie: so, depending on what you have available and how good you are with soldering :)

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

(which would simply make the ARM work with 3.1V instead and you can directly conenct it to all I/Os without any problems)

each diode will typically give a voltage drop of 0.8V so two of them will put you at 3.14V

can i ship you the teensy and you did the modification & power test ?

okay, then it is probably better we go a different route

yeah, probably would be easier to get one myself, modify it and send you that one

schmoggie: but I think we can do better than that it just takes more time (as would the send, modify, return) anyways

I assume students will show up here on our org page: https://summerofcode.withgoogle.com/organizations/6367280998383616/

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

seems the best possible way.

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

vup: oh, wait, i looked at the wrong rail; that 1,2v rail seems to be for the gtp

okay, so day 1 we will use the teensy to connect to the shield.

that was my question

i know. whcih is great.

well. we'll find out.

(summerofcode)

nice! congrats to the student whose projects got selected

well done!

congratulations to the apertus' GSoC 2020 Students!

thank you so much everyone!! specially BAndiT1983 , Bertl and se6ast1an :-)

Thank you all! And also congrats to other participants! :)

congratulations to GSoC 2020 Students..

pullups for !wp and !hold sound good

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

yeah seems reasonable

feeding them by the 3V3 or 2V5 rail sounds like a good idea

i'd be very wary of mems oscillators; those tend to jitter quite a bit

yeah I remember that

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

I fully agree that the dram symbol is unintuitive, I drew it before I knew what dqs were :)

If I didn't fuck anything up they should be ok this way

hello vincentlenoir!

I recommended you two meet, great that it seems to work out right away, wonderful :)

vup: ^

yeah, ldqs is for dq[0..7] and udqs for dq[8..15]

the pcb isn't manufactured yet, so no harm done ;)

felix_: it is not even placed or routed, so good that somebody spotted it early

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.

A btw Bertl here are some of the pmics we looked at:

more expensive one: TPS6594, LTC3589 (also rather low current)

non i2c ones we looked at: LTC3374

okay, we certainly can find something there :)

will do

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 ...

:)

felix_: did you take a vacation? your github image looks so relaxed! :)

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

sorry to hear, so the picture is from good old times then ...

great, thanks :-)

Bertl: the IRPS5401 doesnt support programmable Vref, right? so instead of external current sense we then need a i2c potentiometer or something like that

to adjust the output voltages

well, you do that on the IRPS5401 with the VOUT_MODE/COMMAND/TRIM

interesting

yeah and maybe slightly higher price

good find

I found it in the Ultra96-v2 schematic among other nice parts

yeah I think the telemetry should be sufficient

(if we use them we will use two of them aswell :)

unfortunately they have been discontinued by the manufacturer

*schottky

what about alternatives?

the nice part there is 40V/5A in 1616 (metric)

cannot imagine that nothing exists that can replace it

which is way larger and twice as expensive :)

BAndiT1983: if you find an alternative, that would be quite interesting

do you have some key data, like price and size?

40V 5A Schottky Barrier Diode (or Rectifier) in a package below 2x2mm

vup: the clock generator they used for the MGT clocks looks nice too

but I cant find a distributor

for example the 5P49V6975A000LTGI is readily available

lol

but $6.5 is still quite steep (atleast for using it in the micro)

yeah maybe

yeah thats already done a bit

there are a lot of different pin compatible choices for the DDR RAM

specifically the VersaClock 3 and 5 series

sounds large, let me check :)

BAndiT1983: 2.3x1.4 (3.2 footprint) not bad but still large compared to the 1.6x1.6mm

looking for smd package name for comparison

0606 it seems

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

yes, diode packages are terrible, I have to look them up every time as there seems to be no system behind the sizes

yep, looking at the list and 0606 is not there, so trying to figure out something, looks like a puzzle

used this page to find suitable packages -> https://www.electrodragon.com/w/Diode

ah, again what learned ;)

you need sod-523 or so

yes, that would be greatr

but I doubt that you will find 5A/30V in SOD-523 or smaller

doesn't have the thermal contact required to dissipate the losses

*info

sod-123 has some sort of pad underneath, but higher ones not, at least according to google images

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

so having a viable solution in a small package makes it simpler to design small boards

vup: do you know, is there a suitable nMigen toolchain for the MachXO2?

s/support/supports/

okay, so it should work in theory :)

sure

ah, SG32, nice :)

and https://github.com/RobertBaruch/nmigen-tutorial

great! thanks!

Hi Bertl!

Good, thanks! How are you?