#apertus IRC Channel Logs

hello Bertl :)

I am working on the post implementation , I have switched to Cyclone IV as it supports the post-fitting timing and generated the files functions and time constraints ( .vho & .sdo) and currently trying to shift the cells to the I/O pins of the FPGA

as quarus report to the

for the (Slow 1200mV 0C Model)

moving stuff to or into the I/O blocks is a good idea

I'am

I'm worry not to submit the proposal on time

so make sure to spend some quality time on that too

yes I was writing that question right now

I am interested in more than two projects :)

T887 is not high priority but probably quite interesting and the results might be quite relevant for Apertus

T885 and T721 are related to the SDI work already tackled by _florent_ and felix_ but they are still valid tasks

so if I applied for T885 or T721 their would be a competition ?

Okay

let me know if you have any questions and good luck with the exam!

Sure, Thank you alot :)

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

how i submit proposal?

it would be a good idea to send the proposal together with a link to your CV and challenge task to one of the mentors listed for the task you are applying for

how could i found that link?

here is an overview: https://wiki.apertus.org/index.php/GSoC_Overview

can i submit this link?

ok

Hi Bertl

I have pushed the code on GitHub

Usage of make command is written in README

yes please

Hello. BAndiT1983

you told me yesterday that use of pragma pack should be avoided. How about __attribute__((packed)) , I am asking as I found mixed opinions about this too on forums

to pack the structs of bitmap, when I write the structs without packing them the output file is corrupted

yes

not padded

yes

isn't a character usually unsigned char?

or maybe also uint8_t?

don't see any possible packing problems there, so please verify it again, as pragma pack of 2 is rather unusual there

as i see many problems whcih relate to OOP and naming of constants, also global definitions are bad, as they can be redefined elsewhere in the code, which can lead to serious problems in real applications

and don'T forget to have a lot more consistency, like header guards have to be in upper-case

I have updated the code, simplified the demosaicing process, and added avi writing

performance-wise there is also a big problem, as you have separate structure for pixel, which would kill performance as you push data there one by one

so should I store the data in a buffer array and write it all once ?

also one .cpp and .h for a class, not everything in one place

okey.. I will try to organize it all better.

you can get some ideas from here -> https://stackoverflow.com/questions/46656699/modeling-a-pipeline-in-c-with-replaceable-stages

if i'm not mistaken, then just one data object is required to hold image data and to be suitable for the whole pipeline

ehm, why?

isn't an image object enough?

demosaicing inside the image object?

please read about OOP principles and application structure, as i have given enough hints and not in the mood after work to do more code review, doing it enough through the day

off for now, will be back later

I had a basic doubt ,so can't we access the CMV registers through the MemoryAdapter.h present in the daemon as done in CMV12000Adapter.cpp? Is there something that I am missing here?

okay, even I thought so...but in the logs I have seen you mentioning that access is still not added, that's why I thought I was missing out something or probably interpreting something wrong. Anyways, now I get it

analog and digital gains can be controlled perfectly fine, tested it on real axiom beta through live feed

okay

probably

i hope with 100% code coverage

https://www.atlassian.com/continuous-delivery/software-testing/code-coverage

So is it currently evaluated automatically in the Cirrus CI builds of Axiom projects?

cirrus is building the firmware, rest is using circle ci

currently which tool is used for evaluating code coverage for the projects?

but there are built-in coverage tools in GCC and clang which would be used for CI builds

yes -> https://circleci.com/gh/apertus-open-source-cinema/axiom-control-daemon/40

yes, but the task is not that simple, tested it already locally

the process works, but it involves some advanced steps to generate reports of code coveragem based on the tests

by the way, was the MessageHandlerTests deleted (apparently) because of low code coverage?

but probably commented out, as the interface has changed and nobody had time to adjust tests

we changed the schema of data

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