01:34 <sb0> cr1901_modern: do you know other shells for windows that do not do weird stuff that requires cygwin (like bash) and have decent scripting capabilities?

02:14 <cr1901_modern> sb0: Powershell if that's your thing. It's not my thing and I have very little experience w/ it.

02:15 <cr1901_modern> Ppl like powershell b/c you can pipe more structured stuff than plaintext between processes compared to *nix.

04:14 <_whitenotifier-3> [nmigen] programmerjake commented on issue #145: pypy3 support tracking issue - https://git.io/fjPEA

04:23 <_whitenotifier-3> [nmigen] programmerjake commented on issue #145: pypy3 support tracking issue - https://git.io/fjPuv

06:13 <_whitenotifier-3> [nmigen] programmerjake commented on issue #145: pypy3 support tracking issue - https://git.io/fjPup

06:26 <_whitenotifier-3> [nmigen] programmerjake commented on issue #145: pypy3 support tracking issue - https://git.io/fjPzf

07:40 <_whitenotifier-3> [nmigen] programmerjake commented on issue #145: pypy3 support tracking issue - https://git.io/fjPzx

07:58 <_whitenotifier-3> [nmigen] programmerjake commented on issue #145: pypy3 support tracking issue - https://git.io/fjPg8

09:29 <whitequark> powershell is pretty good

09:38 <_whitenotifier-3> [nmigen] whitequark commented on issue #145: pypy3 support tracking issue - https://git.io/fjPag

10:16 <mtrbot-ml> [mattermost] <hartytp> @rjo https://github.com/sinara-hw/Thermostat/issues/7#issuecomment-510139382 to check we're on the same page about this

10:17 <mtrbot-ml> [mattermost] <hartytp> do you mean that you (or whoever will do the Thermostat fw) are happy to do initial development on existing hw and then port to the new hw without requiring additional funding?

10:18 <mtrbot-ml> [mattermost] <hartytp> or is your comment more that with a bit of extra funding we could prototype on existing hw and then port?

10:54 <rjo> i'm not doing any thermostat development currently and in the near future. i don't need thermostat right now, just down the road. i only meant to say that if there was a need for characterization of the hardware, then a lot of the software that would be developed as part of that characterization would be reusable. i.e. i don't see the differences between the hardware versions as something that should hold up

10:54 <rjo> software development.

10:55 <rjo> i think there is a lot of benefit in prototyping on v1.0 and then porting to v2

11:02 <rjo[m]> opticlock operating: https://www.opticlock.de/fileadmin/_processed_/9/2/csm_Screenshot_788f2062a4.png

11:21 <mtrbot-ml> [mattermost] <sb10q> To validate hardware or to speed up fw development?

11:30 <_whitenotifier-3> [nmigen-boards] whitequark reviewed pull request #19 commit - https://git.io/fjPwO

11:30 <_whitenotifier-3> [nmigen-boards] whitequark reviewed pull request #19 commit - https://git.io/fjPw3

11:44 <rjo[m]> both

11:54 <mtrbot-ml> [mattermost] <sb10q> OK but what is the priority here?

11:55 <mtrbot-ml> [mattermost] <sb10q> And things like the network interface can be developed on the stm32 kit as well

12:07 <rjo[m]> IMO hardware validation needs to be done before v2 can be signed off and before v2 firmware development can commit to implementation details. Things like the HW/PoE aspects of the network interface should be tested on v1. Yes. A some things should better be done on any stm32 kit.

12:47 <mtrbot-ml> [mattermost] <hartytp> " IMO hardware validation needs to be done before v2 can be signed off and before v2 firmware development can commit to implementation details"

12:47 <mtrbot-ml> [mattermost] <hartytp> what in particular are you worried about?

12:48 <mtrbot-ml> [mattermost] <hartytp> The basic concept has been prototyped here, so I'm happy that's low risk

12:48 <mtrbot-ml> [mattermost] <hartytp> there is a risk of bad layout etc

