Guest7282 has left #rust-embedded [Error from remote client]
Guest7282 has joined #rust-embedded
M9names[m] has joined #rust-embedded
<M9names[m]>
looks like a compiler built-in function to me, but maybe more appropriate to ask in esp-rs?
<M9names[m]>
the hint is leading double-underscores are reserved for the implementation (of the C compiler/standard library). no-one else is supposed to have any symbols with names like this.
<thejpster[m]>
I’ll be at the Pi Party in Cambridge tomorrow if anyone wants to stop by and say hi.
laura[m] has quit [Quit: Idle timeout reached: 172800s]
burrbull[m] has quit [Quit: Idle timeout reached: 172800s]
diondokter[m] has quit [Quit: Idle timeout reached: 172800s]
andodeki2[m] has quit [Quit: Idle timeout reached: 172800s]
<Ralph[m]>
i'm still trying to get my BNO055 IMU to work... with my STM32F401RE nucleo board it works fine, but with my ESP32C6 DevKit it fails to start.
<Ralph[m]>
i now wired it up to my picoscope and had a look at the I2C lines:
<Ralph[m]>
the first picture is of the STM32, where it works (though the decoding doesn't work)
<Ralph[m]>
and this is with the ESP32 where it doesn't work
diondokter[m] has joined #rust-embedded
<diondokter[m]>
Are your pulldowns in order on the I2C bus?
<JamesMunns[m]>
(probably pullups for i2c)
<diondokter[m]>
Oh right :P
<JamesMunns[m]>
that scope trace looks very weird tho, that "double hump" seems very wrong
<Ralph[m]>
diondokter[m]: i think that both the STM32 and the ESP32 have pull-ups for I2C built-in (though i admittedly didn't check the datasheet 😬) and the breakout board might have them too.
<Ralph[m]>
but to be save i've added a 10kOhm pull-up on each line (SCA & SCL) but to no avail
<JamesMunns[m]>
like, are you sure there's no short between the SCL and SDA lines, and there's a shared ground between the two boards?
<Ralph[m]>
at least on the STM32 it worked fine w/o an external pull-up, i've tested on the ESP32 with and without the pull-up
<JamesMunns[m]>
and your red line is only millivolts, are you actually connected to the right line?
<JamesMunns[m]>
that looks like crosstalk noise
<JamesMunns[m]>
your blue line looks correct, though you are pulling up to 5v not 3.3v, which the stm32 is probably okay with, but the esp32 might not be
<JamesMunns[m]>
those are both 3.3v devices, and you are feeding them 5v.
barnabyw[m] has joined #rust-embedded
<barnabyw[m]>
and the blue signal is going up to 5v, which sounds high for those devices
<barnabyw[m]>
ah James got there first
<Ralph[m]>
JamesMunns[m]: yes, GND is connected fine and there's no short between SCL & SDA
<JamesMunns[m]>
(you probably want the 10k resistors to go to 3.3v, not 5.0v, this could also damage the BNO055 if the dev board doesn't have level shifters on it
<barnabyw[m]>
also, depending on the properties of your I2C traces/wires, 10k pullups might be too high. but solve the other problems first and then try dropping them down to 2-3k if you still have rounded-off edges
<JamesMunns[m]>
yeah, if you're at 100k and not 400k/1M, 10k is probably fine
<JamesMunns[m]>
* yeah, if you're at 100khz and not 400khz/1Mhz, 10k is probably fine
<JamesMunns[m]>
cool, so you wont damage that board, but might damage the MCU
<JamesMunns[m]>
> > [..] complete with 3.3V regulator, logic level shifting for the Reset and I2C pins [..]
<JamesMunns[m]>
> The BNO055 I2C implementation violates the I2C protocol in some circumstances. This causes it not to work well with certain chip families. It does not work well with Espressif ESP32, ESP32-S3, and NXP i.MX RT1011, and it does not work well with I2C multiplexers. Operation with SAMD51, RP2040, STM32F4, and nRF52840 is more reliable.
<Ralph[m]>
> The BNO055 I2C implementation violates the I2C protocol in some circumstances. This causes it not to work well with certain chip families. It does not work well with Espressif ESP32, ESP32-S3, and NXP i.MX RT1011, and it does not work well with I2C multiplexers. Operation with SAMD51, RP2040, STM32F4, and nRF52840 is more reliable.
<JamesMunns[m]>
but I think your logic analyzer is attached wrong, or there is something wrong with the connection on the SDA pin
<Ralph[m]>
JamesMunns[m]: note to self: check voltage of I/O pins next time you start playing with a new toy... 😐️
<JamesMunns[m]>
the blue line looks like a pretty normal SCL line, but the SDA line looks very wrong. You are not measuring the actual wire - you're measuring radio noise from other wires.
<JamesMunns[m]>
that's probably why there's that weird double-hump (that I thought might be a short)
<Ralph[m]>
yeah, you're right - the probe wasn't attached properly 🙁
<diondokter[m]>
And this time it's not any release, I decided to make it the 1.0 release :D
<JamesMunns[m]>
Ah, use 0x28 not 0x29 for addr
<Ralph[m]>
JamesMunns[m]: i'm getting a `AckCheckFailed` (just realised i didn't mention this in my initial post... got thrown off when i realised that pasting images in matrix pastes them directly rather than embedded in a message, so i was in a hurry to get the message out to let you know what the random picture was about^^)
<JamesMunns[m]>
the adafruit board pulls the addr line low by default
<JamesMunns[m]>
Ralph[m]: try switching the address to 0x28 if your driver lets you, or pull the "ADR" pin to 3.3v.
<JamesMunns[m]>
(like, dead short to 3.3v, not with a resistor, there's already a 10k pulldown on the line)
<Ralph[m]>
oh! damnit, i had switched that (in software) on the STM32 test but not on the ESP32 test 😬 (though i think i've tried it there before and it didn't work - but then i also hadn't increased the timeout yet IIRC).
<Ralph[m]>
i'm getting responses now!
<Ralph[m]>
i just tested again without the added pull ups and it still looks fine:
<JamesMunns[m]>
your breakout board already has 10k pullups on them
<Ralph[m]>
thanks everyone for helping out, much appreciated!
<Ralph[m]>
so, in short, to get the BNO055 working with ESP32 (and possibly others): the main trick is to increase the timeout value. and then of course to use the correct I2C address in the process 😅
<JamesMunns[m]>
so when you added 10k externally you made the total pullups 5k, which is also a reasonable number :)
<Ralph[m]>
when i start the application (i.e. reboot the microcontroller) it crashes on the first attempt (AckCheckFailed which i just unwrap, triggering esp-backtrace in this case) and then it works on the second attempt. no clue why, but it's good enough for me
<JamesMunns[m]>
check the datasheet, the sensor might have a "don't talk to me for xx milliseconds after boot" rule
<Ralph[m]>
JamesMunns[m]: ah, i was looking for that but couldn't find it on their page!
<Ralph[m]>
JamesMunns[m]: thanks for the tip! yes, it indeed lists a "start-up time (From Off to configuration mode)" of ~400ms and a "POR time (From Reset to Config mode)" of ~650ms
<Ralph[m]>
so that's then probably it and my ESP32 is just faster in starting to talk to it than my STM32 👍️ (which makes sense, seeing the 160MHz vs. 84MHz clock speed?)
<Ralph[m]>
<JamesMunns[m]> "yeah, that looks like a read..." <- btw: how'd you glance the 0x29 from the screenshot of the I2C lines? am i missing something from that picture or do you just have the experience to read numbers from the squiggly lines? 😅
<JamesMunns[m]>
You can look at the bits, you read the data line on the rising edge of the clock line
<JamesMunns[m]>
so, look at the red line every time the blue line goes high
<JamesMunns[m]>
you get (start) 0101001_0_1 (stop)
<JamesMunns[m]>
where `0b010_1001` -> `0x29`, `0` means "write" (I was wrong before), `1` means "NAK"
<JamesMunns[m]>
but yeah I speak squiggly line
<Ralph[m]>
thanks for the explanation, that helps! 👍️ in a cinch i'll be able to use it - though i think i'll leave it to the tools to decode these signals if ever possible - i'm not (yet) used enough to reading squiggly lines 😅
marmrt[m] has joined #rust-embedded
<marmrt[m]>
When you're a real pro, you won't even need the probe, you can just touch the pads and feel the signals
<JamesMunns[m]>
lol, I mean don't get me wrong, I use Saleae's decoder any time I can
<JamesMunns[m]>
but I can manually decode it if I have to (but get details like READ/WRITE wrong lol)
<Ralph[m]>
so thanks everyone for taking some time out to help me out with this!
<Ralph[m]>
FWIW i've now created a PR to document this on the driver, so hopefully the next person using this sensor with such a microcontroller won't have as many issues: https://github.com/eupn/bno055/pull/35
<NiaLinaLunaStorm>
trying to get USB to run on my very first self designed PCB.
IlPalazzo-ojiisa has quit [Quit: Leaving.]
Dr_Who has joined #rust-embedded
<NiaLinaLunaStorm>
I know that the hardware is good, set the pins to high ans measured the voltage, that works
NickStevens[m] has quit [Quit: Idle timeout reached: 172800s]
<barnabyw[m]>
<NiaLinaLunaStorm> "I know that the hardware is good..." <- are you referring to the DP pull-up which is required for the STM32F103s to be electrically compliant? did you read and design your board according to AN4879?
<barnabyw[m]>
almost all STM32s have an embedded USB pull-up resistor except for the F103s and a couple of other old families
<NiaLinaLunaStorm>
barnabyw[m]: no, I meant setting it to high via the GPIO function
<barnabyw[m]>
well that’s a good start at least
<NiaLinaLunaStorm>
I know that I've set resistors around the USB stuff, let me check that
<barnabyw[m]>
it’d be useful to see the schematic and/or layout, if you’re okay with sharing it, in case it’s a hardware issue
<NiaLinaLunaStorm>
no, we don't have that resistor... so we screwed up our design?
<barnabyw[m]>
perhaps 😬 depending on your board, you might be able to botch it in?
<NiaLinaLunaStorm>
we already noticed some flaws
<NiaLinaLunaStorm>
and messed stuff up
<NiaLinaLunaStorm>
not the first thing which is a mess in hardware
<NiaLinaLunaStorm>
but ig we learn from our mistakes.
<NiaLinaLunaStorm>
I could share the git if our DNS wasn't broken rn, let me zip it up real quick
<barnabyw[m]>
yeah, everyone messes up their first PCB – and if not that one, then the second or third ;)
<barnabyw[m]>
and the F103 pull-up thing is an annoying gotcha because it’s basically only necessary for that one family
<NiaLinaLunaStorm>
barnabyw[m]: caught us already with the crystal, we looked at stuff and seen internal crystal so skipped that one... luckily got caught in review
<NiaLinaLunaStorm>
happens when you're overwhelmed and then look at too much stuff at once
sourcebox[m] has joined #rust-embedded
<sourcebox[m]>
barnabyw[m]: F303 also needs it.
<barnabyw[m]>
yeah hence the “basically” hedge 😁
<dirbaio[m]>
old stm32 is ☠️
<JamesMunns[m]>
does the f103 need the vdetect pin too? not sure if usb device code requires that
<barnabyw[m]>
and the f302 and f102, according to the application note
<NiaLinaLunaStorm>
we also find the stm datasheets not always understandable
<JamesMunns[m]>
(vdetect might be an F4-and-newer thing)
<barnabyw[m]>
JamesMunns[m]: AN4879 seems to imply that a vdetect pin is only necessary if your board isn’t bus-powered
<barnabyw[m]>
NiaLinaLunaStorm: yeah, it’s easy to get overwhelmed and confused from the huge pile of long datasheets, manuals and application notes you need to read in order to do anything useful 🙃
<dirbaio[m]>
all stm32's require vbus detect, but only if your usb device is self-powered.
<dirbaio[m]>
stm32's with OTG have a builtin vbus detect pin that's 5v tolerant and all. for others you have to DIY with any random GPIO and a voltage divider or something to not exceed 3v3
<JamesMunns[m]>
yeah, sorry, the embassy-usb impl gets mad if you say "use vdectect" but don't actually have vdetect wired up :D
<JamesMunns[m]>
I wasn't sure if usb-device did that too
<dirbaio[m]>
usb-device doesn't have vbus detect support :P
<JamesMunns[m]>
dirbaio[m]: perfect :D
<dirbaio[m]>
¯\_(ツ)_/¯
<NiaLinaLunaStorm>
barnabyw[m]: well... 3k pages A320 flight crew manual? wasn't an issue... 150 pages controller manual? is overwhelming, ig also cause at the same time learning like... everything we need
<NiaLinaLunaStorm>
am confused, that sensing pin didn't get shown in cubeIDE
<barnabyw[m]>
I’ve not used cubeIDE to configure USB stuff, but it might not have shown up because on the f103 you can use any GPIO, not a specific pin/set of pins?
<NiaLinaLunaStorm>
I didn't configure it, just used it for pinout guide
<NiaLinaLunaStorm>
so to fix it, solder a 1.5k resistor between DP and 3.3V
<NiaLinaLunaStorm>
?
<barnabyw[m]>
no guarantees that it’ll completely fix the issue, but it’s a reasonable next step, yes
<sourcebox[m]>
There are devices out there that use a fix connection of the pullup to +3.3V. It will work, it just can be annoying while debugging because the host does not realize when the device is reset.
<barnabyw[m]>
checked my g474 USB pinout configuration in cubeIDE and it doesn’t mention vdetect anywhere their either 🤷 wonder if it shows up at all in the auto-generated C code it makes for you
<barnabyw[m]>
s/their/there/
<dirbaio[m]>
g474 is not OTG
<dirbaio[m]>
only OTG chips have a dedicated vbus detect pin
<dirbaio[m]>
for chips with non-OTG USB you're supposed to use any random GPIO as input and do it in software
<barnabyw[m]>
ah yeah, I meant the random GPIO pin you need. I was wondering if cubeIDE’s pinout configuration thing might prompt you to pick a GPIO for that purpose when setting up the USB peripheral, but it doesn’t look like it
<dirbaio[m]>
uhhh no idea about that
<dirbaio[m]>
maybe it assumes you're building a bus-powered device?
<barnabyw[m]>
yeah I looked for any sort of project power configuration and couldn’t find any way of telling it whether you’re using bus power or not
<barnabyw[m]>
didn’t look very hard though, the text is unreadably small and painful to use on my high-DPI linux laptop 🥲
<dirbaio[m]>
java font rendering <3
<dirbaio[m]>
at least it works on linux, gotta give them that
<barnabyw[m]>
yeah, it’s even packaged and installable using KDE Discover, and I don’t remember having to do any weird cursed stuff to get it to install correctly
<barnabyw[m]>
so good job either STM or whatever kind soul decided to package it
<NiaLinaLunaStorm>
there are a few weird things it does tho... her Ctrl+S only works if the cursor is outside that pinout window part, and it keeps creating a directory in ~/
<barnabyw[m]>
a web-based version of the config tools would be even better though
<NiaLinaLunaStorm>
but yeah, good that there are linux tools
<NiaLinaLunaStorm>
have to mess with windows/macos only software and tho VMs (cause proton doesn't help either) for other hardware (not embedded controller stuff tho)
<barnabyw[m]>
I only use it for selecting pinouts and occasional clock configuration, i.e. I open it 1-2 times per project, which isn’t too painful
<NiaLinaLunaStorm>
hm... could I like... get a cheap usb cable and just add that resistor there?
<NiaLinaLunaStorm>
then I don't have to solder more on that tiny stuff
<NiaLinaLunaStorm>
barnabyw[m]: same
<sourcebox[m]>
Whenever I use the clock resolver I think it was done by some poor soul thrown into a dungeon.
Dr_Who has quit [Quit: ZZZzzz…]
<barnabyw[m]>
<NiaLinaLunaStorm> "hm... could I like... get a..." <- personally I’d try botching on a small TH resistor here
<NiaLinaLunaStorm>
sourcebox[m]: that fooled us too... did layout and it didn't show clock issues, clock issue got caught in review, opened it up and only after opening it up again it complained
<barnabyw[m]>
if you go the cable mod route, hot-glue the cursed cable in place or something so the board never gets used without it
<NiaLinaLunaStorm>
barnabyw[m]: yes, it's all so tiny tho so I thought, buy a cheap cable where we can like get to the DP wire, we've got a 3.3V pin header just connect that up with the resistor
<barnabyw[m]>
all too easy to come back to an old project in a few years, not use the cursed cable, and wonder why it’s not working 🤣
<NiaLinaLunaStorm>
oh, already thinking about a rework where all the mistakes I made are gone
<NiaLinaLunaStorm>
and also expand other things
<barnabyw[m]>
maybe pick a newer MCU 😅
<NiaLinaLunaStorm>
am open for suggestions
<barnabyw[m]>
I started out using f103 dev boards too, quickly swapped to f411 and then g474. can recommend the g4 family if you want to stick with STM32s, they’re much more modern and capable without being too complex
<NiaLinaLunaStorm>
also would like... consider one where I don't need an external crystal cause for the extended use I will need really almost all pins iirc
<barnabyw[m]>
but I’ve not used much else, and depending on your needs there might be better options
<dirbaio[m]>
g0/c0 if you need smaller/cheaper
<NiaLinaLunaStorm>
oki, gimme a few min, food's here, then I can talk about the requirements I'd have
<NiaLinaLunaStorm>
generally I struggle with finding suiting parts tbh
<NiaLinaLunaStorm>
and controllers are just more overwhelming but even rotary switches I've got big issues finding what I really need
<NiaLinaLunaStorm>
I need about 94 GPIO pins, (about 20 of which with ADC) + pins for I2C (probably for some 7 segment display) and USB and all the other normal things like SWD etc
<barnabyw[m]>
that’s a lot of gpio! what’s the application?
<NiaLinaLunaStorm>
I want to build an A320 pedestal
<NiaLinaLunaStorm>
home cockpit stuff
GrantM11235[m] has joined #rust-embedded
<GrantM11235[m]>
lol, that was my first thought too. Have you considered some kind of multiplexing or gpio expanders?
<barnabyw[m]>
ooh nice. yeah if the GPIOs don’t need to be super fast then expanders/multiplexing is probably the way to go. it will vastly simplify routing, too
<NiaLinaLunaStorm>
yes, kinda but again the issue of finding parts... we looked for I2C ADCs and didn't really find anything affordable, maybe we looked for the wrong thing or set the wrong fliter, idk
<sourcebox[m]>
Why not just muxing with 74HC4051 or similar?
<NiaLinaLunaStorm>
thanks for the idea, would have never considered using anything like that
<NiaLinaLunaStorm>
sounds like a good thing for this usecase
<NiaLinaLunaStorm>
ig part of failing suiting parts is cause I don't know alternative ways of doing things yet
<sourcebox[m]>
I do this all the time, way less expensive than using a chip that offers the amount of pins.
<GrantM11235[m]>
Is the non-analog io mostly a bunch of buttons/switches and leds? Chips like the TM1638 are designed for exactly that
<NiaLinaLunaStorm>
sourcebox[m]: yeah, can imagine that, just never thought of it
<sourcebox[m]>
For buttons, switches and leds there are shift registers.
<sourcebox[m]>
74HC165 and 74HC595.
<NiaLinaLunaStorm>
GrantM11235[m]: about 20 or so analog inputs and roughly 80 switches and buttons and LEDs
<sourcebox[m]>
These shift registers can also be services via the SPI peripheral and DMA.
<sourcebox[m]>
s/services/serviced/
<NiaLinaLunaStorm>
thanks will look into those things once I get to the next design, still need to figure some things out and learn a bit more from my first design
<NiaLinaLunaStorm>
also wanna learn a bit more about PCB design in general to understand things better
<NiaLinaLunaStorm>
this first one was like... "I wanna do this" does it without almost any pre-existing knowledge in like less than a week
<barnabyw[m]>
building an airliner cockpit is quite an ambitious first project ;)
<NiaLinaLunaStorm>
> Don't dream small dreams, they lack magic. Dream big, then make your dreams real
<NiaLinaLunaStorm>
- Donald Douglas (who built real aircraft)
<NiaLinaLunaStorm>
s/-/\-/
Dr_Who has joined #rust-embedded
<barnabyw[m]>
wonder if he had ever had to read ST datasheets 🤣
<sourcebox[m]>
If you use one of the bigger series like H7 anyway because of DSP performance and you already have a lot of pins, that's fine. But if you don't need that much DSP power or alike but just a lot of I/O, then you're better of with a smaller pin count chip and external components.
<sourcebox[m]>
It can also be a challenge to get such a large amount of pins routed and connected to a single chip on the PCB while the muxing/shift registers allow for more distributed design.
<NiaLinaLunaStorm>
barnabyw[m]: Don't think so, he was more involved in the DC-3 which got manufactured starting 1935
<NiaLinaLunaStorm>
sourcebox[m]: never heard of DSP performance
<NiaLinaLunaStorm>
sourcebox[m]: yes, already with this 64 pin thing it was kinda tricky...
<NiaLinaLunaStorm>
otoh, had exactly 0 experience with it and constantly forgot I have another layer...
Foxyloxy_ has quit [Read error: Connection reset by peer]
Foxyloxy has joined #rust-embedded
sirhcel[m] has quit [Quit: Idle timeout reached: 172800s]
Alex[m] has joined #rust-embedded
<Alex[m]>
Noob question. I've got an stm32f103 and I want to drive PWM PB6 (TIM4 Channel 1) dutycycle asynchronously so that interrupts don't mess up some timing. Is it possible to DMA to the PWM duty cycle using the same timer?
<Alex[m]>
This is for WS2812. The existing SPI implementations are getting messed up by my interrupts I think
jannic[m] has quit [Quit: Idle timeout reached: 172800s]
mattnite[m] has quit [Quit: Idle timeout reached: 172800s]
PhilMarkgraf[m] has joined #rust-embedded
<PhilMarkgraf[m]>
Coming back to the questions on task-arena-size... I have a large data structure that is being pulled into a future. How can I keep it from being included in the future? (The article provided talks about performing a box-pin, but that seems like the wrong choice in an embedded system. But perhaps I am wrong.)
<dirbaio[m]>
easiest is to put it in a static
<dirbaio[m]>
or put it in a StaticCell if you need mutable access, then pass the `&mut` around
<dirbaio[m]>
or actually
<PhilMarkgraf[m]>
P.S. The first software I ever wrote for pay was automating calculations for a McDonnell Douglas mechanical engineer who had started their career on the DC-2, the narrow-fuselage predecessor of the DC-3. (Bringing the Donald Douglas topic back.)
<dirbaio[m]>
perhaps you're OK with it being included once but the compiler is being dumb and including mnultiple copies of it in the same future?
<dirbaio[m]>
in that case you don't need statics, just make sure to own it in a single place (a single local variable) and pass `&mut`s around, never pass it by value
<PhilMarkgraf[m]>
Can the "single ownership and pass by &mut" be in the same task as the await? (The structure is quite large, so I do not want it in the task-arena even once.)
<dirbaio[m]>
you can make the task arena larger
<dirbaio[m]>
I mean, there's no advantage in moving it out of the task arena
<dirbaio[m]>
if you have a 1kb thing in a task local variable, it's using space from the task arena. if you move it out you can now make the task arena 1kb smaller, but you have added another static of 1kb. so total ram usage is the same
<PhilMarkgraf[m]>
I have made the task arena larger... it currently half the total RAM of my processor (32K out of 64K), which has me a little unnerved. I'll try to do some checking to ensure it is not making more than one copy... although I think that is probably the case (that there is only one copy.) I was concerned that there might be an in-arena and not-in-arena copy.
<dirbaio[m]>
it's quite common that the tasks are a big % of the RAM
<dirbaio[m]>
because in the end most "state" of your program is stored in local variables in tasks
<dirbaio[m]>
(vs a non-async interrupt-driven program, which forces you to put the state in statics so you can share them between main and irqs.)
<PhilMarkgraf[m]>
That makes good sense.
<PhilMarkgraf[m]>
Thank you for your time. I always find myself learning something new from this group!
<sourcebox[m]>
<Alex[m]> "Noob question. I've got an..." <- If you want to set the timers CC register via DMA, that should be possible.
ragarnoy[m] has quit [Quit: Idle timeout reached: 172800s]
<sourcebox[m]>
But you to check which DMA channel supports the request for that timer, if it should be self-updating.
<sourcebox[m]>
On older chips like the F103, the request routing is not that flexible.