<metaGross128>
but it doesn't work i activated the kernel modules
<metaGross128>
for backlight and ILI9341 accordingly
buzzmarshall has joined #beagle
<metaGross128>
but no idea why it doesn't work
metaGross128 has quit [Ping timeout: 256 seconds]
mattb0ne has joined #beagle
<mattb0ne>
when they were creating python why just have one thread for everything
<mattb0ne>
this asyncio stuff is confusing
<set_>
That, that, asyncio stuff is not easy-peasey.
<set_>
Learning how to account for bits is upsetting. I thought it was harder. I still think this class is lying to me.
<set_>
I am using Keil right now to account for M4 chips but I think setting up a GPIO in C/C++ might be a bit more complicated than just accounting for bits.
<set_>
fro the am335x.
<set_>
So, 32-bits wide on the am335x for whatever peripheral. Okay. Then, if bit 1, 2, 4, 8, and another one are all needing to be 1 for an I/O port to be open and used seems practical.
<set_>
..
<set_>
Then, making binary into hexadecimal is needed!
<set_>
Then, once that is done, a person would need to account for what exactly is the motivation of the chip to handle peripherals. Right?
<set_>
For instance, GPIO would need on the am335x a memory mapping of a particular idea. This idea are directives in the form of includes and then defines plus the hexadecimal expressions which will tell what to expect for the clocks, ports, and delays.
<set_>
Man...it is getting complicated.
<set_>
Anyway...I will chill out.
<set_>
I can actually start to describe how to do things again. It is neat. Since some libs. are becoming extinct or not available, I need to learn.
<zmatt>
mattb0ne: threads are worse... threads seem simpler, except threaded applications are much harder to get right, they make it really easy to make things that seem to work at first but will randomly fail
<zmatt>
mattb0ne: not saying asyncio is perfect though, it's definitely not the clearest event-driven framework I've used
<zmatt>
asyncio.StreamReader's api is definitely kinda limited, e.g. to implement that readlines() function I had to access its internals (reader._buffer and reader._maybe_resume_transport)
<set_>
What kind of timer is on the am335x, BBB?
<set_>
16-bit, 24-bit?
<zmatt>
that's too vague a question
<zmatt>
which timer are you talking about?
<set_>
Oh! There are more than one?
<zmatt>
normally you don't have any direct dealings with hardware timers, linux provides timers for you (implemented using a hardware timer, but that's an implementation detail)
<set_>
So, we have a clock, right? Is there a timer for the clock or are there timers for each, separate clock on the am335x? If so, how many clocks do we have on it?
<zmatt>
do you mean clock in the sense of clock signal, or in the sense of what time it is?
<set_>
Not time, a whatever MHz or Hz clock.
<set_>
Some people call them crystals, right?
<zmatt>
the BBB has a 24 MHz crystal oscillator that's the main clock signal, the AM335x uses PLLs to convert this into various other clock signals as needed, e.g. the 1 GHz clock for the cortex-a8, the 200 MHz clock for the interconnects and many peripherals, 960 MHz for usb and various other peripherals
<set_>
Okay.
<set_>
Got it.
<zmatt>
there's also a 32768 Hz crystal used for the RTC, although it's not very useful in practice on the BBB
<set_>
I will not use it yet, i.e. the RTC.
<zmatt>
and it has a 24.576 MHz oscillator as master clock for the digital audio interface
<zmatt>
the RTC is used implicitly
<zmatt>
but really all it does for you is preserve the date and time across reboots
<set_>
Right.
starblue has quit [Ping timeout: 256 seconds]
<set_>
So, we have a 24-MHz clock that sets the clock speed for different peripherals via busses and ports, right?
<set_>
So, this 24MHz clock will have to be accounted for even w/ mmap'ing an I/O like a GPIO.
<zmatt>
ehmm nothing you just said makes any sense
<set_>
Is there a particular clock and timer for the accessible GPIO on the am335x/BBB?
<set_>
Oh.
starblue has joined #beagle
<set_>
Let me explain.
<zmatt>
none of these things have anything to do with each other
<set_>
You are right. I am forumulating and speculation is now.
<set_>
I am turning thought into science for myself.
<set_>
So, are you saying that using a clock and timer for GPIO is useless?
<zmatt>
these words individually mean something, but not when put together in a sentence like you just did
<set_>
Fine.
<zmatt>
you might as well ask about using pineapple juice for GPIO
<set_>
No issue.
<set_>
Okay.
<zmatt>
I just don't know what you could possibly mean
thinkfat has joined #beagle
<set_>
No issue.
thinkfat_ has quit [Ping timeout: 265 seconds]
<set_>
I am over here thinking that if I memmap my clock and timer(s), I could then set up a script to handle an end result.
<zmatt>
you can't mmap pineapple juice
<set_>
W/ I/O specifically, I would then use these...
<set_>
Fine.
<set_>
Fine.
<set_>
Fine.
<set_>
Okay. You win.
<set_>
No description in here.
<set_>
I am not upset but my pina collada juice should get memmapped harshly.
<set_>
The only reason I bring it up this late in the set_-@zmatt conundrum is that I am learning a bunch again and trying to use it for the BBB (am335x) for an end product.
<set_>
That is all.
<set_>
I should not use the libs. for this reasoning is what I am thinking.
<zmatt>
???
<set_>
GenTooMan: Where in the world are you? @zmatt is not playing nice!
<zmatt>
I just can't make any sense of what you're trying to say or ask
<set_>
I understand.
<set_>
It is me.
<set_>
My issues, my problems, my understandings. I cannot just describe everything well enough yet.
<set_>
No issue.
<set_>
So, I can set the system clock, this 24MHz clock source, w/out the PLLs?
<set_>
zoom!
<set_>
Or...would I have to account for the PLL of each, separate clock source outside of the main oscillator (24MHz)?
<zmatt>
you have no reason to have any sort of direct interaction with the clocks or the PLLs
<zmatt>
all of that is dealt with by the bootloader and linux
<zmatt>
there's nothing to set, nothing to "account for"
<set_>
Are you being serious? So, using the timers would not rely on the clock sources?
<set_>
Okay.
<set_>
Even when memory mapping hexadecimal values from the TRM for the am335x setting up of peripherals?
<zmatt>
???????
Guest43 has joined #beagle
<set_>
Let me try to better articulate that idea.
<Guest43>
i'm a beginner here. so many people logged in...
<set_>
So, the am335x TRM is a long doc. Okay, in that TRM is a bunch of values on how to set bits and some of them have to do w/ timers, clocks, and phase-lock-loops.
<zmatt>
set_: most of the TRM is not relevant for typical users but only for kernel developers
<set_>
I was thinking that managing the bits in this TRM would be...
<set_>
Okay.
<set_>
No issue.
<zmatt>
anything to do with power, clock, and reset management especially
<zmatt>
Guest43: it's not uncommon on IRC to leave clients connected 24/7
<set_>
Okay. Okay. I will try to refrain from chatting about power, clock, and reset management.
<zmatt>
Guest43: so the number of people in an IRC channel is not necessarily indicative of activity
xet7 has joined #beagle
<Guest43>
i got it. but i'm developing driver, too.
<zmatt>
driver for what?
xet7 has quit [Remote host closed the connection]
<Guest43>
and app.
<Guest43>
in my case, i am using am572x
<Guest43>
so i bought idkam572x and evm...
<Guest43>
and made my own board using am572x
<zmatt>
sounds like no small task
<Guest43>
^^
<Guest43>
after make my own am572x board, there is no app for gpmc.
<zmatt>
pretty sure the gpmc has a kernel driver but I've never worked with it
<Guest43>
so i read datasheet. and it works well.
<Guest43>
but i think my code is not good. it is just for using.
<zmatt>
drivers/memory/omap-gpmc.c is the standard kernel driver
<Guest43>
thx.
<Guest43>
i wander which environment is better between window and linux.
<Guest43>
i am working with windows.
<zmatt>
better for what
<Guest43>
now i am developing a PLC controller.
<Guest43>
dual arm is for managing and plc(like LD), and one dsp is for ethercat, and the other dsp is for motion.
<Guest43>
development state is on going...
<Guest43>
i heard that linux is good to develop.
<Guest43>
is it really good comparing to windows environments?
<Guest43>
i 'm considering to using linux environments...
<Guest43>
it's time to go to lunch.
<Guest43>
see you ...
Guest43 has quit [Quit: Client closed]
Guest43 has joined #beagle
Guest43 has quit [Client Quit]
troth has quit [Ping timeout: 265 seconds]
<set_>
FSM!
troth has joined #beagle
buzzmarshall has quit [Ping timeout: 256 seconds]
vd62 has joined #beagle
vd has quit [Ping timeout: 256 seconds]
rob_w has joined #beagle
troth has quit [Ping timeout: 260 seconds]
troth has joined #beagle
_whitelogger has joined #beagle
vd62 has quit [Ping timeout: 256 seconds]
ikarso has joined #beagle
florian has joined #beagle
Shadyman has quit [Quit: Leaving.]
ikarso has quit [Quit: Connection closed for inactivity]
ikarso has joined #beagle
rob_w has quit [Remote host closed the connection]
lucas_ has joined #beagle
lucascastro has quit [Read error: Connection reset by peer]
sicelo_ has joined #beagle
sicelo_ has quit [Client Quit]
sicelo_ has joined #beagle
sicelo_ has joined #beagle
sicelo_ has quit [Changing host]
buzzmarshall has joined #beagle
zjason` is now known as zjason
rcn-ee has quit [Remote host closed the connection]
mattb0ne has quit [Ping timeout: 260 seconds]
vd has joined #beagle
Konsgn has joined #beagle
<Konsgn>
Hi all!
<Outrageous>
Hello Konsgn
rcn-ee has joined #beagle
sicelo_ has quit [Remote host closed the connection]
florian has quit [Quit: Ex-Chat]
xet7 has joined #beagle
vagrantc has joined #beagle
metaGross128 has joined #beagle
lucas_ has quit [Quit: Leaving]
Outrageous has quit [Quit: I QUIT AND I'M NEVER EVER COMING BACK!]
Outrageous has joined #beagle
ikarso has quit [Quit: Connection closed for inactivity]
metaGross128 has quit [Ping timeout: 256 seconds]
russ has quit [Remote host closed the connection]
mattb0ne has joined #beagle
<mattb0ne>
zmatt: my code keeps aborting
<mattb0ne>
lol
<mattb0ne>
the ring buffer fails an assertion now for some reason
<mattb0ne>
i will put up a paste bin
<mattb0ne>
let me use your code
<mattb0ne>
hold um
<mattb0ne>
on.... i am getting ring buffer is full
russ has joined #beagle
mattb00ne has joined #beagle
<Konsgn>
did you end up rate limiting the qt rendering?
vagrantc has quit [Quit: leaving]
<mattb0ne>
well i am still up in the air on that
<mattb0ne>
so the timestamp match up
<mattb0ne>
but the plots seem to lag a bit not as bad as before but there is a lag
<mattb0ne>
i can live with that. Now I just need to be able to run for more than 3 minutes without the ring buffer blowing up
<mattb0ne>
i am dropping zmatts pastebin in now
<mattb0ne>
hopefully that fixes it but it seems I cannot process data fast enough
<mattb0ne>
so there probably need some optimization still.
xet7 has quit [Quit: Leaving]
xet7 has joined #beagle
Konsgn has quit [Quit: Leaving]
mattb00ne has quit [Ping timeout: 256 seconds]
vd has quit [Quit: Client closed]
vd has joined #beagle
troth has quit [Quit: Leaving.]
set_ has quit [Ping timeout: 256 seconds]
mattb0ne has quit [Ping timeout: 260 seconds]
set_ has joined #beagle
meta has joined #beagle
meta is now known as metgros
<metgros>
hellow anyone knows how to bind a EHRPWM1A pin to backlight driver ?
<zmatt>
you create a backlight device that references the pwm output
<zmatt>
seems okay at first glance, have you checked the kernel log for errors?
<zmatt>
status="okay"; is redundant when declaring a new device node btw, that's only needed if you're overriding a previously declared status="disabled";
<metgros>
[ 2.329706] pwm-backlight: probe of ocp:backlight failed with error -22
<zmatt>
oh actually, your pinmux block is the problem
<metgros>
how ?
<zmatt>
use the AM33XX_PADCONF macro, not a bunch of hex constants... the kernel devs in their infinite wisdom changed the format of the pinctrl-single,pins property, relying purely on the macro to maintain "backwards compatibility" (but only on source level, not on dtb level, nor for anyone who wasn't using the AM33XX_PADCONF macro)
<zmatt>
actually, that happened somewhere in 5.x, dunno if 5.10 is already affected
<metgros>
i'm in 5.10.23
<metgros>
do you have the Correction with AM33XX_PADCONF ?
<metgros>
i copy paste the pin config from an overlay i found on the internet
<zmatt>
https://goo.gl/Jkcg0w#gid=698174264&fvid=2017068390 shows that P9.14 is named "GPMC_A2", so that should be AM33XX_PADCONF(AM335X_PIN_GPMC_A2, PIN_OUTPUT_PULLDOWN, MUX_MODE6)
<zmatt>
(note that the PIN_OUTPUT_* and PIN_INPUT_* macro names are misleading: what they mean is "input disabled" and "input enabled", it has no control over the pin's output driver)
<metgros>
okay
<zmatt>
(when in doubt use PIN_INPUT_* since it's always safe, PIN_OUTPUT_* is basically just a tiny power consumption optimization)