<re_irc>
<@adamgreig:matrix.org> if you want to put a buffer in sdram just stick `#[link_section(".sdram_bss")]` on it
<re_irc>
<@xnorman:matrix.org> I guess I don't know enough to know how to avoid the stack.. like, if i somehow get blah: &mut Blah that is stored in SDRAM would *blah = postcard::from_bytes(...) avoid the stack?
<re_irc>
<@adamgreig:matrix.org> note it won't be initialised to anything, not 0 and not valid data
<re_irc>
<@adamgreig:matrix.org> putting _code_ in another memory/ram is trickier, but just having a buffer live there is relatively easy
<re_irc>
<@adamgreig:matrix.org> I'm not sure about postcard to know if/how to make it deserialise into your sdram buffer, perhaps you can pass it a &mut to deserialise into? if it just returns a value you might be out of luck getting it off the stack
<re_irc>
<@adamgreig:matrix.org> (but like I said, at first glance this object should fit on the stack OK, so it would be worth confirming exactly what's going wrong...)
<re_irc>
<@xnorman:matrix.org> adamgreig: so.. .sdram_bss .. I assume then I should still initialize my sdram in my initialization routine, but then not try to access the data beyond those specified with the link_section attribute?
<re_irc>
<@adamgreig:matrix.org> what initialisation are you doing at the moment?
<re_irc>
<@adamgreig:matrix.org> from a quick look at postcard's api I don't see any obvious way to have it avoid stack allocating the object being deserialised
<re_irc>
<@adamgreig:matrix.org> and worse I guess you might end up with two (or more?) stack allocations for it for the various stack frames
<re_irc>
<@adamgreig:matrix.org> (I don't think there's any question about putting code into ram, only data)
<re_irc>
<@xnorman:matrix.org> yeah.. i'm only considering putting data there
<re_irc>
<@xnorman:matrix.org> cool.. well i'll first see if the hardfault handler gets hit,
<re_irc>
<@adamgreig:matrix.org> right, that bit of code you links sets up the chip to allow access to the sdram memory
<re_irc>
<@adamgreig:matrix.org> so that must still be present
<re_irc>
<@adamgreig:matrix.org> but to actually place any data into the sdram memory, you need to use `#[link_section(".sdram_bss")]` to locate the buffer
<re_irc>
<@adamgreig:matrix.org> you might consider renaming it to just ".sdram" in your memory.x, it's a bit confusing calling it _bss when nothing will actually zero it
<re_irc>
<@adamgreig:matrix.org> but so long as the names match in memory.x and in your `link_section` attribute you can call it whatever you like
troth has quit [Ping timeout: 252 seconds]
<re_irc>
<@xnorman:matrix.org> okay, so if i did that, i just have to make sure i wait to access it until after the initialization and likely wrap it in something like MaybeUninit then explicitly init after the sdram is setup?
<re_irc>
<@xnorman:matrix.org> by "wrap it" i mean.. the thing i have in the link section
<re_irc>
<@adamgreig:matrix.org> yea
<re_irc>
<@adamgreig:matrix.org> that's useful for later but I don't know that it will help you right now
<re_irc>
<@xnorman:matrix.org> cool. so the library that this library uses gives me a pointer to the sdram.. i figure i should not use that at all and only use link_section if i'm using any link_section huh?
<re_irc>
<@adamgreig:matrix.org> you probably want it to pass to your sdram_init method or whatever, because that needs the start and lenght of the whole sdram section to configure the MPU there
<re_irc>
<@adamgreig:matrix.org> but you wouldn't want to use the raw pointer to actually access the sdram in general, that would be quite inconvenient
<re_irc>
<@xnorman:matrix.org> but yeah.. i'd be jumping into trying to trigger the handler but i'm about to have to leave so i'm asking questions i've been meaning to ask for a while anyway :)
<re_irc>
<@adamgreig:matrix.org> you could, it would work, but it'd require unsafe everywhere and be annoying for arrays and all that... much simpler to just place a static array into sdram section, I think
<re_irc>
<@xnorman:matrix.org> yeah. that sounds good!
<re_irc>
<@xnorman:matrix.org> thanks again.. i'll probably report back if/when i figure out whats up.. in case anyone cares :) but i might have to wait until i get another hack night
<re_irc>
<@adamgreig:matrix.org> 👍️ good luck! this sort of thing can be a real pain to debug but sometimes you work out exactly what the problem is and fix it which is nice :)
<re_irc>
<@xnorman:matrix.org> yeah, i would generally rather know whats wrong than just work around it
<re_irc>
<@xnorman:matrix.org> cuz often, something is still wrong and you end up having to fix it later anyway
<re_irc>
<@xnorman:matrix.org> gotta run now!
troth has joined #rust-embedded
bpye has quit [Ping timeout: 268 seconds]
troth has quit [Ping timeout: 268 seconds]
bpye has joined #rust-embedded
troth has joined #rust-embedded
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
cr1901 has quit [Remote host closed the connection]
cr1901 has joined #rust-embedded
cr1901 has quit [Remote host closed the connection]
cr1901 has joined #rust-embedded
cr1901 has quit [Remote host closed the connection]
cr1901 has joined #rust-embedded
cr1901 has quit [Remote host closed the connection]
cr1901 has joined #rust-embedded
<re_irc>
<@dngrs:matrix.org> so after reading some FTDI app notes I've improved my fifo jitter but it's not perfect, however said app notes have convinced me the remaining issue is USB scheduling by the OS so I'll probably not get around that, unless I figure out how to change sched priority
<Darius>
I have used FTDI serial dongles to synchronise PC clocks via NTP (reading from a GPS) engine.. IME USB jitter is surprisingly good
<Darius>
what sort of level of jitter are you talking abou?
<re_irc>
<@k900:0upti.me> For your first device, I'd honestly get something with already soldered headers
<re_irc>
<@fragadaleta:matrix.org> for a rust toolchain of course
<re_irc>
<@fragadaleta:matrix.org> totally
<re_irc>
<@fragadaleta:matrix.org> but how about the debug options?
<re_irc>
<@fragadaleta:matrix.org> the MDK has DAPLink
<re_irc>
<@fragadaleta:matrix.org> the other has SWD
<re_irc>
<@fragadaleta:matrix.org> i have no clue which one should i start with
<re_irc>
<@k900:0upti.me> No real difference
<re_irc>
<@fragadaleta:matrix.org> ok then
<re_irc>
<@k900:0upti.me> Actually
<re_irc>
<@k900:0upti.me> Probably yes difference
<re_irc>
<@k900:0upti.me> DAPLink runs on a second chip on the board itself
<re_irc>
<@k900:0upti.me> SWD is just a protocol, so you'll need an external debugger
<re_irc>
<@k900:0upti.me> Generally both will work just fine
<re_irc>
<@k900:0upti.me> But the external debugger part is important
<re_irc>
<@fragadaleta:matrix.org> so i go with the second board? the one with DAPlink?
<re_irc>
<@k900:0upti.me> If you want the best out of the box experience, probably yeah
<re_irc>
<@fragadaleta:matrix.org> thank you K900
<re_irc>
<@k900:0upti.me> But if you're getting into those form factors, you might as well try and get a blue pill IMO
<re_irc>
<@k900:0upti.me> They're like $5
<re_irc>
<@k900:0upti.me> You're going to need an external debugger for that one too, but noname Chinesium ST-Link debuggers are like $2 a pop on Aliexpress
<re_irc>
<@k900:0upti.me> I guess the question is, do you want to pay more for something that works better out of the box
<re_irc>
<@k900:0upti.me> Or are you a cheap asshole like me
<re_irc>
<@fragadaleta:matrix.org> ahha i wanna focus on what matters now having the least amount of headaches
<re_irc>
<@fragadaleta:matrix.org> so i guess an out of the box solution would make me focus on the programming and flashing part
<re_irc>
<@fragadaleta:matrix.org> and debugging
<re_irc>
<@k900:0upti.me> Also here's a fun weekend crime: those ST-Link debuggers are actually usually STM32s on a small board, so you can buy two of them, rip one open, and use the other to debug it, or flash it to do something completely different
<re_irc>
<@fragadaleta:matrix.org> btw the search engine of digikey ducks
<re_irc>
<@k900:0upti.me> It's hands down the cheapest way I know of to obtain USB-capable boards
<re_irc>
<@fragadaleta:matrix.org> *sucks
<re_irc>
<@9names:matrix.org> all of the electronics suppliers i've ever tried have terrible search, it's only a question of how bad
<re_irc>
<@k900:0upti.me> Sparkfun is decent
<re_irc>
<@k900:0upti.me> And Adafruit
<re_irc>
<@k900:0upti.me> Basically all the "hobbyist" sites
<re_irc>
<@k900:0upti.me> The big guys probably don't care much about the search, because if you're going to them, you already know the part number
<Lumpio->
You should be able to, since SD cards talk plain SPI
<Lumpio->
It's not as fast as using the full interface but I'd imagine it's plenty fast for some audio.
<re_irc>
<@fragadaleta:matrix.org> ah interesting so i'd have a bandwidth of ~60 Mbps, which should be enough to store in real-time
<re_irc>
<@fragadaleta:matrix.org> thanks!
<Lumpio->
Where'd you get 60Mbps from?
<Lumpio->
That sounds pretty high for SPI
<re_irc>
<@fragadaleta:matrix.org> that's what SPI can do
<re_irc>
<@fragadaleta:matrix.org> i think...
<Lumpio->
also fwiw audio is move like 60...kbps
<Lumpio->
more like*
<Lumpio->
And you can definitely get many times that
<Lumpio->
btw what comes to soldering headers, do you have a local makerspace or something similar you could go to?
<Lumpio->
Learning basic soldering would expand your possibilities by a lot
<Lumpio->
Plus they usually have the equipment to do that so you don't have to buy it yourself.
<re_irc>
<@fragadaleta:matrix.org> heisenbridge:psion.agg.io: yeah i believe i should find one
<re_irc>
<@fragadaleta:matrix.org> heisenbridge:psion.agg.io: for the time being i want to focus on the coding part. And then buy myself a 60w soldering station to expand my possibilities
<re_irc>
<@fragadaleta:matrix.org> that's why i am preferring out of the box solutions for now
<Lumpio->
alright
<Lumpio->
wow I just looked at the Matrix side, this bridge is really noisy
<Lumpio->
On most channels it's just nicer
<re_irc>
<@yatekii:matrix.org> yeah idk what changed. now the messages look really spammy. this was no issue before
<re_irc>
<@dngrs:matrix.org> irc_libera_darius:psion.agg.io: I'm trying to do sustained 40mbyte/s sync FIFO reads to build an el cheapo logic analyzer. It seems there's always the occasional frame drop, and during some test runs there's a *lot* of them
<Darius>
oh, I wouldn't really call that jitter
<Darius>
bulk USB is pretty spotty at those rates
<Darius>
FWIW at work we stream radar data via a Cypress FX2 and it is difficult to reliably get >15MByte/sec without dropping anything :(
<re_irc>
<@korken89:matrix.org> dngrs:matrix.org: If you use an FT600 + the cheapest ECP5 you should get a hacky ~250 MB/s logic analyzer for ~30-40 euros :)
<re_irc>
<@korken89:matrix.org> Though that's entering FPGA land, and all the complexities that comes with that
<re_irc>
<@korken89:matrix.org> The FT600 series is quite nice though
<re_irc>
<@dngrs:matrix.org> It's mostly driven by curiosity at this point, like wouldn't it be cool to do 40mbyte with a 3€ board
<re_irc>
<@dngrs:matrix.org> But now that you mention it maybe I should play around with my ULX3S more
<Darius>
maybe I should take a look
<Darius>
how unobtanium are they? :D
kehvo has joined #rust-embedded
<re_irc>
<@therealprof:matrix.org> korken89:matrix.org: At those speeds you're in for some fun electrical surprises, glimpsing into FPGA land is probably one of the lesser challenges. 😉
<re_irc>
<@korken89:matrix.org> Or a loooot in parallel ;)
<re_irc>
<@korken89:matrix.org> I mean 250 inputs 1 MHz :D
creich has quit [Remote host closed the connection]
creich has joined #rust-embedded
creich has quit [Remote host closed the connection]
creich has joined #rust-embedded
creich has quit [Remote host closed the connection]
<re_irc>
<@adamgreig:matrix.org> Lumpio-: I kicked the bridge a bit, try again? it's meant to puppet irc users on matrix side, but if the puppet isn't working it falls back to writing your message from itself
<Lumpio->
Hello
<re_irc>
<@adamgreig:matrix.org> looks good
<Lumpio->
Definitely less chatty now
<re_irc>
<@mvirkkunen:matrix.org> I can still see a lot of freenode ghosts on this side, wonder if that's causing it to show the entire Matrix username (duplicate display name)
<re_irc>
<@mvirkkunen:matrix.org> My Matrix name has a fancy unicode dash in hopes to avoid that heh
<re_irc>
<@adamgreig:matrix.org> freenode? they really shouldn't be there any more...
<re_irc>
<@mvirkkunen:matrix.org> At least there's a lot of users with "freenode" in the name, but I dunno how it works
<re_irc>
<@thejpster:matrix.org> dngrs:matrix.org: Speaking of ramfuncs, just make this mut...
<re_irc>
<@thejpster:matrix.org> Also the RP2040 can capture 32-bit input at full clock rate using PIO. You just can't get it out again, so you are limited by RAM size to maybe 500us worth.
Guest91 has joined #rust-embedded
Guest91 has quit [Client Quit]
<re_irc>
<@9names:matrix.org> This is not a bad option if you have a beaglebone black gathering dust: