#apertus IRC Channel Logs

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

Hi all, it's been a while

BAndiT1983: All good, how have you guys been?

So that I proceed accordingly

in fact the settings are not that dynamic, as we usually know which one are required

ok, thanks. I'll return to it and get back with other things that might be a unclear

will do

yes, I created an Attriubute class with an enum "Type" member for this

and used a C union as the storage. I'd like you to review this sometime today

I'll let you know once it's in my fork

you can also use uint8_t as it will be unsigned char

but isn't uint32_t just 4 bytes?

we also need floating point numbers, e.g. when time is involved

yes, it's 4 bytes. but the compiler needs to know how much memory to allocate for this "struct". So it will allocate the largest of the member's size

yeah, sure I'll add a float too

very good and already looking nice

I'll try my best, but I'm sure an embedded systems guy will scold me for parts of my code

:)

yep, c++11 is activated

ok, I will use auto and for-ranged for loops for now. Let me know if you want to change this

you can check how the size of firmware changes in the build folder, the .map file

how do I build? Do you guys have a readme with toolchani details, etc?

you need to download and install xc32 from microchip

ok :)

Hey Bertl! Can you confirm that these are the commands we need to program the PICs in beta main board: https://drive.google.com/file/d/1mWhFZ5BNiwE43WLxiJsuubEAHqbUzx4-/view?usp=sharing

hi

bluez_[m]: looks good. I always do an rf_sel A/B first although that should not be required

alright! i'll add it to the wiki then..

https://wiki.apertus.org/index.php/Beta_Main_Board

looks good, did you test it as well?

nah i didn't ':D

why does it say no module named 'intelhex'?

should i install that using pip?

interesting, what are you using python for?

*understands

otherwise it doesn't find the pic

ah ok

just looked up this module, will definitely talk to metal_dent[m] about switching to python for UART LVP, this would simplify the task

at least for now

BAndiT1983: this is what I've done for the initial programming of the remote PICs

Bertl: not with pickit?

the LVP part is rather nice to get the idea of things working and we are on the good way to get it done soon, many thanks for the python idea, haven't thought of it, although i use it almost daily for the PCB stuff at the moment

dumb question from my side, forgot that we have a chain there

*MCU

i mean the chain, know from xilinx fpga boards about boundary chain and that i can access chips with just one JTAG connector

PIC16 do not support JTAG

ok, thanks, then my question is volatile by definition

Bertl: made the changes..

did you have to install any additional modules?

also what do you mean with "upload a special FPGA firmware" exactly?

I had to install a python package thats all... intelhex

this would be also helpful for the remote flasher, as i tend to use python because of this module, this would spare a lot of trouble and development

I mean the gatware... there is an icsp.bin image that we upload into the fpga if m not wrong..?

is the correct verb "upload" here? or "flash" ?

just checked IntelHex is already there indeed: https://github.com/apertus-open-source-cinema/axiom-firmware/blob/master/makefiles/in_chroot/requirements_pip.txt#L8

MEETING TIME!

M not sure there ':D

everyone please pm me for ordering the reports as usual

Thanks!

So this week i made more progress with the driver

Currently the only entry now is idcode...which correctly reads out the idcode from the mxo2

I also made many changes to adhere to the linux kernel coding style that i was missing

https://github.com/Swaraj1998/axiom-beta-rfdev

Nd ofc today i added the pic programming brief guide :)

that is https://wiki.apertus.org/index.php/Beta_Main_Board#Programming

apoorva_arora you are next

Np!

> bluez_: you tested the flashing already right? please close lab task when confirmed working

So, I continued my work on SERDES PHY. I first tried to build upin the PHY made by GSOC student from 2018 but realized that it was not compatible with the protocol that needs to be built on top of it. So, I made a completely new SERDES. with proper handshaking signals allowing data and control flow for burst as well as as singular data transfers

I am currently building the test bench for the master and this week I will implement slave side as well.

thats all from my side

I can not predict at the moment because I dont know how to predict data rates without complete timing closure (after pacemetn and route)

okay

preetimenghwani is next

So this week i spent most of the time working on test framework, the code is ready (i.e modifications done ), need to make changes in script to test it.

link to the code?

*will put here after the meeting

please do so! tx!

panintended, please go ahead

please avoid long messages in the meetings

Ah, sorry about that. I had it ready in a text file and pasted it. Should I paste it line-by-line next time?

regarding 3, you discovered the microchip wonder #1 :)

panintended: if you disable some options in xc32 setup then you're good to go usually, anything besides pic32 can be turned off

Let me paste my status once again

