#apertus IRC Channel Logs

https://pastebin.com/raw/Gnqp64id

doesn;'t happen reliably though

i.e. sometimes it simply locks up, sometimes it gives the error

still 11.5MB/s only too

got it booting!

so probably still not perfect

hmm, that might be unrelated, i.e. some kind of data corruption on the card ...

What was the problem / what made it boot?

lol

but it is not really a stable setup

Well thats atleast something we have the source for / can change

Yeah probably

That sounds great

http://vserver.13thfloor.at/Stuff/AXIOM/sd-resistors.jpg

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

nn!

committed adjusted debug painter yesterday, debug overlay button should work now, just not happy about my naming of some classes and methods at the moment, but this is the least of the problems

naming is okay afa we understand what that is :D

ImageButton is ready (referred PushButton), I'm thinking of testing it with WB screen first

why WB screen? my expectation would be that it works in every screen, e.g. settings screen

i hope the code hasn't to be placed in every dialog

?

*class

"and draws the icons deriving from ImageButton" -> what do you mean?

i meant that we'll define a class which derives from ImageButton, there we'll make the sidebar with the help of ButtonBar

you should look at this image: https://www.gamasutra.com/db_area/images/blog/mini2Dx/ClassHierarchy.png

https://www.researchgate.net/profile/Maria_Gemou/publication/221908814/figure/fig2/AS:305243830145029@1449787208370/LWUIT-Widget-library-class-hierarchy-Moreover-the-Lightweight-UI-Toolkit-library.png

metal_dent[m]: please make a drawing of your planned structure, so i can check it and give you proper advices, you can use either gdoc or draw.io -> https://app.diagrams.net/

using it on daily basis for my work and trying to incorporate it here, at least for the axiom remote project

it's half past 8, i think se6ast1an will appear shortly ;)

hi

how are things going

claimed the parameter menu task

something like this -> https://www.plantuml.com/plantuml/svg/SoWkIImgAStDuUBAp2j9BKfBJ4vLy7GgBId9prFWIiv9B2vMWF2S4ekWVC_SnFHKL2N1cIcfG0KAN5mmlRgwTiWAkP0rWUIWEhZWXgE8SZcavgK0NGK0

metal_dent[m]: sorry, but no, please explain why you derive a sidebar from a button?

to actually draw the bar which will have the icons and the button handlers and if we want to implement the bar in a screen (like WB) then we'll just add that class in that dialog

i think we should start with the tree hierarchy first, as your diagram is exactly inverted

normal approach is from big to small, let's do a quick discussion

the base of the task is a sidebar, which should have 3 UI buttons, as we have 4 sides with 3 buttons on each side of the display

IScreen is still not the abstract interface it should be and we would introduce Screen which derives from it later, remember our discussion yesterday?

At the end IScreen will have 4 attributes for the bars: _topButtonBar, _bottomButtonBar an so on

which button types does the ButtonBar accept?

yes

no

> At the end IScreen will have 4 attributes for the bars: _topButtonBar, _bottomButtonBar an so on

yes, but this is not important at the moment, as the structure is there, but i try to explain OOP side of it, as your diagram shows totally different picture of what should be done

just pulled latest changes, great to see debug painter switch working in visualizer!

metal_dent[m]: not directions, why should a bar derive from button?

BAndiT1983: alright, I agree it's totally wrong... I had some idea.

se6ast1an: great, maybe you can just grab the code from the visualiser, just 2 lines or so

have a university video conference coming up soon

metal_dent[m]: another nice topic in this direction -> https://en.wikipedia.org/wiki/Composition_over_inheritance

se6ast1an: my bad, build crashed because of version change, will push a fix quickly

builds fine here...

https://app.circleci.com/pipelines/github/apertus-open-source-cinema/AXIOM-Remote

P13 is not recognized currently, need to add that first

BAndiT1983: i looked at the code more closely and i think i got the present structure regarding the ButtonBar, IScreen, IButton, etc. and agree that we don't need another SideBar class which i was proposing, sorry for the wrong structure ':D

metal_dent[m]: no problem, just ask questions, as many as you need to grasp things

BAndiT1983: I've one more ques (which I had asked you earlier but I'm still not sure):

of course, left, right, top and bottom, as we have a structure which is influenced by the hardware

video conf done

added the task so we dont forget

my acm communication is currently weird so I cant get the i2c data required to add p13

the whole i2c communication is also not checked yet, will try to acquire the code for pic16 and look at it again

thanks, testing

worked, great!

one example is power consumption, as we don't need to poll every time, but get a pin change trigger from outside, which should reactivate pic32 from sleep and so on

sounds not that essential atm

remote is meant to be powered from the beta currently so power consumption optimization is not that important atm

our goal is to trigger the processing through interrupts

