freecoupnss was kicked from #glasgow by whitequark[m] [Kicked by @whitequark:matrix.org]
kmc has joined #glasgow
<d1b2>
<TomKeddie> @esden ^^
<sorear>
they were already kicked
<d1b2>
<esden> @TomKeddie deleted, on the discord side 🙂
d1b22 has joined #glasgow
umarcor has quit [Read error: Connection reset by peer]
d1b2 has quit [Read error: Connection reset by peer]
merry has quit [Read error: Connection reset by peer]
d1b22 is now known as d1b2
umarcor|2 has joined #glasgow
merry has joined #glasgow
egg|anbo|egg has quit [Remote host closed the connection]
jstein has joined #glasgow
Eli2_ has joined #glasgow
Eli2 has quit [Ping timeout: 240 seconds]
tomtastic has quit [Ping timeout: 240 seconds]
<d1b2>
<datenwolf> Hey @esden could you give me a short update on the status of the crowd supply? There's been some time since the last update.
<d1b2>
<datenwolf> Also it might be necessary to update the shipping details for my order, depending on if my current employment contract gets renewed or not.
<d1b2>
<Attie> @TomKeddie ooh, it'd be good to hear how it turns out... I don't remember how far I got with it, but it's definitely missing the ground pour, and I was planning to add other HUB* interfaces too
<d1b2>
<thomasflummer> There is an "Update shipping address" button when you log into Crowd Supply and click the order, that is probably the best way to make corrections to shipping details
tomtastic has joined #glasgow
<d1b2>
<TomKeddie> @Attie thanks, I got the board to no drc/unrouted. I'll try to send you my spares once they come in.
m42uko has quit [Quit: Leaving.]
m42uko has joined #glasgow
<d1b2>
<sarea> I'm currently trying to get to know the Glasgow Explorer a little better and have a question about it. Is there a possibility to control a pin directly via the scripting interface (for example to control an LED when I have sent a certain data pattern via UART)? I only saw that there is already a method to control the voltage of the ports, but none for individual pins, or did I miss something?
<d1b2>
<Attie> the individual pins are controlled by gateware, so you'll need to write some nMigen to do what you're after
tomtastic has joined #glasgow
<tnt>
I don't think there is just a 'gpio' applet yet, but probably would be usefu ...
<d1b2>
<Attie> you could possibly match on the incoming byte as / before it's put into the FIFO to the host, and toggle / set a pin there, if that sounds like what you're asking?
<tnt>
there are quite a few cases where you just need to sw toggle with no timing / speed requirements.
egg|anbo|egg has joined #glasgow
egg|anbo|egg has quit [Remote host closed the connection]
egg|anbo|egg has joined #glasgow
<electronic_eel>
a hacky solution for a slow control of pins from python, without any need for gateware: use the pullups. they are controlled by the fx2.
<whitequark[m]>
sigh
<whitequark[m]>
the way this is done in applets that need slow software pin control is by exposing relevant pins via i2c registers
<electronic_eel>
i explicitly wrote "hacky solution"
<whitequark[m]>
it's not really a solution
<whitequark[m]>
it doesn't do the same thing
<whitequark[m]>
whatever
<whitequark[m]>
one could solve this in a general way by interposing GPIO registers in between applets and IOs the way you see this done on microcontrollers
<whitequark[m]>
direction, value, whether it's controlled by the applet or by the GPIO module
<whitequark[m]>
however, this would change timings (both for synchronous and asynchronous case) and add a nontrivial amount of complexity to the bitstreams (mostly from the point of view of timing closure and synthesis/pnr time)
<electronic_eel>
the problem is that i2c registers need to be in the applet you want to use them with. as you can't have multiple applets at the same time, you have to modify the applet. if you want to control the pins from a script, it means you have to change an existing applet and maintain the diff.
<whitequark[m]>
yes, i agree that the current situation is very much not ideal
<whitequark[m]>
you don't necessarily have to modify the applet
<whitequark[m]>
you could inherit from it
<whitequark[m]>
but that doens't help for scripts
<whitequark[m]>
with this additional context, i see why you've suggested using pull resistors
<electronic_eel>
would it be possible to have multiple applets at the same time when only one of them uses the fx2 pipeline, all the others just i2c registers?
<electronic_eel>
i mean without much work of course
<whitequark[m]>
yes, of course, and almost all of the infrastructure is there already
<whitequark[m]>
except for the CLI option parsing
<whitequark[m]>
that was the intent from day 1
<whitequark[m]>
i basically flunked the UI for that feature
<whitequark[m]>
but the infrastructure is inherently designed in a way that there is no implicit "main" applet or anything
<whitequark[m]>
there's a few places where the code assumes having just one, but those are all connected with the UI in some way
<whitequark[m]>
actually, you could use multiple FX2 pipes from multiple applets too, there's no problem with that
<whitequark[m]>
(this is why you have to pass the multiplexer object you made at the build stage to the demultiplexer object you're making at the run stage)
<electronic_eel>
hmm, it is not obvious to me how to make this usable on the cli. i guess you faced the same problem and this is why it is in the state it is
<whitequark[m]>
precisely
<whitequark[m]>
i have some ideas
<electronic_eel>
but maybe we could make it usable for scripts first?
<whitequark[m]>
but as you probably know i've had more important things to do than to implement those lately
<whitequark[m]>
well
<whitequark[m]>
scripts replace the interact stage with them
<whitequark[m]>
*with the user code
<whitequark[m]>
everything that comes before, the build and run stages, and their CLI options parsing, is the same
<whitequark[m]>
so there is the same problem
<whitequark[m]>
if you are using glasgow as a library and instantiating targets directly, you already won't have any issues using multiple applets or something
<whitequark[m]>
but then you could just add I2C registers directly without adding an applet
<whitequark[m]>
however, it's not something i would call a stable API
<whitequark[m]>
oh, there's another consideration
<whitequark[m]>
if you want to toggle or read GPIOs at a certain point in, for example, SPI data stream
<whitequark[m]>
you cannot do this without cooperation from the SPI applet
<whitequark[m]>
we need the SERDES+sideband architecture first for that
<whitequark[m]>
so i'm not convinced that we should expose this for scripts even if we had an easy way to do it technically
<whitequark[m]>
i do see the convenience, but i'm worried about adding a mechanism that would ultimately be misleading and yet impossible to remove later
<electronic_eel>
yes, the i2c registers don't have any synchronization to the main data pipe
<whitequark[m]>
you can manually flush the data pipe but it's not reliable in any meaningful sense
<electronic_eel>
for stuff like additional chip selects or something like this you obviously need the true sync
<whitequark[m]>
not just that
<whitequark[m]>
there's a EPD applet and it has a startup sequence that looks like it can be done via I2C
<electronic_eel>
but for stuff like a user led or a button to interact with the user you don't need it at all
<whitequark[m]>
hm
<whitequark[m]>
that wasn't even in scope when i started
<electronic_eel>
:)
<electronic_eel>
think for example of using glasgow to implement a test jig
<electronic_eel>
if we had a applet + mechanism for this kind of slow async io, we could keep it, even if we create a better way with serdes+sideband in the future. so the api for scripts wouldn't change
<whitequark[m]>
i specifically want to avoid that
<whitequark[m]>
glasgow already consists mostly of technical debt
<whitequark[m]>
my #1 goal is keeping the project in a way that is sustainable for continued development, and i am not particularly bothered by not having some convenience features that would interfere with that
<whitequark[m]>
and yes, i very much do realize the frustration this causes to people.
<electronic_eel>
this is why i mentioned the pullup hack first: everything for it is available now
<whitequark[m]>
yeah
<whitequark[m]>
within the context of doing things from a script, it's... reasonable
<whitequark[m]>
i misunderstood you, sorry
<electronic_eel>
no need to apologize, i know very well that it is a bad hack and that the glasgow hardware could do much better. and that hurts
<electronic_eel>
also i don't know if sarea wants to use this in script context or not, this was just something i assumed because it is a case i thought about earlier
<whitequark[m]>
ah
egg|anbo|egg has quit [Remote host closed the connection]
egg|anbo|egg has joined #glasgow
emily has quit [Ping timeout: 245 seconds]
KryptoKidz[m] has quit [Ping timeout: 260 seconds]
KryptoKidz[m] has joined #glasgow
d_olex has joined #glasgow
emily has joined #glasgow
egg|anbo|egg has quit [Remote host closed the connection]
<d1b2>
<esden> @datenwolf we are working on the next update. It will be out when we are finished with it. Currently juggling a few things. As you can imagine the IC shortage situation is affecting our timeline. We will share more details in the update. As for the shipping address update @thomasflummer is correct. It can be changed in your crowd supply profile. 🙂
tomtastic has joined #glasgow
egg|anbo|egg has quit [Remote host closed the connection]
<electronic_eel>
@esden do you plan to stream today?
<d1b2>
<esden> Yes 👍 🙂 running bit late but still. I forget that you don’t see my #streaming posts here on discord 🙂
<electronic_eel>
you could bridge some more discord channels to irc ;)
<d1b2>
<esden> yeah no... you could also join discord 😛
<d1b2>
<esden> one is less trouble than the other for one of us...
mossmann has joined #glasgow
egg|anbo|egg has joined #glasgow
<d1b2>
<esden> It is time! "Electronics Let's Play Stream" is live! Join us! 🙂 https://www.twitch.tv/esden 🙂