#apertus IRC Channel Logs

good day

morning folks!

i am here for the meeting

ok se6astian has invited me to start so, are we missing anybody? i'll wait a couple more minutes

tpw_rules: just go ahead, everybody can read up later ...

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

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

many thanks!

tpw_rules: also feel free to open a WIP PR so anuejn and I can take a first look

se6astian: I think anuejn should be able to provide remote access to a beta with sensor very soon

bluez: you are next

to gather some real world data on how it works and the utilization and stuff

which Bertl will help arrange :)

sounds good, many thanks

Hi

I've started working on the code to interface with the JTAGF primitive available on the MACHXO2

maybe first using the python scripts and then later with the kernel driver

many thanks, any questions or comments so far?

which did go unnoticed so far, but it is probably easy to fix

well, we have a shield designed for the remote control purpose

now for whatever reason, the schematic uses N/P pairs of mosfets

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

so no redesign oder rewiring required

thanks!

Hi!

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

what kind of crash do you see?

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.

could be, will port exception handlers to the main code, then i can see the address of cause

hmm, okay, tx

I hope to get that set up soon with the JTAG debugger

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

*exception handling of pic32

yeah, I think that and reset codes should help a lot

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

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

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

many thanks

we had a tele videoconference today about the last remaining issues of the production run

I guess Bertl will talk about it in detail then

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

and today I photographed around 15 panels they did

this is reference/sample data for the automated optical inspection sotware: https://github.com/apertus-open-source-cinema/pcb-aoi

so not that much to report from my side this week, but should get better again now that I am settled in

will Bertl now report? We might find out!

well, okay, so let's see what I can report there ...

we already had discussions with tele whether a potential future issue is 'worth' fixing

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

that said, I hope that we can learn from those issues and improve the process in the future

that's it from my side for this week

anyone else who wants to report/discuss/share anything?

manav you there?

ok then, many thanks everyone! meeting concluded!

my pleasure

here is my report:

I can sucessfully do bit and word alignment to the hdmi signal

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

... which is a bit unfortunate since I hoped to gain some kind of enlightenment what my current hdmi tx core is doing wrong

thats it from my side

any chance we can use that on the hdmi digitizer board?

(and something something transcievers)

yeah, the something something we could probably solve by configuring them with the xilinx tools and copying the settings from there

Yeah I once inspected the output from the wizzard but then decided to be overwhelmed ;)

anyway, would be nice to get that working at some point