Current Server Time: 18:46 (Central Europe)

#apertus IRC Channel Logs

2019/06/03

Timezone: UTC


01:28
Bertl
off to bed now ... have a good one everyone!
01:28
Bertl
changed nick to: Bertl_zZ
01:56
illwieckz_
joined the channel
02:00
illwieckz
left the channel
03:04
illwieckz_
changed nick to: illwieckz
04:26
futarisIRCcloud
joined the channel
06:18
BAndiT1983|away
changed nick to: BAndiT1983
06:18
BAndiT1983
changed nick to: BAndiT1983|away
07:12
apurvanandan
left the channel
08:05
futarisIRCcloud
left the channel
08:13
se6astian|away
changed nick to: se6astian
08:17
LordVan
joined the channel
08:41
elkos
left the channel
08:41
comradekingu
left the channel
08:44
mithro
left the channel
08:46
mithro
joined the channel
08:47
WalterZimmermann
left the channel
08:47
Umori_
left the channel
08:52
WalterZimmermann
joined the channel
08:52
Umori_
joined the channel
08:53
elkos
joined the channel
08:53
comradekingu
joined the channel
10:16
se6astian
changed nick to: se6astian|away
11:17
apurvanandan[m]
Good afternoon, Can anybody see there why Remote Beta e is refusing ssh connection?
11:24
Bertl_zZ
changed nick to: Bertl
11:24
Bertl
morning folks!
11:25
Bertl
apurvanandan[m]: will check shortly
11:25
apurvanandan[m]
Thanks
11:26
aSobhy
morning Bertl :)
11:26
aSobhy
and me also
11:29
Bertl
please try again, should work now :)
11:29
apurvanandan[m]
working :)
11:30
aSobhy
yes it works :)
11:31
Bertl
great! :)
11:42
Bertl
apurvanandan[m], aSobhy: how was the weekend?
11:45
apurvanandan[m]
I will say it was good and productive, I went through ftdi documentation for preparing presentation, was able to get urJTAG work ie read idcode with my hardware. Currently I and aSobhy are trying to program the remote beta's machXO2.
11:46
Bertl
sounds great!
11:55
aSobhy
yes as apurvanandan[m] said we are working on the first programe to write on the beta now
12:17
LordVan
left the channel
12:24
apurvanandan[m]
Is there a meeting today?
12:28
Bertl
yep, same time as last week
12:32
se6astian|away
changed nick to: se6astian
12:37
LordVan
joined the channel
12:39
apurvanandan[m]
ok
13:25
illwieckz
left the channel
13:36
RexOrCine|away
changed nick to: RexOrCine
14:05
se6astian
changed nick to: se6astian|away
14:22
se6astian|away
changed nick to: se6astian
14:22
se6astian
left the channel
14:22
se6astian|away
joined the channel
14:22
se6astian|away
changed nick to: se6astian
14:22
se6astian
left the channel
14:22
se6astian|away
joined the channel
14:23
se6astian|away
changed nick to: se6astian
14:23
se6astian
left the channel
14:23
se6astian|away
joined the channel
14:23
se6astian|away
changed nick to: se6astian
14:23
se6astian
left the channel
14:23
se6astian|away
joined the channel
14:24
se6astian|away
changed nick to: se6astian
14:24
se6astian
left the channel
14:24
se6astian|away
joined the channel
14:25
se6astian|away
changed nick to: se6astian
14:25
se6astian
left the channel
14:25
se6astian|away
joined the channel
14:25
se6astian|away
changed nick to: se6astian
14:25
se6astian
left the channel
14:25
se6astian
joined the channel
14:26
se6astian
changed nick to: se6astian|away
14:26
se6astian|away
changed nick to: se6astian
14:26
se6astian
left the channel
14:26
se6astian|away
joined the channel
14:26
se6astian|away
changed nick to: se6astian
14:26
se6astian
left the channel
14:26
se6astian|away
joined the channel
14:28
se6astian|away
changed nick to: se6astian
14:28
se6astian
left the channel
14:28
aSobhy
Bertl: how can I share a the terminal screen with apurvanandan[m]
14:28
aSobhy
we tried "screen -x share" but didn't work
14:28
se6astian
joined the channel
14:28
se6astian
changed nick to: se6astian|away
14:29
aSobhy
does the one who sharing suppose to do a different action( command)
14:29
se6astian|away
changed nick to: se6astian
14:29
se6astian
left the channel
14:29
se6astian
joined the channel
14:30
Bertl
aSobhy: the shared screen is not started there, one of you needs to use 'screen -S share' to create it (but only one)
14:30
Bertl
you can see if there is one already with 'screen -ls'
14:30
aSobhy
apurvanandan[m]:
14:31
aSobhy
ok thanks Bertl :)
14:32
Bertl
you're welcome!
14:59
BAndiT1983|away
changed nick to: BAndiT1983
14:59
BAndiT1983
changed nick to: BAndiT1983|away
15:47
apurvanandan[m]
Bertl we are not able to figure out how to use pic_gpio.py, it giving Traceback OS Error 6. Please help us
16:21
Bertl
what do you want to use it for?
16:26
Bertl
it seems it wasn't used for some while and the version assumes a 0.23 power board
16:27
Bertl
I made a backup and adjusted the I2C addresses accordingly, so should work now
16:35
dev_
joined the channel
16:37
Nira|away
changed nick to: Nira
16:38
se6astian
hi nira
16:39
Nira
hi! Good afternoon
16:43
se6astian
did you get my email?
16:49
Nira
wow! I didn't see it! I send you the reply now
16:55
se6astian
thanks
16:56
supragyaraj
joined the channel
16:56
supragyaraj
left the channel
16:58
supraraj
joined the channel
17:00
supraraj
left the channel
17:00
se6astian
meeting time!
17:00
se6astian
welcome everyone
17:00
se6astian
as you have probably read in today meeting reminder email the meeting is now every week, same day, same time, same place
17:01
se6astian
I will not send out reminder emails anymore
17:01
se6astian
just come here every week :)
17:01
Bertl
excellent!
17:02
se6astian
please pm me now if you want to report/share, like usual!
17:02
se6astian
regarding meeting minutes, unfortuantely I didnt have the time to write summaries in the wiki, but since the IRC logs can be read easily I think its fine to just look up any history there
17:04
se6astian
dev_: please go ahead
17:04
Fares
joined the channel
17:04
dev_
Hello Everyone !!
17:05
dev_
Last week , I was able to test simple RAW12 frames for simple playback using brute force. I was also trying the same for MLV file but I am facing some problems regrading this, which i would like to discuss with task mentor.
17:05
dev_
https://github.com/kakashi-Of-Saringan/opencine/commit/65ab5a55fce45efe423a61313b157c6d36da61b1 This is my last commit in my forked repo for mlv file.
17:05
dev_
For this week, I would like to start optimization in playback approach and bringing sliders into processing test so it can control playback.
17:05
dev_
Thanks
17:06
Bertl
BAndiT1983 is currently on the road, but I'm sure he will contact you once he is back
17:06
dev_
Okay , Bertl !!
17:07
se6astian
thanks dev_, anything else?
17:07
dev_
No se6astian , that's it
17:07
dev_
thank you
17:08
se6astian
great, apurvanandan[m] you are next
17:08
suprarj
joined the channel
17:10
suprarj
left the channel
17:11
apurvanandan[m]
Hi everybody, This week most of my time was spent on understanding ft60xx, going through as much documentation as possible. I am succesfully able to use urJtag to detect my jtag chain using cypress fx2 firmware. Also was learning to use remote beta hardware.
17:13
Bertl
everything as you expected regarding remote hardware?
17:14
apurvanandan[m]
We were able to do the things you showed us, but we were stuck on trying to use gpio pins of RFs.
17:15
Bertl
see my comment earlier here on the channel :)
17:15
apurvanandan[m]
oh ok, will try just now!
17:18
apurvanandan[m]
Yes, it is working! Thanks ^_^
17:19
Bertl
you're welcome!
17:19
se6astian
thanks, apurvanandan[m]
17:19
apurvanandan[m]
Thanks :)
17:19
se6astian
the DHL package to you was labeled today and will be picked up tomorrow
17:19
Bertl
apurvanandan[m]: I presume this was part of the first MachXO2 test
17:19
se6astian
its DHL express so it should arrive quite quickly
17:20
se6astian
probably within this week
17:20
apurvanandan[m]
Bertl: Yes it was
17:20
se6astian
apurvanandan[m]: anything else to add, otherwise Fares is next
17:20
apurvanandan[m]
se6astian: Can I get the tracking details of the package when you have it?
17:21
apurvanandan[m]
se6astian: No, I am done, Thank you.
17:21
sraj
joined the channel
17:22
Fares
Hi everyone
17:22
sraj
Hi fares
17:22
sraj
Hi dev_
17:22
Fares
In then last week I completed a basic lj92 pipeline with the basic functionality and committed it to the repo, https://github.com/FaresMehanna/JPEG-1992-lossless-encoder-core
17:23
se6astian
apurvanandan[m]: you should already have received an email notification from DHL
17:23
sraj
dev_ can we have a chat on call?
17:23
Fares
since then I was working on a module to pack a variable length data to a fixed length one and I'm still working on that part
17:24
dev_
yes sraj
17:24
sraj
Cool
17:24
Bertl
Fares: history still shows initial commit 5 days ago?
17:24
Fares
I will commit the new module with related stuff soon
17:25
Bertl
okay
17:25
sraj
left the channel
17:25
Fares
yes the packing module took too much time
17:25
Fares
after finishing a first version I refactor it several times
17:25
Bertl
no problem, just curious
17:25
Fares
and still looking for a way to optimize a left shift operation with a big register
17:26
Fares
okay, that would be all :) thank you!
17:26
apurvanandan[m]
se6astian: No I didn't
17:27
se6astian
thanks fares
17:27
se6astian
apurvanandan[m]: to your @ac.in address
17:27
se6astian
maybe it also sends a notification not when the shipment has been created but when its been picked up
17:27
se6astian
we will know tomorrow
17:28
apurvanandan[m]
Yeah fine
17:28
se6astian
Nira: please go ahead
17:28
Nira
hi, on this week I have been learning about debouncing test, so learning about interrupt routines
17:28
Nira
also checking PIC16 codes and understanding everyhting, as how its memory work and getting familiar with its registers
17:29
Nira
and basically that's it, getting deeper on it and making sure I know how to do everything
17:29
Nira
and on the next week I will keep trying code, checking if I can make everything work as I want, and going on with the interrupts for debouncing
17:33
Bertl
sounds good, you should also get your hardware soon
17:33
se6astian
will be picked up tomorrow by DHL, yes
17:33
Bertl
till then, let me know if you want to test something on the Remote, I'll can probably run it for you
17:33
se6astian
thanks for the report Nira, anything else to add?
17:34
Nira
that's all, thank you!
17:34
se6astian
great, aSobhy your turn
17:34
aSobhy
Hi all
17:34
aSobhy
my last week was about learning how to access the Beta remotly as Bertl showed us
17:34
aSobhy
cuerntly I'm teaming with apurvanandan[m] to do our first test on the beta testing that our code has been successfully writen on the MachX02
17:35
aSobhy
and also I finished my exams ^_^ so I'll work more :)
17:36
Bertl
excellent! feel free to report your success with the remote Beta on the channel
17:38
se6astian
anything else aSobhy?
17:38
aSobhy
No, Thanks se6astian :)
17:38
se6astian
great, thanks everyone
17:38
se6astian
Bertl: your turn
17:39
Bertl
it seems Y_G is unfortunately missing
17:39
Bertl
BAndiT1983 would very much like to hear from him as well, so when you read up on the logs, please give a brief report
17:40
Bertl
after finishing the hardware for our students last week, I spent most of this week on Axiom Beta rework and testing
17:40
Bertl
(and mentoring GSoC students of course :)
17:41
Bertl
we also did a remote Beta tour as well as MachXO2 programming howto
17:41
Bertl
(might be interesting to collect the data in the Wiki btw :)
17:42
se6astian
please do!
17:42
Bertl
(hint for our students :)
17:42
Bertl
I've also revisited the Axiom Remote code and fixed some minor stability issues there
17:43
se6astian
great, did you push it to gh already?
17:43
Bertl
and will probably write some test code for the new mems oscillator and maybe preliminary USB support?
17:44
Bertl
(all changes were uploaded to my server as usual, no GH commits as I didn't modify the codebase there (yet))
17:44
Bertl
but probably BAndiT1983 has incorporated them ... not sure
17:45
Bertl
(will check and let you know)
17:45
se6astian
well it would be good to have it on GH in the end
17:45
se6astian
anything else?
17:45
Bertl
is the demo.c and lcd.c on github already?
17:45
Bertl
that's it from my side for last week
17:46
apurvanandan[m]
Bertl: We have already made a small wiki/documentation from the chats we had.
17:46
se6astian
https://github.com/apertus-open-source-cinema/AXIOM-Remote/tree/master/AXIOM_Remote_Prototype_V01.X/reference
17:46
Bertl
excellent!
17:46
se6astian
thanks Bertl
17:46
Bertl
tx, will update it there then
17:46
se6astian
quick updates from me
17:47
se6astian
https://www.mak.at/en opening was last tuesday, exhibition is running now with AXIOM Beta as exhibit
17:47
se6astian
also saw fairphone there
17:47
se6astian
makerbot
17:47
se6astian
couple of other things
17:48
se6astian
on friday Mathijs van Oosterhoudt was in town for a project presentation of his project: http://focalcamera.com/
17:48
se6astian
he basically builds a DIY open source analog camera toolkit
17:48
se6astian
with several building blocks
17:48
se6astian
I invited him to visit the AXIOM office today but he unfortunately wasnt able to fit it into his schedule
17:49
se6astian
there might be an area for future collaboration with designing/making open hardware lenses
17:50
se6astian
with focus rather on artistic lens effects, not super sharp high end glass which will not easily be possible with DIY
17:50
se6astian
you have probably seen the brand new AXIOM Remote rendering here: https://wiki.apertus.org/index.php/File:AXIOM-Remote-Concept-Rendering-v4--4.jpg
17:50
se6astian
thats it from my side
17:51
se6astian
anyone else have anything to add/share/discuss? now is the time
17:51
se6astian
otherwise same time, same place next week
17:51
Bertl
apurvanandan[m]: you plan a short presentation on the FT60x chips tomorrow, if I'm not mistaken?
17:52
apurvanandan[m]
Yes I do
17:52
Bertl
so this might be interesting for other folks here as well
17:52
Bertl
(just as a note)
17:53
apurvanandan[m]
Don't call too much audience please ^^'
17:53
se6astian
great, when is it planned to happen?
17:54
Bertl
probably 19:00 CEST (17:00 UTC)
17:54
Bertl
apurvanandan[m]: but if you have other preferences, that's fine as well
17:55
apurvanandan[m]
No its ok.
17:56
se6astian
great, noted
17:57
vup
Fares: if you only ever need to shift at most once per clock cycle the SRL16/32 are really efficient for shifting
18:00
Fares
vup: I read a little about SRL16/32 and I don't really know if the inference happens automatically or not, so mainly what I try to do is to ((old_data << count_new_data) | new_data)
18:01
Fares
old_data is the buffer, at the first versions it was 256 bit and this oprtation alone take a lot of LUTs, around 1.5k
18:01
dev_
left the channel
18:02
Bertl
depends on how you code it
18:02
Fares
so I add converter to make "((old_data << count_new_data) | new_data)" work with smaller registers, it now took around 500 LUTs and I still looking in how to make it better, the buffer now is 128bits
18:02
Bertl
the SLR16/32 blocks allow at most access to one extra bit for the entire shift length
18:02
Bertl
so you get bit 0, 16 and one of your choice
18:03
illwieckz
joined the channel
18:03
Fares
No I need to access 32bits of the buffer in the same cycle
18:03
Bertl
it's perfect for delaying stuff, but not very suitable for shifting 128bit by one bit for example
18:03
Fares
the reading input loop and output loop are asynchronous to each other
18:04
Bertl
that very much sounds like a clock domain crossing :)
18:06
Fares
can you explain more? I mean not totally asyn but both can happen at the same cycle with shared clk and shred buffer
18:07
Bertl
so they are synchronous then, just gated
18:07
vup
is count_new_data constant?
18:09
Fares
yes sorry I mean concurrently happening, so I would need to access any part of the buffer in every cycle
18:09
Fares
vup: no, count_new_data was up tp 128 in value but after adding the converter it is up to 36 in value
18:10
vup
ok, i think thats the main problem
18:11
Fares
let me explain, the main pipeline output data is from 4 to 124bits of data, usually most of them less than 36bits
18:12
Fares
this data then in inserted in fifo, and then a module after the fifo pack those into 32/64 bits output
18:13
Fares
it is crucial to handle new input / new output every cycle
18:15
Fares
as optimization, I wrote a module to read (4-124)bits of data from a first fifo module and write them to a second fifo module with only(4-36)bits, that make it more efficient to handle in the last module (the shift left operation would work on smaller registers)
18:16
Fares
what more can be done in the problem of packing variable length data?
18:18
vup
yeah, you basically need a barrel shifter if you do it this way, which just needs a lot of lut's
18:18
vup
any way to constrain the 36 bits even further
18:18
vup
?
18:18
niemand
joined the channel
18:18
niemand
left the channel
18:18
niemand
joined the channel
18:19
Fares
constraint it how?
18:20
Fares
to less than 36bits?
18:20
vup
reduce it further
18:20
vup
yes
18:20
Fares
it would be fine, but it will affect the throughput
18:20
Fares
every cycle 4 pixels are inserted, 4*12=48bits
18:21
Fares
with compression and usb module, they expect 32bits of data every cycle
18:21
Y_G
joined the channel
18:21
Y_G
Hi All ,Really Sorry couldn't make it to the meeting ,Was on road
18:22
Fares
constraining the 36 to smaller is easy but will effect the throughput
18:23
Fares_
joined the channel
18:23
vup
ok i see
18:24
Fares
left the channel
18:24
Nira
changed nick to: Nira|away
18:24
Fares
joined the channel
18:25
Y_G
last week I worked on sysfsAdapter and the EnvironmentModule (Module to monitor temperature and voltages) ,Currently the base functionality has been completed however ,this module is limited to temperatures and voltages defined in zynq_info.sh .We might want this module to be extended to cover all the temp/voltage sensors . However I don't have much information about these sensors .
18:25
Y_G
Hence as of now I am planning to work on the I2CAdapter this week
18:26
Y_G
Also Modules and Adapters were separated into different folders for cleaner structure.
18:26
Y_G
Code -> https://github.com/kiquance21/axiom-control-daemon
18:28
Fares
left the channel
18:31
Nira|away
changed nick to: Nira
18:32
vup
Fares_: the pipeline runs at about 100MHz, right
18:32
vup
?
18:32
Fares_
Correct
18:32
vup
then maybe running the packer at double the speed is possible
18:33
vup
and only allowing a maximum shift of 18 bits per cycle
18:33
vup
which should about half the amount of luts
18:33
Bertl
way less
18:34
vup
why?
18:34
Bertl
a barrell shifter is quadratic
18:34
vup
quadratic in the number of bits?
18:35
Bertl
if you have 4 bits, you basically need 4x4 cross points for all variants
18:35
Bertl
if you have 8 bits, you need 8x8 cross points, because you have 4 more shift variants _and_ 4 more bits
18:35
vup
yeah, but here the buffer lenght is constant / has a fixed lower limit
18:36
vup
s/lenght/length/
18:36
Bertl
okay, so it's a reduced barrel shifter
18:37
Bertl
but even there the number of luts should be less than 'only' half
18:37
Bertl
because of the size of the LUTs
18:38
Bertl
6 input luts can at most select 4, but typically will only select 3 bits
18:39
vup
yeah, possible, but a bit of that is offset by the fact that more controll logic is needed
18:39
Bertl
of course
18:40
vup
another funny idea could be to use the DSP48 and a multiply + add operation
18:41
Fares
joined the channel
18:41
Fares_
I searched into that but I think DSP48 work with smaller number of bits
18:42
Fares_
Is it okay to design parts with 2x the 100mhz clk?
18:42
Bertl
sure
18:43
Bertl
you can even go up to 400MHz if you can handle it
18:43
Bertl
it's fine for the fabric but it might become tricky with timing
18:43
se6astian
changed nick to: se6astian|away
18:44
Fares_
Aha okay
18:45
Fares
left the channel
18:47
Fares_
There is another idea of reversing the order of the bits, but I donât think it will help much, I will look into it and checking what parts can benefit from increased MHZ
18:48
Bertl
keep in mind that you will generate clock domain crossing in this case as well, but as the clocks are related, the tools will do the right thing
18:48
Bertl
but you might need to set multicycle pathes or similar
18:48
vup
i think the DSP48 should be able to do up to 18 bit shifts
18:49
Bertl
it should be able to do more
18:53
vup
hmm yes maybe up to 25 bits
18:54
vup
but with only a 25x18 multiplier i don't see how you would do bigger shifts
18:54
vup
(with only one DSP48)
18:54
Bertl
depends on what part you are interested in
18:55
Bertl
if you want to get the full word as output
18:55
Bertl
then you are obviously limited by the 48 bit P reg
18:55
vup
yeah sure
18:56
Bertl
which means you can for example shift 24 bit by up to 24 bit
18:56
vup
yes, but not in one operation
18:56
Bertl
why not?
18:56
vup
because the multiplier is only 25x18
18:57
Bertl
there is a shift by 17 somewhere
18:57
vup
oh ok
18:57
BAndiT1983|away
changed nick to: BAndiT1983
18:58
vup
ok totally missed that
18:58
Bertl
but not sure it can be used in this case
18:59
vup
why not, it would just need a bit of control logic, no?
18:59
vup
(control logic to enable is when the shift amount is >=17 and disable when lower)
19:00
Bertl
yes, when it is in the correct path for the multiplier
19:00
Bertl
(have to verify that)
19:02
vup
ok looked it up, it is unfortunately only in the adder / substractor / logic part
19:02
vup
/path
19:03
aSobhy
Bertl: how can we access the GPIO of the MachXO2 from the PIC ?
19:04
aSobhy
as the gpio.py is for the ZYNQ
19:04
aSobhy
and pic_gpio.y if for the PIC
19:06
Fares
joined the channel
19:12
Fares_
left the channel
19:14
se6astian|away
changed nick to: se6astian
19:15
Fares
I'm sorry, but would it make big difference to move number of bits from 36 to 18? ((buffer << count) | new_data), buffer=128bits, count=6bits, new_data=36bits. the new one should be buffer=128bits/or less, count=5bits, new_data=18bits
19:16
Fares
change number of bits..*
19:18
Bertl
aSobhy: depends on the GPIOs
19:18
Bertl
those connected to the PIC can be inspected with the pic_gpio.py
19:18
Bertl
those connected to the Zynq can be checked with a Zynq bitstream
19:19
Bertl
those connected to e.g. the shields or plugin slots need a debug shield/plugin to check
19:20
Y_|G
joined the channel
19:20
vup
Fares: i think it should atleast about half the number of luts
19:22
Y_G
left the channel
19:23
Fares
so that should be the same effect if count=5bits and new_data=31bits correct?
19:26
vup
why should count=5bits and new_data=31bits half the number of luts?
19:27
Fares
number of LUTs is dependent on the left shift or the OR-ing?
19:36
Fares
left the channel
19:42
Davelister
joined the channel
19:42
Davelister
good evening
19:47
Y_|G
left the channel
19:49
Fares_
joined the channel
19:52
Fares_
left the channel
20:05
BAndiT1983
changed nick to: BAndiT1983|away
20:10
BAndiT1983|away
changed nick to: BAndiT1983
20:19
niemand
left the channel
20:26
vup
Fares: the shift
20:26
vup
the or should only take nbits / 2 luts
20:32
dev_
joined the channel
20:33
dev_
Hello BAndiT1983 , Are u there ?
20:33
dev_
https://github.com/kakashi-Of-Saringan/opencine/commit/65ab5a55fce45efe423a61313b157c6d36da61b1
20:33
BAndiT1983
hi dev_
20:34
dev_
Actually I am having problem in loading frames of MLV
20:34
BAndiT1983
yes, i see, as you are trying to break the loader right away
20:35
BAndiT1983
why do you init parameters there, as the loader is the one responsible for getting values, especially bayer pattern
20:36
dev_
umm , I thought it won't matter , as i am passing reference of image object
20:36
BAndiT1983
describe your approach please
20:37
BAndiT1983
i want to understand general way you want to take, as it's evening here and after a day of work i don't have passion to compile code right now
20:37
apurvanandan[m]
Bertl: we are planing to use PIC's gpio for testing the our code on MachXO2, can you please tell which pins are unused ( will not interfere with normal functioning).
20:38
apurvanandan[m]
We have gone through schematics and using PCIE_SCL and PCIE_SDA seems fine to us
20:38
BAndiT1983
dev_, i also miss a bit a loop which gets all frames from MLV
20:40
dev_
yes : I am taking a simple vector to read frames from MLV, Then for each frame i am doing initParameters to initialize paramters like aspect ratio etc and further processing is done by downscaler which gives us channel(RGB) data into a big chunk of memory each time.
20:41
BAndiT1983
please point me to the loop which loads all frames
20:42
dev_
In Presenter , I am trying to retrive that data using a function GetData by using offset.
20:42
apurvanandan[m]
BAndiT1983: Thanks for help, Now my programmer is able to detect jtag chain by using urjtag. I used the c51 fx2 firmware (had to compile on Windows due to deprecated packages :p ) on the platform cable and it worked under UsbBlaster.
20:43
dev_
please point me to the loop which loads all frame : Every time a vidf block is encountered , the _sourceData will read frame using pushback (line 111 in MLVLoader.cpp)
20:44
BAndiT1983
apurvanandan[m], glad to hear, that it helped, will also try to rework my XUP to general jtag for pic32
20:46
apurvanandan[m]
Now it is getting the correct idcode of every member in the chain but they are being shown as unkown part, probably will have to use the BSDLs.
20:46
BAndiT1983
dev_, and where does the code fail?
20:47
Bertl
apurvanandan[m]: you also have PB22B
20:47
BAndiT1983
apurvanandan[m], that's exactly what is required
20:47
apurvanandan[m]
Yeah I noticed that Bertl
20:47
Bertl
SDO_W, SCK_W and #SS_W
20:48
dev_
where does the code fail? : I think, when i am trying to retrive channel data again in processing test , it is not getting the correct data
20:48
Bertl
apurvanandan[m]: and of course SDO_E, SCK_E and #SS_E on the East side
20:48
dev_
and that's why blank frames are appearing
20:49
apurvanandan[m]
Bertl: Ok great, thanks
20:49
Bertl
apurvanandan[m]: BANK13_SE_0 and JX1_SE_0 are even shared between all three (MachXO2, PIC and Zynq)
20:50
dev_
, i see, as you are trying to break the loader right away : I tried to load one frame even using initparameter function : but that worked
20:50
dev_
I think the problem is in presenter
20:51
BAndiT1983
which problem do you suspect?
20:53
BAndiT1983
and another question, have you verified stored data through memory viewer?
20:53
BAndiT1983
example for qtcreator -> https://i.stack.imgur.com/9md8n.png
20:54
dev_
I want to be sure on this note : When we allocate memory for channel using (image.SetChannel(alloctor->allocate(dataSize)), this chunk of memory will contain the channel data
20:54
dev_
right ??
20:54
BAndiT1983
please write methods starting with upper-case -> Allocate
20:54
dev_
so why when i retrive it back , it is not giving me correct data :(
20:54
Bertl
Davelister: hey, how's it going?
20:54
BAndiT1983
yes, it should allocate fixed size for the chunk
20:54
dev_
ohh sory
20:56
BAndiT1983
normally the loader should predefine the size of each channel or image data, as it's the one who knows it
20:56
BAndiT1983
so you could init allocator with general amount of memory to be allocated and chunk size
20:56
dev_
yes, and can we also retrieve it back using offset which we storing in _pointerMap(in static allocator.h , line 22 )
20:57
BAndiT1983
e.g. new StaticAllocator(500 * 1024 * 1024, 32768)
20:58
BAndiT1983
first note, you are not storing pointers there, as i see size_t
20:59
BAndiT1983
second note, why is it exposed in public area? all the attributes of the class which start with _ are private, as we should use getters/setters to prevent failures and malicious usage
21:00
BAndiT1983
third note, ensure that it returns proper offset
21:01
BAndiT1983
you could also rework or add another getter, to get the chunk by index, rather than by offset, if it would help
21:02
dev_
Yes, please see GetData function (line 33 staticallocator.cpp)
21:02
dev_
I am trying to get pointer using offset
21:02
apurvanandan[m]
Hey Bertl , we have MachXO2 LCMXO2-1200HC-TQFP100-4 fpga in RFW no?
21:02
dev_
Offset is : from where channel data is stored
21:03
dev_
third note, ensure that it returns proper offset : Yes , I tried to print it , they are correct
21:04
BAndiT1983
are you sure that setting it two times isn't breaking it?
21:04
BAndiT1983
first time you allocate the memory, but second time you assign data from frame processor
21:07
BAndiT1983
can't test it currently, as my local version has some modifications already for MLV
21:10
BAndiT1983
dev_, as the code is rather old for OCImage etc., there are many artefacts which should be removed, e.g. channel related setters
21:10
BAndiT1983
try to work only with one channel first and remove all unnecessary stuff from red setter or which colour you like
21:11
BAndiT1983
can try to assist tomorrow, as today it's late in the evening and i will leave IRC soon
21:11
dev_
No problem, I am also trying it ,
21:11
Fares
joined the channel
21:12
Fares
left the channel
21:13
BAndiT1983
start with bare minimum
21:13
dev_
bare minimum ??
21:14
BAndiT1983
yes, remove everything memory related in OCImage first, so it doesn't allocate it's own memory
21:14
BAndiT1983
this is coming from long ago and was never reworked
21:14
BAndiT1983
start with setredchannel
21:14
BAndiT1983
*SetRedChannel()
21:15
elkos
left the channel
21:15
comradekingu
left the channel
21:18
dev_
BAndiT1983, are u there ?
21:18
BAndiT1983
yes
21:21
elkos
joined the channel
21:21
dev_
start with setredchannel : okay , i will also try this
21:22
BAndiT1983
remove memmove there and also new[]
21:23
BAndiT1983
just store the pointer to the data in allocator, or offset, but then you have to rework some other parts also, so pointer is easier for now
21:23
BAndiT1983
so, off for today, please continue to write here, then i will read logs tomorrow or just write an email
21:24
Davelister
hello Bertl, I am going okay; what about you?
21:24
BAndiT1983
will try to be tomorrow longer available, had other stuff to accomplish today
21:24
BAndiT1983
see you, good night
21:24
BAndiT1983
changed nick to: BAndiT1983|away
21:24
Davelister
(sorry I could not been here last week, I got one of these crazy ones at work)
21:24
dev_
No problem , BAndiT1983, Good night
21:25
Bertl
Davelister: happens ...
21:25
dev_
left the channel
21:28
Davelister
Bertl: anyway. If I remember well, you told me there is a blank page for the communication from the interface board to the main board isn't it?
21:29
Bertl
we have a bunch of I2C/SPI/JTAG connections from the main board
21:30
Bertl
but the LVDS channels (36) are general purpose
21:30
Bertl
(only the clock capables are special there)
21:30
Davelister
yes. I was speaking of these latter :-)
21:32
Davelister
Because I was wondering what kind of FPGA you wanted to put here. I remember somebody during our chat introduced an Artix-7, but if it just a basic packet handling from the sensor, and then a direct transmission of the pixel values, I suppose I can have a look at Lattice products
21:32
Davelister
(the FPGA would the one on the interface board)
21:33
Bertl
I think the Artix-7 might be a good choice, mainly because of the similar architecture and the high data rates over LVDS
21:33
Davelister
yes
21:33
Bertl
i.e. with a Lattice we probably can't do 1.2GBit over the 36 LVDS channels :)
21:33
Davelister
plus the fact Vivado is free for everyone
21:33
Bertl
(over each of them that is :)
21:34
Davelister
damn, commercials from Lattice sold me dream (again)
21:35
Davelister
okay, so I'll have a look to the Artix-7 then
21:35
Bertl
I'm not against a Lattice or even Microsemi if you find something suitable
21:35
Davelister
ok, I take note
21:35
Bertl
we have Lattice FPGAs already on the Main Board
21:36
Bertl
and Diamond is kind-of free as well, similar to Vivado
21:36
Bertl
(again, check which parts do not require a special license)
21:36
Davelister
(of course)
21:38
Davelister
so I'll try to propose a draft for the end of this week
21:39
Bertl
sounds great!
21:40
Davelister
I'll keep you in touch ;-)
21:41
Bertl
perfect! tx!
21:53
aSobhy
Bertl how can I generate SVF file from lattice ?
21:55
aSobhy
and for the MachXO2 are we use LCMXO2-1200HC-TQFP100-4 that apurvanandan[m] mentioned ?
21:59
Nira
changed nick to: Nira|away
22:02
Bertl
aSobhy: check out the build scripts for MachXO2 here http://vserver.13thfloor.at/Stuff/AXIOM/BETA/LATTICE/
22:07
aSobhy
yeah I forgot for those files
22:08
aSobhy
i remember i saw the model no but where didn't remember (dory memory)
22:09
aSobhy
thanks Bertl :)
22:09
Bertl
you're welcome!
22:11
Davelister
left the channel
22:16
se6astian
changed nick to: se6astian|away
22:53
futarisIRCcloud
joined the channel
23:07
Davelister
joined the channel
23:08
Davelister
changed nick to: Guest20142
23:12
Guest20142
left the channel
23:41
Fares
joined the channel
23:45
Fares
left the channel
00:55
aSobhy
Bertl should we shutdown the beta or wat
00:55
aSobhy
I saw a command like that
00:55
aSobhy
what*
00:55
Bertl
nah, don't bother
00:55
aSobhy
OK