00:05 <mtrbot-ml_> [mattermost] <sb10q> OK, well let's use the MMU

00:05 <mtrbot-ml_> [mattermost] <sb10q> Or compile for stm32.whatever gets this thing running faster

00:07 <mtrbot-ml_> [mattermost] <astro> excuse the really stupid question: do you mean sooner or with higher performance?

00:11 <mtrbot-ml_> [mattermost] <sb10q> sooner

00:12 <mtrbot-ml_> [mattermost] <sb10q> we can always turn on the MMU later to optimize it

00:14 <mtrbot-ml_> [mattermost] <astro> ok

12:56 <mtrbot-ml_> [mattermost] <hartytp> @sb10q Thermistors are very non-linear, whereas the ad590 provides a pretty constant uA/K

12:56 <mtrbot-ml_> [mattermost] <hartytp> if you just want to use a thermistor around room temp, that's not an issue

12:57 <mtrbot-ml_> [mattermost] <hartytp> but if you want to vary the temperature over 10s of degrees, you have to deal with significant variations in the thermistor sensitivity. That's a pita for analog control loops.

12:58 <mtrbot-ml_> [mattermost] <sb10q> okay, but do you care about the absolute laser temperature or just want to set it to reproducible setpoints?

12:59 <mtrbot-ml_> [mattermost] <hartytp> also, to preserve thermistor accuracy far from T0, you need a well calibrated thermistor, which isn't so cheap (a really cheap one will not be accurate far from T0)

12:59 <mtrbot-ml_> [mattermost] <hartytp> depends on the application.

12:59 <mtrbot-ml_> [mattermost] <hartytp> if you just want something to play with then I would porbably use a thermistor

12:59 <mtrbot-ml_> [mattermost] <sb10q> what applications need an accurate actual temperature reading?

13:01 <mtrbot-ml_> [mattermost] <hartytp> e.g. if you characterise a diode in a test setup, put it back in a drawer and then want to reproduce your old results in a new setup

13:01 <mtrbot-ml_> [mattermost] <hartytp> also, having a constant sensor gain is nice for control loops

13:02 <mtrbot-ml_> [mattermost] <hartytp> the other thing about the ad590 is that the front-end circuit is simpler than a thermistor since it provides a constant current

13:02 <mtrbot-ml_> [mattermost] <hartytp> e.g. compare data sheet figure 17 to the typical bridge circuits for thermistors

13:02 <mtrbot-ml_> [mattermost] <hartytp> anyway, by the sounds of it, for what you're doing a cheapo thermistor will be fine

13:03 <mtrbot-ml_> [mattermost] <sb10q> ok. will the sinara thermostat support both thermistors and ad590 type of devices?

13:05 <mtrbot-ml_> [mattermost] <hartytp> by default it will only support resistive sensors like thermistors and RTDs

13:05 <mtrbot-ml_> [mattermost] <hartytp> (It won't provide the 4V supply that the 590 needs)

13:06 <mtrbot-ml_> [mattermost] <sb10q> hmm

13:06 <mtrbot-ml_> [mattermost] <hartytp> unless you're interfacing with a pre-existing design with a 590 that shouldn't be a problem, since a well-calibrated thermistor can usually provide decent accuracy over the ranges one cares about (although, the effective ADC noise increases with decreasing detector gain, it's so small it should still be fine for most applications)

13:06 <mtrbot-ml_> [mattermost] <sb10q> you probably know more, but it sounded to me that the ad950 was a really popular choice in ECDLs

13:07 <mtrbot-ml_> [mattermost] <hartytp> pass. might well be, I haven't checked.

13:07 <mtrbot-ml_> [mattermost] <hartytp> replacing the temperature controller in an existing ECDL is not something I've worried about.

13:08 <mtrbot-ml_> [mattermost] <hartytp> For a new design, a decent Thermistor should generally do fine

13:10 <mtrbot-ml_> [mattermost] <sb10q> I wonder how hard it would be to add 950 support to the hardware

13:11 <mtrbot-ml_> [mattermost] <sb10q> er, 590

13:12 <mtrbot-ml_> [mattermost] <hartytp> anyway, if you have a design that needs a 590, open an issue and we can consider options. We can probably add some jumpers to allow both to be supported. Someone just needs to check compliance, voltage requirements etc, which I don't have time to do right now

13:13 <mtrbot-ml_> [mattermost] <sb10q> we have a 5V rail already

13:13 <mtrbot-ml_> [mattermost] <sb10q> the 590 takes 4V to 30V

13:19 <mtrbot-ml_> [mattermost] <sb10q> personally I don't really need a 590; but it seems a popular option in several commercial or academic designs, and it might be interesting to support it

13:26 <mtrbot-ml_> [mattermost] <hartytp> can you open an issue?

13:28 <mtrbot-ml_> [mattermost] <sb10q> ok

13:46 <mtrbot-ml_> [mattermost] <hartytp> thx. It's a good idea to check if we can support them easily

17:14 <Astro-> success: properly setup mmu and unaligned access no longer cause cpu exceptions

17:14 <cr1901_modern> I wonder why that would be...

17:15 <cr1901_modern> i.e. why would the MMU all of a sudden make the CPU stop caring about unaligned access

17:20 <Astro-> you actually need to set the U bit in SCTLR but it only works if the mmu is enabled

17:21 <Astro-> maybe it is the mmu that does the actual bit shifting?

17:23 <cr1901_modern> ahhh

17:24 <cr1901_modern> My own experience talking to people is (reluctantly) unaligned accesses should be built into all CPU archs without jumping through hoops

17:54 <TD-Linux> keep in mind #[repr(align())] only aligns struct members, not the struct itself

18:02 <TD-Linux> ... nvm apparently it guarantees where the struct itself is allocated too, at least in theory.

18:24 <Astro-> I have only one struct member.

20:14 <TD-Linux> I had to look what we did for aligned arrays and it is a hack relying on that https://github.com/xiph/rav1e/blob/master/src/util.rs#L28

20:16 <_whitenotifier-3> [nmigen-boards] Fatsie opened pull request #5: Convert DOS line endings. - https://git.io/fjVIB

20:18 <_whitenotifier-3> [nmigen-boards] Fatsie opened pull request #6: mystorm BlackIce support - https://git.io/fjVIR

20:20 <_whitenotifier-3> [nmigen-boards] Fatsie opened pull request #7: mystorm BlackIceII support - https://git.io/fjVIu

21:09 <Astro-> after rechecking my io initialization, I can talk to the PHY