<JamesSizeland[m]>
I might have missed in the chat somewhere, but is there a new expected release date for embedded_hal 1.0?
<vollbrecht[m]>
probably announced after the next meeting
<vollbrecht[m]>
* probably will be announced after
crabbedhaloablut has quit [Read error: Connection reset by peer]
crabbedhaloablut has joined #rust-embedded
Ralph[m] has joined #rust-embedded
<Ralph[m]>
since you discussed oscilloscopes & logic analyzers before: i don't have much experience with these things, but i got a [picoscope](https://www.picotech.com/oscilloscope/2000/picoscope-2000-overview). while i haven't used it a lot i think it's nice that you actually use it with your PC - i never warmed up to the more classical oscilloscopes (if you're not already used to them it's a bit of a voodoo thing to operate; having a nice GUI
<Ralph[m]>
makes it a lot more intuitive).
notgull has quit [Ping timeout: 252 seconds]
<diondokter[m]>
Picoscope is nice yeah! And it doesn't cost too much. Perfectly fine as your first scope that you won't have to replace for a long time (or ever).
diondokter[m] has joined #rust-embedded
<diondokter[m]>
Personally though, I prefer a 'real' scope. Getting used to the buttons is only a matter of keeping using it
<Lumpio->
I'm trying to write an actually good PC scope program
<Lakier15[m]>
Hey guys! I am currently looking at upgrading from the nRF52840 (single-core) to the nRF5340 (multi-core).
<Lakier15[m]>
I understand that having 2 cores: 1 for bluetooth (C zepyhr or apache-mynewt) and 1 for application (Rust Embassy) is possible. However I don't know how to handle IPC (Inter Processor Communication). Does anybody have any experience on multicore Rust embedded? Couldn't find OpenAMP bindings or any Rust alternative
<diondokter[m]>
It is super critical though that both cores agree on the data. If sharing data with Rust types, you need to make sure that both applications are compiled with the same exact compiler version. If you don't want this, then both the queue and any data in it has to be `repr C`
<diondokter[m]>
The exact memory address used is important.
<diondokter[m]>
* used is also important.
jannic[m] has quit [Quit: Idle timeout reached: 172800s]
<Lakier15[m]>
That's exactly what I thought. I just wanted to avoid to either force the same Rust compiler on both sides or having to do my own C-repr of synchronizing primitives (Mutex, Queue). But you are right! Both option are valid and I probably will have to see what would work in my case. I'll definitely use the `IPC` peripheral so that I don't have to poll from the network core.
<Lakier15[m]>
Thanks!
cr1901 has quit [Read error: Connection reset by peer]
cr1901 has joined #rust-embedded
Amanieu has joined #rust-embedded
IlPalazzo-ojiisa has quit [Quit: Leaving.]
dirbaio[m] has quit [Quit: Idle timeout reached: 172800s]
ChristianHeussy[ has quit [Quit: Idle timeout reached: 172800s]
samkent has quit [Ping timeout: 268 seconds]
U007D[m] has quit [Quit: Idle timeout reached: 172800s]
rtyler has quit [Ping timeout: 264 seconds]
rtyler has joined #rust-embedded
notgull has joined #rust-embedded
<AdamHott[m]>
Hi All, I need a scope, and have looked at the Glasgow Interface Explorer but the shipping times are highly delayed. Catherine mentioned that I could contract out someone to build one for me custom since the hardware designs and software are all open source. I sent an email to PCBWay, but was wondering if anyone know of any other services that could take on a project like this?
<JamesMunns[m]>
I super recommend you not doing that.
<JamesMunns[m]>
you COULD get your own built, but sourcing parts for building a single unit is very much not a beginner project
<AdamHott[m]>
ah okay! thanks!
<barnabyw[m]>
that sounds like a very roundabout and challenging way of solving the “get a scope” problem
<JamesMunns[m]>
yeah, if you find someone that WILL do it for you, they will charge a LOT of money for a single item.
<barnabyw[m]>
I bought an AD2 years ago. They’re a bit pricey, but are the equivalent to having a huge stack of test equipment which works fine for low-frequency low-power stuff most hobbyists are playing around with
<barnabyw[m]>
it’s probably also possible to find similar things for less money, the AD2 just happens to be the one I have experience with
<AdamHott[m]>
I'm checking out this analog discovery, I hadn't heard of this one
<barnabyw[m]>
IIRC both EEEVblog and the signal path have good analog discovery videos which showcases what it can do
<barnabyw[m]>
the AD2 used to have an amazing deal for students where they could get it for like 99$, not sure if they still do that tho
<Lumpio->
I've tried out Miniware scopes and they're just not that nice to use. They're too small to have a nice user interface.
<Lumpio->
Plus a 1MS/s sample rate isn't going to cut it for relatively simple digital stuff these days
<Lumpio->
(I know they have higher spec scopes, was talking about this particular one)
sourcebox[m] has joined #rust-embedded
<sourcebox[m]>
200kHz bandwidth is not that much. Typically, you want to have a bandwidth of min 10x the signal you want to probe.
<barnabyw[m]>
yeah, just wanted to suggest a cheaper alternative to the analog discovery in case they’re on a tight budget
<Lumpio->
If AdamHott[m] was looking for a logic analyzer you can get an el cheapo USB one off Amazon or something and it's likely it'll work fine
<Lumpio->
Or I guess that Glasgow thing did output as well
<AdamHott[m]>
I am on a tight budget, but it looks like the Analyzer Discovery 3 has a payment plan!
<Lumpio->
So do you need an analog scope, or a logic analyzer, or something that also outputs signals or what
<AdamHott[m]>
I need something where I can drive sensors on and read transmissions from that
<barnabyw[m]>
yeah, knowing more specific requirements will enable more specific (and potentially MUCH cheaper) recommendations
<K900>
As we said the other day, you can't drive a sensor with a scope
<K900>
Or a logic analyzer
<Lumpio->
So the driving part is something that most test equipment will not do
<K900>
They can only record signals
<Lumpio->
Do you just want to test individual sensors at a time or
<AdamHott[m]>
For now, yes I just want to test sensors one at a time
<Lumpio->
If you want to play with individual SPI/I2C sensors, you could look into an FT2232H based product
<Lumpio->
Play with them from a PC I mean
<AdamHott[m]>
K900: Sorry I'm slow to pick up on this!
<K900>
If all you want is to poke a bunch of sensors, just get any of those small Linux SBCs
<barnabyw[m]>
yeah if you want to communicate directly from your computer to sensors via, say, I2C or serial then a glasgow will do that but a “scope” will not. How about a raspberry pi? they expose a bunch of peripherals via the GPIO
<K900>
They have a whole-ass OS and a bunch of pins you can poke
<Lumpio->
You can get cheaper ones from AliExpress/Amazon
<barnabyw[m]>
what sensors specifically?
<barnabyw[m]>
* the GPIO pins
<sourcebox[m]>
For checking and playing with sensors using I2C or SPI, I often just use a board running MicroPython.
<K900>
And you can actually make them run as an appliance if you want to
<AdamHott[m]>
Lumpio-: Wait this one is less than 30 euros, and it supports all these protocols?
<barnabyw[m]>
(btw the analog discovery can also do direct communication via a bunch of protocols, so could work for that use case. But if you only need to do digital comms then there are much cheaper options)
<Lumpio->
It does SPI, I2C, UART and GPIO from your PC
<K900>
It's basically just a bunch of pins that can be controlled from your PC
<K900>
And you can mostly bitbang any protocol you want over them
<Lumpio->
But you can an equivalent for half price from Amazon or similar websites.
<K900>
But it's digital only
<Lumpio->
K900: FT2232H also has a serial engine to run SPI/I2C/UART at a reasonable speed
<K900>
And it doesn't have memory or anything
<Lumpio->
There's some limitations like USB polling speed but still it's faster than bit banging over USB.
<Lumpio->
But that random microcontroller board with MicroPython or something is also a good idea for experimenting
<Lumpio->
Fast iteration and those boards are like 5€
<Lumpio->
Anyways AdamHott[m] welcome to the world of electronics where there's 100 options and everyone has their favorite
<sourcebox[m]>
The scope is the instrument you need to check if the signals are ok in terms of electrical specs. E.g. levels, ringing etc.
<Lumpio->
yes
<Lumpio->
An analog scope is absolutely required for checking stuff like that, _that being said_ you don't necessarily have to check those from the very beginning!
<Lumpio->
I did some interesting projects with just a multimeter.
<sourcebox[m]>
But when the levels are ok, you're better of with something that understands the protocols.
<Lumpio->
Then again I did have to debug a video signal by listening to it with headphones...
<barnabyw[m]>
yeah a scope is nice to have (and even a low-frequency 70$ one with a small screen is infinitely better than not having one at all) but you can get a long way doing mostly-digital hobby stuff without one entirely
<AdamHott[m]>
Lumpio-: My multimeter arrives tomorrow
<Lumpio->
The multimeter is an absolute essential
<Lumpio->
Honestly a scope can wait
<AdamHott[m]>
Ok, I'll check out how far along I can get with the multimeter then bother you all again tomorrow with questions like, what's a scope, huh? jk jk lol!
firefrommoonligh has quit [Quit: Idle timeout reached: 172800s]
<adamgreig[m]>
no, this is the second of two weeks off
<adamgreig[m]>
or anyway I'm not running a meeting :P
<bartmassey[m]>
Thanks! Sorry, have been out of it last couple of weeks, so missed it.
<sourcebox[m]>
Btw. running MicroPython on an RPi Pico should be even cheaper than using an ESP32.
<AdamHott[m]>
sourcebox[m]: And the MicroPython is written in Python of course, so it can do some things to test hardware but it doesn't touch Rust, right?
<sourcebox[m]>
AdamHott[m]: I think it's written in C. But since you only use it as a tool, it should not matter.
<K900>
But it's a nice interactive environment that you can write Python in
<K900>
And you can use that Python to poke your hardware
<AdamHott[m]>
That's pretty awesome, and I know a bit of Python already so I'm leaning towards this now
<vollbrecht[m]>
just one general advice, while no solution is perfect in terms of cost/features/simplicity etc. If you need some tool to measure/debug/influence something you better hope that the tool does exactly that. E.g whatever you pick, you don't want to come in a situation where you need to "debug your debugger" as in you need to learn to trust your tools
<vollbrecht[m]>
this is a general hard problem, as you first need to learn about "how to use the tool correctly"
<vollbrecht[m]>
etc
<AdamHott[m]>
<vollbrecht[m]> "this is a general hard problem..." <- that's a great point, it doesn't make much sense investing in a tool if you don't have time to learn how to use it
jamwaffles[m] has quit [Quit: Idle timeout reached: 172800s]
crabbedhaloablut has quit [Read error: Connection reset by peer]
crabbedhaloablut has joined #rust-embedded
onkoe[m] has quit [Quit: Idle timeout reached: 172800s]