#apertus IRC Channel Logs

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

good day!

so I guess what you are seeing is the ft600 sending less than 2048 bytes in a buffer

which is what our ft601 driver core does

but if you have a link to your gateware I can have another look

I pushed it here: https://github.com/korken89/ovio_core_firmware/blob/master/gateware/apps/ft600_test.py

I just send right now if there is something in the FIFO, no matter how full it is

From the datasheet it only says it will use smaller frames if not sending full 1024 byte packets

yup it can do that but our rust driver does not support that atm ;)

also the time the ft60x seems to need seems to be independent of the packet length so it is beneficial for performance anyways to always do full packets

(smaller packets would be implementable but most likely not with our current zero coppy aproach so it would give us a performance hit on the pc side too)

the whole save_to_begin_new_transaction logic from that file

I'll give it a try to see how the ft60x-rs interacts :)

Indeed

It's for VIO which expects sub 20 ms latency

As I was sort of just planning to packet each data type and ship it

20ms doesnt sound like padding all data packets would hurt ;)

You run with fixed length frames?

our setup is a bit more funky

as the usb3 plugin module has its own fpga (a machxo2) we have to run some interface between that fpga and the main fpga

Hmm, it just pumps the data?

so basically if the pc side (or the usb bus or whatever) cant keep up receiving the data we loose data in random places

so we need an automatically alignig protocol

therfore we did that framing hack with a blanking area to which we syncronize

ah but I guess I missunterstood your question

Haha no problem

I could have fixed frame sizes

I'm just wondering what happens then if the FT60x reader looses sync, does this happen?

it just resyncs again ;)

probably the current desing will not stay for long

Is this due to the "ready"-less design?

we will need a better plan anyways once we have wavelet compression

I think this is part of the ready-less design

when i send a counter that is generated in the machxo2 I dont get any data loss

I feel there is a lot to learn from you all there :D

so your hope for a lossless pipe is probably fulfilled :)

If you have questions just ask :)

Ah I see that

(not really what my board is supposed to do though)

+ debugging purposes

> f you have questions just ask :)

Haha

Oh I didnt notice that the MT9V034 was just vga

is there any specific reason you went for that sensor?

Had quite good HDR as well

I was kind of thinking if the ovio could be used as a better webcam with background removal

I just have used that camera a lot, and the first time I tried Lattice FPGAs I wanted something I was used to :)

Global shutter, HDR, and very short shutter times as well

also vga seems a lot more chill to process

Yeah

is the ovio intendet to go on a drone?

That was my research area :)

Hehe

Sorry, I sort of assumed you knew what I was up to

And to run as much of the VIO algorithms in the FPGA as I can

now I understand your process

Not really, the high level algorithms still need it

sounds like a fun project

Things that an FPGA is perfect for

is that a university project?

It was before

But I find the area so interesting that I sort of can't stop :)

ah I see

btw: did you read https://github.com/nmigen/nmigen/issues/213

Oh that looks interesting

Haha, was still interesting :D

ah no it was the right one

Would be a nice feature

How we used to implement the pipelines were like small modules with know delay and data width

I'm so amazed by the nMigen area

sounds... fun? :p

Now in a few days I have learned enough nMigen to get the FT600 running, which was horrible before, and its really amazing!

so I am probably lacking most of the basics

yup me too

But it was a VHDL + simulation, not even mentioning FPGAs

With tools like nMigen it gets actually quite enjoyable :)

Oh

;)

You picked up FPGAs just for fun?

Oh, you started with cameras?

yup somehow I stumbled into the apertus project a couple of years ago and since then I am quite into cameras ;)

Is there like an arhc overview of the camera in the apertus project?

se6ast1an: do you know one

sounds like a good plan :)

actually there is one more thing I want to point you to (for gateware development)

I'm very new to nMigen so all tips are welcome :)

the SocPlatform infrastructure in our nmigen-gateware

Oh

then it generates some glue-logic to be able to access that register via jtag (currently used for the machxo; probably works for the ecp5 with some changes) or via axi (for the zynq)

Ohh

then it generates a python library which exposes those registers as fake python variables

ah, no sorry, not that I am aware of

you can even define methods on your driver in your gareware codebase (example: https://github.com/apertus-open-source-cinema/nmigen-gateware/blob/master/src/lib/io/plugin_module_streamer/rx.py#L63)

Very cool

I can walk you trough the process of getting that up and running if you are interested

okay, cool :)

good luck and keep me posted :)

good night