|
hobbesmaster posted:if you have c++11 look at std::atomic and let the compiler deal with it also rust
|
# ? Jan 23, 2017 20:41 |
|
|
# ? May 16, 2024 18:12 |
|
Probably the only universally safe way to do this on ARM is using the bitband regions (google it). ARM's atomic ops are of the load reserved/store conditional variety. This protects you against interrupt pre-emption between the load and the store but it does not protect you against the register itself changing under your feet. Well-designed micros don't do that, they always have separate command and status registers, but you should check the data sheet just to be sure. Whether LLVM bitcode has a way of faithfully expressing ARM atomic ops I don't know.
|
# ? Jan 23, 2017 20:42 |
|
^^ not on m0s, right? std::sync::atomic then but I would inspect the assembly output if you have interrupts because you don't have the exclusive instructions hobbesmaster fucked around with this message at 20:46 on Jan 23, 2017 |
# ? Jan 23, 2017 20:43 |
|
JawnV6 posted:yeah, whatever you're reading has other bits set that you don't want to perturb. so you need a read (to figure out what's already set), modify the one bit of interest, then a write with your new value or just target a different processor with bit set/bit clear instructions for atomic bit modification!
|
# ? Jan 23, 2017 21:07 |
|
@microcontroller_dril Do I have the best-designed peripheral layout register imaginable? No. But, do I at least have robust atomic load and store ops to make the best of a bad situation? Also no.
|
# ? Jan 23, 2017 21:16 |
|
Bloody posted:or just target a different processor with bit set/bit clear instructions for atomic bit modification! i phrased it that way because i thought Rust had some under-the-hood thing that would generate a mutex/lock for you but yeah MSP430 bis/bic supremacy
|
# ? Jan 24, 2017 00:50 |
|
Harik posted:I need to either magic up an analog pedal in the space constraints of the current "go button" fake pedal, or just implement soft-start speed ramping on my micro. look at how guitar foot pedals are done, you can either go geared potentiometer or led blocking wedge into the middle of a homemade vactrol in that size easily you'll need to rig a return spring obvs and a kill switch on the dash
|
# ? Jan 24, 2017 05:27 |
|
Storysmith posted:look at how guitar foot pedals are done, you can either go geared potentiometer or led blocking wedge into the middle of a homemade vactrol in that size easily is just going to a junkyard and spending $7.59 for a dbw pedal out of the question? although i dunno if the jy would try to call it a pedal + sensor, in which case it'd be like, over $20 and gently caress that
|
# ? Jan 24, 2017 05:42 |
|
samd21g manual posted:Before entering the STANDBY sleep mode the user must make sure that a significant amount of clocks i love this sentence, it's my favourite one so far. now i feel like a hardware programmer. nothing is absolute, there are no hard limits
|
# ? Jan 24, 2017 19:41 |
|
enjoy your new life of going through 1000 page reference manuals to find the one number you need
|
# ? Jan 24, 2017 19:55 |
|
also, the number is wrong
|
# ? Jan 24, 2017 20:34 |
|
also the peripheral doesn't work, and the solution in the errata is "don't use it"
|
# ? Jan 24, 2017 20:39 |
|
and its the on every rev of the chip
|
# ? Jan 24, 2017 20:44 |
|
exhaustive list of microcontrollers whose DMAs work as advertised:
|
# ? Jan 24, 2017 20:44 |
|
idk the EFM32's DMA worked pretty well i.m.e. and I did some fairly aggressive poo poo with it, driving multiple I2C buses as well as a SPI bus now, i was but a baby embdev at the time, and didn't realize that driving a slow i2c bus with the dma controller instead of an interrupt-driven fsm was massive overkill but it worked
|
# ? Jan 24, 2017 23:24 |
|
gonadic io posted:I'm switching my code to properly use volatile read and writes, which correspond directly to the llvm instructions: http://llvm.org/docs/LangRef.html#volatile-memory-accesses depending on the register (more common for registers the designers think will be frequently twiddled) you may have strobe interfaces, where you have a SET register you can write to and it'll set any bit that was a 1 in the write to the set. so you don't have to read it
|
# ? Jan 25, 2017 14:49 |
|
i think i'm doing something dumb here. i'm trying to enable the RTC, by setting the mode, prescaler, and enable bits as instructed. the enable bit is synced, so according to: samd21g manual posted:When executing an operation that requires synchronization, the Synchronization Busy bit in the Status i'm writing to CTRL.ENABLE and then waiting on the STATUS.SYNCBUSY bit. code:
but if i attempt to wait for the syncbusy, then it waits indefinitely. i've checked, and clock/power to the RTC is enabled on reset. the enable bit IS set when i write to it (and is zero before). i've checked that the syncbusy bit is zero before the operation, and as far as i can tell you don't need to do anything to enable the sync functionality. i tried setting all of my interrupts to just immediately return too, but no difference there. the syncbusy bit just...isn't set... e: hmm, let me fiddle around with the global clock a bit gonadic io fucked around with this message at 13:27 on Jan 26, 2017 |
# ? Jan 26, 2017 10:28 |
|
From the description, I think the syncbusy bit is clearing itself automatically after you enable the RTC, you don't need to poll on it. e: In other words, the syncbusy may go high for a few cycles immediately after the RTC is enabled but then it goes low again before your `while (*rtc).status.get() != 0 {}` executes. Jerry Bindle fucked around with this message at 15:13 on Jan 26, 2017 |
# ? Jan 26, 2017 15:09 |
|
You're not waiting for the SYNCBUSY bit in the STATUS register to be clear, you are waiting for the entire STATUS register to be zero.
|
# ? Jan 26, 2017 15:22 |
|
Update: I got openocd working and managed to crash gdb a bunch
|
# ? Jan 26, 2017 15:31 |
|
Sapozhnik posted:You're not waiting for the SYNCBUSY bit in the STATUS register to be clear, you are waiting for the entire STATUS register to be zero. I did an & 1 << 7 too, sync busy is the only bit on that register.
|
# ? Jan 26, 2017 15:32 |
|
Barnyard Protein posted:From the description, I think the syncbusy bit is clearing itself automatically after you enable the RTC, you don't need to poll on it. If that was low, then the loop would never iterate.
|
# ? Jan 26, 2017 16:14 |
|
gonadic io posted:If that was low, then the loop would never iterate. oh i see, i think i got confused because you said it never gets set... if you have access to a field engineer, it might make your life easier to ask them. the most frustrating thing to me is not being able to tell if firmware is wrong, or if i've found a silicon bug. its really difficult to confirm a silicon bug diagnosis unless you've got someone at the sausage factory willing to tell you. good luck!
|
# ? Jan 26, 2017 17:08 |
|
post the disasm
|
# ? Jan 26, 2017 17:42 |
|
Sapozhnik posted:post the disasm will do. i'm fairly sure this is something i'm doing wrong, i guess i'll go back to C until i get it working
|
# ? Jan 26, 2017 17:59 |
|
is "rtc" marked as volatile? if not the compiler will likely transform the loop to one memory access followed by an [effectively] infinite loop.
|
# ? Jan 26, 2017 20:20 |
|
Spatial posted:is "rtc" marked as volatile? if not the compiler will likely transform the loop to one memory access followed by an [effectively] infinite loop. yep it is. i even put asm!(""); in the loop but no change.
|
# ? Jan 26, 2017 20:35 |
|
Sapozhnik posted:post the disasm this is the next step when C messes up too
|
# ? Jan 26, 2017 22:42 |
|
double post, but I took a look at the repo you're setting up a struct with all the variable names, then instantiating it at the right base address? im assuming the [#c] bit is saying "lay this out like a dumb C POD struct, don't reorder, don't collapse". it might generate the right asm, but I'd be reluctant to give that much choice to the compiler. i'd want to know at the site I'm writing to a device exactly how wide that access will be, seems like you might specify writing to a byte-sized chunk and ending up with a 4-byte unaligned access somewhere i wouldn't change the names at all. you have a couple deltas, more friendly names, replacing vowels, etc. idk, maybe it's just my terrible practices but if a name doesn't come up with a grep -iRl i'd probably assume it doesn't exist
|
# ? Jan 27, 2017 06:00 |
|
JawnV6 posted:double post, but I took a look at the repo that's what im doing yeah. i have mostly been adapting the original files, so samd21g18a.h containing: #define PORT ((Port *)0x41004400UL) /**< \brief (PORT) APB Base Address */ becomes samd21g18a.rs with: pub const PORT: *mut PIO = 0x41004400 as *mut PIO; // (PORT) APB Base Address and then code:
code:
then later i'll wrap this in methods that make more sense from the outside and obey the occasional read-only/write-only register. gonadic io fucked around with this message at 08:00 on Jan 27, 2017 |
# ? Jan 27, 2017 07:57 |
|
that preserves the granularity, but in rtc.rs there's byte widths?code:
|
# ? Jan 27, 2017 22:30 |
|
JawnV6 posted:that preserves the granularity, but in rtc.rs there's byte widths? are you talking about the arrays or the reserved field? that's the definition right out of the manual, but instead of a single u16 field they're bitflags so i split them up.
|
# ? Jan 28, 2017 18:02 |
|
hmm, i think i may have broken my arduino by flashing the wrong thing. i was trying to upload using openocd and flashed the wrong section of memory. anyway after reburning the bootloader using the ide (Amtel EDBG) i have blink.rs working again but can't load the globals anymore. i got the debugger working and it's going into the hard fault interrupt handler so i guess im making trying the stuff in http://www.freertos.org/Debugging-Hard-Faults-On-Cortex-M-Microcontrollers.html is this a thing that's possible to have hosed it up? the offending code is identical to what was working before* i checked the addresses of the linker variables: code:
code:
|
# ? Feb 3, 2017 14:41 |
|
if you want to go down the debugging path, make yourself handlers for the other faults that result in a HardFault if unhandled then read out the status registers associated with whichever one you're triggering. on a CM4, sometimes you get the the address of an offending instruction directly. EDIT: if you have a real debugger attached, don't worry about the assembly. you can just set a breakpoint in the hook and inspect the registers and stack. yippee cahier fucked around with this message at 18:14 on Feb 3, 2017 |
# ? Feb 3, 2017 18:11 |
|
the M0 doesn't have the other fault handlers or the cause-of-error registers, only hardfault. that thing is cut down to the bone e: however, you can make a decent crashdump because of the way the exception stacking works. the program counter and link register [among others] are placed on the stack automatically before entering the hardfault handler. see here for the layout. Spatial fucked around with this message at 19:15 on Feb 3, 2017 |
# ? Feb 3, 2017 19:12 |
|
i hope you're happy thread:
|
# ? Feb 8, 2017 22:54 |
|
also i think i've been fundamentally misunderstanding a bunch of stuff. how does the bootloader code interact with the binary code? does it matter if they contain the same symbols or sections? or does it just handle flashing, and the reset button etc and they don't actually share any env?
|
# ? Feb 8, 2017 23:00 |
|
they most likely do not share anything also clean breadboards will always make me extremely happy
|
# ? Feb 8, 2017 23:38 |
|
nice, clean wiring i sorta prefer to color code things, at the very least vcc/ground should be red/black gonadic io posted:also i think i've been fundamentally misunderstanding a bunch of stuff.
|
# ? Feb 9, 2017 05:55 |
|
|
# ? May 16, 2024 18:12 |
|
JawnV6 posted:nice, clean wiring i only got one set of wires colour coded by length. and i ain't got a snipper/stripper. hence you can see me bending the red ones at the top to the right length
|
# ? Feb 9, 2017 07:52 |