#avr Logs
Sep 25 2019
#avr Calendar
12:10 AM rue_mohr: who help with what?
08:13 AM soreau: Anyone have an idea what's meant by this comment? https://github.com/rogerclarkmelbourne/Arduino_STM32/blob/master/STM32F1/system/libmaple/usb/stm32f1/usb_reg_map.h#L461
08:41 AM cehteh: whatever it says
09:01 AM soreau: well it's more of a question about what is the expected thing to do in this case if it's not covered
09:58 AM soreau: hm, from RM0008 - "Note: Double-buffered and Isochronous IN Endpoints have two USB_COUNTn_TX registers: named USB_COUNTn_TX_1 and USB_COUNTn_TX_0 with the following content." ...
10:08 AM [1]MrMobius is now known as MrMobius
10:35 AM soreau: though it doesn't seem to help https://github.com/rogerclarkmelbourne/Arduino_STM32/issues/687#issuecomment-535077035
10:46 AM soreau: and now I found the same comment under USB_COUNTn_RX but I think they typo'ed and meant s/USB_COUNTn_TX/USB_COUNTn_RX because it's in this section and the image describing it says rx
10:47 AM soreau: but that would mean there are 4 registers for double buffered or isochronous IN endpoints.. which leaves me a bit puzzled
10:47 AM * soreau keeps hackin
10:48 AM cehteh: possibly one for each part of the doublebuffer
10:49 AM cehteh: is that doublebuffer managed by hardware?
10:50 AM soreau: well if they copypasta'd that comment, maybe they meant s/IN/OUT too
10:50 AM soreau: cehteh: it's managed my the usb peripheral afaik
10:50 AM soreau: which would mean hardware
10:55 AM soreau: I just have a feeling somewhere the registers are only setup for bulk/interrupt and not double buffered/isochronous
10:58 AM soreau: cehteh: what makes you ask?
11:00 AM cehteh: i havent read the datasheets for your parts
11:34 AM soreau: holy crap I found something that worked
11:34 AM Fuchikoma: It compiled! Ship it!
11:35 AM soreau: heh
11:36 AM soreau: well at least I'm getting payloads every frame now, but the data isn't in the order I expect
11:36 AM soreau: definitely a libmaple issue though
11:36 AM Fuchikoma: Step in the right direction at least
11:37 AM soreau: yea just every other payload is the same now
11:37 AM soreau: but it contains familiar data
12:04 PM soreau: yay, if I ditch dtog and just use my own variable to toggle, I get correct data
12:06 PM soreau: now to figure out why it's taking twice as long to record as it does to play back
12:09 PM vmt: you sure you're not doubling sampling rate in some calculation?
12:10 PM vmt: that's the only thing that comes to mind
12:10 PM vmt: and if i was a betting man i'd wager on that anyway
12:16 PM soreau: If I send twice as much data as I'm thinking I should send, it records at the right time with right data
12:19 PM soreau: vmt: must be something like that
12:19 PM soreau: though I can't put my finger on it exactly yet
12:19 PM soreau: it's 16000 sampler rate stereo, so I expect that every 1ms, I should send (16000/1000) * 2 bytes
12:23 PM soreau: which is 32, but I have to send 64 bytes each ms to make things happy
12:23 PM vmt: so that would be with 8-bit samples
12:24 PM vmt: are you sure the data is not being recorded as 16-bit samples?
12:24 PM soreau: well it is afaik
12:24 PM vmt: well, so it would appear
12:25 PM soreau: I mean the descriptor is setup to say 2 bytes each sub frame and each sample is 16 bytes
12:25 PM vmt: you're using arecord, yes?
12:25 PM soreau: yea
12:25 PM vmt: try specifying the format directly
12:25 PM soreau: I am
12:25 PM vmt: with the -f switch
12:25 PM soreau: I am
12:25 PM vmt: as S8/U8?
12:25 PM soreau: no
12:25 PM vmt: ...
12:25 PM vmt: why?
12:26 PM soreau: arecord: begin_wave:2552: Wave doesn't support S8 format...
12:26 PM vmt: well try U8
12:26 PM soreau: Available formats:
12:26 PM soreau: - S16_LE
12:27 PM soreau: I must use S16_LE or else it fails
12:27 PM soreau: but I think you're right, that it's taking 16bits as a single sample
12:28 PM soreau: so I guess it makes sense I have to send twice as much since it's stereo, but that doesn't completely sit well with me
12:29 PM soreau: for one, the max packet size is 64 bytes in the PMA so this would mean my max is 16000 stereo or 32000 mono
12:29 PM vmt: errrr
12:29 PM vmt: what kind of an arecord this is
12:29 PM vmt: arecord does u8 perfectly fine here
12:29 PM soreau: what do you mean?
12:29 PM soreau: with what input?
12:30 PM vmt: any
12:30 PM vmt: it's dummy so that it can never perform any reconversion or something?
12:30 PM vmt: i'm not sure where it pulls the formats
12:30 PM soreau: from the device
12:30 PM soreau: afaik
12:31 PM vmt: well then there's something wrong with your usb setup i figure
12:31 PM vmt: and gl&hf finding that with that overly verbose codebase you're using
12:32 PM vmt: and no, you're wrong. you don't have to send any more data than what you intend to
12:32 PM vmt: just that it's stereo means there's two channels, and a sample depth is the sample size per channel.
12:38 PM vmt: you can just change the wave header afterwards, changing the bitspersample to 8 instead of 16 and then it'll be alright:D
12:38 PM vmt: depending on whether it's LE or BE you might get the channels reversed
12:38 PM vmt: off a quick think
12:47 PM soreau: ok I think I might have found it
12:49 PM soreau: When I set wFormatTag to PCM8 instead of PCM, I can only use U8 and everything seems correct
12:49 PM soreau: now to try with real data
12:55 PM vmt: quite sure it will work
01:03 PM soreau: except I managed to crash the chip now
01:08 PM vonnieda: Is there any way to generate position independent code with avr-gcc? -fPIC and -pie say not supported.
01:09 PM Emil: Consider joining #avrs
01:10 PM soreau: How do I get gdb to tell me where it's crashing?
01:10 PM Fuchikoma: "position independent code" ?
01:10 PM vonnieda: Fuchikoma: Yes, code that can be run from any origin.
01:11 PM vmt: soreau: you mean the chip resets?
01:11 PM Fuchikoma: Isn't the entire point of a high level language to solve that particular problem?
01:12 PM soreau: vmt: At runtime, the light flashes indicating a crash. I run openocd and gdb and reset the chip but when I continue, gdb doesn't return and the chip shows the blinking crash light
01:13 PM vmt: you have to step, cm3s don't have mmus
01:13 PM vmt: cm7/f has an mpu. cm4 as well, if memory serves
01:13 PM soreau: so what's the order of operations?
01:14 PM soreau: run openocd, then reset the chip then run gdb quickly and single step through it?
01:14 PM vmt: step or set breakpoints and narrow it down
01:14 PM vmt: run openocd, reset + halt
01:14 PM vmt: and then use gdb
01:14 PM soreau: I don't know how to do that
01:14 PM soreau: where do I enter reset + halt?
01:14 PM vmt: telnet to the openocd server
01:14 PM soreau: oh
01:14 PM vmt: type reset halt
01:14 PM vmt: boom, done
01:15 PM vonnieda: Fuchikoma: I'm referring to lower level than that. I'm trying to find a way to have a binary that can execute from different origins for the purpose of multiple partition bootloading.
01:15 PM vmt: though, ... i'm pretty sure you can tell openocd to do that automagically
01:15 PM vmt: via some input switch or a file containing commands... can't remember, i haven't exactly done mcu fuckery in a long time
01:16 PM Fuchikoma: vonnieda: Use nothing but relative jumps and figure out some sort of API system where the call addresses to functions external to the call block are always known
01:17 PM vmt: and then again, e.g. sw4stm32 integrates the arm gcc toolchain into eclipse, and eclipse's gdb frontend is good. it also lets you specify what openocd runs after it starts up, but i'm sure you can do that by hand, too
01:17 PM vmt: well, configure it...
01:17 PM soreau: vmt: thanks I can at least step through now
01:17 PM vmt: no biggie
01:18 PM vonnieda: Fuchikoma: Yea, I'm trying to avoid doing it all by hand, since this is a feature of gcc for some platforms.
01:18 PM Fuchikoma: vonnieda: I'm not sure how they work but I'm aware that operating systems for microcontrollers exist, perhaps managing that kind of thing is exactly WHY they exist? I never looked into them myself.
01:30 PM soreau: huh. I seemingly have an uninitialized variable but it's declared as static volatile uint32 var = 0; at the top of the file and in the usbreset function, it's set to 0 as well..
01:31 PM soreau: so how did it get to 1661468672 the first round..
01:32 PM soreau: also I had this code working before but not sure what changed
01:32 PM vmt: smells like you aren't writing where you're supposed to
01:32 PM soreau: yea
01:32 PM Fuchikoma: Schrodenbug
01:32 PM soreau: let me go fix that..
01:33 PM vmt: they're amazing to track down :)
01:33 PM vmt: annyway, the only thing that really changes is related to buffers now
01:33 PM vmt: so i suggest double check all math that has to do with the packet sizes and so on
01:35 PM * soreau tramples all over the chip memory
01:36 PM soreau: actually I'm not really sure where I'm going wrong
01:36 PM soreau: but this is pretty annoying
01:36 PM soreau: why gdb no help me
01:38 PM vmt: when you change the sample depth back to 16b does it work as expected when you step through or is there still some black magic happening?
01:38 PM soreau: no it's not related to that
01:38 PM soreau: that part is just the descriptor to the host
01:39 PM soreau: oh I think I see it
01:39 PM soreau: nope :P
01:42 PM vmt: well then you're leaving something out, i thought this started happening when you changed the format
01:45 PM soreau: ok it works when I don't init the serial interface
01:46 PM soreau: the real data has a slight bit of static but it's working
01:47 PM soreau: thanks for all the help you guys
03:10 PM soreau: I set a watch on the variable in question, then for some reason it hits `if (len == 0) return 0;` though len isn't the variable. I print len and it's 2, not 0 (which it should be because it is a constant value of 2)
03:10 PM soreau: how does this happen
03:12 PM soreau: stack must be trashed
10:01 PM soreau: I figured it all out except using adc, analogRead works fine at 20Khz stereo
10:02 PM cehteh: m(
11:54 PM day__ is now known as day