#apertus IRC Channel Logs

off to bed now ... have a good one everyone!

morning folks!

who else is available?

me is here

ah, great, lets start in same order

Hi..!

I had started documenting the process of flashing firmware on PIC16s and PIC32 on remote.. it's mostly finished, I'll finish other modifications in the same that might be needed..

Because of the help from BAndiT and bertl, I was able to understand how I can use timer to time any block of code or get the fps on remote,

I was also working little bit on transition task, I had started writing down other transition animations of the remote, so far I have written push-up ;), push-left, and push-right.. but I was struggling a bit designing push-up and push-right.. I'll work on it..

Above is 42 second long video (with 5 second of me struggling a bit to navigate through menu using knob :), which I use to mostly do in visualizer) of current progress on AXIOM remote, that number on the right side is fps, buttons and everything is working.

https://github.com/eppisai/AXIOM-Remote/tree/transitiontask

have general trouble to play videos on google page, probably ad blocker

Above is code for the same.. ( transition animation, and core timer)

alright, many thanks

alright

i finished the work to receive and validate the beta sensor test pattern which proves the PHY works

vup, anuejn, and i also collaborated on various infrastructure improvements which should make future things nicer

next, and really final, step is the pixel remapper to order the camera images correctly

really nice work :)

yep, nice work!

tpw_rules: anything to add?

many thanks for the report

Hi

However I tested this only on the debug shield on the east side where the LEDs

There were a few issues with testing it on the remote

However still there seems to be an issue with I2C

Apart from that been cleaning up the code here and there

please report from time to time in gsoc channel, how the I2C investigation goes on, would like to know the progress, as EF version was not tested that often yet

anuejn: please go on

I'd say it wasn't tested at all before ;)

This week I colaborated a bit with tpw_rules and vup on the "various improvements" for naps

on the narui (new axiom recorder ui; my gsoc project) side I was able to draw the first debayered picture

I also fixed a rather nasty delta-evaluation related bug in narui and improved input latency in debug builds

currently I am hunting for a rather nasty vulkan api usage bug together with vup

thats it from my side for this week

very nice work!

vup: please continue

this includes some performance improvements when accessing fpga registers from the pydriver framework on the zynq

and some other usability and performance improvements in naps

many thanks

also not much to report here, am a bit obstructed by work, so just small fixes done for the 3d visualiser and started to look into ICSP, package delivery failed today and proper cables for JTAG have not arrived, so replacement has to be found, but in general next steps are: implementation of communication on the remote, with focus on ICSP

Bertl: please finish us

to my surprise, it seems that nobody has ever programmed the PIC16s there correctly before ...

well, there are some hardware changes between v0.9 and v0.13+ which make it impossible to program the PIC16s with the old tools

*the only EF board

so I would have expected somebody to 'discover' the problem before ;)

we can count how many people had access :D

2-3 at max, leaving myself out, as i like local development and often it's tedious to try things on remote systems, where i can't even fix things if something goes wrong

and currently we are getting some unexpected feedback from the KMs which hints at some I2C problems

we get key presses and rotary encoder movements reported from the remote even when there is nothing happening

I also cleaned up the demo (code example) for KM access and I2C communication so that it will work with both Remote versions

the I2C connection is on the PCB, so there is little to none cross talk or similar

we have a PICkit2 here (or a clone, I do not remember which) and it seems to work just fine with all the code I tested

the serial console is on the FT2232 and that works fine as well, we are using 1MBaud at the moment without any issues

and if that is true, we probably have to revisit the KM code base and see if there is a weird bug

but my money is still on the PIC32 side as the software was not really updated over years now and the compiler might have changed things a little

anyway, that's it from my side for this week

was just wondering, as you've added UART from pic16 to pic32, if the pin setup has changed, or if I2C is also there

alright, many thanks everyone! keeü up the good work!

the pins in the v0.13+ remote are capable for UART as well

was just asking, to cross-chekc, if there is something problematic in the layout, haven't looked at the 0.13+ schematics and pin layout there thoroughly yet

Sorry couldn't make it on time

me and Bertl, we connected the analyzer and identified, sorted 8 channel pins

the ports are constrained in my repo if anyone wants to reuse them

back at the main issue at hand

so for the next thing I'll do, I'll disable the live view and see, trigger a single frame capture

that's it for me :)