<urja>
I'm not going to spend more time off-topic on that issue, but i'll just leave a note here; this "remarkably low end" machine is not fast, but in general it's totally capable enough for a lot of stuff. It compiles the AVR firmware I needed to flash over UPDI in about the same time as a "glasgow -h" takes :P (the binary is about 20kB)
<whitequark[cis]>
yes, which is why I think it is worth supporting
<urja>
It can run extremetuxracer at playable FPS, i can browse the web and watch youtube, it can run KDE 5 ...
<whitequark[cis]>
if I had thought it was not worth being used I would have said as much as well
<whitequark[cis]>
it's just that you can get a mid-end cellphone at a like $100 price point if you get it used and have it be significantly faster (from my measurements)
<urja>
I wouldnt have mentioned the slowness if I was trying on my Pentuum 233
<urja>
*Pentium 233 :P
<whitequark[cis]>
I don't think modern Python even runs on Pentium 233 due to lack of SSE support
<urja>
Hm, didn't complain for me (i mean, i compiled it for i586, with buildroot...)
<whitequark[cis]>
oh yeah I mean like prebuilts
<urja>
but there even a "python -c pass" is slow
<whitequark[cis]>
if you emerge python then sure it will work
<urja>
Hmm... i think my AMD G-T40E (1Ghz embedded x86-64, PC Engines APU1) might be slower than the RK3288...
<urja>
Yeah, i have x86-64 hardware where a "warm" (second try, forgot to put "time" the first time) "glasgow -h" is 7.5 seconds
<urja>
(i just have no point to use the glasgow with that headless box, the laptop on the other hand is really handy to use to program things "in the field" so to say...)
<whitequark[cis]>
yeah; it's about 8-12 seconds on a first gen rpi
<whitequark[cis]>
s/first/second/
<whitequark[cis]>
which is where most of my experience with really underpowered hardware comes from
redstarcomrade has quit [Read error: Connection reset by peer]
Foxyloxy has quit [Read error: Connection reset by peer]
redstarcomrade has joined #glasgow
redstarcomrade has quit [Read error: Connection reset by peer]
redstarcomrade has joined #glasgow
redstarcomrade has quit [Changing host]
redstarcomrade has joined #glasgow
redstarcomrade has quit [Read error: Connection reset by peer]
Tom has joined #glasgow
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #glasgow
viskipappa has quit [Quit: ZNC 1.9.1+deb2+b2 - https://znc.in]
viskipappa has joined #glasgow
be65da6e451238ff has joined #glasgow
<be65da6e451238ff>
I just got a glasgow to do some sniffing of different interfaces, thanks for making a cool product! I'm trying to learn a bit about developing applets, but the learning curve is a bit steep. I've been looking at the SPI and UART code as some examples to follow, but is there a more "beginner friendly" (mostly just looking for comments about why X is
<be65da6e451238ff>
being done) applet to use as a guide?
<whitequark[cis]>
no, not really, I got too sick to really maintain it before I had a chance to refactor the internals to the point where it's beginner-friendly
<whitequark[cis]>
(as in, "too physically sick", not "burned out")
<be65da6e451238ff>
Sorry :(
<be65da6e451238ff>
Would this be a good place to ask some questions?
<whitequark[cis]>
i don't really plan to document the current system lest it become even more fossilized than before
<whitequark[cis]>
yeah
<be65da6e451238ff>
My quick learning goal right now is just to make a simple applet that will read a few different inputs on the rising edge of an input clock signal and then just write them to a file on the host end of things
<whitequark[cis]>
Amaranth does not do the thing Verilog does where top-level ports can be assigned normal values
<whitequark[cis]>
and in fact, Glasgow adds functionality to the normal buffers, which allows it to transparently grab the output-enable and route it to the level shifter output-enable
<whitequark[cis]>
(on revA/revB we do not have output-enables, on revC we do, on revD we will likely invert the polarity for those)
<galibert[m]>
As to why ports are not buffers already, it's because you don't want to instantiate what you don't need, and in general fpgas can have multiple modes possible on the same pin (like normal + ddr) and you want to instantiate the one you want only
<whitequark[cis]>
also what galibert says
<be65da6e451238ff>
Reading those docs right now; I was having trouble finding the Buffer docs on the site earlier