<agg>
But yes I too really want a cortex-m and some FPGA fabric. It exists but not quite right yet I guess.
<TD-Linux>
I didn't see any way to use it for capture
<TD-Linux>
the compare lines for it are output only
<TD-Linux>
the one obnoxious thing is that the hrtim isn't actually emulatatble with a fpga
<TD-Linux>
(except, maybe, with some very clever manual placement)
<agg>
it can't capture the CHA1 etc outputs but can capture the sub-timer counter values based on any of the external events or output set/reset events, so e.g. can capture the comparator triggering
<agg>
i use it to read back how long a pulse was that's terminated by a per-pulse current limit comparator
<TD-Linux>
oh huh, I'll have to reread the datasheet again then
<agg>
this is on the f334, i think it changes a bit on some other chips
<TD-Linux>
I was looking at the g7 version
<agg>
not used it on the h7
<TD-Linux>
h7 doesn't have it :(
<agg>
there's a g7 now??
<TD-Linux>
er sorry I meant g4
<agg>
i think the g474 and also some h7s have hrtim
<agg>
yea, h7x3 for example does
<TD-Linux>
oh cool
<agg>
how did you find the g4? i've not used one before but it seems like one day i'll probably have to :p
<TD-Linux>
I have a project that currently uses the the f7 (without hrtimer) and I wanted hrtimer. the closest I could pick is g4, but that sacrifices clock speed and gives me some useless stuff like cordic accelerator
<agg>
it's wild that it has a CORDIC peripheral
<agg>
i don't think any f7 has an hrtim
<TD-Linux>
yeah. I didn't realize the h7 was an option for some reason
<agg>
the FMAC looks kinda cool. the g4 in general seems a pretty wicked lowish speed dsp/motor/power control chip
<TD-Linux>
assuming the packaging is ok I'll probably swap next version of this board to h7 then
<agg>
they are pretty wild chips
<TD-Linux>
the FMAC and CORDIC are kind of cool but it's awkward how they are separate memory mapped controllers. the FMAC in particular is pretty redundant with the DSP instructions
<agg>
clock speed is up at like 400MHz, some are dual core too
<TD-Linux>
in fact I think m4f dsp instructions would probably outperform it
cr1901_modern1 has joined ##openfpga
cr1901_modern has quit [Ping timeout: 260 seconds]
somlo has quit [Remote host closed the connection]
somlo has joined ##openfpga
OmniMancer has joined ##openfpga
OmniMancer has quit [Read error: Connection reset by peer]
Asu has quit [Ping timeout: 264 seconds]
OmniMancer has joined ##openfpga
mumptai has quit [Quit: Verlassend]
<emeb_mac>
Having some fun with this UP5k hooked to an RPi - loading the bitstream with a shell script that uses sysfs to drive the GPIO results in proper load & execute of of code from SPRAM, but the HFOSC is not properly calibrated.
<emeb_mac>
But, loading the bitstream via a C prog that uses the gpio character device results in properly calibrated HFOSC but the CPU isn't running properly (sorry - not SPRAM, BRAM)
<emeb_mac>
So, down to comparing the differences in timing of the two approaches.
<emeb_mac>
Really proud of myself for inadvertently finding two unique ways to fail.
<pie_>
I dont know where I could possibly ask this; so I looted an big ol CRT monitor that turns on and shows its "no signal" stuff, but I cant seem to be able to enable my vga output on my laptop
<pie_>
edp1 is the built in monitor, and dp1 and dp1 and hdmi1 and hdmi2 are grayed out in arandr and thats all i have
<pie_>
protip, the lenovo thinkpad dock has a vga port. it seems to take precedence. doh.
<gruetzkopf>
yeah, there's a video switch in the laptop