<re_irc>
<wucke13> I want to do some simple linear algebra without "alloc". Can "ndarray" serve this use case? I have all my matrices with compile time known size simply as "[[f32;COLS];ROWS]". Are there some nice examples somewhere where something similar is done?
<re_irc>
<ryan-summers> Why can't you just use const-generics, if COLS and ROWs are compile time constants?
<re_irc>
<ryan-summers> Ah sorry, I see what you're asking now
<re_irc>
<ryan-summers> It looks like ndarray is no-std enabled, so I don't see why not?
<re_irc>
<wucke13> It looks quite complicated to do even a simple thing like a dot multiplication. I don't understand yet why it would have to be more code with creating the views in the matrices and so on so forth to do a dot multiplication than just writing it with iterators. But for sure there is a nice way of doing it?
tokomak has quit [Read error: Connection reset by peer]
slugbyte has quit [Ping timeout: 240 seconds]
xnor_ is now known as xnor
slugbyte has joined #rust-embedded
<onio>
How do I create an embedded rust vscode build task so it can be called just before debugging starts?
<onio>
I use the following for building "cargo build --example hello" on a command terminal
neceve has joined #rust-embedded
unmanbearpig has quit [Ping timeout: 256 seconds]
Rahix has quit [Ping timeout: 256 seconds]
Socke has quit [Ping timeout: 256 seconds]
Ekho has quit [Ping timeout: 256 seconds]
unmanbearpig has joined #rust-embedded
Rahix has joined #rust-embedded
Socke has joined #rust-embedded
Amadiro has quit [Ping timeout: 250 seconds]
Ekho has joined #rust-embedded
xnor has quit [Remote host closed the connection]
xnor has joined #rust-embedded
<re_irc>
<danielzfranklin> Is it possibly to use interrupts in "defmt_test"? I'd ideally want to write one interrupt for the whole test module that just pushes into a global buffer, which tests can then read from.
<re_irc>
<danielzfranklin> -ideally
<re_irc>
<jchimene> Hi folks - I'm trying to implement transistors using switch_hal. Is it as simple as defining an "InputPin" for the base , an "InputPin" for the collector, and an "OutputPin" for the emitter?
<re_irc>
<jchimene> +Plus some logic to decide when to drive output high or low.
<re_irc>
<pinealservo> In general, no, that won't implement "transistors", which are a large family of analog devices with different properties.
<re_irc>
<pinealservo> Not sure exactly what you're trying to do though, so maybe I am misunderstanding you.
<re_irc>
<jchimene> pinealservo: I'm trying to simulate the transistor circuit that implements content-addressable-memory, particularly TCAM. I'd like to model these circuits to gain a better understanding of the technology
<re_irc>
<jchimene> For example, given the following image, shouldn't it be possible to model it in switch_hal? (from the wikipedia page on the topic)
<re_irc>
<jchimene> * above
<re_irc>
<jchimene> We haven't even gotten to the "why rust?" part.
<re_irc>
<jchimene> * Rust?"
<re_irc>
<jchimene> +Although this may be the wrong room for this topic. It may not be "embedded" in the sense that it's used here, despite the "hal" part.
<re_irc>
<pinealservo> I don't really see what switch_hal is buying you in this scenario.
<re_irc>
<pinealservo> Especially if you are concerned with ternary logic.
neceve has quit [Read error: Connection reset by peer]
<re_irc>
<jchimene> I was hoping to use it to translate the diagram to software. It seems easier to connect objects built from switch_hal to simulate such a TCAM machine. The idea is to build an in-memory array (say Vec<> for now) of these using switch_hal. It's the library I'm trying to leverage. I'd have to build something like this myself anyway.
<re_irc>
However, for this particular project, I am interested in starting from logic gates.
<re_irc>
If you're interested, here's another reference to such technology:
<re_irc>
<pinealservo> For the purposes of learning how the circuit works, something like Verilog might be a better fit.
<re_irc>
<jchimene> This isn't that kind of project.
<re_irc>
<pinealservo> It already encompasses tri-state logic and there's an ecosystem of visualization tools to see what's happening.
<re_irc>
<pinealservo> Isn't what kind of project
<re_irc>
<pinealservo> ?
<re_irc>
<jchimene> I don't need to watch a simulation. I know what it will do. I'm really just interested in understanding how to "model" a transistor in "switch_hal". Do I treat the collector, emitter and base as pins? It would be up to the match and sense line logic to manage the storage and readout of each cell.
<re_irc>
<K900> How does switch_hal even help here
<re_irc>
<K900> If you have no actual hardware to abstract
<re_irc>
<jchimene> It's a library I'd have to write myself.
<re_irc>
<jchimene> The hardware is the circuit picture I posted above.
<re_irc>
<K900> But you have no chip that runs your Rust code
<re_irc>
<K900> And no pins to control
<re_irc>
<jchimene> Yes, I know that. that's why perhaps this room is the wrong place to ask.
<re_irc>
<K900> switch_hal abstracts that
<re_irc>
<K900> It doesn't abstract the general concept of a transistor
<re_irc>
<K900> It's not supposed to
<re_irc>
<jchimene> Oh, it doesn't? that's certainly not the impression I got.
<re_irc>
<pinealservo> There's a nice chapter in SICP on writing a logic simulator.
<re_irc>
<jchimene> It looks like I can simulate circuits by building Vec<>s (for example) of these things.
<re_irc>
<K900> It doesn't, it kinda abstracts controlling a transistor through I/O pins on your chip
<re_irc>
<jchimene> oh.
<re_irc>
<K900> But it doesn't actually simulate anything
<re_irc>
<jchimene> Yeah, I'd have to provide the simulation logic. I just need the framework.
<re_irc>
<K900> It's just an abstraction that allows you to point at an I/O pin on a SoC and say "a transistor is connected to that, turn it on"
<re_irc>
<jchimene> damn.
<re_irc>
<K900> Instead of saying "set that output to high"
<re_irc>
<K900> That's all it does
<re_irc>
<pinealservo> The switch_hal exists to translate between a high-level control function (i.e. Light on vs Light off) and whether it's implemented via active-high or active-low logic.
<re_irc>
<K900> It doesn't actually model anything you care about
<re_irc>
<jchimene> pinealservo: I think that's what I want thop...
<re_irc>
<jchimene> right. it doesn't actually model. So I can't really model a 2 pins in and 1 pin out?
<re_irc>
<K900> No, that's not what you want
<re_irc>
<K900> What you want is a _model_
<re_irc>
<K900> switch_hal is not a model
<re_irc>
<jchimene> I'd have to decide in my simulator when to set a pin high or low, and when to read a pin.
<re_irc>
<pinealservo> At the FET level, you should be modeling everything based on actual wire states at the nodes connecting your FETs.
<re_irc>
<jchimene> I have to write the model. I was hoping switch_hal would provide a nice library to build on.
<re_irc>
<K900> Basically, if you have no actual chip running your Rust code, and no actual transistors connected to it, switch_hal is not for you
<re_irc>
<K900> Though realistically you probably want Verilog or Amaranth
<re_irc>
<xiretza> s/Verilog/VHDL/
<re_irc>
<xiretza> unless you like pain
<re_irc>
<xiretza> +and hate types
<re_irc>
<K900> I'm not sure which is worse tbh
<re_irc>
<pinealservo> Well, the goal here seems to be to write the simulator rather than to understand what the circuit does.
<re_irc>
<K900> But yeah if you want a sane HDL, just use Amaranth
<re_irc>
<jchimene> pinealservo: Right. The circuit is well-known. I'm more interested in how TCAM can be used in Rust. It's an embedded problem in some senses.
<re_irc>
<K900> That's a completely different problem
<re_irc>
<K900> Do you actually want to simulate a circuit
<re_irc>
<K900> Or do you want to talk to a piece of hardware
<re_irc>
<K900> Because the ways you do that are very very very very different
<re_irc>
<jchimene> Rust's tuples are already a form of CAM. I'm looking at leveraging tuples for that pupose.
<re_irc>
<K900> Rust or not
<re_irc>
<jchimene> I was hoping to simulate a transistor, gang the transistors to a TCAM cell, gang the TCAM cells, ...
<re_irc>
<K900> And then what?
<re_irc>
<jchimene> The hook the mess to a tuple-based CAM library
<re_irc>
<pinealservo> Don't you already know what that will do as well?
<re_irc>
<K900> Simulating hardware and controlling hardware are two very different things
<re_irc>
<pinealservo> What it won't do is give you an efficient implementation.
<re_irc>
<jchimene> If it works, the software can be abstracted away, and you're left with something that will attach to real hardware.
<re_irc>
<K900> Also, what is a "tuple-based CAM library"?
<re_irc>
<jchimene> I don't know if it will work. CAM seems an underused technique in Rust
<re_irc>
<jchimene> K900: It's similar to how Mumps uses tuples to implement CAM
<re_irc>
<K900> What is Mumps, and what is CAM?
<re_irc>
<jchimene> I don't know if it will work. CAM seems an underexplored technique in Rust
<re_irc>
<K900> You're making a lot of assumptions here
<re_irc>
<K900> Largely about the fact that we have any idea what you're talking about
<re_irc>
<jchimene> Mumps is a data processing language. My first exposure to it was in laboratory data collection systems on VAX hardware.
<re_irc>
CAM is content addressable memory. Hashes are a form of that. Also "stem-and-leaf"
<re_irc>
<jchimene> Hashes are nodes in search space. stem-and-leaf describes the edges that connect the nodes.
<re_irc>
<jchimene> Sorry! I assume too much. I appreciate your patience!
<re_irc>
<K900> So what are you actually trying to do? Are you trying to drive a content addressable memory IC from Rust?
<re_irc>
<jchimene> The scripting language REXX also implements stem-and-leaf
<re_irc>
<K900> Are you trying to _design_ a content addressable memory IC?
<re_irc>
<jchimene> No, I assume such a thing will exist. I'm more interested in how to transform Rust tuples to TCAM
<re_irc>
<K900> What do you mean by "transform Rust tuples" then?
<re_irc>
<pinealservo> With a HashMap?
<re_irc>
<K900> A Rust tuple is just a bunch of data
<re_irc>
<K900> You can't transform data to hardware
<re_irc>
<K900> You can have a piece of hardware process a piece of data
<re_irc>
<jchimene> Honestly, I'm not quite sure. I have several ideas
<re_irc>
<K900> Ideas of what?
<cr1901_>
Rust is not a Hardware Description Language (HDL)
<re_irc>
<jchimene> 1 -> transform tuple objects
<re_irc>
<pinealservo> CAM isn't a purely hardware thing; git, for example, is a content-addressable source code store.
<re_irc>
<jchimene> For example, construct a tuple of n (n < 12?) objects where each object has a hash signature
<re_irc>
<jchimene> The hash signature is what gets sent to the CAM machine
<re_irc>
<jchimene> as a tuple
<re_irc>
<K900> There is no such thing as "a tuple" in hardware
<re_irc>
<pinealservo> Again, you're describing a hash table, i.e. HashMap.
<re_irc>
<K900> Correct me if I'm wrong, but content addressable memory is basically a hardware lookup table
<re_irc>
<jchimene> Yes, I know there's no such thing. Conceptually, a chain of hash maps is fine.
<re_irc>
<K900> So why do you need to "transform" anything?
<re_irc>
<K900> If you have a piece of hardware like that, all you need is a driver that exposes a set operation and a get operation
<re_irc>
<K900> Like a normal in-memory HashMap would
<re_irc>
<K900> You can build that driver in any language, it can be Rust, C, Ada, MicroPython, there's nothing language specific to it
<re_irc>
<pinealservo> There's actually a bunch of stuff in the Linux kernel's network code for interfacing with CAM/TCAM hardware in fancy enterprise networking cards for SDN.
<re_irc>
<jchimene> Yes, networks use TCAM for address lookups.
<re_irc>
<jchimene> That's the embedded space.
<re_irc>
<jchimene> s/networks/routers/
<re_irc>
<K900> But you want to... simulate something to then do something to transform something to something tuples
<re_irc>
<K900> And I don't think anyone here understands what you're actually trying to do
<re_irc>
<K900> As in what you want the result of all of that work to be
<re_irc>
<jchimene> Yeah, I know it sounds weird.
<re_irc>
<K900> Like, imagine you did the thing
<re_irc>
<K900> What is the thing that you did?
<re_irc>
<K900> What does it look like?
<re_irc>
<K900> How do you use it?
<re_irc>
<jchimene> stem-and-leaf occurs in medical settings. For example, longitudinal patient surveys during drug trials.
<re_irc>
<jchimene> It's incredibly helpful when managing missing data
<re_irc>
<jchimene> Consider a directed acylic graph
<re_irc>
<K900> No, stop
<re_irc>
<K900> You're trying to explain theory again
<re_irc>
<jchimene> Such things are very hard to do with hash tables
<re_irc>
<K900> I'm not asking you about the theory
<re_irc>
<K900> I'm not asking you about why you want to do the thingn
<re_irc>
<pinealservo> Sure, but there's no need to model transistors to do a content-addressed medical data store.
<re_irc>
<K900> * thing
<re_irc>
<K900> I want you to explain what the thing _is_
<re_irc>
<K900> Is it a piece of hardware?
<re_irc>
<jchimene> pinealservo: Of course. This is a personal project.
<re_irc>
<K900> Is it software that interacts with existing hardware?
<re_irc>
<K900> Is it a model of a piece of hardware?
<re_irc>
<jchimene> K900: The store itself will be a piece of hardware. It doesn't exist.
<re_irc>
<pinealservo> You've said you understand what the circuit does, so I don't understand the point of modeling it at the transitor level.
<re_irc>
<K900> jchimene: But do you want to build it?
<re_irc>
<K900> Or do you want to build a model of it?
<re_irc>
<jchimene> pinealservo: It was merely an exercise in learning more about Rust.
<re_irc>
<K900> The vibe I'm getting right now is kind of what I'm getting from blockchain people a lot of the time
<re_irc>
<jchimene> K900: Ouch!
<re_irc>
<K900> Blockchains are inherently cool and good therefore we can take a thing and Do A Blockchain to it and that will be cool and good because that's what blockchains are
<re_irc>
<jchimene> brb
<re_irc>
<K900> And there's no real problem statement and no real goal, just the idea that throwing blockchain at things will lead to... something good
<re_irc>
<K900> And I'm sorry but I'm getting the same vibe here
<re_irc>
<K900> Like you have a piece of tech that you think is cool, and another piece of tech that you think is cool, and you just want to smash them together somehow
<re_irc>
<K900> But you don't actually know how, or, most importantly, _why_
<re_irc>
<jchimene> give me a few minutes and I'll find some references to stem-and-leaf storage. The best explanations are in the form of tuples.
<re_irc>
<K900> And now you're back to trying to convince me that your tech is cool
<re_irc>
<jchimene> No, I don't right now. That's kind of the point of exploration, isn't it? :)
<re_irc>
<K900> Which is not at all the point
<re_irc>
<jchimene> I've go to go to the post office,
<re_irc>
<jchimene> No, I don't say it's cool, only if switch_hal can be used. Which it probably can't....
<re_irc>
<pinealservo> Writing a gate-level logic simulator just because you want to do that is a fine thing to do. I don't think switch_hal will actually help with it, though. Your main issue will be how to deal with the fact that memories are inherently feedback-based systems, so you will have to model the system's state over time.
<re_irc>
<pinealservo> That is not what I'd do if I was interested in exploring content-addressable memory in Rust, though.
<re_irc>
<pinealservo> But if this is just personal projects for your own learning and fun, and you think it sounds like fun to interface your higher-level code to a gate-level model of your content store, then go for it!
<re_irc>
<pinealservo> I think we're all in agreement that the abstraction provided by switch_hal is probably not a good fit for a gate-level logic simulation though. If you need a translation layer, it probably makes the most sense at the simulated hardware/software interface; i.e. something that inverts all the bits in a number before asserting it to the hardware as the lookup value, if such a thing is necessary.
<re_irc>
<jchimene> pinealservo: very helpful! thnks!
<re_irc>
<jchimene> pinealservo: What would you do?
cr1901_ is now known as cr1901
<re_irc>
<pinealservo> Depends on what sort of memory I wanted to model and how efficient it needed to be. Lots of CAM types can be modeled with a hash table, others with a radix tree or some other search tree, or if the set of items is small, just a Vec of (key, value) tuples w/linear search.
<re_irc>
<theunkn0wn1> So, say I have arm based cpu running Linux, that they're isn't any BSP for.
<re_irc>
Say I just want to drive a mmio peripheral and an willing to write said driver. How can I access this mmio peripheral?
<re_irc>
<sajattack> once you have a driver that implements an ioctl, you can use nix::ioctl_read, not sure if that answers the question but it's one way I got through a similar exercise
<re_irc>
<theunkn0wn1> Not sure that does. To rephrase:
<re_irc>
How can I define the register structure of the peripheral, and how can I actually mmap it?
<re_irc>
<sajattack> ah, yeah not sure, in my case the driver was already written and I was trying to interface it to rust on linux
<re_irc>
<adamgreig> theunkn0wn1: You can just read and write memory like on bare metal if you want
<re_irc>
<adamgreig> It's not really the Linux Way I guess? I've only ever done this, not written an actual driver, but for very very quick and dirty...
<re_irc>
<jchimene> pinealservo: Those are all describing nodes. There are other ways to build CAM. My particular interest is stem-and-leaf. It looks like a builder pattern:
<re_irc>
"patient.address.state" or "patient.cohort" or "cohort.patient" type constructions where "patient", "cohort", "address", "state" are members of an n-ary tuple
<re_irc>
(address,patient) or (cohort,patient) .
<re_irc>
Such constructions describe the graph edges. In Perl, the structure you are describing with the extension I'm moving towards is called a "tied hash", except that it, too, describes a single hash entry, rather than the path to that entry.
<re_irc>
<theunkn0wn1> adamgreig: How would I go about doing that?
<re_irc>
And yes, this is for a quick and dirty thing
<re_irc>
<jchimene> BTW: I thinkk kaze/vhdl is what I was looking for.
<re_irc>
<adamgreig> hold a sec, I'll dig up a link to some gross thing
<re_irc>
<adamgreig> but on hosted linux your addressable memory space is virtual from userspace, right?
<re_irc>
<theunkn0wn1> I have no idea
<re_irc>
<adamgreig> I guess you then mmap it...
<re_irc>
<adamgreig> yea, I think that is basically what I was doing in my weird c example
<re_irc>
<adamgreig> so call mmap to set up the mapping of your peripheral's physical memory into your process's virtual memory space, then use tock-registers or other abstraction of your choice (or just structs...) to access fields?
<re_irc>
<theunkn0wn1> The original impl invokes devmem from the cli