12:49 <mtrbot-ml> [mattermost] <hartytp> the PoE etc has been prototyped on Stabilizer

12:49 <mtrbot-ml> [mattermost] <hartytp> although again there is a risk of EMI etc in this design

12:49 <mtrbot-ml> [mattermost] <hartytp> the digital side can't be prototyped on v1.0 because v2.0 is so different

12:50 <mtrbot-ml> [mattermost] <hartytp> so the only things I can see that we would want to prototype on v1.0 hw are analog/noise concerns to do with the ADC + TEC driver

12:52 <mtrbot-ml> [mattermost] <hartytp> ideally I would like to prototype that before finalizing the designs. but my assumption is that the cost of writing code for v1.0 and then porting to v2.0 is likely to be >= the cost of a small hw run. so better to just spin up some v2.0 hw to test on, with the aim of moving quickly on to v2.1

12:52 <mtrbot-ml> [mattermost] <hartytp> if Greg's student's code worked decently I would use that to test v1.0 but it sounds like it doesn't

12:59 <rjo[m]> v1 is an excellent platform for testing the ADC+frontend section, the TEC driver, the TEC driver limit PWMs, the power supplies, EMI, the thermal design, and the interaction between them. That's pretty everything apart from the CPU/PHY and the DAC. For most of those blocks it's the only platform we have currently. Networking can also be tested/developed on a Nucleo.

13:03 <mtrbot-ml> [mattermost] <hartytp> @sb10q what's your thought on this? I agree it would be best to prototype on existing hw if we can. If that can be done easily given existing code then let's do it, but it's not something we have additional funding for

13:03 <mtrbot-ml> [mattermost] <hartytp> (I guess it does have a side benefit to you in that the board you end up keeping will likely be higher quality if we do more pre-production tests)

13:03 <rjo[m]> I don't think reversing the testing burden of proof is the right approach. It seems prudent to default to being worried about everything and positively exclude parts from suspicion by testing/qualifying them or using qualified components. Not the other way around where you assume something works just because nobody has voiced concern.

13:04 <mtrbot-ml> [mattermost] <hartytp> @rjo that's not quite how I look at it. Put it this way, if the cost and lead time of producing hw were nothing then it would make no sense to write code for v1.0 hw

13:06 <mtrbot-ml> [mattermost] <hartytp> or, if the cost of producing a couple of PCBs is less than the cost of porting the code from v1.0 to v2.0 then it makes more sense to produce v2.0 hw quickly, find the faults there, then move on to v2.1

13:07 <rjo[m]> But to give you my subjective worries: ADC analog front end issues, EMI from the various PWMs and switchers, thermal issues, corner case issues on the power supply chain.

13:07 <mtrbot-ml> [mattermost] <hartytp> sure. at least one of those things will likely to be an issue

13:08 <mtrbot-ml> [mattermost] <hartytp> but that doesn't mean it's necessarily cheaper to find the issues on v1.0 rather than v2.0

13:08 <mtrbot-ml> [mattermost] <hartytp> depends on the cost of porting code v producing hw

13:08 <rjo[m]> Absolutely. If it takes no time and costs nothing, I would not worry about anything. Is that really how you approximate reality?

13:09 <mtrbot-ml> [mattermost] <hartytp> well, the time only really costs us something if there is someone ready to write the code. not sure what your pipeline looks like

13:09 <mtrbot-ml> [mattermost] <hartytp> the cost of producing hw has to be compared to the cost of porting code. ime code development is usually expensive compared with producing simple pcbs like this.

13:10 <mtrbot-ml> [mattermost] <hartytp> anyway, happy to leave the decision up to whoever is writing the code. if prototyping can be done on v1.0 with existing funding then we should definitely do that

13:10 <mtrbot-ml> [mattermost] <hartytp> if it's going to require extra funds then seems more sensible to just produce some hw

