#apertus IRC Channel Logs

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

Do we want to send them via daemon ?

so there should be some way to 'transfer' all the values to the daemon

(ideally synchronized to the HDMI output)

a 'LUT file' format wasn't defined yet, so yes, it might look like that ... note that the current LUTs are 12->16 or 12->18 bit tables

the list you linked is a 3D lut, i.e. it describes a complete RGB -> XYZ mapping

so a LUT file format, if it was designed, would probably need to list 4096 x 4 values

we just want to fill those registers in a coordinated way via the daemon

there are huge number of different peripherials in the Beta which need to be 'adjusted' to make everything work as intended

we have virtual devices with memory mapped regions created by the FPGA bitstream

in general, there is a problem if more than one 'user' or 'client' adjusts those registers or changes values of those peripherials

in addition to just preventing two 'clients' from accessing those registers at the same time (and causing huge provlems, maybe even lockups)

e.g. change sensor specific registers only when the sensor is not acquiring a new frame

Ok ,Makes sense

Thanks :)

so there needs to be some kind of interface which can be used from bash, python, etc

for the LUT tables, I can imagine a number of interfaces which would work quite well

this is perfectly fine for unix commands and the C program to generate the various computed LUTs can be easily adjusted to produce this file format

for the synchronization part it would be benificial to store the 'new' LUTs somewhere in the daemon and have some 'activate config' command to actually transfer them to the respective registers

but he asked me to take over for him if he doesn't make it here

I'm sure you all have plenty to report this week ;)

(via PM, as usual)

he reported: 'I wrote the deserializer module for the machXO2 side' and 'Working on word alignment'

hi everyone!

not at the moment, but soon I will send you something more

anything else to report?

great! Fares please go ahead then

last week I have been working on Axi lite module to set and read lj92 parameters (height and width and huffman encoding values)

and I tested them in the FPGA as well.

actually both of them can be enabled or disabled via flags. lastly I started working on axi hp reader/writer, wrote them in migen and will continue working on them next week.

that would be all. thank you!

sounds good to me, thank you!

*you're

This week I spent major time on implementing the deserializer for machXO2 of usb plugin. As the machXO2 doesn't has a ISERDES, I went through all documentation available figured out how to use IDDRX4B primitive for deserializeing the data. Deserializer has been written and I am writing other modules and then I will test it on hardware.

Thats all from my side

Y_G: please go ahead

This week didn't have much coding done as most of work was reading about gamma configuration and LUT tables.

Work was also done to update the wiki about more sample DaemonCLI commands.

okay, thanks!

thus we conclude the meeting for today.

aSobhy, apurvanandan[m]: we'll hold a metting tomorrow evening to discuss the first evaluation and further tasks

so if there is anything to discuss while most of the students and mentors are here ... please go ahead

Nothing for now ,but will ping later for the LUT conf part .

sorry for the delay

i was working on the axiom micro recorder lately

also the preview is now configurable which is good for performance on low end devices which can use halfres debayering

so that the recorder can directly be used with the beta

Is the USB module attachable to the axiom micro? You mean the mp4 files will serve as data source from the axiom?'

https://github.com/axiom-micro/recorder

Okay, I will see if I can understand how it can be helpful

Hello everyone. Sorry, I was outside at that time and away from Internet that's why couldn't attend the meet

This will be done before in first half and then we will go for Fuse

Now

how many parameters at max do we need for general tasks? 3 or 4?

For now most work is done with 1/2 parameters.

1)"i2c set/get" through DaemonCLI requires 4 parameters

2) For gamma_config we need another data blob packet

Y_G, sounds fine, please go on, will try to assist in the next days, but am rather busy with my job at the moment

Data arrays and the blob

we have one for general settings, max 4 params, second one for data blobs

Oh ,if we are increasing to 4 parameters then only 2

as you'Ve discovered that we require 4 params to be able to check on i2c, then i would say that is max

not that many, at least for 4 params

packet header would be an additional parameter in the daemon request ?

you would have a header, which would tell the type of payload (enum) and maybe an attribute for payload size, but this has to be checked

just as example -> http://solace.com/wp-content/uploads/2016/05/solace-message_payload.png

so you just have to split current packet in 2 suitable parts and extend header with enum

off for today, see you

Will have a look and update you with the procedure tomorrow