#apertus IRC Channel Logs

Bertl_oO: hello :)

I have changed the code and raised the speed but not reaching the required speed could you advice me :)

Can you check my code , I sent the git link to your mail

aSobhy: I'm almost off to bed now ... will check the code in detail later but you definitely want to fix spacing (especially around operators) as well as indentation and code style (make sure that it is consistent)

Also can someone point me to resources in reference to "Add further camera/image sensor parameters, besides currently implemented image sensor plain register configuration, digital and analog gain, like white balance, color matrix for output etc."

read up on the registers and sensor parameters

hello everyone !

Any pointers on the first question ?

the scripts are located in here: https://github.com/apertus-open-source-cinema/axiom-beta-firmware/tree/master/software/scripts

well i have formatted the signal names and spacing , is the code still unclear ?

so let's see if you did a good job in not hurting my eyes ...

first, if possible, try to stay within 80 characters width

then, stick to a specific indentation width ... 8 or 4 characters typically, but do not switch

you start with 8 char indentations in line 5 and keep that in line 8

(note that 4 chars is probably a lot better as you have wide lines)

you want to stick to underscores, camelCase is for C++

line 10, you have 'serialBit :in' in line 11 you have 'bitslip: in' both should use a space on the left and right of the ':'

line 30, you have 'end component ;' which should be 'end component;'

line 73 has an additional space before the ')' which shouldn't be there

note: it's okay to use a single or double empty line to separate blocks, but there should be a good reason for 3+ empty lines

line 93, '(size=> 8)' is missing a space before the operator

of course those are only examples of bad formatting, basically every second line is badly formatted ...

there are a number of logic operations which most likely have a larger depth than one lut (check with the tools for details) so you might want to look into that and if you find such pathes in the list of critical ones, you want to consider pipelining those

off for now ... bbl

i will do that and update the code :) thanks alot

another question : is it accepted to have the parallel data (output) delayed one cycle than it should be ?

aSobhy: there is no problem with delays on the parallel side

so as long as you know how much the delay is, it will be fine

i hope it will pass , thanks Bertl :D

ok I would be grateful :)

(just saying, because it simplifies things a lot)

OK, I'll see for the difference :D

OK

good night