Current Server Time: 17:35 (Central Europe)

#apertus IRC Channel Logs

2021/06/21

Timezone: UTC


01:45
Spirit532
left the channel
01:45
Spirit532
joined the channel
05:00
aombk3
joined the channel
05:09
fredy
left the channel
05:09
aombk2
left the channel
05:16
fredy
joined the channel
05:16
Bertl_oO
off to bed now ... have a good one everyone!
05:17
Bertl_oO
changed nick to: Bertl_zZ
08:07
metaldent
joined the channel
10:45
se6astian
good day
11:41
BAndiT1983_
left the channel
11:42
BAndiT1983
joined the channel
13:00
Bertl_zZ
changed nick to: Bertl
13:00
Bertl
morning folks!
17:00
se6astian
MEETING TIME! Who is here? Please message me know to get put into the report queue
17:00
BAndiT1983
is here
17:00
vup
is here
17:00
tpw_rules
i am here for the meeting
17:00
bluez
is here
17:01
Bertl
is here ...
17:01
vnksnkr
is here
17:01
tpw_rules
ok se6astian has invited me to start so, are we missing anybody? i'll wait a couple more minutes
17:01
eppisai
is here
17:02
Bertl
tpw_rules: just go ahead, everybody can read up later ...
17:03
tpw_rules
ok
17: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
17:04
tpw_rules
i can't simulate it because it mostly involves the linux device tree stuff
17: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
17:04
tpw_rules
that is it from me
17:05
se6astian
many thanks!
17:05
se6astian
is there another area you can progress on in parallel until the sensor hardware matter is settled?
17:05
vup
tpw_rules: also feel free to open a WIP PR so anuejn and I can take a first look
17: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
17:06
vup
se6astian: I think anuejn should be able to provide remote access to a beta with sensor very soon
17:06
se6astian
very good
17:07
se6astian
bluez: you are next
17:08
bluez
yup! so nothing much from me but i recently started working on accomodating the reconfigurable register project to the beta gateware
17:08
bluez
to gather some real world data on how it works and the utilization and stuff
17:09
bluez
i was just compiling atm and if everything looks good i would need to test it on a partial beta
17:09
bluez
which Bertl will help arrange :)
17:09
bluez
so that's it from me
17:10
se6astian
sounds good, many thanks
17:10
se6astian
vnksnkr: your turn!
17:10
vnksnkr
Hi
17:10
vnksnkr
quick updates from me..
17:11
vnksnkr
I've started working on the code to interface with the JTAGF primitive available on the MACHXO2
17:11
vnksnkr
Once that's complete I could start testing the gateware
17:12
vnksnkr
maybe first using the python scripts and then later with the kernel driver
17:12
vnksnkr
That's all from my side :)
17:13
se6astian
many thanks, any questions or comments so far?
17:13
Bertl
yes, vnksnkr also discovered a problem in our shield design
17:14
Bertl
which did go unnoticed so far, but it is probably easy to fix
17:14
se6astian
ah, interesting, please elaborate
17:14
Bertl
well, we have a shield designed for the remote control purpose
17:14
Bertl
which is basically a bunch of mosfets controlled via GPIOs
17:14
Bertl
now for whatever reason, the schematic uses N/P pairs of mosfets
17:15
Bertl
while we actually want to use N/N pairs there (i.e. no P channels)
17: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
17:15
Bertl
luckily even if we did, this can be easily fixed as the N/N pairs have the same pinout
17:16
Bertl
so no redesign oder rewiring required
17:16
se6astian
understood, great work vnksnkr!
17:16
vnksnkr
thanks!
17:16
se6astian
eppisai: your turn
17:17
eppisai
Hi!
17:19
Bertl
hello ;)
17: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
17:20
eppisai
But still crashing..
17:21
Bertl
what kind of crash do you see?
17: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..
17: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.
17:23
Bertl
so stack overflow or what?
17:23
BAndiT1983
could be, will port exception handlers to the main code, then i can see the address of cause
17:24
BAndiT1983
or the memory area is not set fully correctly up
17:24
Bertl
hmm, okay, tx
17:25
se6astian
we are still lacking a hardware debugging setup so a bit handicapped :)
17:26
se6astian
I hope to get that set up soon with the JTAG debugger
17:26
BAndiT1983
yep, have also not ordered 4232h yet
17: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..
17:26
BAndiT1983
but exception handling helps already a lot with crashes usually
17:26
BAndiT1983
*exception handling of pic32
17:26
se6astian
BAndiT1983: please continue with your report
17:27
Bertl
yeah, I think that and reset codes should help a lot
17:27
BAndiT1983
have resumed remote development again, previously my time was rather occupied
17: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
17:28
se6astian
nice
17: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
17: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
17: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
17:30
BAndiT1983
that's it from me
17:30
se6astian
many thanks
17:30
se6astian
quick updates from me:
17:31
se6astian
we had a tele videoconference today about the last remaining issues of the production run
17:31
se6astian
and concluded that Bertl can start the manual rework, tele wil give us a small refund in return
17:31
se6astian
I guess Bertl will talk about it in detail then
17:32
Bertl
.o( will I? )
17: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
17:33
se6astian
another company in the factory hub remembered our wish to capture high resolution images of populated boards
17:33
se6astian
and today I photographed around 15 panels they did
17:34
BAndiT1983
Bertl: are you a lot into VSauce lately with such questions? ;)
17:34
se6astian
this is reference/sample data for the automated optical inspection sotware: https://github.com/apertus-open-source-cinema/pcb-aoi
17:34
se6astian
currently in development
17:35
se6astian
so not that much to report from my side this week, but should get better again now that I am settled in
17:35
se6astian
thats it
17:35
se6astian
will Bertl now report? We might find out!
17:35
Bertl
BAndiT1983: always have been ...
17:35
Bertl
well, okay, so let's see what I can report there ...
17:36
Bertl
basically we decided that repairing the boards by reworking them ourself is the lesser evil here
17:37
Bertl
we already had discussions with tele whether a potential future issue is 'worth' fixing
17:37
Bertl
and our position here is that we do not want any Betas to come back in a few weeks with problems
17: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
17: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
17:39
Bertl
that said, I hope that we can learn from those issues and improve the process in the future
17:40
Bertl
not much project related work was done from my side last week, I was mostly otherwise busy, except for GSoC
17:40
Bertl
that's it from my side for this week
17:40
se6astian
many thanks!
17:41
se6astian
anyone else who wants to report/discuss/share anything?
17:41
se6astian
anuejn: any news?
17:41
se6astian
manav you there?
17:41
metaldent
left the channel
17:42
se6astian
ok then, many thanks everyone! meeting concluded!
17:43
Bertl
thank you for the moderation!
17:44
se6astian
my pleasure
18:13
fredy
left the channel
18:52
fredy
joined the channel
19:40
anuejn
sorry for not being at the meeting
19:40
anuejn
here is my report:
19:45
anuejn
I continued to develop the cores for receiving and debugging hdmi with some sucess
19:46
anuejn
I can sucessfully do bit and word alignment to the hdmi signal
19:46
anuejn
and connect the ILA to it and watch the timing
19: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
19:49
anuejn
after some initial glances, the hdmi signal I inspected (a rpi forced to dvi mode) looked exactly as I wolud expect
19: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
19:50
anuejn
however with this approach I still hope to be able to get our cores to work with the camlink and the recorder :)
19:51
anuejn
thats it from my side
19:58
Bertl
sounds great!
19:58
Bertl
any chance we can use that on the hdmi digitizer board?
20:37
anuejn
in princicple yes, but the io had to be adapted
20:38
anuejn
(and something something transcievers)
20:44
fredy
left the channel
20:56
Bertl
yeah, the something something we could probably solve by configuring them with the xilinx tools and copying the settings from there
20:57
fredy
joined the channel
20:59
anuejn
Yeah I once inspected the output from the wizzard but then decided to be overwhelmed ;)
21:02
Bertl
we might just read them out via the configuration interface
21:02
Bertl
anyway, would be nice to get that working at some point
23: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?