<grazianom[m]>
how easy is it to learn on shape from fusion? I put a lot of hours in the past year learning fusion 🙂 and it seems to have by far the best learning resources
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #glasgow
owoday[m]1 has joined #glasgow
<owoday[m]1>
hey I need a sanity check
<owoday[m]1>
the tty for the uart applet is spawned in the same terminal right?
<owoday[m]1>
I dont get any echo or anything, thats my connection right?
alephbias[m] has quit [Quit: Bridge terminating on SIGTERM]
whitequark[cis]1 has quit [Quit: Bridge terminating on SIGTERM]
_catircservices has quit [Quit: Bridge terminating on SIGTERM]
wiebel[m] has quit [Quit: Bridge terminating on SIGTERM]
fishmonger[m] has quit [Quit: Bridge terminating on SIGTERM]
Jarrett[m] has quit [Quit: Bridge terminating on SIGTERM]
owoday[m]1 has quit [Client Quit]
sigstoat[m] has quit [Quit: Bridge terminating on SIGTERM]
grazianom[m] has quit [Quit: Bridge terminating on SIGTERM]
_catircservices has joined #glasgow
whitequark[cis] has joined #glasgow
<whitequark[cis]>
try connecting RX to TX
<whitequark[cis]>
yeah
owoday[m]1 has joined #glasgow
<owoday[m]1>
like, glasgow to glasgow?
<whitequark[cis]>
itself to itself
<owoday[m]1>
hmm
<owoday[m]1>
still no echo
<whitequark[cis]>
weird
<whitequark[cis]>
which platform?
<owoday[m]1>
not sure how to answer
<owoday[m]1>
pypy3 with glasgow on linux using default uart applet
<owoday[m]1>
there that should do it
<whitequark[cis]>
that's weird
<whitequark[cis]>
what if you run glasgow -vv; does that show data being sent at least?
<owoday[m]1>
seems to
<whitequark[cis]>
but not received?
<whitequark[cis]>
can you show the log?
<owoday[m]1>
sec
<owoday[m]1>
bpa.st/4CUQ
Jarrett[m] has joined #glasgow
<Jarrett[m]>
graziano.m (@_discord_119160277555085314:catircservices.org) similar workflow, not too hard to switch over
<Jarrett[m]>
same kind of parametric CAD. And bonus, you'll get used to the slightly different quirks, which will also help you be faster at picking up SolidWorks, or any other parametric CAD down the line.
<owoday[m]1>
<owoday[m]1> "bpa.st/4CUQ" <- aw fuck?
<owoday[m]1>
s is a pin?
<owoday[m]1>
me stupid?
<whitequark[cis]>
S is the sync port
<whitequark[cis]>
but I don't see you using it?
<whitequark[cis]>
wait
<owoday[m]1>
like physically lol
<owoday[m]1>
sorry
<whitequark[cis]>
ah
<owoday[m]1>
thanks for helping
<owoday[m]1>
also thanks for making cool device
<whitequark[cis]>
you're welcome :3
<whitequark[cis]>
i'm glad you like it
<owoday[m]1>
:)
bvernoux has joined #glasgow
redstarcomrade has quit [Read error: Connection reset by peer]
<hcsch>
How would I best write simulation tests for a 24-series EEPROM emulator? I feel like stapling together the I2CInitiatorApplet with the 24-serier emulator applet somehow is probably the nicest so I can issue reads/writes via the I2CInitiatorInterface instead of fiddling with the lower level I2CInitiator gateware directly. I want to upstream the 24-series emulator, but it needs some more testing and probably
<hcsch>
some fixes after that
<whitequark[cis]>
we have I2CInitiator and I2CTarget tested already, right? I would probably mock the lower levels of both (i.e. not involve the gateware) since the primary source of complexity is the protocol parsing
<whitequark[cis]>
running gateware tests has significant overhead (both in terms of runtime, but they're also written in a deprecated subset of amaranth.sim so they're a pain to maintain)
<whitequark[cis]>
ideally we would have them be easy but right now the situation is simply not that
<hcsch>
> we have I2CInitiator and I2CTarget tested already, right? I would probably mock the lower levels of both (i.e. not involve the gateware) since the primary source of complexity is the protocol parsing
<hcsch>
I may have missed something, but in the main branch they only have assertBuilds tests
<whitequark[cis]>
the improvements to amaranth.sim were in no small part motivated by this difficulty, so it's kind of a necessary element of Glasgow's legacy...
<whitequark[cis]>
no, that sounds right
<whitequark[cis]>
the gateware is tested by ... well, at this point multiple people have taped it out as an ASIC (both of them IIRC) so I'd say they are pretty well tested :D
Wanda[cis] has joined #glasgow
<Wanda[cis]>
it is actually tested
<Wanda[cis]>
software/tests/gateware/test_i2c.py
<whitequark[cis]>
oh, right, we have it in glasgow.gateware.i2c, I forgot
<hcsch>
Ah nice, I had missed that indeed
<hcsch>
> we have I2CInitiator and I2CTarget tested already, right? I would probably mock the lower levels of both (i.e. not involve the gateware) since the primary source of complexity is the protocol parsing
<hcsch>
Do you perhaps have an example of such mock based testing handy? I'm not quite sure how I would go about that. For reference, I built the 24-series emulator directly around the I2CTarget gateware, not the I2CTarget applet, because I was having some issues with clock stretching and getting reads other than 0xFF to work while testing with a friend. Reads with the MSB set other than 0xFF were causing some prob
<hcsch>
lems for us. Will have to debug that again tho, so I can actually tell you what happened
<whitequark[cis]>
ohh, I see
<whitequark[cis]>
take a look at the UART gateware
<whitequark[cis]>
yes, that would indeed be easiest to test by stapling some gateware together
<whitequark[cis]>
clock stretching is an issue I've encountered and it is in fact why there is no in-tree 24-series EEPROM emulator in-tree
<whitequark[cis]>
(the description of the i2c-target applet alludes to that)
<hcsch>
Yeah, we weren't entirely certain whether that was the issue, since 0xFF reads seemed to work with the arduino we had attached, but it may well have just been that
<hcsch>
> take a look at the UART gateware
<hcsch>
I had a look at the loopback test and was planing on cobbling together something with the I2CInitiator gateware. Just wanted to ask around to see if I can avoid duplicating some code from the I2CInitiatorApplet, because I didn't see an easy way to connect the I2CInitiatorInterface with working fifos, so I can have a "setup_initiator" method and afterwards just push some bytes into some fifos, instead of wri
<hcsch>
ting state machines for each test case.
<hcsch>
Perhaps I just need to look around a bit more in the test_i2c.py and/or try and manually set up the I2CInitiatorInterface without the applet
<whitequark[cis]>
honestly that whole part of the project is very under-developed so if you're hitting papercuts or issues with it it won't surprise me
<hcsch>
That's alright, then I'll just continue poking around until something works ^^
<hcsch>
Thanks for the hints and for working on the glasgow in general :)
<whitequark[cis]>
you're welcome!
grazianom[m] has joined #glasgow
<grazianom[m]>
Why is it that the swd applet uses the bitbang protocol between openocd and the socket? Couldn't it emulate something much much faster? It takes multiple seconds to step one instruction
<whitequark[cis]>
are you using an option like --freq 4000 yet?
<whitequark[cis]>
but yes, it's known to be inefficient; this is mainly because when I attempted to build SWD on revB, I had to make revC since the level shifters on revB were completely unusable for it
<whitequark[cis]>
and then when I tried to build SWD again on revC I completely burned out on life and didn't finish it
<whitequark[cis]>
I do want to build a probe-rs backend for Glasgow at some point
<whitequark[cis]>
but merging even very simple PRs to openocd has proved to take quite a long time so I think I'm okay with not having first-class openocd support
<grazianom[m]>
I can relate
<grazianom[m]>
Yeah I have like 3 forks locally for different devices
<grazianom[m]>
Nope! That might have saved me a ton of time
FFY00_ has quit [Read error: Connection reset by peer]
FFY00_ has joined #glasgow
bartdewaal[m] has joined #glasgow
<bartdewaal[m]>
How do I run an applet without reinstalling glasgow? Right now I'm running "pipx reinstall glasgow" for every change, but I doubt that's optimal