Current Server Time: 16:13 (Central Europe)

#apertus IRC Channel Logs

2021/06/21

Timezone: UTC


00:45
Spirit532
left the channel
00:45
Spirit532
joined the channel
04:00
aombk3
joined the channel
04:09
fredy
left the channel
04:09
aombk2
left the channel
04:16
fredy
joined the channel
04:16
Bertl_oO
off to bed now ... have a good one everyone!
04:17
Bertl_oO
changed nick to: Bertl_zZ
07:07
metaldent
joined the channel
09:45
se6astian
good day
10:41
BAndiT1983_
left the channel
10:42
BAndiT1983
joined the channel
12:00
Bertl_zZ
changed nick to: Bertl
12:00
Bertl
morning folks!
16:00
se6astian
MEETING TIME! Who is here? Please message me know to get put into the report queue
16:00
BAndiT1983
is here
16:00
vup
is here
16:00
tpw_rules
i am here for the meeting
16:00
bluez
is here
16:01
Bertl
is here ...
16:01
vnksnkr
is here
16:01
tpw_rules
ok se6astian has invited me to start so, are we missing anybody? i'll wait a couple more minutes
16:01
eppisai
is here
16:02
Bertl
tpw_rules: just go ahead, everybody can read up later ...
16:03
tpw_rules
ok
16:03
tpw_rules
so i have written code to access the Beta's sensor over SPI but i have been a bit stuck because i don't have a good way to test it
16:04
tpw_rules
i can't simulate it because it mostly involves the linux device tree stuff
16:04
tpw_rules
but anuejn said i can access their Beta which does have a sensor so hopefully that can get set up today and i can proceed on that front
16:04
tpw_rules
that is it from me
16:05
se6astian
many thanks!
16:05
se6astian
is there another area you can progress on in parallel until the sensor hardware matter is settled?
16:05
vup
tpw_rules: also feel free to open a WIP PR so anuejn and I can take a first look
16:06
tpw_rules
i am not sure. the next step was the sensor LVDS lanes which also is largely a hardware matter. but i can definitely open the PR to progress on the code review
16:06
vup
se6astian: I think anuejn should be able to provide remote access to a beta with sensor very soon
16:06
se6astian
very good
16:07
se6astian
bluez: you are next
16:08
bluez
yup! so nothing much from me but i recently started working on accomodating the reconfigurable register project to the beta gateware
16:08
bluez
to gather some real world data on how it works and the utilization and stuff
16:09
bluez
i was just compiling atm and if everything looks good i would need to test it on a partial beta
16:09
bluez
which Bertl will help arrange :)
16:09
bluez
so that's it from me
16:10
se6astian
sounds good, many thanks
16:10
se6astian
vnksnkr: your turn!
16:10
vnksnkr
Hi
16:10
vnksnkr
quick updates from me..
16:11
vnksnkr
I've started working on the code to interface with the JTAGF primitive available on the MACHXO2
16:11
vnksnkr
Once that's complete I could start testing the gateware
16:12
vnksnkr
maybe first using the python scripts and then later with the kernel driver
16:12
vnksnkr
That's all from my side :)
16:13
se6astian
many thanks, any questions or comments so far?
16:13
Bertl
yes, vnksnkr also discovered a problem in our shield design
16:14
Bertl
which did go unnoticed so far, but it is probably easy to fix
16:14
se6astian
ah, interesting, please elaborate
16:14
Bertl
well, we have a shield designed for the remote control purpose
16:14
Bertl
which is basically a bunch of mosfets controlled via GPIOs
16:14
Bertl
now for whatever reason, the schematic uses N/P pairs of mosfets
16:15
Bertl
while we actually want to use N/N pairs there (i.e. no P channels)
16:15
Bertl
I have to check whether we actually populated N/P units there, I don't think we did, but the schematic there is just wrong
16:15
Bertl
luckily even if we did, this can be easily fixed as the N/N pairs have the same pinout
16:16
Bertl
so no redesign oder rewiring required
16:16
se6astian
understood, great work vnksnkr!
16:16
vnksnkr
thanks!
16:16
se6astian
eppisai: your turn
16:17
eppisai
Hi!
16:19
Bertl
hello ;)
16:20
eppisai
I have been trying to debug as to why transitions were causing crash in remote.. have been testing and have so far.. 1. Made changes to drawing by using single loop (earlier was using two, like previous version of remote) and have tried to remove centraldb variables from transition
16:20
eppisai
But still crashing..
16:21
Bertl
what kind of crash do you see?
16:22
eppisai
But, Andrej has been helping me alot , so got a rough idea of what might be causing the error .. it's where I set transition framebuffer.. so currently making complete flow chart diagram of the logic so.. can improve the entire process properly and discuss with Andrej..
16:22
BAndiT1983
crashes are related to memory usage, have tested the code on my remote and could narrow the problem down in framebuffer switch, so advised to move the logic to proper place and check the implementation regarding memory etc.
16:23
Bertl
so stack overflow or what?
16:23
BAndiT1983
could be, will port exception handlers to the main code, then i can see the address of cause
16:24
BAndiT1983
or the memory area is not set fully correctly up
16:24
Bertl
hmm, okay, tx
16:25
se6astian
we are still lacking a hardware debugging setup so a bit handicapped :)
16:26
se6astian
I hope to get that set up soon with the JTAG debugger
16:26
BAndiT1983
yep, have also not ordered 4232h yet
16:26
eppisai
So, besides have read alot on interupts and timers.. had implemented one.. it wasn't proper.. ISR was bit long.. so need to improve on it.. and will test it also..
16:26
BAndiT1983
but exception handling helps already a lot with crashes usually
16:26
BAndiT1983
*exception handling of pic32
16:26
se6astian
BAndiT1983: please continue with your report
16:27
Bertl
yeah, I think that and reset codes should help a lot
16:27
BAndiT1983
have resumed remote development again, previously my time was rather occupied
16:28
BAndiT1983
main focus is on UART communication through ASCII protocol, USB will follow afterwards, have reworked some parts and now CRC8 is verified, thanks to GSoC code from metaldent
16:28
se6astian
nice
16:28
BAndiT1983
exception handling is done in my version, but will be moved to main repo soon, also added a timer which polls every 5ms if data is there, then a flag is set and main loop processes it, just a quick test for me, before the processing will be adjusted
16:29
BAndiT1983
this also relates to such things as display brightness change, as we currently have some problems with central DB and possible memory bloat from there, i suspect c++11 features, but not verified yet
16:30
BAndiT1983
am thinking about moving brightness handling from function pointers and lambdas to something more simple, but no real plan is there yet, requires a bit of time
16:30
BAndiT1983
that's it from me
16:30
se6astian
many thanks
16:30
se6astian
quick updates from me:
16:31
se6astian
we had a tele videoconference today about the last remaining issues of the production run
16:31
se6astian
and concluded that Bertl can start the manual rework, tele wil give us a small refund in return
16:31
se6astian
I guess Bertl will talk about it in detail then
16:32
Bertl
.o( will I? )
16:32
se6astian
beside that I moved to house sit for the next 4 weeks not that far from our office in the factory hub, I couldnt take all the hardware with me (left the rockpi for example) but will get the remote hardware setup soonand hopefully also jtag hardware debugging then
16:33
se6astian
another company in the factory hub remembered our wish to capture high resolution images of populated boards
16:33
se6astian
and today I photographed around 15 panels they did
16:34
BAndiT1983
Bertl: are you a lot into VSauce lately with such questions? ;)
16:34
se6astian
this is reference/sample data for the automated optical inspection sotware: https://github.com/apertus-open-source-cinema/pcb-aoi
16:34
se6astian
currently in development
16:35
se6astian
so not that much to report from my side this week, but should get better again now that I am settled in
16:35
se6astian
thats it
16:35
se6astian
will Bertl now report? We might find out!
16:35
Bertl
BAndiT1983: always have been ...
16:35
Bertl
well, okay, so let's see what I can report there ...
16:36
Bertl
basically we decided that repairing the boards by reworking them ourself is the lesser evil here
16:37
Bertl
we already had discussions with tele whether a potential future issue is 'worth' fixing
16:37
Bertl
and our position here is that we do not want any Betas to come back in a few weeks with problems
16:38
Bertl
so all issues we identify now, we want to get fixed and fixing them ourseleves is the fastest and probably cheapest way to get that done
16:39
Bertl
also any repair from tele would end up in a lot of logistic and administrative work which we do not want to spend much time on
16:39
Bertl
that said, I hope that we can learn from those issues and improve the process in the future
16:40
Bertl
not much project related work was done from my side last week, I was mostly otherwise busy, except for GSoC
16:40
Bertl
that's it from my side for this week
16:40
se6astian
many thanks!
16:41
se6astian
anyone else who wants to report/discuss/share anything?
16:41
se6astian
anuejn: any news?
16:41
se6astian
manav you there?
16:41
metaldent
left the channel
16:42
se6astian
ok then, many thanks everyone! meeting concluded!
16:43
Bertl
thank you for the moderation!
16:44
se6astian
my pleasure
17:13
fredy
left the channel
17:52
fredy
joined the channel
18:40
anuejn
sorry for not being at the meeting
18:40
anuejn
here is my report:
18:45
anuejn
I continued to develop the cores for receiving and debugging hdmi with some sucess
18:46
anuejn
I can sucessfully do bit and word alignment to the hdmi signal
18:46
anuejn
and connect the ILA to it and watch the timing
18:48
anuejn
however I can not capture long traces since the ecp5 on which I do this does not have much bram and the board does not feature any dram or high speed interfaces to the computer
18:49
anuejn
after some initial glances, the hdmi signal I inspected (a rpi forced to dvi mode) looked exactly as I wolud expect
18:50
anuejn
... which is a bit unfortunate since I hoped to gain some kind of enlightenment what my current hdmi tx core is doing wrong
18:50
anuejn
however with this approach I still hope to be able to get our cores to work with the camlink and the recorder :)
18:51
anuejn
thats it from my side
18:58
Bertl
sounds great!
18:58
Bertl
any chance we can use that on the hdmi digitizer board?
19:37
anuejn
in princicple yes, but the io had to be adapted
19:38
anuejn
(and something something transcievers)
19:44
fredy
left the channel
19:56
Bertl
yeah, the something something we could probably solve by configuring them with the xilinx tools and copying the settings from there
19:57
fredy
joined the channel
19:59
anuejn
Yeah I once inspected the output from the wizzard but then decided to be overwhelmed ;)
20:02
Bertl
we might just read them out via the configuration interface
20:02
Bertl
anyway, would be nice to get that working at some point
22:30
vup
tpw_rules: can you pm me a ssh key you want to use to login to the server to access the remote beta?