<whitequark[cis]>
one potential solution is to use configuration "D" here
<d1b2>
<omnitechnomancer> Gotta have the asn.1 for all the implementation security vulns
<electronic_eel>
i'm not sure if we are making the communication between the python and the fx2 firmware more complicated when we add an extra endpoint that needs special length handling and stuff, while we still need the control endpoint for bitstream uploading and basics like reset
<whitequark[cis]>
bitstream uploading?
<whitequark[cis]>
no, I don't think I was clear enough: if we go EP1IN/EP1OUT route, all of the vendor specific USB requests will be removed
<whitequark[cis]>
so bitstream uploading will use it as well
<whitequark[cis]>
as for the reset, it will be integrated into Set Interface handling, with the FX2 automatically resetting FX2 by using the pin we currently use for FLAGD (which will go unused in this new configuration)
<whitequark[cis]>
so the FPGA won't have any I2C registers
<electronic_eel>
ok, so the limitation with 64 bytes you mentioned earlier doesn't exist with the buffer configuration scheme D
<whitequark[cis]>
correct
<whitequark[cis]>
with scheme D, we will be fully USB compliant
<whitequark[cis]>
however I'm not sure if scheme D allows hitting full USB2 throughput. this will need to be tested
<electronic_eel>
which scheme do we use now?
<whitequark[cis]>
right now we use one of the two options: A+A' or B+B'
<whitequark[cis]>
A+A' does not result in using the full USB2 throughput. B+B' does
<whitequark[cis]>
oh, wait
<whitequark[cis]>
Scheme D won't work since EP8 is unidirectional
<whitequark[cis]>
basically the only limitation with EP1IN/EP1OUT is that the host software must never queue a transfer bigger than 64 bytes
<whitequark[cis]>
instead of the normal situation where you can use transfers of, well, any size
<whitequark[cis]>
however, because we also have Set Interface for EP1IN/EP1OUT, this means that a half transmitted packet can be cleared (and will automatically be cleared) if e.g. host software crashes
<whitequark[cis]>
so I think EP1IN/EP1OUT solution justifies its complexity more than the EP0 solution does
<whitequark[cis]>
almost all of the FX2 pipe packets will be smaller than 64 bytes and require confirmation, so not being able to easily pipeline transfers isn't an issue; this will actually not have any performance downside compared to the current scheme at all
<electronic_eel>
so what advantage does the ep1in/ep1out have over the control endpoint?
<electronic_eel>
there are no access clashes on linux
<whitequark[cis]>
- it is not possible to have two applications transmit on it simultaneously on Linux
<whitequark[cis]>
- it is easy to recover from e.g. someone hitting ^C while firmware is loading
<whitequark[cis]>
basically, we know when the host application crashes if we go that route
<whitequark[cis]>
oh, there's another important one
<whitequark[cis]>
the FX2 can initiate transfers on EP1IN to report conditions such as alert
<whitequark[cis]>
so it's not necessary to e.g. poll it
<electronic_eel>
yeah, that is a good feature
<whitequark[cis]>
this is actually something I planned to make possible anyway by e.g. using EP1IN as an interrupt endpoint
<whitequark[cis]>
but it sending a packet would be way better
<electronic_eel>
so this sounds like a good idea to me - but i'm now getting really tired and i think i should go to sleep soon
<whitequark[cis]>
yeah, have a good rest
<whitequark[cis]>
I'll probably take a stab at implementing this
<electronic_eel>
you too - have a productive night :)
<whitequark[cis]>
thanks
<galibert[m]>
‘Night all
<whitequark[cis]>
oh, btw, should we recommend that people self-build revC3's now? cc esden
<sorear>
> universal test and operations physical interface for ATM (UTOPIA)
<whitequark[cis]>
horrifying
<sorear>
i'm guessing this is like (R)(G)MII?
<sorear>
do we have anything explaining what is and isn't in scope for clients not using the glasgow python stack?
<d1b2>
<esden> @whitequark I have to push a thing (i think it is just a meta data field change or something), then we can merge revC3 into main, and can recommend revC3 to build.
<d1b2>
<esden> Not near the machine with that right now.
<whitequark[cis]>
got it
<whitequark[cis]>
sorear: anyone not using the glasgow python stack is on their own
<sorear>
you mentioned a rust thing more than once
<whitequark[cis]>
that would be internal to Glasgow
<sorear>
so we will be shipping and using native code other than the system libusb at some point?
<whitequark[cis]>
this depends on how fast we can get Python to frame and unframe communications with the device
<whitequark[cis]>
I'm thinking of two potential uses for Rust:
<whitequark[cis]>
- speeding up framing code that's too slow in Python
<whitequark[cis]>
- exporting a Glasgow connected to USB as a TCP socket
<whitequark[cis]>
s/socket/server/
<whitequark[cis]>
the first one will happen whenever we can't hit USB 2 throughput with Python alone
<whitequark[cis]>
the second one doesn't strictly have to use Rust, but it's much cheaper to install a Rust binary on, say, a Raspberry Pi, that you may be using for remoting
<sorear>
i'm just thinking that if we are already planning to use rust for the framing, it might make sense to look more closely at options like byte escaping that would be non-starters in python
<whitequark[cis]>
broadly speaking I agree
<whitequark[cis]>
I'm thinking that the firmware could be made considerably smaller with one optimization for I2C
<whitequark[cis]>
basically, a tiny bytecode for I2C that's interpreted by a loop
<whitequark[cis]>
instead of a ton of calls to i2c_* and jumps
<whitequark[cis]>
anyway, we don't have to build that unless we really run out of firmware space
<whitequark[cis]>
and then that would be turned into a bunch of literal stores into the paged data area
_whitelogger 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
<d1b2>
<esden> @whitequark should glasgow not return with a value != 0 if no device is found? I am getting a 0 return from factory when no glasgow is connected
<whitequark[cis]>
esden: factory is weird...
<whitequark[cis]>
let me just fix that
<whitequark[cis]>
oh that's just a typo
<d1b2>
<esden> Thank you. I am just trying to run it in a loop and "do stuff" when it succeeds (audio cue in this case)
<d1b2>
<esden> @whitequark I am putting the scripts for the different steps right now. factory is working now it seems. 🙂
<d1b2>
<esden> next, is flash and IO test and led blinker. Then last but not least the serial number sticker generation. (I rather do that in 3 distinct steps... for now and streamline as we go)
<d1b2>
<esden> ok, selftest when it fails also returns 0 it seems?
<d1b2>
<esden> I mean it returns 0 if it finds a device but one of the tests fails.
<whitequark[cis]>
think so
<whitequark[cis]>
that would be a more substantial modification
<d1b2>
<esden> ok, I guess I can do some grep magic to check if there is an error or not. But it would be nice to get an expected return in the future.
<d1b2>
<thestumbler> Congrats on the news shared in the Crowd Supply product update. It’s been so long since I ordered (Feb 2021), I can’t remember if I was an “early bird” or a regular supporter.
<d1b2>
<bob_twinkles> You can check on CS (it will say "early bird" in the name of the product if you are I believe) but feb2021 is almost certainly not
<d1b2>
<bob_twinkles> (for reference I ordered in 2019 or early 202 and I'm not =P)
redstarcomrade has joined #glasgow
<d1b2>
<thestumbler> Thanks. I see a label that says "pre-order" Guess I'm in that Feb 2024 batch. Looking forward to it regardless.
<Wanda[cis]>
also, what is the AUX connector for? we've been wondering about this for ages (and don't see any explanation on the CS page)
<whitequark[cis]>
some people REALLY hate leaving unused FPGA balls uncnnected
<whitequark[cis]>
there were two left
<whitequark[cis]>
(+ ground)
<Wanda[cis]>
oh.
<Wanda[cis]>
yeah, that explains it
<whitequark[cis]>
yea you can just do whatever with them lol
<Wanda[cis]>
it's raw FPGA connection like the LVDS pins, right?
bvernoux has quit [Read error: Connection reset by peer]
<d1b2>
<perigoso.> I think such predictions would do more harm than good
<cyborgar>
based on past data all we know that until the boards are all packed and sent to mouser's warehouse the delivery date is anyone's guess :)
TT[m]1 has joined #glasgow
ar-jan has joined #glasgow
redstarcomrade has joined #glasgow
redstarcomrade has quit [Changing host]
redstarcomrade has joined #glasgow
redstarcomrade has quit [Read error: Connection reset by peer]
<d1b2>
<esden> @cyborgar that is indeed a good attitude. This is why I am reluctant to provide delivery dates. There is so much that can always go wrong along the way. I will feel more confident and better over all when all those glasgows are shipped to mouser. (just remember mouser tends to take a few weeks to ship things they received on their dock...)
<d1b2>
<esden> @adaisdead Yes, we have to send around 1500 Glasgows and 1000 cases to fulfill the backers, and another 1k Glasgows and 700 cases for pre-orders.
<d1b2>
<esden> but you can't predict when you will get your board based on that
rcombs has joined #glasgow
<d1b2>
<esden> The best thing is to relax, lean back, and just wait, be pleasantly surprised when a package get's delivered. 😄 (That is what I do with everything I back myself)
<d1b2>
<nemanjan00> It is hard to predict customs delays alone, with stuff that is already shipped
<d1b2>
<nemanjan00> Here in Serbia, it can take up to 20 days, for example
<d1b2>
<esden> yes, indeed, "domestic" (USA) orders are variable 2-5 days ... international orders more like 2-4weeks? International post works in mysterious ways... and I hate it. 😦
<d1b2>
<esden> I recently had someone in Australia, that made me refund their order because the package did not arrive in 3 weeks... it took another 2 weeks and the package was eventually delivered... :/
<d1b2>
<nemanjan00> In my case, I hoped to use it as a part of project, for talk, but i think I will switch to samething I can procure faster and something that has protocol I need already implemented
<d1b2>
<esden> I am sorry it is taking so long, I wish you could use Glasgow for your project 😦
<d1b2>
<nemanjan00> It is not a huge part of project, just wiegand logger and emulator, so I will manage just fine without it 😃
<d1b2>
<esden> 👍
whitequark[cis] has quit [Quit: Bridge terminating on SIGTERM]
TT[m]1 has quit [Quit: Bridge terminating on SIGTERM]
_catircservices has quit [Quit: Bridge terminating on SIGTERM]
jevinskie[m] has quit [Quit: Bridge terminating on SIGTERM]
RobTaylor[m] has quit [Quit: Bridge terminating on SIGTERM]
esden[cis] has quit [Quit: Bridge terminating on SIGTERM]
wifasoi[m]1 has quit [Quit: Bridge terminating on SIGTERM]
ericr[m] has quit [Quit: Bridge terminating on SIGTERM]
Wanda[cis] has quit [Quit: Bridge terminating on SIGTERM]
Chips4MakersakaS has quit [Quit: Bridge terminating on SIGTERM]
galibert[m] has quit [Quit: Bridge terminating on SIGTERM]
charlottia has quit [Quit: Bridge terminating on SIGTERM]
sszilvasi[m] has quit [Quit: Bridge terminating on SIGTERM]
bboett[m] has quit [Quit: Bridge terminating on SIGTERM]
_catircservices has joined #glasgow
whitequark[cis] has joined #glasgow
Wanda[cis] has joined #glasgow
galibert[m] has joined #glasgow
RobTaylor[m] has joined #glasgow
charlottia has joined #glasgow
esden[cis] has joined #glasgow
Chips4MakersakaS has joined #glasgow
wifasoi[m]1 has joined #glasgow
sszilvasi[m] has joined #glasgow
jevinskie[m] has joined #glasgow
bboett[m] has joined #glasgow
ericr[m] has joined #glasgow
TT[m]1 has joined #glasgow
<d1b2>
<josuah_dem> I think that if I received mine to day, I'd be excited and poke at it, but it would stay on the desk taunting me until I gather enough time to give it a real go.
<d1b2>
<esden> Yeah the far row is not visible very well...
<d1b2>
<vegard_e> enable output on a single pin at a time and leave the rest as input with pullup or pulldown, then sample all pins for the expected return, open pin shows up as no change and short shows up as changes on pins that shouldn't, and as long as you don't pick adjacent pins for the loopback, it can't mask a short
<d1b2>
<vegard_e> the orbtrace testsuite works in this manner, but there I've got the extra challenge that I've got the same signals on three different connectors and want to test all of them, so what I ended up with there is different loopback patterns on each connector, effectively making three groups that still satisfy the requirement that no pins in a group are adjacent
<d1b2>
<vegard_e> when you've got point to point signals to a single connector, you can just wire one half to the other half, taking care that you're not looping the middle adjacent pins back
<sorear>
"open" is tricky because it's not a binary condition - the pin exists and is driving a ball, at least, since the FPGA was factory tested, but depending on the board condition the pin could be driving a quite variable amount of trace, with or without the level shifter, pulls, or ESD diodes
<whitequark[cis]>
vegard_e: yeah we know how to implement this
<whitequark[cis]>
it's just that I got much more disabled while revC was being developed
<d1b2>
<vegard_e> ah, I'm not sure if the reference to the message I replied to came across the bridge
<Wanda[cis]>
it did not
<d1b2>
<vegard_e> sorry, I forgot this was a bridged channel, that was a response to something @esden said yesterday
<d1b2>
<esden> It was something I said in regards to the lvds loopback connector idea from electronic_eel