@Wuerfel_21 said:
I don't think the P2's SPI drive is the issue though - otherwise you'd hear everything going on all the other pins and that's not the case. (Notably, PSRAM is entirely quiet AFAICT)
There is some continuous background noise going on all the time in those recordings. That could easily be the PSRAMs.
BTW: It's a nasty crack when enabling the audio out pins when volume is up high. Need to put in my soft start code ...
@evanh said:
There is some continuous background noise going on all the time in those recordings. That could easily be the PSRAMs.
There's (almost) no background noise on the actual signal, it's just that all my PC sound input options are cheap and terrible. And in megayume the PSRAM isn't active during file selection, only when loading and actually playing.
Shrug, it shares pins with EEPROM and 4-bit mode ain't available either. The ROM SD booting pinout wasn't exactly built for speed.
I was disappointed when I saw the SD Accessory Board doesn't support 4-bit mode either - https://www.parallax.com/product/p2-microsd-add-on-board/
Having some 4-bit SD hardware would be an incentive to go the whole hog with using streamer and hubRAM buffering with CRC and full SD protocol.
To get back on topic though, I tried moving my A/V board to P0 and it didn't really make a difference for me either.
Also interestingly, it doesn't make a difference to those dastardly jailbars I get on Y/C output, either. So I guess the crosstalk between adjacent pins is either not that different between the closer and further away headers, or is just not a big factor to begin with.
@Wuerfel_21 said:
I don't think the P2's SPI drive is the issue though - otherwise you'd hear everything going on all the other pins and that's not the case. (Notably, PSRAM is entirely quiet AFAICT)
Good point, you could check that by removing the SD card, and patching the SD code to give (almost) the same clock sequences.
If that is much quieter, that leaves SD Data out and SD Supply current changes, affecting common GND's
Thanks, got my first read of Lonesock's low-level code. I know it would've been in the Obex Exchange all along, but since I never got round to using the Prop1 I also never read much source code for it either.
I see the legendary Kuneko credited there. Making the counters perform as shifters is very ingenious! Achieving a bit rate of sysclock/4 is slick.
Of note in Lonesock's Prop1 source code is the battle to manage SPI clocking mode 0:
...
' don't shift out the final bit...already sent, but be aware
' of this when sending consecutive bytes (send_cmd, for e.g.)
out8_ret
ret
For some reason I'd thought some SD drivers on the Prop2 were using mode 3 but it's looking more like I'd mixed up with EEPROM loaders. Some of those are definitely mode 3.
At any rate, I've found mode 3 to be easier to manage. It means the data appears after the first falling clock edge. Both timing and first/last bit handling just works out easier. The SD cards haven't given me any grief with idle-high on the clock pin.
PS: And idle-high has a natural advantage in the sharing method employed with the Prop2 boot pinout. Swapping the pins of chip-select and clock is a smooth operation when both are already high.
And yes the 'legendary' kuroneko, the black cat is missing here on the P2 side, Not sure when he went away and why.
I usually get a holiday greeting from him via email, but do miss him in the forums. I think he has a growing family and is very busy with work. He is a masterful programmer, though.
I like FSRW best and am going to be starting on a port of it to the P2. I need a file system driver for upcoming project. I have been told it is based on PetitFS. It will be interesting to see what I find when I did in.
@msrobots said:
And yes the 'legendary' kuroneko, the black cat is missing here on the P2 side, Not sure when he went away and why.
@JonnyMac said:
I usually get a holiday greeting from him via email, but do miss him in the forums. I think he has a growing family and is very busy with work. He is a masterful programmer, though.
Huh. I thought he encountered the equally legendary shironeko and they've been locked in eternal battle over the destiny of the universe ever since or smth to that extent.
I like FSRW best and am going to be starting on a port of it to the P2. I need a file system driver for upcoming project. I have been told it is based on PetitFS. It will be interesting to see what I find when I did in.
There's already a P2 FSRW port, but it has/had some bugs (plus the issues it had on P1 to begin with). Not sure where to find it though. There's this one I can sorta vouch for though.. Flexspin's FS libraries are kinda the best though (but there isn't a proper Spin API, so only the subset of C library functions that don't deal with structs can be used without creating a C wrapper)
Comments
That's exactly the DO pin (P58) in my earlier scope snapshot where I realised it would never do 50 MHz SPI. Although, at the time, I didn't know it was caused by the 240 ohm resistor - https://forums.parallax.com/discussion/comment/1537758/#Comment_1537758
There actually is a resistor there, wow. Truly visionary circuit design.
There is some continuous background noise going on all the time in those recordings. That could easily be the PSRAMs.
BTW: It's a nasty crack when enabling the audio out pins when volume is up high. Need to put in my soft start code ...
Hehe, it does have a purpose. The Prop2 can drive that pin hard if configured wrongly, so the resistor is there for circuit protection.
There's (almost) no background noise on the actual signal, it's just that all my PC sound input options are cheap and terrible. And in megayume the PSRAM isn't active during file selection, only when loading and actually playing.
Cool.
Okay, found the original posting on de-popping - https://forums.parallax.com/discussion/comment/1535297/#Comment_1535297
PS: I did do a bunch of further testing after that but didn't really make any headway on a cleaner solution. The only thing new I got was a super high impedance ADC - https://forums.parallax.com/discussion/174441/measuring-floating-pin-voltage-adc-from-just-the-built-in-comparator/p1
Is that an actual issue though? I've never seen it on any other design and it evidently messes up the signal integrity.
Shrug, it shares pins with EEPROM and 4-bit mode ain't available either. The ROM SD booting pinout wasn't exactly built for speed.
I was disappointed when I saw the SD Accessory Board doesn't support 4-bit mode either - https://www.parallax.com/product/p2-microsd-add-on-board/
Having some 4-bit SD hardware would be an incentive to go the whole hog with using streamer and hubRAM buffering with CRC and full SD protocol.
The accessory board also has the resistor, ack!
Yeah it was a compromise to share the bus. Some chatter here:
https://forums.parallax.com/discussion/169233/boot-issue-accessing-spi-flash-after-sd-access/p3
To get back on topic though, I tried moving my A/V board to P0 and it didn't really make a difference for me either.
Also interestingly, it doesn't make a difference to those dastardly jailbars I get on Y/C output, either. So I guess the crosstalk between adjacent pins is either not that different between the closer and further away headers, or is just not a big factor to begin with.
(Top is on pin 24, bottom is on pin 0)
Good point, you could check that by removing the SD card, and patching the SD code to give (almost) the same clock sequences.
If that is much quieter, that leaves SD Data out and SD Supply current changes, affecting common GND's
Thanks, got my first read of Lonesock's low-level code. I know it would've been in the Obex Exchange all along, but since I never got round to using the Prop1 I also never read much source code for it either.
I see the legendary Kuneko credited there. Making the counters perform as shifters is very ingenious! Achieving a bit rate of sysclock/4 is slick.
Of note in Lonesock's Prop1 source code is the battle to manage SPI clocking mode 0:
... ' don't shift out the final bit...already sent, but be aware ' of this when sending consecutive bytes (send_cmd, for e.g.) out8_ret retFor some reason I'd thought some SD drivers on the Prop2 were using mode 3 but it's looking more like I'd mixed up with EEPROM loaders. Some of those are definitely mode 3.
At any rate, I've found mode 3 to be easier to manage. It means the data appears after the first falling clock edge. Both timing and first/last bit handling just works out easier. The SD cards haven't given me any grief with idle-high on the clock pin.
PS: And idle-high has a natural advantage in the sharing method employed with the Prop2 boot pinout. Swapping the pins of chip-select and clock is a smooth operation when both are already high.
yes lonesocks code in fsrw is beautiful. the read ahead and write behind really makes a difference in speed and uses the parallel nature of the cogs.
A lot of P1 and P2 code does not, one cog calls the other one and WAITS for the result, wasting time for nothing.
Somewhere on one of my computers I have a version of Kye's Fat32_engine using lonesock's block driver.
And yes the 'legendary' kuroneko, the black cat is missing here on the P2 side, Not sure when he went away and why.
Mike
I usually get a holiday greeting from him via email, but do miss him in the forums. I think he has a growing family and is very busy with work. He is a masterful programmer, though.
I like FSRW best and am going to be starting on a port of it to the P2. I need a file system driver for upcoming project. I have been told it is based on PetitFS. It will be interesting to see what I find when I did in.
Huh. I thought he encountered the equally legendary shironeko and they've been locked in eternal battle over the destiny of the universe ever since or smth to that extent.
There's already a P2 FSRW port, but it has/had some bugs (plus the issues it had on P1 to begin with). Not sure where to find it though. There's this one I can sorta vouch for though.. Flexspin's FS libraries are kinda the best though (but there isn't a proper Spin API, so only the subset of C library functions that don't deal with structs can be used without creating a C wrapper)
I understand, but I'm going to put on my big-boy pants and give it a try myself.
Ahhh, that feeling~
I know it.
Well, take care of all the silly edge cases then.
I think kye's spin code is better/more complete as fsrw, but lonesocks block driver is simply faster
I need to search on my computers for the source of both combined, did that some years ago for my 4 sd cad RAISD system,