<galibert[m]>
You do have the means to test the bmx280 stuff on real hardware? I'm happy to try the de-inheritancing, but then it will be real important that it's tested
<whitequark[cis]>
yeah, i have a bmp280 or bme280
<whitequark[cis]>
also an scd40
<galibert[m]>
ok good
<whitequark[cis]>
i'll also add actual testcases
<galibert[m]>
that will help
redstarcomrade has quit [Read error: Connection reset by peer]
<brainstorm_nopco>
* be possible (hardware timing/resources/capabilities wise, not human time) to implement
<brainstorm_nopco>
* be possible (hardware timing/resources/capabilities wise, not human dev time) to implement
<whitequark[cis]>
this is something i/we have considered before'
<whitequark[cis]>
* this is something i/we have considered before
<whitequark[cis]>
it is almost certainly possible hardware-wise with the ram-pak addon
<whitequark[cis]>
it is also probably possible with QSPI PSRAM if you don't care about your DUT writing to the flash, and the gateware would be easier in that case
<whitequark[cis]>
i'm open to being contracted for either of those options
<whitequark[cis]>
galibert: so, something i haven't quite realized until looking closely at the I2CInitiator API is that it, frankly, sucks
<whitequark[cis]>
the SPI-controller-style API with async with would work a lot better
<whitequark[cis]>
also, re: clocking: i'm thinking that given I2C's limited range of clock frequencies, something as simple as an input fast would do the job
<galibert[m]>
Interesting, I'll have a look at spi then
<galibert[m]>
according to wikipedia there is 100k, 400k, 1m, 1.7m and 3.4m in open-drain bidir mode
<whitequark[cis]>
hm
<whitequark[cis]>
fairly sure Fm is push pull
<whitequark[cis]>
* sure Fm+ is
<galibert[m]>
According to wikipedia it's 5M uFM that's p/p
<galibert[m]>
s/uFM/UFm/
<whitequark[cis]>
okay, yeah, you're right
<galibert[m]>
and 1.7 and 3.4 are both called Hs because why use different names, heh?
<galibert[m]>
Not sure a glasgow would be reliable at 3.4, even >=1 may be iffy given the wires, no?
<whitequark[cis]>
huh? how so?
<galibert[m]>
You think the mhz signal will travel nicely along the wires?
<galibert[m]>
I know that connecting a saleae to a full-speed usb killed the signal, but it's ten times faster
zyp[m] has joined #glasgow
<zyp[m]>
depends a lot on what «the wires» actually mean in practice
<zyp[m]>
the main limitation on i2c speed is the time constant given from the bus capacitance vs the pullup resistance, and bus capacitance depends on the wiring situation
<whitequark[cis]>
i've used buses at up to about 80 MHz with the wire harness
<galibert[m]>
impressive
<whitequark[cis]>
and if you have proper termination, you should be able to do 200 MHz and more
<whitequark[cis]>
(but it's not as simple as plugging stuff into a breadboard any more)
<galibert[m]>
there's nothing proper about the gross hacks on my desk :-)
<whitequark[cis]>
digilent says theirs are validated up to 400 MHz
<whitequark[cis]>
glasgow doesn't go that high
<galibert[m]>
twisted cables, nice
redstarcomrade has joined #glasgow
redstarcomrade has quit [Changing host]
redstarcomrade has joined #glasgow
<whitequark[cis]>
with inline resistors
redstarcomrade has quit [Read error: Connection reset by peer]
<galibert[m]>
Catherine: any reason your clock divider thing uses a fixed divided rather than dithering (using bresenham or whatever)
leper- has joined #glasgow
leper has quit [Ping timeout: 245 seconds]
leper- is now known as leper
<galibert[m]>
the async with thing, it's the interface to defined the target address for a number of messages?
redstarcomrade has joined #glasgow
<galibert[m]>
s/defined/define/
redstarcomrade has quit [Read error: Connection reset by peer]
esc_ctrl[m] has joined #glasgow
<esc_ctrl[m]>
Hello, quick question- is there an out of the box way to produce an analog voltage from a Glasgow pin? Even just through a 10 bit DAC for example. Some way to toggle a pin to several voltage levels between fully on and fully off
<esc_ctrl[m]>
Or would I need to use the Glasgow to send, for example, I2C commands to an external DAC chip
<galibert[m]>
at what speed?
<esc_ctrl[m]>
Slow is ok
<galibert[m]>
you could PWM and filter
<galibert[m]>
clock is 48MHz, so you have some margin
icb-[m] has joined #glasgow
<icb-[m]>
There's the built-in audio-dac applet
ali_as has quit [Remote host closed the connection]
ali_as has joined #glasgow
redstarcomrade has joined #glasgow
lxdr533 has quit [Read error: Connection reset by peer]
lxdr533 has joined #glasgow
redstarcomrade has quit [Read error: Connection reset by peer]
redstarcomrade has joined #glasgow
redstarcomrade has joined #glasgow
redstarcomrade has quit [Changing host]
<whitequark[cis]>
<galibert[m]> "Catherine: any reason your clock..." <- no jitter
<whitequark[cis]>
<galibert[m]> "the async with thing, it's the..." <- no, it's to delimite transaction boundaries
<whitequark[cis]>
* no, it's to delimit transaction boundaries
<galibert[m]>
Ah, to ensure flushing?
<whitequark[cis]>
no, because I2C transactions are multi-stage
<galibert[m]>
Ok, I think at this point I don’t understand
<zyp[m]>
I'm guessing repeat start?
<zyp[m]>
in I2C, after a read or write, you can send a new start condition instead of a stop condition; this is called a repeat start
<whitequark[cis]>
yeah
<zyp[m]>
AFAIK most devices doesn't care, but devices can treat a repeat start differently from a stop followed by a regular start, so an I2C API needs a way to distinguish what to send
<galibert[m]>
Can the gateware do them or not yet?
<zyp[m]>
(and even if devices doesn't care, it saves a bit of time not having to send the stop)
<whitequark[cis]>
a *lot* of devices care about S vs Sr
<whitequark[cis]>
it's often a part of the protocol and is mandatory
josHua[m] has joined #glasgow
<josHua[m]>
yeah, I think a handful of image sensors seem to care about S vs Sr
<whitequark[cis]>
even in an EEPROM, if you use an Sr instead of P after a write, the write will just not happen
<josHua[m]>
also Sr can be done without relinquishing the bus in a multi-initiator system, to the extent that Glasgow can be expected to be used in such a case
<whitequark[cis]>
glasgow implements clock stretching but not arbitration
<zyp[m]>
multi-initiator i2c is so cursed
<whitequark[cis]>
incredibly, yeah
<galibert[m]>
Collision detection and incremental backoff? Or even worse ?
<whitequark[cis]>
i'm going to sit down in a hour or two and see if i can design a better I2C transaction API
<whitequark[cis]>
this is important bc this is what will be recorded in test fixtures
<galibert[m]>
Ok, I’ll stop touching the derivatives until you’re done then
<whitequark[cis]>
ie it's basically something that cannot be changed later without redoing all the HW testing
<whitequark[cis]>
unlike the I2C gateware for example
<galibert[m]>
Once the i2c interface is good, I can’t help to think one would like to use it from bmx280 (and the others). Inheritance is annoying, do you have an idea of how to go about it?
<whitequark[cis]>
composition
<whitequark[cis]>
instantiate the *Interface
<galibert[m]>
yeah, makes sense
redstarcomrade has quit [Read error: Connection reset by peer]
jfsimon has quit [Read error: Connection reset by peer]
redstarcomrade has joined #glasgow
redstarcomrade has joined #glasgow
redstarcomrade has quit [Changing host]
redstarcomrade has quit [Read error: Connection reset by peer]