Good to be back after a hiatus (personal obligations and let me know if you want to adopt a kitten...)

2. I set up some boilerplate code for how attirbutes are stored in the "database" object. I hoped to submit them for review today, but it this will have wait till tomorrow I'm afraid.

That's all for now, should have more news soon.

the pic32 and pic32mx libs are about 2GB each

BAndiT1983: I did try running the installer with --help, but didn't see any useful options

Bandit your turn!

alright, hello everyone

you can extend the virtual "HDD"

this week i had mostly 3 tasks: panelisation script for PCBs, soldering the adapter board for e-mount research for schmoggie and guiding metal_dent[m]

this is the board outline: https://pasteboard.co/JbnLJb5.png

it is very dark though :)

this is the preview from pcbway, as i had to investigate which layers are correct and which need more adjustments -> https://pasteboard.co/JboEGFo.png

still not final, but bridge generation is already automatic, will also add insets, so the subpanels can be cut off where mouse bites are

I think what Bertl means is the length of the bridge not the width

I mean the bridge width, not the slot width

ah, this is also adjustable by setting the number of bridges horizontally and vertically

trying to keep everything adjustable there

will try to deliver it on thursday, as it'S holiday in germany

and finally GSoC, was looking with metal_dent[m] at low-voltage programming of PIC16 on the axiom remote, she can tell more about it

online calculator plus verified with multimeter ;)

that would be it for now

metal_dent[m]: your turn!

last week i mostly read about more ways for flashing the firmware

for parsing the hex file me and BAndiT1983 decided to create two arrays one for prog mem and other for conf mem but i guess BAndiT1983 is telling now to switch to python scripts (sorry i havent read the logs yet as i was off for sometime)

what did you learn from the bootloader code you studied?

yes, I was about to ask about https://github.com/apertus-open-source-cinema/AXIOM-Remote/pull/17

the one in the repo doesn't work properly so i studied minicom output, where the initial output block gives the IDs, configuration words etc

the one in the repo works correctly, but CI build is somehow not working

anything else metal_dent[m]?

many thanks!

1. the last hand built beta dev kit shipped last week, now all the focus is on getting the hardware ready for industrial production (PCB panelization, last new Powerboard tests/reviews, preparing pick and place files, etc.)

3. In a collaborative effort of me and several GSoC students the documentation of the remote beta setup which bertl talked about in previous meetings has been documented with a list ofvreference commands. The guide itself is not made public but provided to those who need it to avoid requiring to remove all hostnames/ports/etc. for security purposes.

thats it from my side

yeah

It arrived and I took some images:

https://files.niemo.de/DSC01197.JPG

They look fine afaict, so this confirms that we should be able to use jlc.

Furthermore I continued with the board layout of the micro r3. I did a first pass at placing all the connectors according to our current mechanical concept (the one sebastian alreay mentioned last week: https://cloud.apertus.org/index.php/apps/gallery/s/PGHsr9PjkaxLoJC).

I also redid the fanout of the ecp5, paying more attention to high speed signals and while its not perfect, doing it on 4 layers seems doable without too many compromises.

Further work on the layout is now mainly waiting on a thorough review of the schematic and all our footprints.

Bertl: there is now a script called axiom-bringup-environment.sh that should launch a shell with the bringup scripts in $PATH aswell (still with axiom- prefix and underscores replaced by dashes)

Finally anuejn refactored the nmigen gateware a bunch and there is now a handy cli, that lets you build any gateware for any of our supported platforms (micro, beta and zybo currently).

So we no longer have top-level files for each platform :)

great vup

nope, thats it from me

4. AXIOM Team Talk 15.4 has passed first review phase and is now being refined in editing by Max, release is not too far off anymore

(s/tended/tented/)

sure

back now ...

as se6ast1an mentioned, I got new SSDs and enclosures for teting

but all the SSDs I tested so far (3 different ones) only provide the write performance for a short time

heat problem?

give an average throuhgput of 406MB/s for 100GB of data

for the Force_MP_510 SSD about 402MB/s can be reached for 20GB

it doesn't look to me like it would be a problem of the USB interface though

very interesting

yes

besides testing with the ultra-96 we did some planning on the camlink4k/hdmi side for future testing

I'll setup some in-detail tests

I haven't tested this yet

so that's it from my side

many thanks!

many thanks to all participants!

I'm sorry I missed the past couple of meetings

I'm currently working on sensor's registers and its SPI interface

thanks!

thanks!

branch

just a minute there is a mistake i guess i will push latest one in a minute

done!

off for now ... bbl

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

off to bed, good night

yep ENIG is planned

it's also not running at frequencies where the nickel might cause problems