"it just works" won't work at some point also

then somebody should continue with bootloader, as at the moment we have only some tinkering base and not solid fundament with possibilities to restore the remote if firmware fails, don't think that people want to acquire pickit2/3 just to flash firmware

we have a lot of things we have to push and hardware-related side cannot be omitted, but i have to check the latest state first, will revert my pickit to MPLAB mode again, so i can at least flash with IPE, as pic32prog wasn't successful, tried also different branch, still no luck

heard my name being typed in my dreams ... :)

'oh god, bandit has questions!!!'

btw, took a quick snap yesterday with the microscope: http://vserver.13thfloor.at/Stuff/AXIOM/sd-resistors.jpg

and you can get even better if you care to adjust the settings, which I didn't

is any lag involved or can you solder beneath it without a bigger problem?

first, there is an inevitable lag, but it is quite short especially at higher framerates

second, you do not have any 3D information

so you do not know how far away from the PCB you are

what do you use for such small soldering? magnifying glass or goggles?

which is a problem if the distance to the object is really short

something like the Bresser Biorit or the AmScope SE400 are perfect

Bertl: regarding I2C and U(S)ART topic, how did we came to the discussion back then?

hi bertrand!

BAndiT1983: IIRC, you complained about the polling for button presses and wanted something event driven and I suggested to switch to serial (UART) instead

Bertl: this is also what i remember, as polling was colliding with the idea of bootloader a bit, do you have some suggestions about implementing it or postponing?

I just checked, the hyperdeck shuttle only support 1080p25/30

the beta is outputting 50/60p

Bertl: ok, good to know, but you don't have any preference regarding which to use there?

BAndiT1983: no real preference here, but UART is definitely a good choice for the task

most communications in both directions will be 'fire' and 'forget'

so having a one way information exchange vs. an I2C transaction looks more natural

BAndiT1983: it should also be reasonably reliable on the PCB

in this case UART is asynchronous and i2c synchronous, so latter one give us trouble when response does not arrive on time, then the struggles begins

which is less the case for a microcontroller

let's say the user is turning the knob and pressing a button

but the PIC32 most likely only cares about the position when the button was pressed or a 'periodical' snapshot or even just the 'final' position

of course, this can be also done via UART pin-pong

this was what i also was thinking about if we should reduce the flood of events

reaction/response time for the user was already defined in researches, have to check what looks fluent to the user

0.1 seconds is a bit low, but we don't update the screen constantly, at least it won't be the case soon, as currently a loop does it

30 FPS would be better and in any case, they should be synced to the LCD rate

so e.g. with 60 Hz refresh, 20 or 30 FPS

*-keeping +supplying

what I mean is, if you turn the knob and a list scrolls along as you turn it or some value increases/decreases the rate of change should be constant and in sync

we have enough timers to utilize one as LCD sync/update timer

probably the simplest is to phase lock the timer interrupt

well, let's look how you do it practically :)

i would just do while(0x45 != 0)

if you make sure that your guess is on the short side, i.e. shorter delay than actually necessary

in the next step, you can dynamically adjust the timer interval to match the actual framerate

have to test it, shouldn't be that difficult i guess

(but that will probably add quite some overhead)

luckily it's in the base set of commands

looked at the ili9341 docs, but am not sure which is suitable

nevermind, will read more into it later, but i see that we have no setup for the frequency, at least it's not that clear in the code

there is the TE pin which I used for the lcd.hex example

you can put that on an interrupt and set/adjust a timer from there

hi panintended

or did you find a way to avoid it?

on my hardware it works with both without a problem, only ubuntu VM shows black like yours, so maybe panintended can add a fix by extending the initialization

pickit3 reset to MPLAB mode, board flashed but not excited about performance, something is dragging it down

although the values are positive in clockwise direction and negative in counter-clockwise

BAndiT1983: I added _leftButtonBar in the IScreen and also modified the ImageButton class a bit

unlikely

right

hi all, I was out today. Reading up on the log now

se6ast1an: yes, the issue (T1181) is still there for me. for the time being, I have changed the relevant lines in Main.cpp in my local repo

BAndiT1983: yes

panintended: could you add the fix? at the moment i have to check what is required on the firmware side and help metal_dent[m] to understand the structure, but have to shift my focus also more to the bootloader, as it was dormant for quite some time and contains important hardware setup, like memory layout and other "fun" stuff

thanks

if you need more details, just give a ping

finally found the link for led linearization, which was used for currently used array, and commented the LCD dimming task

I will work on the parameter menu tomorrow, have no additions for settings menu planned currently other than parameter menu

Hi all. I think I've pinpointed what's causing https://lab.apertus.org/T1181 and added a comment. Have a look and let me know if the proposed change works for you.