<whitequark>
kc5tja: nmigen is specifically for designing synchronous logic
<whitequark>
you *could* simulate logic with propagation delay in pysim though
<whitequark>
but it's not explicitly supported
<whitequark>
and it wouldn't be synthesizable
<adamgreig>
whitequark: off the top of your head, should smoltcp receive broadcast IPv4 packets? i'm having unicast get through and not 255.255.255.255
<adamgreig>
yea, if i re-add !...is_broadcast() to a local copy it receives broadcast traffic again
<adamgreig>
i'm about 8 hours late getting to sleep but i can do a small pr to restore it and maybe add a test later today if you like
<adamgreig>
there is already a test to receive udp broadcast ipv4 traffic, but it bypasses that check by going directly to udp_process :P
<whitequark>
yep, sounds good
proteusguy has quit [Ping timeout: 255 seconds]
rohitksingh has joined #m-labs
_whitelogger has joined #m-labs
mtrbot-ml has quit [Remote host closed the connection]
mtrbot-ml has joined #m-labs
rohitksingh has quit [Ping timeout: 255 seconds]
rohitksingh has joined #m-labs
proteusguy has joined #m-labs
rohitksingh has quit [Ping timeout: 246 seconds]
rohitksingh has joined #m-labs
rohitksingh has quit [Ping timeout: 240 seconds]
<lkcl>
adamgreig: ping, are you the same adamgreig that did the followingrobot with the STM32F102?
<lkcl>
that was a really cool project
<adamgreig>
lkcl: haha yea! Gosh that was over a decade ago now, stm32f103 had only just been released
<lkcl>
adamgreig: :)
<lkcl>
i used the STM32F103 to try to do a 640x480 VGA CMOS camera driver
<lkcl>
it neeeearly worked, i just couldn't work out the DMA to drive at the necessary 12mhz... *sigh*
<adamgreig>
These days the stm32s run over twice as fast and have camera and screen peripherals built in :p
<adamgreig>
(...and I'd just use an FPGA anyway)
<lkcl>
i hear ya :)
<adamgreig>
I think I got 320x240 and an underclocked pixel clock or something, doing the analysis in the hblank each line
<lkcl>
it was damn impressive
mumptai has joined #m-labs
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<adamgreig>
whitequark: out of interest, do you have any good ideas for smuggling packet metadata from the ethernet interface to the application? specifically ptp timestamps
<whitequark>
adamgreig: oh dear
<adamgreig>
right now i'm doing some naughty things just overwriting bits of the received packet with its timestamp and correcting the checksums
<adamgreig>
which Works(tm)
<whitequark>
like as a transformer?
<adamgreig>
getting the timestamp of a transmitted packet is proving much more awkward
<adamgreig>
transformer seems an overly grand name for it
<whitequark>
anyway my first idea is
<adamgreig>
my ethernet driver is just overwriting the last 8 bytes of the received packet with a timestamp and fixing the udp checksum
<whitequark>
allow associating packets with "cookies", propagate cookies upwards, and then look up cookies in the ethernet interface when you need them
<whitequark>
or rather it'd be some kind of an associative array structure that can be accessed from both application code and ethernet driver
<whitequark>
since all you need is to associate the packet on UdpSocket side with the packet on EthernetInterface side
<whitequark>
this way it cleanly factorizes into a feature flag
<adamgreig>
yea
<adamgreig>
there's already the Tokens
<whitequark>
mhmm
<whitequark>
it could be related
<adamgreig>
I guess for packet transmission I almost need to specify a callback in the udpsocket level that the ethernet driver will call after transmission complete
<adamgreig>
yuck
<travis-ci>
m-labs/smoltcp#1233 (auto - 0a21cb6 : Adam Greig): The build was broken.