13:12 <rjo[m]> Just "cost of a PCB" is shortsighted. By iterating designs you also make previous designs harder to use and support. Iterating PCBs just because PCB manufacture is cheap ignores the non-manufacture investment into hardware. Existing hardware has significant value beyond the cost of manufacturing.

13:16 <rjo[m]> You'll have to estimate the likelihood of having a design issue that requires another iteration and compare that to the development/support/design/re-testing/invalidating-previous-revisions cost.

13:22 <rjo[m]> Looking at it from a distance, we have had two major designs already: the Thorlabs version and v1. If I am not mistaken neither has seen significant testing. If they don't provide a benefit by either being used in the lab or by providing significant amounts of test data informing the next iteration, then per definition schematics/layout/review and manufacturing of those two designs was wasted time and money. It just doesn't

13:22 <rjo[m]> seem prudent to operate with the assumption that there will be major redesigns anyway.

14:42 <mtrbot-ml> [mattermost] <hartytp> okay, discussed with @sb10q

14:43 <mtrbot-ml> [mattermost] <hartytp> plan is to develop minimal fw on v1.0 hw that can read ADC samples and stream over TBD interface

14:43 <mtrbot-ml> [mattermost] <sb10q> the simplest thing possible, i.e. read ADC samples at some hardcoded interval and send to UART or semihoting

14:43 <mtrbot-ml> [mattermost] <hartytp> and control the PWM for the TEC driver. Fixed values in FW fine for this (can just change via GDB)

14:44 <mtrbot-ml> [mattermost] <hartytp> yes, something where I can save the data out for analysis in some decent way

14:44 <mtrbot-ml> [mattermost] <sb10q> cat /dev/ttyUSB0 > log

14:44 <mtrbot-ml> [mattermost] <hartytp> yes UART is easy

14:44 <mtrbot-ml> [mattermost] <sb10q> + python

14:44 <rjo> or just the ITM.

14:45 <mtrbot-ml> [mattermost] <hartytp> we'll test the ADC noise + stability, check TEC current -> ADC measurement cross-talk, check the TEC noise on a scope for a few different currents, check things work fine with PoE

14:45 <rjo> sounds good. that covers a good part of the risk surface.

14:45 <mtrbot-ml> [mattermost] <hartytp> I think that's a decent set of tests

14:45 <mtrbot-ml> [mattermost] <sb10q> the ITM is very slow

14:46 <rjo> nonesense.

14:46 <rjo> *nonsense.

14:46 <mtrbot-ml> [mattermost] <hartytp> (use a 10k low temp co resistor in place of thermistor for those tests)

14:46 <mtrbot-ml> [mattermost] <hartytp> okay, that sounds like a good plan

14:46 <mtrbot-ml> [mattermost] <sb10q> what nonsense?

14:46 <mtrbot-ml> [mattermost] <sb10q> ah, ITM != semihosting

14:47 <mtrbot-ml> [mattermost] <sb10q> but doesn't this require some special JTAG cable?

14:47 <whitequark> there's an additional pin for tracing

14:47 <rjo> not really.

14:47 <whitequark> you have my blackmagic probe, right? it can do ITM

14:48 <mtrbot-ml> [mattermost] <sb10q> no, I don't have it

14:48 <rjo> its much faster than a typical uart and it works just fine with most jtaggers e.g. the broken off jtag interface on any nucleo.

14:48 <whitequark> hm, I'm pretty sure I've specifically left it to you

14:49 <rjo> but for the 1kS/s rate anything other than semohosting will work.

14:51 <mtrbot-ml> [mattermost] <hartytp> okay, just need Greg to post the actual v1.0 schematics rather than some random rc...

18:39 <cr1901_modern> I don't want to call something flawless, but nmigen.build does close to, if not everything, right for me. Generates a standalone project without hassle that can be run anywhere.

18:40 <cr1901_modern> The "source a script" feature being the last missing touch I wanted

22:47 <_whitenotifier-3> [nmigen-boards] cr1901 synchronize pull request #19: Add Mercury platform. - https://git.io/fjilU