@Wuerfel_21 Yet another reason I'm glad was able to get these prototypes to you! I have no idea why you see a difference in Linux. I think they behave the same in Windows as the Parallax boards, at least as far as I can tell.
There are also some settings on the FTDI chip that you set with FTProg. Can't really imagine anything there, but might want to check...
@Rayman said:
@jmg Just looked around and the 5 pin parts do look better, but cost a lot more and have limited supply, at least on Digikey (not that I need a huge supply though).
I did see what looks to be a higher PSRR, more current, 3 pin part for 5 cents more: AP2210N-3.3TRG1DICT-ND
I see lcsc has the 5 pin AP2210 for ~1c more than the 3 pin, so there is a price premium but very slight.
The modern regulators seem to offer only the 5-pin SOT23, which is why I focused on that, older parts are certainly more noisy, with PSRR numbers not quite as good either.
The lowest noise ones do cost a bit more than the vanilla ones, but it's the sort of part where you keep improving it until you cannot hear (or measure) the difference anymore
@Rayman said:
@jmg That is a good argument. I don't really have an upgrade path with 3-pin while there is one for 5-pin.
Just checking ADi and I see their ADP151 & ADP150 & ADM7160 also come in the generic 5-pin option. Those have good PSRR at 10KHz and above.
The crazy-low-noise ADi parts (<1~8uV) jump to 'some-dollars', and come in less friendly packages.
Testing the robot version of this board, noticed that I need the 75k pullup on FTDI DTR otherwise P2 resets with USB cable is disconnected.
Guess I never noticed because always used USB for P2 power...
Also going to have to add LiPo power input to power P2. Powering P2 with same batteries as 8 servos works for a while but P2 eventually hangs. Definitely need decoupling between P2 and servo power supplies. Some giant caps made it work for a while, but not good enough...
@Wuerfel_21 The LDO version fixed the sound issues as far as I can tell. Dead silent with your first version of VGA test and music sounds clean on later version.
Oh yes, the slow mode on the boards that aren't so cooperative. I think fast also isn't stable on the ones where it doesn't immediately crash, but it takes like an hour and may only happen when executing code from either bank. Anyways, maybe new boards are improved.
Hoping some of my issues with this board are because only had time to install have the PSRAM chips.
Might have changed the loading effects...
It can run MegaYume in PSRAM4 mode from bus at pin 32 or 32+4 in fast or slow mode.
Bus at 32+8 and 32+12 need slow mode.
Can do PSRAM16 mode in slow mode but not fast mode.
Sound is perfect, as far as I can tell, you'd like that!
@Wuerfel_21 If I'm doing MegaYume in PSRAM16 slow mode with Sonic1, is it actually using all four chips?
Just making sure.
This might be the minimum level of acceptability. Hopeful for better since all my Seeed boards do better with thick stencil.
This board was made with GoldPheonix pool to save $$ testing out this design. Maybe there's some difference in copper thickness or something that I missed...
@Rayman said:
@Wuerfel_21 If I'm doing MegaYume in PSRAM16 slow mode with Sonic1, is it actually using all four chips?
Just making sure.
Yes, PSRAM16 mode distributes the load across all 4 chips, but only the first bank is used (there infact is no banking support at all in megayume beyond making sure the other banks are deselected)
@Rayman said:
I have notice that Flexprop seems to take longer to get around to loading than Prop Tool. Haven’t checked this against Parallax boards though ..
Hi Ray,
Only had a quick glance through this thread and picked-up on this but I could be way-off what you're discussing; if you are using the FlexProp IDE, do you have Ports->Find Port Automatically selected or your actual com-port? The automatic method takes quite a while.
Yes, always use automatic. Sometimes instant, sometimes slow. Especially slow when doing over Remote Desktop.
Prop tool doesn't work over remote desktop when P2 is local but FlexProp does.
I'm not usually using FlexProp IDE though, I'm normally using Visual Studio and running a build script to invoke the loader...
Think I mentioned before that there seems to be two kinds of failures, one where NeoYume won't even start and another where it starts but then overheats after several minutes.
Looks like these delays can get it past the first issue and then forced air can fix the second issue.
(Putting in freezer for 5 minutes is another way to get past the first issue).
But, most of the boards with the thick stencil don't seem to need these tricks...
These "Pool" ones from GoldPheonix maybe have thinner inner layers or something like that. Or, maybe just being green instead of blue, who knows...
Well that sure is a thing. I guess starting up all those cogs at once causes the power to surge. if you put a
asm
waitx #496
endasm
instead of waiting a whole second, does that still work? (try ##992 or ##1000 otherwise)
Still, boards crashing on that are no good because they could crash in other situations that could arise more randomly (not necessarily in NeoYume or any currently extant software), like all cogs doing block reads simultaneously.
That's something that would be tricky to map out. Building a hubRAM read errors graph of supply volts vs sysclock frequency, at a few different temperatures. Presumably any momentary drooping of the 1.8 volt supply will have instantaneous lowering of the frequency where read/write errors occurs.
@Rayman said:
@Wuerfel_21 496 didn't work, but 992 did.
I guess this means the LUT block read also counts.
@Rayman said:
@Wuerfel_21 I think anybody really worried about crashing isn't going to run at 340 MHz!
If I were to write a native P2 game, it'd probably do a lot of block read/write like that (WMLONG can draw silly amounts of sprites in 256 color mode...). Though yea, that probably wouldn't be be pushing the clkfreq quite as hard. However, maybe try to run the Spin Hexagon P2 port at full HD, that will have a bunch of cogs hammering block writes into memory. Though idk if that hasn't bitrotted yet, haven't ran it in ages. I'll have to look into it.
EDIT: I has bitrotted. spinhexagon_p2/jm_fullduplexserial.spin2:378: error: syntax error, unexpected FIELD my beloved
(WMLONG can draw silly amounts of sprites in 256 color mode...).
Yes, it can. I have 16 (18 with mouse pointer and text cursor) sprites in my HDMI driver (and the Basic interpreter that uses the driver). They can theoretically be 512 px wide and full screen high but there is no HUB RAM to test this. WMLONG does the job, without this making sprites would be much harder.
write a native P2 game
I have to finish my breakout game written in the interpreter
18 isn't silly at all (reminder: this this is what a game I like looks like). I got 32 in my P1 driver (which was the first big PASM I wrote, want to make a better one at some point) Though it'll only do like 14 on one line before crapping out.
Now on P2 that runs normal instructions 8x as fast and has WMLONG for 2cyc-per-pixel blits... though even if you go full proper 32 bit with alpha, that's still only ~12 cycles per pixel (RDLONG source + RDLONG destination + SETPIV + MIXPIX + WRLONG. I wish the pixel mix instructions could use alpha directly from the arguments), so you'd have 10x the fill rate you get on P1 (assuming 80MHz vs 320 MHz and same number of cogs used for render). Main bad is that mirroring is really slow either way, so you need to prerender mirrored frames for everything that needs to be fast. OTOH you can use PSRAM streaming, so memory is pretty good, too.
Comments
p2load probably only got tested with the Eval Board.
I do have series cap but not that 75k pull-up
But can’t remove chip like you can with prop plug
This is on the EVAL board (though on that there's a secondary power input). Not sure why the pullup would make a difference.
@Wuerfel_21 Yet another reason I'm glad was able to get these prototypes to you! I have no idea why you see a difference in Linux. I think they behave the same in Windows as the Parallax boards, at least as far as I can tell.
There are also some settings on the FTDI chip that you set with FTProg. Can't really imagine anything there, but might want to check...
I have notice that Flexprop seems to take longer to get around to loading than Prop Tool. Haven’t checked this against Parallax boards though ..
I see lcsc has the 5 pin AP2210 for ~1c more than the 3 pin, so there is a price premium but very slight.
The modern regulators seem to offer only the 5-pin SOT23, which is why I focused on that, older parts are certainly more noisy, with PSRR numbers not quite as good either.
The lowest noise ones do cost a bit more than the vanilla ones, but it's the sort of part where you keep improving it until you cannot hear (or measure) the difference anymore
@jmg That is a good argument. I don't really have an upgrade path with 3-pin while there is one for 5-pin.
Just checking ADi and I see their ADP151 & ADP150 & ADM7160 also come in the generic 5-pin option. Those have good PSRR at 10KHz and above.
The crazy-low-noise ADi parts (<1~8uV) jump to 'some-dollars', and come in less friendly packages.
Testing the robot version of this board, noticed that I need the 75k pullup on FTDI DTR otherwise P2 resets with USB cable is disconnected.
Guess I never noticed because always used USB for P2 power...
Also going to have to add LiPo power input to power P2. Powering P2 with same batteries as 8 servos works for a while but P2 eventually hangs. Definitely need decoupling between P2 and servo power supplies. Some giant caps made it work for a while, but not good enough...
@Wuerfel_21 The LDO version fixed the sound issues as far as I can tell. Dead silent with your first version of VGA test and music sounds clean on later version.
Thanks for pointing out this issue!
Very good! ~
RAM stability on that one?
Had to substitute 2.8 v ldo because forgot to order the 3.3v version …
Had to flip over and rotate to make it work as pin out is different.
Wasn’t sure vga would work at 2.8v vdd but seems ok
Only had a few minutes to test so far…
MegaYume worked. Left running a few hours.
NeoYume has problems but might be software issue. Need to test with other computer to say for sure.
Nothing has changed there except board maker so should be ok
Well I don't think the current boards I have are very okay at all. I think I was still getting crashes at 16/async/async.
@Wuerfel_21 That must be slow mode right?
Most of the good boards I have run with fast mode and: 14 with syncs false or 15 with syncs on for fast mode
Oh yes, the slow mode on the boards that aren't so cooperative. I think fast also isn't stable on the ones where it doesn't immediately crash, but it takes like an hour and may only happen when executing code from either bank. Anyways, maybe new boards are improved.
Hoping some of my issues with this board are because only had time to install have the PSRAM chips.
Might have changed the loading effects...
It can run MegaYume in PSRAM4 mode from bus at pin 32 or 32+4 in fast or slow mode.
Bus at 32+8 and 32+12 need slow mode.
Can do PSRAM16 mode in slow mode but not fast mode.
Sound is perfect, as far as I can tell, you'd like that!
@Wuerfel_21 If I'm doing MegaYume in PSRAM16 slow mode with Sonic1, is it actually using all four chips?
Just making sure.
This might be the minimum level of acceptability. Hopeful for better since all my Seeed boards do better with thick stencil.
This board was made with GoldPheonix pool to save $$ testing out this design. Maybe there's some difference in copper thickness or something that I missed...
Yes, PSRAM16 mode distributes the load across all 4 chips, but only the first bank is used (there infact is no banking support at all in megayume beyond making sure the other banks are deselected)
Hi Ray,
Only had a quick glance through this thread and picked-up on this but I could be way-off what you're discussing; if you are using the FlexProp IDE, do you have Ports->Find Port Automatically selected or your actual com-port? The automatic method takes quite a while.
Craig
Yes, always use automatic. Sometimes instant, sometimes slow. Especially slow when doing over Remote Desktop.
Prop tool doesn't work over remote desktop when P2 is local but FlexProp does.
I'm not usually using FlexProp IDE though, I'm normally using Visual Studio and running a build script to invoke the loader...
Got the 3.3V LDOs in place and added the remaining 4 PSRAM chips, but still no go with NeoYume.
But, think I did figure out the trick to make it work!
@Wuerfel_21 Adding in some delays to the cog starting section makes it start up.
Went off the rails after about 10 minutes or so though.
Trying now with forced air cooling and looks good so far...
Think I mentioned before that there seems to be two kinds of failures, one where NeoYume won't even start and another where it starts but then overheats after several minutes.
Looks like these delays can get it past the first issue and then forced air can fix the second issue.
(Putting in freezer for 5 minutes is another way to get past the first issue).
But, most of the boards with the thick stencil don't seem to need these tricks...
These "Pool" ones from GoldPheonix maybe have thinner inner layers or something like that. Or, maybe just being green instead of blue, who knows...
Well that sure is a thing. I guess starting up all those cogs at once causes the power to surge. if you put a
instead of waiting a whole second, does that still work? (try
##992or##1000otherwise)Still, boards crashing on that are no good because they could crash in other situations that could arise more randomly (not necessarily in NeoYume or any currently extant software), like all cogs doing block reads simultaneously.
That's something that would be tricky to map out. Building a hubRAM read errors graph of supply volts vs sysclock frequency, at a few different temperatures. Presumably any momentary drooping of the 1.8 volt supply will have instantaneous lowering of the frequency where read/write errors occurs.
It's been doing the Metal Slug demo now for 2 hours, so think it's OK thermally with forced air.
@Wuerfel_21 I think anybody really worried about crashing isn't going to run at 340 MHz!
I'll try those delays...
@Wuerfel_21 496 didn't work, but 992 did.
I guess this means the LUT block read also counts.
If I were to write a native P2 game, it'd probably do a lot of block read/write like that (WMLONG can draw silly amounts of sprites in 256 color mode...). Though yea, that probably wouldn't be be pushing the clkfreq quite as hard. However, maybe try to run the Spin Hexagon P2 port at full HD, that will have a bunch of cogs hammering block writes into memory. Though idk if that hasn't bitrotted yet, haven't ran it in ages. I'll have to look into it.
EDIT: I has bitrotted.
spinhexagon_p2/jm_fullduplexserial.spin2:378: error: syntax error, unexpected FIELDmy belovedYes, it can. I have 16 (18 with mouse pointer and text cursor) sprites in my HDMI driver (and the Basic interpreter that uses the driver). They can theoretically be 512 px wide and full screen high but there is no HUB RAM to test this. WMLONG does the job, without this making sprites would be much harder.
I have to finish my breakout game written in the interpreter
18 isn't silly at all (reminder: this this is what a game I like looks like). I got 32 in my P1 driver (which was the first big PASM I wrote, want to make a better one at some point)
Though it'll only do like 14 on one line before crapping out.
Now on P2 that runs normal instructions 8x as fast and has WMLONG for 2cyc-per-pixel blits... though even if you go full proper 32 bit with alpha, that's still only ~12 cycles per pixel (RDLONG source + RDLONG destination + SETPIV + MIXPIX + WRLONG. I wish the pixel mix instructions could use alpha directly from the arguments), so you'd have 10x the fill rate you get on P1 (assuming 80MHz vs 320 MHz and same number of cogs used for render). Main bad is that mirroring is really slow either way, so you need to prerender mirrored frames for everything that needs to be fast. OTOH you can use PSRAM streaming, so memory is pretty good, too.