Current Server Time: 19:32 (Central Europe)

#apertus IRC Channel Logs

2019/06/03

Timezone: UTC


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