<re_irc>
<@sourcebox:matrix.org> But you need the right software archtecture for it.
<re_irc>
<@sourcebox:matrix.org> Of course, there are other options. I just think that the chip is not as bad as it seems at first glance.
troth has quit [Ping timeout: 256 seconds]
<re_irc>
<@sourcebox:matrix.org> Some stuff regarding the peripherals is also not obvious. If you don't dig deeply into the reference manual but just have a look into CubeMX, you assume limitations regarding the peripherals that are not true.
<re_irc>
<@therealprof:matrix.org> Well, you have to look deeply into the manual, otherwise you can't even map the peripherals into the MCU.
<re_irc>
<@sourcebox:matrix.org> E.g. the CubeMX does not allow certain peripherals to be used from a certain core.
<re_irc>
<@therealprof:matrix.org> I'd say if you want to do DSP stuff you might want to look into CPUs combined with a true DSP, like a TI OMAP or Qualcomm Snapdragon.
<re_irc>
<@therealprof:matrix.org> sourcebox:matrix.org: Yeah, CubeMX is a nice tool to figure out some things like how the clock works which the manuals are rather mum about but other than that we're not really big CubeMX users around here, especially since they've published the underlying data...
<re_irc>
<@sourcebox:matrix.org> But this often require special tools.
<re_irc>
<@therealprof:matrix.org> What does?
<re_irc>
<@sourcebox:matrix.org> True DSPs.
crabbedhaloablut has quit [Remote host closed the connection]
<re_irc>
<@therealprof:matrix.org> Sure, but you get true performance. If you use a Cortex-A7, you can just as well use any other Cortex-A7 implementation or even jump a couple of generations up...
crabbedhaloablut has joined #rust-embedded
<re_irc>
<@therealprof:matrix.org> I mean you can't say this particular A7 core is great for software DSP but all other Cortex-A are not...
<re_irc>
<@sourcebox:matrix.org> Motorola DSPs have been the weapon of choice for a long time, but today everyone is happy to get rid of them. Also for SHARC.
<re_irc>
<@sourcebox:matrix.org> With ARM, we have the advantage of open source toolchains.
<re_irc>
<@therealprof:matrix.org> True, but this chip is still using a "scrape from the bottom of a barrel" ARM.
<re_irc>
<@therealprof:matrix.org> I'm certainly just missing your point why this particular low-end CPU is so great for running DSP algorithms.
<re_irc>
<@sourcebox:matrix.org> You can always argue that something is faster.
troth has joined #rust-embedded
<re_irc>
<@therealprof:matrix.org> That's not my point. You tried to explain that MP1 is a great product; I don't see it.
<re_irc>
<@sourcebox:matrix.org> This is probably because I try to have a picture of the product that can be build with it. And there are more aspects than just the processing power.
<re_irc>
<@therealprof:matrix.org> Fair enough.
<re_irc>
<@sourcebox:matrix.org> You can have the fastest chip available, as long as you're not able to put this into a product with reasonable effort and cost, it doesn't help.
<re_irc>
<@sourcebox:matrix.org> It's the same with some FPGA designs, btw.
<re_irc>
<@dirbaio:matrix.org> đ đŋ
<re_irc>
<@dirbaio:matrix.org> to me seems like an interesting chip if you're already within the stm32 ecosystem and need more power
<re_irc>
<@dirbaio:matrix.org> or need linux for whatever reason
<re_irc>
<@sourcebox:matrix.org> ST is selling this as a solution for having a combination of realtime and Linux. But I think, for Linux it's a quite small system with only 512MB RAM.
<re_irc>
<@dirbaio:matrix.org> it's enough to run quite a bit of nodejs/python spaghetti đ
<re_irc>
<@sourcebox:matrix.org> But the intention is also to run graphics stuff on it. There's at least hardware support for it on the 157 series.
<re_irc>
<@dirbaio:matrix.org> so your interns can ship their IoT garbo without having to learn C đī¸
<re_irc>
<@therealprof:matrix.org> dirbaio:matrix.org: If they don't quite before the device has deviced to finish booting, that is.
<re_irc>
<@sourcebox:matrix.org> That's true.
<re_irc>
<@hyphened:matrix.org> sourcebox:matrix.org: I mean, the new RPi Zero 2 comes with similar specs, so there is a market for those chips.
<re_irc>
<@hyphened:matrix.org> Maybe not in industrial applications though
<re_irc>
<@therealprof:matrix.org> hyphened:matrix.org: At least it's minimum 3 times faster. That reduces the annoyance factor considerably.
<re_irc>
<@sourcebox:matrix.org> It's also quad core.
<re_irc>
<@therealprof:matrix.org> There's also the Compute Module which is said to be qualified for industrial applications...
<re_irc>
<@sourcebox:matrix.org> Yes, the CM is already used by more and more companies.
<re_irc>
<@sourcebox:matrix.org> One of the important requirements for industrial applications is lon-term availability.
rardiol has joined #rust-embedded
<re_irc>
<@neltnerb:matrix.org> therealprof:matrix.org: Is it reasonably straightforward to do basic configuration of all STM32 chips then? If I configure a chip in CubeMX because I don't know what I'm doing yet can I export something into a useful crate?
<re_irc>
<@neltnerb:matrix.org> I've only tried in C and there I recall it just generating header files
<re_irc>
<@sourcebox:matrix.org> CubeMX creates ugly C code using the lowest common denominator that all compilers will accept.
<re_irc>
<@neltnerb:matrix.org> gotcha
<re_irc>
<@neltnerb:matrix.org> thanks
<re_irc>
<@sourcebox:matrix.org> I never use this code direclty without modification.
<re_irc>
<@neltnerb:matrix.org> I got the discovery kit so I should be all set for hardware, hopefully it's not too painful to configure a new target
<re_irc>
<@neltnerb:matrix.org> I've had to design a few PCBs with STM32 chips but never had the job of programming much of it
<re_irc>
<@neltnerb:matrix.org> still slowly but surely working through the manual XD
<re_irc>
<@sourcebox:matrix.org> The CubeMX really helps to make sure that you use the right pins for a certain peripheral. I always use it to double-check that I don't have accidently swapped pin functions.
<re_irc>
<@sourcebox:matrix.org> Also, if you use some of the smaller chips with little memory, the generated code can be so large that you don't have much space left for your application code.
<re_irc>
<@therealprof:matrix.org> neltnerb:matrix.org: CubeMX can be a great help to chose a working pin/peripheral mapping and select parts for custom designs. It's also sometimes helpful to check the clock setup which for some parts can be crazy complex. The generated code is pretty much useless, for Rust use even more so.
<re_irc>
<@therealprof:matrix.org> Elmo: Many of the STM32 families (if not even all?) have decent Rust support, some even in multiple alternative flavours. I see you're on #stm32-rs:matrix.org already, feel free to ask STM32 specific questions there. (Can also ask them here but they may go under in other discussions)
troth has quit [Ping timeout: 256 seconds]
starblue has quit [Ping timeout: 256 seconds]
starblue has joined #rust-embedded
troth has joined #rust-embedded
<re_irc>
<@firefrommoonlight:matrix.org> Cube (I think it's called Cube IDE now) is also great for clock config
<re_irc>
<@firefrommoonlight:matrix.org> I've been using User Manuals for pin assignments, but no reason you couldn't use the GUI there as well
<re_irc>
<@fragadaleta:matrix.org> do you find it sufficient to start learning embedded rust using qemu and debugging on tcp:3333 as usual?
<re_irc>
<@fragadaleta:matrix.org> I guess my question is, when will real hardware become a necessity in the learning process?
<re_irc>
<@therealprof:matrix.org> frag: I'd start with real hardware ASAP. QEmu behaves quite differently and emulates only very few peripherals which are at the hard of embedded development.
<re_irc>
<@therealprof:matrix.org> The ecosystem is quite advanced so there's very little (if any) benefit using an emulator.
dcz_ has joined #rust-embedded
cr1901_ has joined #rust-embedded
cr1901 has quit [Read error: Connection reset by peer]
<re_irc>
<@fragadaleta:matrix.org> I see that the STM32 discovery board is a beginner board on many tutorials. Do you also have a suggestion about what hardware to start with (consider that i dont really start from scratch, having played quite a bit with PIC microcontrollers a dozen years ago) đ
<re_irc>
<@mehmet:grusbv.com> fragadaleta:matrix.org: By hardware, what do you have in mind?
<re_irc>
<@mehmet:grusbv.com> The discovery board has most of the bells and whistles.
<re_irc>
<@mehmet:grusbv.com> The debugger, chip, peripherals.
<re_irc>
<@mehmet:grusbv.com> On the computer side, there are options. The Embedded Rust book instructs a way to build a system that you can step with the debugger, thats one way to go.
<re_irc>
<@mehmet:grusbv.com> It requires a gdb server to run on the machine etc.
<re_irc>
<@mehmet:grusbv.com> And there is what I call the knurling stack, which is easier to setup but doesnt yet (?) have the ability to step, but has extensive logging capabilities.
<re_irc>
<@mehmet:grusbv.com> For this, knurling has a template, and with that and VSCode one is ready to go.
<re_irc>
<@fragadaleta:matrix.org> cool so i think the stm32 discovery board will be my first purchase đ
<re_irc>
<@mehmet:grusbv.com> I first look at the level of support Rust has in each.
<re_irc>
<@mehmet:grusbv.com> Nrf52 feather is pretty good.
<re_irc>
<@mehmet:grusbv.com> I dont know about STMP32,
<re_irc>
<@mehmet:grusbv.com> ESP should be all right but I never used it.
<re_irc>
<@mehmet:grusbv.com> PI is all right, but not bare bones, I presume and not a microcontroller.
<re_irc>
<@mehmet:grusbv.com> Raspberry Pi 2040 microcontroller has some support and I think it is here to stay
<re_irc>
<@mehmet:grusbv.com> But that also is sth that I noticed, not tried it.
<re_irc>
<@mehmet:grusbv.com> RPi2040 has an exciting IO peripheral, and is dual core btw. Can do a lot of low level things there.
<re_irc>
<@mehmet:grusbv.com> The dev board is rpi micro
<re_irc>
<@mehmet:grusbv.com> I feel that these are the ones that have enough material out there to onboard.
<re_irc>
<@fragadaleta:matrix.org> ah what a review thanks! Mehmet Ali
<re_irc>
<@fragadaleta:matrix.org> when you say PI is not bare bones, what exactly do you mean? I could access hw directly via a HAL crate for rpi? no?
<re_irc>
<@k900:0upti.me> fragadaleta:matrix.org: You'll still be running Linux
<re_irc>
<@k900:0upti.me> The HAL crates will generally go through the Linux API too
<re_irc>
<@fragadaleta:matrix.org> ah so rpi doesnt even boot without loading a linux kernel first?
<re_irc>
<@k900:0upti.me> It _can_
<re_irc>
<@k900:0upti.me> But it's extremely annoying to do so
<re_irc>
<@k900:0upti.me> And the boot chain is very weird
<re_irc>
<@fragadaleta:matrix.org> got it
<re_irc>
<@k900:0upti.me> There's about three layers of proprietary bootloaders
<re_irc>
<@k900:0upti.me> And at least two of them run on the GPU cores
<re_irc>
<@fragadaleta:matrix.org> jesus
<re_irc>
<@k900:0upti.me> Those Broadcom SoCs they use are EXTREMELY jank
<re_irc>
<@k900:0upti.me> They're very complex, sometimes seemingly for no reason, and there's basically no documentation available publicly on most of it
<re_irc>
<@k900:0upti.me> I'm not sure how much you can find out if you sign an NDA
<re_irc>
<@k900:0upti.me> But knowing Broadcom, it's probably not much either
<re_irc>
<@fragadaleta:matrix.org> anything in between STM32F discovery and RP2040? I think i'd need more ram. STM comes with 48 kbytes only
<re_irc>
<@zentux:zwergenfreun.de> zentux:zwergenfreun.de: Today I checked with a scope and can confirm that the SPI is sending just as I expected, but still, if I use read right after, (or use the write method) it blocks indefinitely. If I keep sending at a pace I would assume is slow enough (about two messages per second) it reports an overrun after a few messages.
<re_irc>
<@k900:0upti.me> fragadaleta:matrix.org: Maybe look at the nRF5x SoCs
<re_irc>
<@fragadaleta:matrix.org> ah Mehmet Ali mentioned nRF52
<re_irc>
<@k900:0upti.me> They are really nice
<re_irc>
<@k900:0upti.me> Though kind of expensive
<re_irc>
<@k900:0upti.me> Also they all come with onboard wireless of some sort, so if you don't need it, you'll be paying extra for that too
<re_irc>
<@fragadaleta:matrix.org> yeah i see that many come with BT
<re_irc>
<@9names:matrix.org> the microbit v2 is pretty nice if you want to try nrf52. It has a debugger and a bunch of other nice things on board
<re_irc>
<@9names:matrix.org> not as cheap as a Pico, but once you factor in the cost of a second Pico to use as a debugger + the external peripherals you're probably looking at around that price anyway.
<re_irc>
<@9names:matrix.org> it does depend on what your goals are.
<re_irc>
<@9names:matrix.org> and your budget, of course
<re_irc>
<@fragadaleta:matrix.org> i think i need a breadboard first LOL
<re_irc>
<@fragadaleta:matrix.org> and a really basic kit to get started
<re_irc>
<@fragadaleta:matrix.org> đ
<re_irc>
<@k900:0upti.me> The official Nordic dev boards are also really good
<re_irc>
<@k900:0upti.me> Lots of I/O and built like a tank
cr1901_ is now known as cr1901
troth has quit [Ping timeout: 252 seconds]
<re_irc>
<@fragadaleta:matrix.org> K900: do you have a name? Also how's Rust support?
<re_irc>
<@k900:0upti.me> I think they're just called "nRF5xxxx development kit"
<re_irc>
<@k900:0upti.me> Rust support is good for all nRF5 stuff
<re_irc>
<@fragadaleta:matrix.org> ok will read a bit and decide
<re_irc>
<@k900:0upti.me> Actually looks like they have final versions of nRF53 dev kits nown
<re_irc>
<@k900:0upti.me> Maybe avoid those until the HALs get updated though
<re_irc>
<@k900:0upti.me> nRF53s are pretty different from 52s from what I've seen
<re_irc>
<@fragadaleta:matrix.org> arm m33 vs m4 too
<re_irc>
<@fragadaleta:matrix.org> nRF52840? K900
<re_irc>
<@k900:0upti.me> That's actually generally not the interesting part
<re_irc>
<@k900:0upti.me> The actual core design isn't too important
<re_irc>
<@k900:0upti.me> It's everything else that is
<re_irc>
<@fragadaleta:matrix.org> you're right
<re_irc>
<@k900:0upti.me> fragadaleta:matrix.org: I don't remember the exact part numbers off the top of my head
<re_irc>
<@k900:0upti.me> But the differences are mostly in the memory size and wireless connectivity
<re_irc>
<@k900:0upti.me> The core is the same
<re_irc>
<@fragadaleta:matrix.org> k900:0upti.me: yeah i found it in this amazing table
<re_irc>
<@k900:0upti.me> Also the cheapest versions don't have dev kits
<re_irc>
<@k900:0upti.me> Probably because the dev board costs like 50x what the SoC costs anyway
<re_irc>
<@fragadaleta:matrix.org> when i purchase, say the nRF52xxxx what else would I need to get started? A breadboard, special cables?
<re_irc>
<@fragadaleta:matrix.org> other components?
<re_irc>
<@zentux:zwergenfreun.de> zentux:zwergenfreun.de: Apparently the frxth bit is not properly set in the hal, eventhough looking at the code it looks correct, because if I send two bytes instead of one and then do two reads it works. Strange..
<re_irc>
<@zentux:zwergenfreun.de> The question now is: Where should I fix it? Do you know if it doesn't work just for my chip or is SPI1 generally untested in the stm32l4xx-hal?
<re_irc>
<@k900:0upti.me> If you get the dev board, probably a USB cable
<re_irc>
<@k900:0upti.me> They run off USB
<re_irc>
<@fragadaleta:matrix.org> i saw âšī¸
<re_irc>
<@fragadaleta:matrix.org> is there a cool website to find projects with SoC or MCU?
<re_irc>
<@fragadaleta:matrix.org> stuff to get inspired or simply to see what is possible building with certain components/boards
<re_irc>
<@k900:0upti.me> There should be a direct power input too I think
<re_irc>
<@k900:0upti.me> If you want to wire up a battery or something
<re_irc>
<@k900:0upti.me> For project ideas check the Arduino website
<re_irc>
<@k900:0upti.me> It's got lots of info on stuff you can plug into Arduinos
<re_irc>
<@k900:0upti.me> And most of that will work with other boards as well
troth has joined #rust-embedded
<re_irc>
<@fragadaleta:matrix.org> i see
<re_irc>
<@fragadaleta:matrix.org> found... the tinyML dog bark stopper project
<re_irc>
<@fragadaleta:matrix.org> i could adapt it for my girlfriend
<re_irc>
<@fragadaleta:matrix.org> eldruin: this is indeed very helpful! Thank you so much
<re_irc>
<@eldruin:matrix.org> also in this [driver examples repo](https://github.com/eldruin/driver-examples) you can find very simple examples using a bunch of sensors which you can buy very cheap in aliexpress or so. Might be an inspiration and you can start with programs that work out of the box, just wire them up
<re_irc>
<@fragadaleta:matrix.org> thanks!
<re_irc>
<@fragadaleta:matrix.org> your blog has very interesting posts! You just made my weekend busy đ
<re_irc>
<@eldruin:matrix.org> haha, I'm glad :D I only wrote blog posts for some of the drivers but there are many more in the driver examples repo
<re_irc>
<@fragadaleta:matrix.org> yeah i see that. Will read your posts first. Then decide what equipment i need to buy and then move to the drivers part đ
<re_irc>
<@lidialiker:matrix.org> eldruin:matrix.org: great post, thanks! wondering is there any additional tips to starting out solder-less? seems like an involving process, I know some boards like arduino uno are more friendly to beginners and I could use breadboards but then if I want to connect it to sensors like mpu-6050 (gyro) they look like they would still requires some soldering
<Lumpio->
A lot of sensors are available as modules with headers
<Lumpio->
And the Discovery boards and, well, most dev boards have plenty of headers to hook things up without soldering
<Lumpio->
Just google for a "module" or "breakout" for your desired sensor
<re_irc>
<@eldruin:matrix.org> depending on where you buy your sensor boards, they might be already soldered. Otherwise there is stuff like adafruit qwiic, where all boards have the same connector. However, this is quite the vendor lock-in and your module and MCU choice is pretty limited. Also, the price difference will pay for a cheap soldering iron
<re_irc>
<@lidialiker:matrix.org> I see, thanks folks, I'm buying of amazon in japan so there are some issues with translation đ , but I'll explore some more, thanks for the keywords to look for đī¸
<re_irc>
<@lidialiker:matrix.org> k900:0upti.me: those look like exactly what I need, thanks a lot!
<re_irc>
<@k900:0upti.me> The keyword is "alligator clip" or "crocodile clip"
<re_irc>
<@firefrommoonlight:matrix.org> k900:0upti.me: The RF functionality is different (Second core vice softdevice), but the reg layout isn't much dif. More periphs in some cases
<re_irc>
<@firefrommoonlight:matrix.org> Your scope can decode SPI right?
<re_irc>
<@zentux:zwergenfreun.de> firefrommoonlight:matrix.org: I mean, that is checked during the write and read calls by the hal, other than the overflow nothing there. In my actual application (not the gist I sent at the start and have since modified a bit) it looks like it started working for some reason. Currently investigating that.
<re_irc>
<@zentux:zwergenfreun.de> firefrommoonlight:matrix.org: afaik no
dne has joined #rust-embedded
<re_irc>
<@firefrommoonlight:matrix.org> Uhoh
<re_irc>
<@firefrommoonlight:matrix.org> I think it's time to buy a logic analyzer. You can get the Chinese ones cheap, and use with PulseView software, which is free
<re_irc>
<@firefrommoonlight:matrix.org> Glad to hear it's working in the app!
<re_irc>
<@firefrommoonlight:matrix.org> And yea - I'm also a fan of that problem-solving technique, if you have a known working setup to work with
<re_irc>
<@firefrommoonlight:matrix.org> Ie figure out what's different between the working and non working setups
<re_irc>
<@firefrommoonlight:matrix.org> Eg if your slave device works on one board but not another. Or if one slave device works on a board, but a dif slave device doesn't
<re_irc>
<@fragadaleta:matrix.org> when one finishes the prototype on a breadboard and board dev kit, what happens next?
<re_irc>
<@fragadaleta:matrix.org> I guess you would like to print your project and/or miniaturize it. Right?
<re_irc>
<@fragadaleta:matrix.org> How? Where?
<re_irc>
<@sourcebox:matrix.org> I usually do a PCB design which is then manufactured.
<re_irc>
<@mehmet:grusbv.com> I use Altium (many use open source KiCad) then use Aisler for prototyping (PCBWay), Digikey for parts, solder myself.
<re_irc>
<@sourcebox:matrix.org> I also use KiCad for personal projects, EAGLE for most of client work.
<re_irc>
<@fragadaleta:matrix.org> is there a way to design and outsource manufacturing?
<re_irc>
<@sourcebox:matrix.org> Of course, but it's not really that cheap.
<re_irc>
<@mehmet:grusbv.com> fragadaleta:matrix.org: Yep, I can do it with a price (:
<re_irc>
<@fragadaleta:matrix.org> sure thing, but i mean one doesnt have to print millions. Maybe just a few for a demo or something
<re_irc>
<@sourcebox:matrix.org> I think I misunderstood you.
<re_irc>
<@k900:0upti.me> You can order custom PCBs
<re_irc>
<@adamgreig:matrix.org> lots of places will do PCB soldering for you, including Aisler, JLCPCB, etc, but you're often limited in what parts you can use
<re_irc>
<@fragadaleta:matrix.org> i guess my question is, what if one wants to have options about for instance how much can i miniaturize my project
<re_irc>
<@k900:0upti.me> But you still need to order at least like
<re_irc>
<@k900:0upti.me> A few hundred
<re_irc>
<@k900:0upti.me> For it to be anywhere close to viable economically
<re_irc>
<@adamgreig:matrix.org> nah! you can order qty 5 custom PCBs for $2
<re_irc>
<@adamgreig:matrix.org> just the PCBs, without parts soldered
<re_irc>
<@sourcebox:matrix.org> Manufacturing boards is not so expsensive, but having them designed is.
<re_irc>
<@k900:0upti.me> Well yeah, without soldering is cheap
<re_irc>
<@adamgreig:matrix.org> and assembly in qty 5-30 for a few dollars per board somewhere like jlcpcb, it's quite accessible
<re_irc>
<@adamgreig:matrix.org> even qty 2 or 3 I think is fine with them
<re_irc>
<@k900:0upti.me> Last time I checked, JCLPCB required something like 50 minimum for assembly
<re_irc>
<@fragadaleta:matrix.org> ok got it. So one has to design and then PCB
<re_irc>
<@k900:0upti.me> Uhh
<re_irc>
<@k900:0upti.me> I think we need a bit more detail here ^^"
<re_irc>
<@adamgreig:matrix.org> that must have been a while ago, they're happy to assemble single units
<re_irc>
<@k900:0upti.me> "PCB" just means "printed circuit board"
<re_irc>
<@k900:0upti.me> So you can design your own board using software like KiCad
<re_irc>
<@k900:0upti.me> And that means deciding on all the components, where all the traces go and so on
<re_irc>
<@adamgreig:matrix.org> in fact they have a _maximum_ of qty 30
<re_irc>
<@k900:0upti.me> You can then send that design to a PCB factory that will produce it for you
<re_irc>
<@k900:0upti.me> The actual PCB production process only gives you the board, without the components
<re_irc>
<@k900:0upti.me> But if they have all the components you want in stock and you pay them enough money, they can also install the components
<re_irc>
<@sourcebox:matrix.org> I recommend using KiCad for the design. There are some tutorials on YT about the whole process.
<re_irc>
<@k900:0upti.me> Or you can have them ship the naked board to you and solder it yourself
<re_irc>
<@fragadaleta:matrix.org> got it. But if I have size constraints, who can tell me how small i can go?
<re_irc>
<@k900:0upti.me> Only you can
<re_irc>
<@fragadaleta:matrix.org> from the kicad i guess
<re_irc>
<@k900:0upti.me> The PCB factory will have _some_ limitations on how thin the individual traces can be, how many layers the PCB can have and so on
<re_irc>
<@k900:0upti.me> You'll enter that data into KiCad
<re_irc>
<@sourcebox:matrix.org> If you solder the parts yourself, then it's a question of your soldering skills.
<re_irc>
<@k900:0upti.me> And then try to design an optimal layout
<re_irc>
<@fragadaleta:matrix.org> nie
<re_irc>
<@fragadaleta:matrix.org> nice
<re_irc>
<@fragadaleta:matrix.org> i discovered a new world đ
<re_irc>
<@k900:0upti.me> You need to fit all your components on it somehow, so your lower bound is how densely you can pack them
<re_irc>
<@fragadaleta:matrix.org> apologies for the dumb questions
<re_irc>
<@k900:0upti.me> But realistically you'll need at least some clearance for soldering
<re_irc>
<@k900:0upti.me> Even if you order it prebuilt, the soldering machines they use can't squeeze things right next to each other
<re_irc>
<@k900:0upti.me> But generally all of that should be handled mostly automatically by KiCad
<re_irc>
<@sourcebox:matrix.org> I personally like to use 0805 parts, which are easy to solder but considred already large these days.
<re_irc>
<@sourcebox:matrix.org> 0603 is also doable, but with 0402 it starts to get unpleasant.
<re_irc>
<@k900:0upti.me> (for context, 0805/0603/0402 are part sizes)
<re_irc>
<@sourcebox:matrix.org> Sorry, forgot to mention that.
<re_irc>
<@k900:0upti.me> 0805 is actually the size
<re_irc>
<@k900:0upti.me> It's 8 by 5 ... thousands of an inch?
<re_irc>
<@k900:0upti.me> Furlongs per fortnight?
<re_irc>
<@k900:0upti.me> Some weird hamburger unit
<re_irc>
<@sourcebox:matrix.org> For MCUs, I recommend to use the QFP packages.
<re_irc>
<@k900:0upti.me> (QFP means quad-f...something? package)
<re_irc>
<@sourcebox:matrix.org> Typically, a Cortex-A based chip comes in a BGA package. It has often more than 200 pins, e.g. to connect DDR RAM.
<re_irc>
<@sourcebox:matrix.org> You cannot hand-solder this anymore. It requires to put solder paste been put onto the board via a stencil, put the BGA part on and let the whole PCB run thru a reflow oven.
<re_irc>
<@mehmet:grusbv.com> Fitting in a size is somewhat an incremental process, it has many parameters like which chips and what packaging of those chips.
<re_irc>
<@mehmet:grusbv.com> And layer count and how different layers are connected and the voltages you have.
<re_irc>
<@mehmet:grusbv.com> But given the circumstances, I say area of pcb = twice the area of the components
<re_irc>
<@mehmet:grusbv.com> Could be a good starting point.
<re_irc>
<@xiretza:xiretza.xyz> that's way too low imo, I have an extremely miniaturised PCB from $work next to me right now and it's at least 5-10x the area of its components
<re_irc>
<@sourcebox:matrix.org> frag: When doing your first design, start simple and leave enough space. Use 0805 parts for resistors and capacitors, SOIC packages for logic chips and QFP for MCUs.
<re_irc>
<@k900:0upti.me> (for context, SOIC means "small o...something? integrated circuit" (and you'll see the abbreviation "IC" a lot, generally (yay nested parens)), and MCU means "microcontroller unit", which is a terrible term for modern SoCs)
<re_irc>
<@k900:0upti.me> (also, SoC means "system on a chip")
<re_irc>
<@xiretza:xiretza.xyz> SoC != MCU in my opinion
<re_irc>
<@k900:0upti.me> Well yeah, but most things people call MCUs these days are actually pretty beefy SoCs
<re_irc>
<@xiretza:xiretza.xyz> mostly no MMU though.
<re_irc>
<@k900:0upti.me> If it has no MMU, but has wireless, it's a SoC in my eyes
<re_irc>
<@xiretza:xiretza.xyz> hm, fair
<re_irc>
<@k900:0upti.me> But yeah, MCU is just an old term that people are used to, so you'll see it a lot even for things that aren't really micro or controller units
<re_irc>
<@k900:0upti.me> In reality the line is very blurry
<re_irc>
<@k900:0upti.me> Especially now that we have custom silicon for like smart watches and stuff
<re_irc>
<@firefrommoonlight:matrix.org> OK, it's a dev-like board for a microcontroller
<re_irc>
<@sourcebox:matrix.org> Quote: "An SoC may include a microcontroller as one of its components, but usually integrates it with advanced peripherals like a graphics processing unit (GPU), a Wi-Fi module, or one or more coprocessors."
<re_irc>
<@firefrommoonlight:matrix.org> k900:0upti.me: I've found QFN is easier than QFP, since the most common fault I have in QFP is bridges high up on the pins
<re_irc>
<@firefrommoonlight:matrix.org> which QFN eliminates, and you can fix many QFN soldering faults with flux and running an iron along the affected edge
<re_irc>
<@sourcebox:matrix.org> firefrommoonlight:matrix.org: I use a bevel tip and a good amount of flux.
<re_irc>
<@sourcebox:matrix.org> Not much problems with it.
<re_irc>
<@firefrommoonlight:matrix.org> I'm about to solder a QFP144 from a dev board onto a custom PCB, and am not looking forward to it
<re_irc>
<@firefrommoonlight:matrix.org> Ideally it would be a 48 or 64 pin QFN etc, but I'm stuck with whatever I can remove from dev boards :(
<re_irc>
<@newam:matrix.org> sourcebox:matrix.org: It's overloaded jargon these days :/. I am in the industry of building SoCs and if it has a CPU marketing slaps the SOC label on it, even if it really isn't.
<re_irc>
<@firefrommoonlight:matrix.org> I've been doing some work on third party nRF modules that have nonstandard footprints, where there are squares under it. Not too bad, but I hit a reasonable amount of faults I can fix by re-heating and slightly moving, or redoing from scratch
<re_irc>
<@firefrommoonlight:matrix.org> It sucks since you can't visually inspect them like with QFP or QFN
<re_irc>
<@firefrommoonlight:matrix.org> You also have to make the footprints yourself on those
<re_irc>
<@sourcebox:matrix.org> QFP32 is more easy to solder than QFP64 because it uses 0.8mm pitch instead of 0.5mm.
<re_irc>
<@firefrommoonlight:matrix.org> Oh nice
<re_irc>
<@sourcebox:matrix.org> At least for STM32.
<re_irc>
<@firefrommoonlight:matrix.org> I miss the days when JLC could do the MCU soldering for you
<re_irc>
<@newam:matrix.org> I find a lot of my soldering problems are equipment. It's hard to know what you need until you try it, and it usually isn't cheap to try. A microscope improved my soldering skills a ton.
<re_irc>
<@firefrommoonlight:matrix.org> Good point. I should buy a microscope
<re_irc>
<@firefrommoonlight:matrix.org> Switching from generic to Hakko iron tips made a big diff for me a while back
<re_irc>
<@sourcebox:matrix.org> Some QFN chips also have this thermal pad on the bottom that can be a challenge to solder.
<re_irc>
<@newam:matrix.org> sourcebox:matrix.org: You can usually ignore those for hobby boards. They matter for EMI/thermals, not so much for making it work.
<re_irc>
<@neltnerb:matrix.org> One trick I use is that you should just use solder paste and a solder stencil even if you're using an iron since it gets just the right amount on the pads without any bridges of paste to other pads. Much more controllable.
<re_irc>
<@sourcebox:matrix.org> firefrommoonlight:matrix.org: Definately, I'm using a Hakko FX-951.
<re_irc>
<@neltnerb:matrix.org> I always use solder paste even if I could theoretically use regular
<re_irc>
<@sourcebox:matrix.org> newam:matrix.org: I had some audio codecs which required it.
<re_irc>
<@firefrommoonlight:matrix.org> Yea. I like the MG low temp Sn/Bi/Ag
<re_irc>
<@neltnerb:matrix.org> I've had good luck getting thermals by putting in the typical heat pipes and then putting the board on a hot plate but that's not going to work for a dual sided board
<re_irc>
<@firefrommoonlight:matrix.org> sourcebox:matrix.org: I haven't seen one that doesn't. What makes it hard to solder?
<re_irc>
<@newam:matrix.org> Usually requires some reflow work.
<re_irc>
<@newam:matrix.org> firefrommoonlight:matrix.org: it is under the chip :D
<re_irc>
<@neltnerb:matrix.org> oh, if you don't have a hot air gun to heat up the whole ground plane it's hard to get heat to the right place
<re_irc>
<@sourcebox:matrix.org> firefrommoonlight:matrix.org: You can't reach it with the iron.
<re_irc>
<@firefrommoonlight:matrix.org> Oh. I don't use iron for SMD other than rework
<re_irc>
<@sourcebox:matrix.org> Unless you drill a hole thru the PCB and solder it from the bottom.
<re_irc>
<@neltnerb:matrix.org> eh, I have some cute soldering iron tweezers for pulling up components if I need a lot of heat
<re_irc>
<@sourcebox:matrix.org> Yes, rework makes it possible.
<re_irc>
<@neltnerb:matrix.org> otherwise yeah, hot air is so much more gentle
<re_irc>
<@neltnerb:matrix.org> it's poorly controlled, but if you get one of those butane handheld soldering irons and just don't put in a tip it turns into a butane powered hand-held hot air rework gun
<re_irc>
<@neltnerb:matrix.org> like $20
<re_irc>
<@sourcebox:matrix.org> But since this discussion started with questions from a beginner, we can't assume that he can do rework
<re_irc>
<@neltnerb:matrix.org> I think solder paste and a stencil makes it easier regardless of tools.
<re_irc>
<@neltnerb:matrix.org> =)
<re_irc>
<@firefrommoonlight:matrix.org> I'm in an awkward boat where I can't use a stencil since I have the fab house put on the res/caps, and any ICs they have in stock
<re_irc>
<@firefrommoonlight:matrix.org> and I solder on the ICs
<re_irc>
<@firefrommoonlight:matrix.org> Make lots of mistakes that slow things down and requires rigourous testing :(
<re_irc>
<@firefrommoonlight:matrix.org> *I make the mistakes
<re_irc>
<@sourcebox:matrix.org> Making mistakes is part of the game.
<re_irc>
<@gauteh:matrix.org> Hi, I'm trying to use some C++ code in my embedded project (as a lib). But when I use it in my binary crate it pulls in stdc++ which it can't find for thumbv7.. I have cc.link_std_stdlib(None) and bindgen.use_core() in the lib wrapping the c++ code
<re_irc>
<@gauteh:matrix.org> any ideas about what could cause the -stdc++ line to be emitted when used in the binary, but not when I just build the lib crate itself with the thumbv7 target?
<re_irc>
<@newam:matrix.org> so just to be clear, the C++ code: Are you expecting it to use the standard library or not?
<re_irc>
<@gauteh:matrix.org> No, I'm pretty sure it does not
<re_irc>
<@gauteh:matrix.org> err ok.. hang on, I forgot to use the version with link_stdlib(None)
<re_irc>
<@gauteh:matrix.org> now it works
<re_irc>
<@barafael:matrix.org> If yall don't mind :) I'd appreciate some review and outside opinion on this driver I made: https://github.com/barafael/as5600-rs
<re_irc>
<@barafael:matrix.org> For sure willing to review any other projects in exchange. Thanks!
<re_irc>
<@firefrommoonlight:matrix.org> Does it have to be C++? C interop is easyish, C++ isn't guaranteed to work
<re_irc>
<@gauteh:matrix.org> I wrapped it in C to get it through bindgen, but I didn't want to mess with compiling it as C code in case behavior changes
<re_irc>
<@sourcebox:matrix.org> barafael:matrix.org: I'm not the right one to review this because I'm still relatively new to Rust. What I like to see though is some example code in the README how to use it.
<re_irc>
<@firefrommoonlight:matrix.org> From a quick skim - I like how you have it organized, and have the public API well documented. Def above average
<re_irc>
<@firefrommoonlight:matrix.org> Eg each pub fn says what reg is accesses
<re_irc>
<@firefrommoonlight:matrix.org> IMO that's the way to go for config definitions, and is a great grounding and starting point for writing a lib for an peripheral, MCU-internal or external
<re_irc>
<@firefrommoonlight:matrix.org> Eg the doc comments about what each field does, the u8 repr for internal use (and user QCing against datasheet)
<re_irc>
<@firefrommoonlight:matrix.org> The main thing I'd change there is adding what reg each enum affects in its doc comment. Eg `/// Output stage mode... Sets X register, Y field`
<re_irc>
<@newam:matrix.org> Some quality of life things for developers, you can remove `#![deny(warnings)]` in the `lib.rs` and do `RUSTFLAGS="-D warnings" cargo build` in CI to allow developers to make warnings when it is a work-in-progress, but prevent warnings before the code gets merged.
<re_irc>
<@barafael:matrix.org> actually now that I changed it - the get_ prefix is useless :D
<re_irc>
<@newam:matrix.org> barafael:matrix.org: Yup, that's the idiom in rust anyway :)
<re_irc>
<@barafael:matrix.org> oh, I see, that makes sense i guess - why would a driver own the bus, when it doesn't need to drop it
<re_irc>
<@firefrommoonlight:matrix.org> Btw, the owning concept works great and is clean when you can expect only one thing to use it
<re_irc>
<@firefrommoonlight:matrix.org> This isn't the case for busses
<re_irc>
<@firefrommoonlight:matrix.org> So, my objection (and perhaps the others?) are only because *I2C is a bus*
<re_irc>
<@gauteh:matrix.org> Though the most common approach is to own it. Makes things more convenient, and shared_bus works pretty good
<re_irc>
<@firefrommoonlight:matrix.org> Ie by definition is used by multiple things, which is the reason the owning model isn't great
<re_irc>
<@barafael:matrix.org> yeah I love type state programming but here's a case for owned ref
<re_irc>
<@gauteh:matrix.org> you can't own the &mut either, that will also make it useless for other devices
<re_irc>
<@sourcebox:matrix.org> firefrommoonlight: You remember, we had a lengthy talk here with my shift-register driver problem a few days ago. I ended up using a `&RefCell<T>`.
<re_irc>
<@firefrommoonlight:matrix.org> Nice
<re_irc>
<@barafael:matrix.org> sourcebox: can you link? I also have a shift register driver somewhere
<re_irc>
<@barafael:matrix.org> might need some touch-ups
<re_irc>
<@sourcebox:matrix.org> It's not published yet, needs some work.
<re_irc>
<@sourcebox:matrix.org> To be honest, it's quite a mess ATM.
<re_irc>
<@sourcebox:matrix.org> In the end it should support chains of 74xx595 and 74xx165, also using them together with common clock and latch signals.
<re_irc>
<@barafael:matrix.org> interesting edge case i think i found. I'm including in my docs the readme, using `#![doc = include_str!("../README.md")]`. The purpose is that my code example in the readme should be built as doctest, and the docs from the readme should be in the crate docs.
<re_irc>
<@barafael:matrix.org> So I annotate the rust code in the readme with ````rust`
<re_irc>
<@barafael:matrix.org> but then this code is doing I/O on `/dev/...`, that ain't gonna fly
<re_irc>
<@barafael:matrix.org> but I think there is no way to add `no_run` anymore, or is there?
<re_irc>
<@barafael:matrix.org> never mind - even though the code is no longer highlighted as rust in vscode, `cargo test` compiles it just fine. It's late, I should sleep :)