| 22 Jul 2024 |
 Paul D. Faria | Looks like I was missing the top-level interrupt to trigger the waker. I understood why that was needed but definitely confused until I saw that since the current API doesn't have documentation or examples explaining its usage. | 21:02:48 |
 ithinuel | I guess that's either a question for the sdk or a fun experimental session. | 21:03:16 |
| ithinuel | Actually it does say (or imply) that everything is discarded. | 21:18:32 |
| ithinuel | In the 2.5.5.3 chapter. | 21:20:21 |
| ithinuel | It doesn't explicitly talk about the FIFO though. But the way it talks about issues of aborting when the DMA isn't stalled on a dreq or even while actually doing a transfer should be enough to infer a sound expectation from the DMA. | 21:21:41 |
| ithinuel | Now, the question to figure what the transfer count status this is a bit tricker.
Because it may have read more data than written.
In a peripheral-to-memory I guess the read count matters as much as the written count
while for memory-to-memory and memory-to-periph, only the written really matters (because reads on memory don’t have side effects) | 21:47:06 |
 dirbaio | True.. M | 21:49:35 |
| dirbaio | * | 21:49:41 |
| ithinuel | From what I understand, (I’m home now and reading the datasheet).
- There are 12channels
- There can be up to 12 "transfer sequences" live at the same time.
- Each channel supervise a single transfer sequence at any given time.
- A Transfer sequence is atomic (reading between lines of the last paragraph of 2.5.5.3).
It would be nice to have that confirmed explicitly since the hope chapter about DMA talks about "transfer sequence" but this very important paragraph does not.
| 21:56:29 |
| ithinuel |
bus transfers currently in flight between the read and write master, and these transfers cannot be revoked
| 21:57:12 |
| ithinuel | are these referring to the read and write masters or the bus transfers (sequences) ? 🤷 | 21:58:06 |
| ithinuel | But it’d make sense it’s the whole sequence to keep the system in a sound state. | 21:58:36 |
| 23 Jul 2024 |
|  @cesare22:matrix.org joined the room. | 19:20:24 |
| 24 Jul 2024 |
| @cesare22:matrix.org left the room. | 11:11:54 |
| 26 Jul 2024 |
 Chandler | When using the multicore functionality, are there any constraints on what the cores can access? Can they control different ADC pins without issue? | 08:05:23 |
| Chandler | Can each core set up timers without them interfering? | 08:06:55 |
 henrik_alser | Chandler: Main thing to note is that core1 execution is paused during flash operations so you can’t use it for that | 08:12:57 |
| Chandler | Are flash operations something that is done manually, or do they occur from time to time in the background? | 08:13:43 |
 James Munns | Only when you do it specifically | 08:16:17 |
| Chandler | Ok, great, that shouldn't be a problem, then | 08:17:35 |
| Chandler | Am I understanding it right that the only way to communicate between the cores is a single spinlock and a single SioFIFO? | 08:18:23 |
| Chandler | I was expecting something like channel from the std library | 08:19:28 |
| henrik_alser | No they have shared memory so you can use any sync primitives as long as they use a critical section implemented with the hardware spinlocks | 08:22:24 |
| henrik_alser | Check out embassy-sync and use them with CriticalSectionRawMutex | 08:22:45 |
| henrik_alser | Also make sure you enable critical-section-impl feature and not use the standard single core one in cortex-m | 08:23:31 |
 9names | In reply to @chargedhex:beeper.com
Am I understanding it right that the only way to communicate between the cores is a single spinlock and a single SioFIFO? there are 32 spinlocks, rp2040-hal and embassy-rp use 1 of them to provide a multi-core safe critical-section but the rest of them are free for you to use.
the sio fifo is a good way to send signals between cores, as henrik says you would usually use shared memory to copy data. both cores have the same access to memory and peripherals, but you want to ensure that only one core is accessing a specific peripheral or section of memory at a time.
most of the time it's easiest to not use both cores. | 09:35:18 |
| Chandler | Thanks, this looks like what I wanted | 09:40:08 |
|  @slusheea:matrix.org left the room. | 11:30:14 |
 thejpster |
you can use any sync primitives as long as they use a critical section implemented with the hardware spinlocks
Note that on other platforms you could also use core::sync::atomic::AtomicXX types, but on Cortex-M0+ you only get load/store primitives and not compare-and-swap and communication between cores using only load/stores is a race hazard.
| 18:34:17 |
| thejpster | https://docs.rs/portable-atomic uses critical-section to fix the problem, but that counts as "a sync primitive that uses a critical section implemented with hardware spinlocks" provided you turn on the critical-section-spinlock feature of your HAL. | 18:35:40 |
