<get0rix[m]>
Oh whitequark (@_discord_182174208896401419:catircservices.org) I am so sorry posting in a wrong channel as well, I will move post in addons 😦
<whitequark[cis]>
errr what
<whitequark[cis]>
no this is the right channel
<get0rix[m]>
I was told applets are discussed in glasgow-addons
<jn>
get0rix[m]: i think you need an iface.flush() there
<whitequark[cis]>
that is not true
<whitequark[cis]>
the addon channel is a weird side channel i'm not even in, i think it mostly confuses people
<whitequark[cis]>
no one asked me when creating it
<get0rix[m]>
ouch! thanks for letting me know! ok returning post, and gonna try flush
<get0rix[m]>
OMG works! Now when you pointed out to the issue it make perfect sense. Silly me 😄
<get0rix[m]>
Thanks you!
<whitequark[cis]>
generally the channel isn't nearly big or intense enough to partition it
<whitequark[cis]>
i think maybe the other one was originally 1b2-specific or something?
<get0rix[m]>
I am happy to post my silly questions here if everyone is ok with that 🙂
<get0rix[m]>
Btw, is there a way to control LED brightness, or it is hardcoded?
GNUmoon2 has quit [Remote host closed the connection]
GNUmoon2 has joined #glasgow
esden[m] has joined #glasgow
<esden[m]>
I made the addons channel a long time ago, because it was useful back then. I have now made it read only and archived it. So it should remove the confusion.
<esden[m]>
get0rix (@_discord_615646826862870651:catircservices.org) there is no way to control the led brightness besides sticking some tape over them or replacing the dropper resistors 😉
<get0rix[m]>
Using Glasgow since 2019 (GregD built prototype for me) and all the time I was constantly impressed by this device. Especially now with beautiful case and built-in toolchain - works like charm, absolute magic 😍
omnitechnomancer has joined #glasgow
<omnitechnomancer>
Presumably one could try to PWM in gateware for the FPGA attached ones?
redstarcomrade has joined #glasgow
sorear has quit [Ping timeout: 240 seconds]
sorear has joined #glasgow
<esden[m]>
Yeah sure, those could work. I bet the issue is with the white led for the FX2... it was mentioned before that it is too bright.
<get0rix[m]>
Nah, I was actually talking about brightness of User LEDs. Cause when you power Glasgow they are actually only half as bright from when you control them using applet 🤷♂️
<get0rix[m]>
s/from/as/
<get0rix[m]>
* Nah, I was actually talking about brightness of FPGA controlled User LEDs. Cause when you power Glasgow they are actually only half as bright as when you control them using applet 🤷♂️
notgull has joined #glasgow
notgull has quit [Ping timeout: 256 seconds]
redstarcomrade has quit [Read error: Connection reset by peer]
<omnitechnomancer>
That is the default pull-ups on the pins when the FPGA is unconfigured afaik
redstarcomrade has joined #glasgow
josHua[m] has joined #glasgow
<josHua[m]>
seems solvable with the pad pull register and the OE pin then!
<get0rix[m]>
hm, interesting. Any volontiers for an example? 😄
<get0rix[m]>
* hm, interesting. Any volontiers for an example? 😄
<get0rix[m]>
All I can think if - probably `self.device.set_pulls()` is involved, but it seems designed to work with "pin" pins, not "led" pins 🤨
<get0rix[m]>
* hm, interesting. Any volontiers for an example? 😄
<get0rix[m]>
All I can think of - probably `self.device.set_pulls()` is involved, but it seems designed to work with "pin" pins, not "led" pins 🤨
redstarcomrade has quit [Read error: Connection reset by peer]
<get0rix[m]>
* hm, interesting. Any volontiers for an example? 😄
<get0rix[m]>
All I can think of - probably `self.device.set_pulls()` is involved, but it seems designed to work with "port" pins, not "led" pins 🤨
<get0rix[m]>
Yep, I am messing with multiple applets as well, pushing the limits...
<get0rix[m]>
* as well, and it works, just pushing the
<get0rix[m]>
s/the/that/
<whitequark[cis]>
<esden[m]> "I made the addons channel a long..." <- thanks!
<jn>
get0rix[m]: so, if you want to access this default brightness, i suppose you can disable the output-endable signal on the LEDs
<jn>
s/endable/enable/
<jn>
i.e. led.oe.eq(0)
<get0rix[m]>
thanks, lemme try
<get0rix[m]>
ok, there is not output enable in hw definition for led it seems, only for ports 😦
<get0rix[m]>
s/not/no/
<whitequark[cis]>
there is not one in hardware
<jn>
oh, interesting
<whitequark[cis]>
well, sorry, let me rephrase
<whitequark[cis]>
the main connectors have *two* output enables
<whitequark[cis]>
the leds have one, and it's implicit. also the pullup can be only turned on or off for the entire bitstream, it's build time controllable only
<jn>
ah well. i guess that only leaves PWM for fine-grained brightness control
gatecat[m] has joined #glasgow
<gatecat[m]>
you could switch between outputting 0 and tristate with pullup
<whitequark[cis]>
that is true
<whitequark[cis]>
pwm is less hassle tho
<gatecat[m]>
yeah
<get0rix[m]>
ok, got it thanks, should not be hard to turn my blinky into PWM for LED 😄
<get0rix[m]>
There we go, USER LED applet with pwm brightness control (as run arg) 😎
<whitequark[cis]>
neat
jmi2k[m] has joined #glasgow
<jmi2k[m]>
Hello people! I've known about this project since a long time ago but never really paid attention to it until now.
<jmi2k[m]>
I've seen it can be used as a logic analyzer, so I wonder... What are its specs for that task? I've tried looking for figures but came empty-handed.
<get0rix[m]>
whitequark (@_discord_182174208896401419:catircservices.org) one question though, I used reg_rw to control brigheness, during build I get address and save it to self.brightness. but unless I print it, in script I have no way to get this value. What is the proper practice to access register address from script context?
<get0rix[m]>
* whitequark (@_discord_182174208896401419:catircservices.org) one question though, I used add_rw to control brightness, during build I get address and save it to self.brightness (got from other applets). However, unless I print it to console, in `glasgow script` I have no way to get this value. What is the proper practice to access register address from script context?
<whitequark[cis]>
create an Interface+Subtarget subclass pair and encapsulate register access into it
<get0rix[m]>
ah, custom class, I see
<jn>
jmi2k[m]: hi, welcome!
<get0rix[m]>
* ah, custom wrapper class, I
<jmi2k[m]>
Hello! I assume you're talking from IRC? Sorry, I'm not used to IRC bridges and it always takes a few seconds to understand why a bot is talking to me haha
<jn>
yes indeed, i'm bridged in from the IRC side. the glasgow chat spans three different platforms, i think: IRC, Matrix, Discord
<whitequark[cis]>
jn is on irc, jmi2k is on discord, i'm on matrix (which is squeezed in between these two)
<jmi2k[m]>
neat, networks are lovely aren't they? haha
<whitequark[cis]>
it is actually a real pain to set up and maintain
<jmi2k[m]>
well, basically I stumbled upon the Glasgow Interface Explorer after forgetting about it like a year or two ago, and during that time I've experienced the need of something like it (basically "I need something that lets me interface SPI/UART/raw IO/whatever" in a matter of minutes) and well, who could've guessed, that exists as an open source project!
<jmi2k[m]>
Also now I remember the original reason I follow you on twitter lol
<jn>
it's neat, especially for prototyping or if you need voltages other than 5V or 3.3V
<jn>
jmi2k[m]: about the logic analyzer applet, in my (limited) experience it can quickly fill up the FIFO buffer and then stop working, with current gateware/software
<jmi2k[m]>
what could I expect from it as a logic analyzer? I mean, it's by far cheaper than the other two alternatives my coworkers suggested (cheaper than the Digital Discovery and _far cheaper_ than whatever Saleae has to offer) so even if it performs worse I'd be more than glad to give it an opportunity (more so considering the other stuff I need and it does)
<whitequark[cis]>
it doesn't have a lot of onboard RAM so the effective throughput is limited by however quickly your PC can poll USB
<whitequark[cis]>
and how consistently, which is actually more important (spikes in latency basically kill the capture)
<whitequark[cis]>
there's an expansion option for RAM that's currently in beta testing that will fix that issue
<whitequark[cis]>
I think what'll probably be most limiting for you is the fairly immature state of the frontend (the software you'd interact with)
<jn>
the RAM pack will also enable some other shenanigans :)
<jmi2k[m]>
well, sounds reasonable (I was also surprised because I saw no RAM in the block diagram)
<jn>
the FPGA has some built-in RAM
<jmi2k[m]>
btw before proceeding: if I reply to messages does it get properly communicate to you all external users? or should I prefix my replies with a quote or something?
<whitequark[cis]>
for most digital interfaces, the USB FIFO buffers provide sufficient capacity/latency/etc, for most use cases
<whitequark[cis]>
try doing a reply-to to this message
<jn>
wait, where are the USB FIFOs located, are they in the FX2?
<whitequark[cis]>
jn: both FX2 and FPGA
<jmi2k[m]>
testing 🙂
<whitequark[cis]>
jmi2k: prefix with a quote
<jn>
the "testing" message renders without any indication of a reply, on the IRC side
<whitequark[cis]>
jn: the FPGA FIFO can be thought of as the extension of the FX2 FIFO for most purposes
<whitequark[cis]>
jmi2k: 18KB iirc
<jn>
the new RAM extension would bring 32 MiB, as far as i remember seeing in the WIP schematics
wheresheisnt[m] has joined #glasgow
<wheresheisnt[m]>
Is it possible to do differential output from the buffered Glasgow I/O? (Not the expansion header, I’m aware those pins are LVDS-capable)
<jmi2k[m]>
> I think what'll probably be most limiting for you is the fairly immature state of the frontend (the software you'd interact with)
<jmi2k[m]>
Honestly I wouldn't mind this too much. I'm no pro user, tinkering is part of the fun, and I would rather support an open-source project with an improvement roadmap than pay much more money for a finished product
<whitequark[cis]>
wheresheisnt: it is possible to take a pair of CMOS output pins and convert them to a differential standard using some amount of passives
<whitequark[cis]>
this is true in general, not just for glasgow
<wheresheisnt[m]>
Thank you !
<whitequark[cis]>
actually, this is the only way ice40 can do differential output, even on the LVDS header
<jmi2k[m]>
so I assume the sample rate would be "whatever my PC can take from the USB port"?
<wheresheisnt[m]>
I’ll do some more reading then!
<whitequark[cis]>
jmi2k: sorta? it's limited by both the gateware and the USB throughput
<whitequark[cis]>
the gateware by default runs at 48 MHz in revC, so you could easily reach 96 Msps with a DDR input register
<whitequark[cis]>
generally you can easily upload ~300 Mbps via USB, but there's a catch: latency spikes
<whitequark[cis]>
unless you teach your LA how to represent missing capture intervals (which we really should) or give it a RAM controller (which we really should), just half a microsecond where the host controller doesn't poll USB for whatever reason can break your capture if you do it at 300 Mbps
<whitequark[cis]>
so you need to be really, absolutely certain that the host controller would poll the device as thoroughly as it is achievable on your system. and even then if you like, run chrome or something, it's entirely possible it'll bog down your CPU enough that you'll still miss that latency target
<whitequark[cis]>
you could also do compression, which we currently do, but that has its own flaws and difficulties
<jmi2k[m]>
For now I doubt I will reach those limits. I'll keep things simple for now.
<jmi2k[m]>
I rarely hog the computer while working on electronics stuff, and worst-case scenario I can just plug it to my server and run everything from there (that one is barely underutilized)
<tpw_rules>
it's still not a great user experience for these reasons. even if you don't try to push it it will just get unhappy and die
<tpw_rules>
maybe i have a below average setup but for logic analysis i would personally not recommend glasgow. all the decoding stuff is fantastic though
<whitequark[cis]>
yeah the logic analyzer is currently very much an afterthought, it basically only exists because "well obviously glasgow should be able to be a logic analyzer"
<whitequark[cis]>
and yes, it should, but actually building a great logic analyzer within the constraints is surprisingly difficult
<whitequark[cis]>
plus when i wrote the gateware backing it, i was pretty inexperienced
<jmi2k[m]>
One last question: I've seen the plans for a revD. Is it coming up anytime "soon" (2024-2025)? I would gladly wait for it.
<jmi2k[m]>
I've read the README message so no pressure implied at all 🙂
<whitequark[cis]>
it will come when it is done
* whitequark[cis]
is pondering adopting the teamhacksung's policy of "no ETA"
<ari>
"ETA WEN" ;)
* whitequark[cis]
* is pondering adopting the teamhacksung policy of "no ETA"
<tpw_rules>
asahi's each ask bumps it out by one month
<whitequark[cis]>
nice
<whitequark[cis]>
i'm also partial to "it costs $50 to get an ETA"
<whitequark[cis]>
each time you want it updated it costs $25 more
<jmi2k[m]>
did my request come as disrespectful? I sincerely had no ill intention, but maybe it was a bit insensitive from my side
galibert[m] has joined #glasgow
<galibert[m]>
jmi2k: not only they are still fulfilling the orders they have, but they need more feedback from users of the current version to be certain on where to go
<galibert[m]>
Plus the semiconductor market is still a mess afaict
<whitequark[cis]>
jmi2k: this isn't personal, it's just that none of us here except for esden are working on glasgow as a job
<whitequark[cis]>
and it is tradition in complex software/hardware porting/hacking projects, especially the more open ones, to dissuade people from asking about ETAs (because it is a completely meaningless act)
<whitequark[cis]>
like, it could result in either literally nothing or creating pressure
<jmi2k[m]>
yeah I totally understand, completely reasonable
<jmi2k[m]>
well, thanks a lot for answering my questions!
<whitequark[cis]>
you're welcome
<whitequark[cis]>
<galibert[m]> "jmi2k: not only they are still..." <- are you thinking of some specific unresolved revD questions?
redstarcomrade has joined #glasgow
redstarcomrade has quit [Changing host]
redstarcomrade has joined #glasgow
redstarcomrade has quit [Read error: Connection reset by peer]
<esden[m]>
It is interesting how even a vague mention of a potential long term plan for a newer version of a hardware results in an Osborne effect... even if that is years out...
benny2366[m] has joined #glasgow
<benny2366[m]>
begs the question why you should ever mention it , besids transparancy etc
<esden[m]>
I mean, we need to do some planning and it makes sense to write the ideas down...
GNUmoon2 has quit [Ping timeout: 260 seconds]
<benny2366[m]>
true , but not publicly is what i meant
<whitequark[cis]>
from this i can infer that many customers aren't interested in solving problems but rather they want to have a cool toy sitting on the shelf
<whitequark[cis]>
which coincidentally may or may not solve some hypothetical problem they may have
GNUmoon2 has joined #glasgow
<whitequark[cis]>
since if you are solving a problem you typically want all the capacity you can get yesterday
<esden[m]>
Right... I think it will be bit better when the hardware is finally just in stock and can be ordered for shipping today ...
<esden[m]>
People still like to theorize how cool it would be if they had this hypothetical future hardware... but will get what is available right now to just get things done ...
<esden[m]>
At least that is the case for my other hardware projects...
<esden[m]>
Can't wait to have Glasgow reach that same availability spot... *sigh*
<whitequark[cis]>
don't we all
<whitequark[cis]>
well, at least Amaranth has greatly increased in maturity in the years since, to the point where by the time of general availability i might have some spare cycles for writing Glasgow docs
<benny2366[m]>
btw now i think of it what is the diffrence between glasgow and a bus pirate? i asume the speed?
<whitequark[cis]>
bus pirate isn't really field programmable
<whitequark[cis]>
its use model is fixed function hardware with multiple functions
<whitequark[cis]>
you can't even set the pins you want to use, iirc?
<whitequark[cis]>
a lot of that is actually simply due to software, i.e. if somebody made a FOSS CPLD toolchain that could be lifted potentially, modulo EEPROM durability which is usually high enough to not care
<benny2366[m]>
idk never used one so idk sorry
Eli2_ has joined #glasgow
helene_ has joined #glasgow
dfriehs_ has joined #glasgow
<esden[m]>
SBTW... we should be hearing from the next set of people that they are getting their Glasgows this week. The last shipment that went out arrived at Mouser last Thursday, and should be processed for fulfillment this week.
<omnitechnomancer>
I'm pretty sure the Bus Pirate is a PIC you talk to and does things
<whitequark[cis]>
omnitechnomancer: iirc it had an XC9532XL CPLD?
<whitequark[cis]>
s/XC9532XL/XC9536XL/
<whitequark[cis]>
ohhhhh that was Bus Blaster
nyaanotech has joined #glasgow
<whitequark[cis]>
ok yeah bus pirate is just a completely different product with a mild overlap in use cases
helene has quit [Ping timeout: 268 seconds]
josuah has quit [Ping timeout: 268 seconds]
dfriehs has quit [Ping timeout: 268 seconds]
Eli2 has quit [Read error: Connection reset by peer]
nyanotech has quit [Ping timeout: 268 seconds]
helene_ is now known as helene
dfriehs_ is now known as dfriehs
<omnitechnomancer>
For current use I think something like tigard or other FTDI + level shifters is more useful than a Bus Pirate.
<whitequark[cis]>
ok so actually bus pirate v5 is vaguely similar to glasgow in some ways
<whitequark[cis]>
it's still a very different device but there's quantitatively more overlap in scope than "almost nothing" it was with bus pirate 3
<whitequark[cis]>
i guess it's just the general trend of hardware getting more and more programmable over time
<omnitechnomancer>
Ah the v5 is in an entirely different place too
<whitequark[cis]>
yea the v5 is a radically different design
<whitequark[cis]>
and it looks like they went through the ice40 stage, and may have even taken inspiration from glasgow?
<omnitechnomancer>
From what I gleaned from a quick look its an rp2040 based thing now?
<whitequark[cis]>
i really dislike the landing page of https://docs.buspirate.com/, with the bland AI renders and bullshit-laden text
<whitequark[cis]>
yes
<omnitechnomancer>
yea being like 50% AI render by area doesn't help the website :/
<whitequark[cis]>
it's a shame, it's doing a disservice to what seems to be a cool product
<omnitechnomancer>
I much prefer the older wiki
icb[m] has joined #glasgow
<icb[m]>
They really seem to have lost the plot with version 5, with an enclosure full of superfluous RGB LEDs
<esden[m]>
I scrolled through the forum thread regarding the v5 design a while ago... and it was pretty much "let's put all the ideas from everyone into this"
<sorear>
I ordered one on the assumption that my hypothetical future self would have a concrete use for it, which seems less likely now than it did at the time (me issues, this is not a dig at the schedule)
<esden[m]>
At least this time they have someone who seems to know one or two things about firmware development do that part.
duskwuff[m] has joined #glasgow
<duskwuff[m]>
yeah, it gives the whole thing an unpleasant "probably a scam" vibe
<omnitechnomancer>
dusk: yes certainly, along with the general kind of empty feeling of the new website in that it feels kind of devoid of meaningful information as if it's mostly marketing fluff and buzzwords
<esden[m]>
@sorear you mean Glasgow? I hope it will come in useful at some point none the less...
<whitequark[cis]>
i think sorear means BPv5
<esden[m]>
ohh ok, still.. 🙂 But to be honest I personally do prefer the Glasgow REPL than the buspirate REPL... having full python power available is nice
<sorear>
Glasgow
<whitequark[cis]>
oh
<esden[m]>
@sorear you are not doing any hardware stuff any more?
<gruetzkopf>
my most complex setup would fit one glasgow -CD, but two -C is exactly as valid and what i'm currently doing (needs two channels of exactly 16 pins)
<whitequark[cis]>
what is -CD?
<gruetzkopf>
a typo. -D
<galibert[m]>
<whitequark[cis]> "are you thinking of some..." <- Nothing specific no
<gruetzkopf>
(talking on a propietary differential byte-parallel interconnect in railway signalling equipment with 7 control lines. leaves one for the receive/transmit select on the RS485 drivers.
<whitequark[cis]>
neat
GNUmoon2 has quit [Remote host closed the connection]
GNUmoon2 has joined #glasgow
bvernoux has quit [Quit: Leaving]
jstein has joined #glasgow
notgull has joined #glasgow
Attie[m] has joined #glasgow
<Attie[m]>
I'm going more glasgow-as-a-sig-gen
<Attie[m]>
(i really need to get a better sig-gen)
<Attie[m]>
this time ~62.5 MHz into a FET driver with a powerful-ish laser hanging off the back
<tpw_rules>
sounds like a party
<Attie[m]>
😂
<whitequark[cis]>
Attie[m]: nice
<whitequark[cis]>
the lvc1t devices are really quite incredible
<Attie[m]>
yeah, it's going a good job
<Attie[m]>
struggling a bit into a 100 Ohm load, but ehh...
<Attie[m]>
i'm currently waiting to see if the "laser alignment issues" i was having were actually "FET driver cooked itself and shutdown"
<Attie[m]>
but it doesn't look super likely at the moment
<whitequark[cis]>
Attie[m]: could always parallel a bunch of pins
<Attie[m]>
yeah, i was wondering about doing that
<whitequark[cis]>
it works very well
<Attie[m]>
i'll do it if i turn to this applet more regularly going forward
notgull has quit [Ping timeout: 272 seconds]
<get0rix[m]>
For me Glasgow is far more versatile than BP5 and obviously has more potential, especially if you can do HDL 🙂 Thought have to admit that sometimes BP5 is a bit more convenient exactly beacause it doesn't need to be reprogrammed when you switch from UART to SPI to I2C in a field. However, it is very important to note that Glasgow is also capable of holding multiple applets, just two for now, but there is a proposal from Catherine
<get0rix[m]>
already to remove this limitation. And when this happen I honestly see no reason to use pirate as soon as you have enought LUTs in FPGA for your applets 😄
<get0rix[m]>
* For me Glasgow is far more versatile than BP5 and obviously has more potential, especially if you can do HDL 🙂 Thought have to admit that sometimes BP5 is a bit more convenient exactly beacause it doesn't need to be reprogrammed when you switch from UART to SPI to I2C in a field. However, it is very important to note that Glasgow is also capable of holding multiple applets, just two for now, but there is a proposal from Catherine
<get0rix[m]>
already to remove this limitation. And when this happen I honestly see no reason to use pirate as soon as you have enought LUTs in FPGA for your applets 😄
<tpw_rules>
what do you mean in the field? won't you have a pc to view the output?
<get0rix[m]>
well, when it was old toolchain to build Glasgow, I once somehow broke it on my laptop on conference (tried to update and did stupid thing) before ctf. The choice was to try fixing it and waste time or use buspirate/hydrabus/etc (there was no BP5 back then). I mean yeah, it is corner case, but still.
<whitequark[cis]>
was that before or after the switch to pdm?
<icb[m]>
BusPirate might have a lower barrier to entry (though with YoWASP and large number of built-in applets that's debatable) might also has a much lower ceiling of ability
<get0rix[m]>
* but still. And you dont need PC exactly to deal with serial 🙂
<icb[m]>
s/might/it/
<whitequark[cis]>
pdm+yowasp are preeeetty difficult to break, especially as we have a known good lockfile checked in at all times
<get0rix[m]>
* but still. And you dont need PC exactly to deal with serial, even Android phone can do that I think 🙂
<whitequark[cis]>
like just cp pdm.min.lock pdm.lock then pdm install should basically always work
<tpw_rules>
(how would you get into a state where you even need to do that?)
<whitequark[cis]>
I have been considering offering glasgow software as an "appliance" or a single prebuilt binary but it's actually kind of hard to get a really polished experience with that, especially if you consider stupid shit like antimalware
<whitequark[cis]>
tpw_rules: idk. people seem to come up with real creative ways to break tools often
<get0rix[m]>
yeah, it was long ago when we had to configure formulas manually in brew, and there were conflics all over the place between nextpnr and other stuff. Remember I use glasgow since 2019 😄 Now there are 0 issues with toolchain I think.
<whitequark[cis]>
oh i see
<tpw_rules>
brew *shudder*
<whitequark[cis]>
yeah those were dark times
<whitequark[cis]>
yowasp was developed directly so that glasgow could have the built in toolchain
<get0rix[m]>
yeah, and it is awesome how it works now. Funny enough I spent more times messing with my terminal to try BP5 than I spent on setting up for glasgow following website instructions 😄
<get0rix[m]>
s/times/time/
<get0rix[m]>
* yeah, and it is awesome how it works now. Funny enough I spent more time messing with my terminal to try BP5 in color properly than I spent on setting up for glasgow following website instructions 😄
<get0rix[m]>
* yeah, and it is awesome how it works now. Funny enough I spent more time messing with my terminal to try BP5 in color properly than I spent on setting up mac for glasgow following website instructions 😄
<whitequark[cis]>
lol oops
<whitequark[cis]>
yeah, glasgow is very conservative in many of the actual tech choices
<whitequark[cis]>
python and asyncio aren't exactly bleeding edge
<whitequark[cis]>
though the latter definitely involves bleeding
<get0rix[m]>
also I remember why I loved glasgow from day one, cause all these BP and other tools they always had problems with usb drivers on mac back then, ftdi, silabs - pain in a ass. Glasgow just worked 😄
<get0rix[m]>
s/other/friends/, s/tools//
notgull has joined #glasgow
<whitequark[cis]>
oh huh
<whitequark[cis]>
i basically don't test on macs so that is fun to hear
<esden[m]>
I test all Glasgows on a Mac … 😉
<esden[m]>
I just happen to have the iMac in the shop where it was convenient to set up testing…
<whitequark[cis]>
right!
prop_head_mania[ has joined #glasgow
<prop_head_mania[>
I know , glasgow can measure digital signals , can it generate signals ? precise pulses , clocks
<whitequark[cis]>
yeah
<whitequark[cis]>
your timebase is a 48 MHz XO with something like 15 ppm of tolerance
<whitequark[cis]>
if you can live with that much precision it's good. you could also calibrate it further or use an external 12 MHz clock if you wanted a really accurate timebase for some reason
<whitequark[cis]>
* also calibrate (and compensate) it further
<whitequark[cis]>
actually it doesn't have to be 12 MHz, could be any clock between let's say about 20 and 100 MHz
<Attie[m]>
speaking of, I came across this earlier today... somewhat tempted!