richbridger has quit [Remote host closed the connection]
richbridger has joined #glasgow
<DX-MON>
yeah, my one piece of advice with Glasgow, yorick.. is to use the HEAD version of yosys, nextpnr and nMigen. There are just so many fixes and improvements that Glasgow is leveraging that aren't yet released, that it's not worth not doing. Also, the community aims to keep those HEAD versions fairly stable.
d_olex has quit [Remote host closed the connection]
aquijoule_ has joined #glasgow
richbridger has quit [Ping timeout: 265 seconds]
electronic_eel has quit [Ping timeout: 240 seconds]
electronic_eel has joined #glasgow
FFY00 has quit [Remote host closed the connection]
FFY00 has joined #glasgow
jstein has quit [Quit: quit]
GNUmoon has joined #glasgow
ShoXer has joined #glasgow
FFY00 has quit [Remote host closed the connection]
ShoXer has left #glasgow [#glasgow]
FFY00 has joined #glasgow
PyroPeter_ has joined #glasgow
PyroPeter has quit [Ping timeout: 246 seconds]
PyroPeter_ is now known as PyroPeter
FFY00 has quit [Remote host closed the connection]
FFY00 has joined #glasgow
egg|anbo|egg_ has joined #glasgow
egg|anbo|egg has quit [Ping timeout: 264 seconds]
GNUmoon has quit [Remote host closed the connection]
<hell__>
oO(bleeding edge Scots Army Knife)
GNUmoon has joined #glasgow
bvernoux has joined #glasgow
GNUmoon has quit [Remote host closed the connection]
<d1b2>
<Attie> thanks @electronic_eel! I was about to say the same... @esden is talking too! 🙂
<d1b2>
<Attie> (oh oops... i missed your mention of esden in the notification i saw...)
<apo>
conveniently, I'm already on that track anyway =P
<d1b2>
<fishmonger> Direct link to feed your VLC: https://stream.fosdem.org/dcad.m3u8 (but also open the chat link from the event link above to follow the discussion)
egg|anbo|egg has quit [Remote host closed the connection]
egg|anbo|egg has joined #glasgow
TimSmall has joined #glasgow
<d1b2>
<alen> @Attie @esden nice presentation
<d1b2>
<fishmonger> Yea. Well done!
egg|anbo|egg has quit [Remote host closed the connection]
shoragan[m] has joined #glasgow
konsgn has joined #glasgow
<konsgn>
On Irc?
<konsgn>
Annnd cut out.
<d1b2>
<fishmonger> And there the feed is killed. We shall never know what attie tried to show 🙂
<d1b2>
<konsgn> ohhhh, interesting bot.
<d1b2>
<konsgn> kinda weird being on both platforms at once.
<d1b2>
<fishmonger> https://chat.fosdem.org/#/room/#cad-glasgow:fosdem.org has the video now. Requested sign-in first time I tried, but worked on reload
<d1b2>
<konsgn> /join #electronics
egg|anbo|egg has joined #glasgow
Konsgnx has joined #glasgow
Konsgnx has quit [Remote host closed the connection]
<d1b2>
<Lambda> @Attie @esden Thanks for that great presentation and Q&A!
futarisIRCcloud has joined #glasgow
<ebb>
Seconded, I thought that was great both as a showcase and a technical talk on the byte-blasting side of how it all works
<d1b2>
<esden> It was a lot of fun! Thank you everyone who joined! 😄
<d1b2>
<esden> I don't think the Post Q&A sessions are recorded though... which is a bummer.
<d1b2>
<Lambda> Yeah, the Q&A was great, I think it really helped some of the folks there wrap their heads around what it really is.
<d1b2>
<theorbtwo> I hope you take some notes ... hate to say it, but y'all are not always great at explaining what it really is.
<electronic_eel>
maybe they are recorded and it just takes some time till the recording shows up? the recordings of the presentations are not yet online too
<d1b2>
<Lambda> I would actually like to help out with writing some docs, but I don't actually have one to play with, and my soldering skills/tools aren't up to making one myself
<electronic_eel>
theorbtwo: it's quite hard to explain something that can be anything ;)
<d1b2>
<Attie> that was great, and the post-Q&A ("hallyway"?) was also really nice, thanks for joining us!
<d1b2>
<Attie> i have to admit that it's one of those huge projects, that is difficult to get across in a sentance or two
<d1b2>
<esden> I tried many times... so far I don't have a all encompassing elevator pitch...
<d1b2>
<esden> There is too much that makes it special and different from anything that came before it.
<d1b2>
<Lambda> What I think would be good is just a short, written example that walks through building and using an applet
<d1b2>
<Lambda> Or a few of them
<d1b2>
<Attie> like many of the more complex projects, the surface level explanation is often a bit thin and sometimes misleading
<d1b2>
<Attie> people being introduced to the concept can jump to conclusions / make assumptions without realising it, and this makes it difficult to accurately communicate the whole concept clearly
<d1b2>
<Lambda> There are some good streams of the same, but they can be a bit long to watch end to end
<d1b2>
<theorbtwo> I think you need to give several elevator pitches at different angles.
<apo>
elevator pitch, yaw, and roll
<d1b2>
<Attie> e.g: if we talk about what an applet is, how it works, etc... then we gloss over a whole heap of other core / important details, because they are largely irrelevant / distracting at that level
<d1b2>
<esden> @Lambda written walkthroughs would be great. As well as edited down YT videos. All of that will help to communicate it for the different ways people like to ingest information. 🙂
<d1b2>
<Attie> i'd like to roll some of the diagrams i made for the slides into docs
<d1b2>
<Attie> @Lambda please let me know if you'd like the sources!
<d1b2>
<Lambda> @Attie Yeah, that sounds good!
<d1b2>
<Lambda> For me, the thought process that led me to the Glasgow was looking at the Bus Pirate and other things like it, but getting frustrated that they each had had a fairly limited set of interfaces, and while you might be able to bit-bang some others, it can frequently be a bit tough to get the timing right that way.
<d1b2>
<Lambda> So I was thinking about what you would need to do better, and said "what if you had an FPGA with some level shifters in front"
<d1b2>
<Lambda> But I didn't have the chops to build such a thing myself
<d1b2>
<Lambda> Then I was browsing CrowdSupply, and saw that the Glasgow was exactly that, but actually even nicer than I had imagined with the use of nMigen to allow applets with both the host and gateware written in Python
<d1b2>
<Lambda> So I think that might be a good way to introduce the concept; start with something that might be more familiar, like the Bus Pirate or any of the FTDI based solutions, but then mention the limitations you encounter when you need to go beyond the few built-in protocols
<d1b2>
<TomKeddie> The concept I found hardest to grasp (and which kinda blows my mind) is how whitequark puts the nmigen python to generate the hdl and the python for the applet in the same object. It's so well contained, all neat and tidy.
marvs has joined #glasgow
egg|anbo|egg has quit [Remote host closed the connection]
egg|anbo|egg has joined #glasgow
egg|anbo|egg has quit [Remote host closed the connection]
egg|anbo|egg has joined #glasgow
lambda[m]1 has joined #glasgow
AttieGrande[m]1 has joined #glasgow
Konsgnx has joined #glasgow
Konsgnx has quit [Read error: Connection reset by peer]
Konsgnx has joined #glasgow
d_olex has joined #glasgow
Konsgnx has quit [Read error: Connection reset by peer]
Konsgnx has joined #glasgow
Konsgnx has quit [Read error: Connection reset by peer]
Konsgnx has joined #glasgow
Konsgnx has quit [Client Quit]
Konsgnx has joined #glasgow
Konsgnx has quit [Remote host closed the connection]
<electronic_eel>
@Attie at the end of your can stream you were sending very similar data, but receiving vastly different data. one idea for a reason that came to my mind for this was the bit stuffing can does. if a stuff bit were inserted due to the data, that would shift bit offsets around.
<d1b2>
<Attie> @electronic_eel - yeah, i'm aware that this is likely playing a role in my fields not aligning, and probably also affects the value in the DLC field
<d1b2>
<Attie> thinking about it after the stream an 0x01 was a bad choice of test data for exactly this reason... doh
<electronic_eel>
yeah, the many zeroes on 0x01 were what brought me to the idea with the stuff bits
<d1b2>
<Attie> heh, thanks for mentioning 🙂
<ebb>
6 zero bits is the criterion, right?
<d1b2>
<Attie> yeah
<electronic_eel>
isn't it 5 bits? not sure
<d1b2>
<Attie> iirc, 6 bits that are the same, causes an insertion of the opposite value
<ebb>
> The bit stuffing mechanism prevents six consecutive bits from having the same polarity by inserting a bit of opposite polarity after the fifth bit.
<electronic_eel>
ebb: problem with more bytes will be the size field, won't it?
<agg>
CAN FD changes up the bit stuffing concept too, because it was a mistake in original CAN
<agg>
the size field is 4 bits, so 0-15 bytes
<agg>
but 9-15 are "illegal" values
<ebb>
Yep
<electronic_eel>
ah, right
<ebb>
Bit stuffing was the thing that made me think "hm, maybe I can't cram a controller into PIO"
<agg>
also beware no bit stuffing inside the CRC field (or the ack slot)
<agg>
sorry, inside the CRC delimiter field, the CRC itself is stuffed
<electronic_eel>
ebb: i don't think the raspi PIO can do can, because a proper can device has to send ack at the right momen. and sending ack means calculating the crc in time
<ebb>
So in effect the consecutive-bits-with-same-polarity counter is reset to zero whenever you reach the CRC delimiter or ACK?
<ebb>
Ah yeah :/
<agg>
those are all the final bits so you just never insert a stuff bit after the final CRC data bit
<ebb>
electronic_eel: I feel we've had this exact conversation before in fact
<ebb>
And you telling me the same (or similar) thing
<agg>
I guess you could just send the ack and hope the checksum later proves correct
<ebb>
Or let someone else ACK it :P
<agg>
if there's anyone else on the bus
<electronic_eel>
ok, cheating is always an option. but won't be a true can interface then
<agg>
Could you calculate the crc in time? At 1MBit CAN and like 100MHz rp2040 it doesn't seem impossible
<agg>
I guess getting the response into the pio in time might be tricky
<ebb>
I was thinking this
<ebb>
You get a hundred cycles or so
<ebb>
Or a few hundred
<ebb>
And it *could* be done incrementally as data comes in too
<electronic_eel>
they should have added a crc building block into PIO that would allow to calc different crc type efficiently
<agg>
Or just a tiny fpga at that point :p
<electronic_eel>
also some kind of soft pll thing for clock recovery
<agg>
In general the pio seems more specialised for transmit than receive
<modwizcode>
That'd be neat
<agg>
Yea exactly
<modwizcode>
A clock recovery peripheral would be awesome
<agg>
I'd love to be able to synchronously sample to an external clock even, but clock recovery would be nice too (if somewhat trickier)
<agg>
CAN defines the oversampling quanta though right? So you wouldn't use typical clock recovery anyway iirc
<d1b2>
<Attie> > ebb: Or let someone else ACK it 😛
<d1b2>
<Attie> ^ my plan for getting it started!
<electronic_eel>
agg: yeah, for can you wouldn't need clock recovery. but if you wanted to receive for example spdif, you'd need it
<d1b2>
<Attie> agg: not sure about oversampling, but it uses the quanta to position the sample point, yeah
<kmc>
I wonder if the main RPi SBC boards will eventually ship with a RP2040-like microcontroller onboard
<agg>
Yea. I have a 50MHz 8b10b thing that would almost be ideal but without synchronous sampling I'm not sure it can work
<kmc>
or even a custom SoC that integrates application processor, realtime microcontroller and PIO all together
<agg>
Maybe overclock pi to 200M and 4x oversampling
<kmc>
that could be pretty neat, especially since the whole stack can be programmed in Python (or Python DSLs)
<modwizcode>
I wonder if getting one of these new pi things would be worth it overall
<kmc>
if they do that hopefully they come up with a nice way of getting data between the various processors that is a little higher level than "here's a UART"
<kmc>
like it would be pretty awesome if you could pass Python objects between the main Linux cores and the Cortex-M cores running MicroPython
<kmc>
with all the serialization handled for you
<d1b2>
<Attie> there are rpc things for python, not to mention things like picke
<ebb>
> In general the pio seems more specialised for transmit than receive
<ebb>
I suppose if you have just some sensors you want to put on CAN -- works fine
pg12_ has quit [Quit: pg12_]
<modwizcode>
I think you're dreaming at this point heh
pg12 has joined #glasgow
<modwizcode>
I think I'm going to need to write a CAN peripheral for an FPGA at some point
<modwizcode>
Is there any value in trying to do it via the PIO on the rp2040? Like is it super janky?
<modwizcode>
I've been kinda wondering if just embedding a small FPGA with some easy to program PIO like gateware layer would have been a better option for them.
<d1b2>
<Lambda> If I'm going to try writing up an intro to Glasgow, what's a good example of a simple protocol that would be difficult to deal with in a Bus Pirate/Tigard/etc, but could be done easily with Glasgow? My first thought is ws2812b, because of the timing requirements, but of course there are already a ton of bit-bang implementations of that and also it's generally write only, so wouldn't provide an example of receiving.
<modwizcode>
Also if you implement that protocol in a different way it's a lot less resource intensive (found a cool article on it the other day)
<d1b2>
<Attie> honestly, i'd suggest starting with a simple / familiar protocol, like UART
<hell__>
SPI is pretty annoying to bitbang because of the strict timing constraints
<modwizcode>
Yeah SPI or maybe high-speed UART?
<d1b2>
<Lambda> Part of the point would be to demo something that an FTDI based interface like Tigard can't do
<d1b2>
<Attie> fair
<modwizcode>
Maybe proper JTAG?
<modwizcode>
But I don't think that's implemented yet?
<d1b2>
<Attie> the PDM / SigmaDelta DAC is pretty neat
<hell__>
sure, you can bitbang SPI to read/write a flash chip, but the speed will be slow
<d1b2>
<Attie> and self contained / easy to understand
<d1b2>
<Attie> or perhaps the PROM interface?
<modwizcode>
I still haven't figured out what part of JTAG always ends up using a CPLD even though it seems to be low speed bitbang rate anyway.
<d1b2>
<Attie> again, fairly simple to understand
<d1b2>
<Lambda> Yeah, something like PROM or JTAG sounds like what I'm thinking of
<d1b2>
<Attie> ... but it's really a pin count issue for bus pirate more than anything else
<modwizcode>
Speaking of JTAG does the Glasgow expose the ICE40 JTAG pins?
<modwizcode>
Pin count?
<hell__>
hmm, but I use a FTDI FT2232H as SPI programmer and it's fast
<modwizcode>
For JTAG?
<d1b2>
<Attie> (bus pirate doesn't have enough pins... for PROM)
<modwizcode>
The 2232H is different isn't it?
<d1b2>
<Lambda> Pin count for PROM, I think
<hell__>
what exactly is a PROM?
<d1b2>
<Benny> programable read only memory?
<d1b2>
<Attie> yeah - precursor to EPROM, and EEPROM
<d1b2>
<Attie> the interface is parallel address, parallel data, and read/write strobes, etc...
<hell__>
I meant to ask if it meant a particular family of chips, or just PROM in general
<agg>
modwizcode: the ice40 "doesn't have" JTAG pins
<hell__>
ok, I can't find a "PROM interface" specification, but I imagine it refers to the parallel interface that stuff like EPROMs use
<d1b2>
<Attie> yeah - it's not a specific chip / family as such - they are fairly generic parts at this point
<hell__>
aaah, that kind of interface
<hell__>
makes sense now, thanks
<d1b2>
<Attie> yep
<d1b2>
<Attie> np!
egg|anbo|egg__ has joined #glasgow
egg|anbo|egg_ has quit [Ping timeout: 264 seconds]
<d1b2>
<DX-MON> generally they're the 24-series of parts, so.. for example, 24C512 is a PROM
<d1b2>
<DX-MON> 25 tends to be SPI-based addressable serial-interface (E|EE)PROM's and Flash
<hell__>
er, 24-series are I2C EEPROMs
<d1b2>
<DX-MON> non-C part numbers, sure.. but the 24C stuff is all RPOM
<d1b2>
<theorbtwo> Only problem I see with prom as an example protocol is that you will run out of pins, no?
* hell__
often deals with 25-series SPI flash chips
<d1b2>
<Attie> @esden has made up a board with a shift register, to take on the high-end address bits
<d1b2>
<DX-MON> the PROM applet supports using shift registers to provide sufficient pins for address pins
<d1b2>
<theorbtwo> Aha.
<d1b2>
<DX-MON> ugh.. I forgot what the number after the 2 for the parallel PROM's are then
<d1b2>
<DX-MON> that's embarasing
<hell__>
29 is parallel flash, 27 is EPROM
<hell__>
28 is EEPROM
<d1b2>
<DX-MON> ..26C512.. 26 is what I was thinking
<hell__>
ah, I've never heard of these, but makes lots of sense
<d1b2>
<DX-MON> 26 is PROM
<d1b2>
<DX-MON> UV erasable, sometimes
<d1b2>
<DX-MON> (usually)
<hell__>
I have few UV-erasable EPROMs, and they're usually 27. but internet has a few pictures of 26 PROMs and EPROMs
<d1b2>
<DX-MON> yeah, not the lack of E in the name
<d1b2>
<DX-MON> EPROM is a different device series to PROM
<d1b2>
<DX-MON> but the applet should work fine for all the parallel forms
<d1b2>
<theorbtwo> ...and presumably the actual-ROMs that the prom interface is based upon as well?
<d1b2>
<Lambda> Hmm. Is there no I2S applet yet? That seems like it could be a good candidate for something that's reasonable simple with Glasgow but difficult or impossible with the other probes.
<d1b2>
<theorbtwo> I2S seems like something that could be fun to play with.
<d1b2>
<theorbtwo> Good use case for parallel applets on different ports, since those are often i2s for data and SPI, i2c, or the like for configuration, as I understand it.
<d1b2>
<Lambda> Yeah. What's the status of multiple applets at once?
<whitequark>
there's a PR for I2S
<whitequark>
multiple applets are not done and will not be done for a long time due to the large refactors required
egg|anbo|egg has quit [Remote host closed the connection]
<tnt>
AttieGrande[m]1: is the fosdem talk available somewhere already ?
<d1b2>
<Lambda> Is it bad that I read issue 234 and thought "I have a lot of experience with argument parsing in Python and PEP 302 import hooks, maybe I could try working on some of those"?
<d1b2>
<DX-MON> there's a whole big dependency tree, Lambda
<d1b2>
<DX-MON> including stuff in nMigen too
<d1b2>
<Lambda> Ah
<d1b2>
<DX-MON> no, that's really good - contribs are welcome
<whitequark>
a lot of this stuff is of the "it's easier to implement it than review it" kind
<d1b2>
<DX-MON> this too
<d1b2>
<Lambda> Yeah, exactly, that's why I was asking
<whitequark>
#234 has the disclaimer at the top for a reason
<d1b2>
<Lambda> Yep, saw that
<d1b2>
<Lambda> And that's why I asked
<whitequark>
well, right now i have time for neither
<modwizcode>
It might be worth adding some tags for tasks that are expected to be contribution friendly (I don't remember seeing anything like this)
<modwizcode>
obviously that's just another thing to do but it might help for future things (rather than trying to retroactively apply it)
<d1b2>
<Lambda> Hmm. Any way I can help that will reduce rather than increase your workload?
<whitequark>
not offhand. the project got popular *far* faster than i anticipated or had capacity for
<whitequark>
this is fixable but patience is required
<whitequark>
at least the current state of the codebase is not bad per se, it's just more limited than it ought to be
<whitequark>
'doesn't scale' you could say
<whitequark>
which is a lot better than the state of many other OSS projects that got popular faster than anticipated...
<d1b2>
<Lambda> And I really do have considerable experience with import hooks in Python; I've had to work through multiple different ways of implementing the same import hook in migrations between Python 2.x versions and Python 3.x versions, so while I know that one might be one of the hardest to discuss and review, it's also one where I could possibly be the most useful.
<whitequark>
I believe that, and I appreciate your experience; you'll certainly be tagged in during both review and design
egg|anbo|egg has joined #glasgow
GNUmoon has quit [Ping timeout: 268 seconds]
egg|anbo|egg__ has quit [Ping timeout: 240 seconds]
<d1b2>
<Attie> @tnt i don't think the video is out yet (i can't find it)
<d1b2>
<Attie> i'd like to wait to see if the Q&A session was recorded before i share if that's okay (obviously the talk itself was pre-recorded)
<d1b2>
<tnt> ack
<d1b2>
<theorbtwo> Things I've seen here and there suggest that the Q&A will have been recorded (from the moderator asking the presenter to read questions before answering them so the video would preserve them). Also, that in previous years it's been a slightly manual process -- the room's moderator was asked to approve the video before it went up.
<d1b2>
<Attie> yeah, i figured something like that - but i don't think the "hallway" video after the slot was over / Q&A finished was recorded, which is a bit of a shame
<d1b2>
<theorbtwo> Yar.
<d1b2>
<Attie> we had a good ~45 min discussion, demo, etc... there too
<d1b2>
<theorbtwo> The chat log is still available, but yeah, the video would have been nice too.
<d1b2>
<theorbtwo> (Though the video quality, at least here, was horrible .)
<d1b2>
<Attie> gah... i was a bit afraid of that
<electronic_eel>
don't know why the video quality during q&a and hallway was so bad. when attie and esden do their twitch streams it is much better. so i guess it is something on the fosdem end?
<d1b2>
<theorbtwo> I assume so.
<d1b2>
<theorbtwo> I noticed the same during another speaker's Q&A.
<electronic_eel>
but the prerecorded main presentation was good. so it must be their live streaming and not streaming in general
<electronic_eel>
what kind of input did they want for the live stream? rtmp like twitch or a browser with webrtc?
<d1b2>
<Attie> it seemed to be a jitsi call that they captured somehow and spliced into the track's stream
<d1b2>
<Attie> i think esden had to reduce his webcam resolution to 480p... mine seemed okay at 720p
<electronic_eel>
that was never 720p that we saw. more like 320x200 with max compression artifacts or similar
<d1b2>
<Attie> (there were quite specific instructions for the talk itself, and we both used OBS' virtual camera to feed the Q&A live, which is probably not standard)
<d1b2>
<Attie> i saw other live segments that looked bad too... was kinda hoping for a setup / bandwidth issue for that/those individuals, but oh well
<electronic_eel>
obs virtual cam works fine. i use it all the time in big blue button at work and that works well
<d1b2>
<Attie> the jitsi call itself looked great for us! 😦
<electronic_eel>
so maybe it was their tech that grabbed the jitsi call and distributed it
<d1b2>
<Attie> oh yeah, no complaint about obs in that sense... just describing our setup
<d1b2>
<Attie> yep - i suspect so
d_olex has quit [Ping timeout: 265 seconds]
<d1b2>
<DX-MON> from comments made elsewhere.. they had some crazy requirements around lowering resolution to "work with their gear" so almost certainly the jitsi call capture was doing some serious res dropping
<d1b2>
<DX-MON> I know the presentation itself had to be lowered in quality to work (props to Esden and you for doing such a good job and with such nice looking slides etc)
<d1b2>
<Attie> thanks!
<d1b2>
<Attie> and yeah... at one point i heard that over 50% of the uploaded videos were not playing well with their system
<d1b2>
<Attie> which is a bit ... intense?
<gruetzkopf>
fosdem runs absurd amounts of tracks in parallel
<electronic_eel>
and it's the first time they've been doing it fully online like this. so no learning curve
<ebb>
I'm staring at what is apparently a Microwire EEPROM... anybody have past experience with those?
<ebb>
Microwire is said to be SPI-ish
<ebb>
Once this SOIC clip arrives I'll see if I can just throw the eeprom applet at it
<ebb>
...which, ah, is for 24-series I2C chips
GNUmoon has joined #glasgow
DragoonAethis has quit [Quit: hej-hej!]
egg|anbo|egg has quit [Read error: Connection reset by peer]