This SMT PLCC socket is especially tight. Think going to replace with the through hole version.
Plus, like the gold contacts can get with through hole..
And, there's the holes that might be able to use to push SWaP module out of the socket...
@Rayman said:
Guess final test will be for the hyperram... Have to dig up something for that...
Think @Wuerfel_21 posted an emulator code here, might use that...
Should just be able to use the latest emulators and/or the RAM test program, they all support HyperRAM. For the Winbond one, the latency setting needs to be increased by 1 from the default.
@Wuerfel_21 said:
Okay, datasheets indicate that your Winbond HyperRAM defaults to 7 latency clocks and the ISSI one parallax uses defaults to 6. There's a register that configures this, but roger's init code doesn't seem to have that ability. Now going to brain hurt about how to properly change the values to account for 7 latency (there's also a place where the 6 latency is hardcoded, I think).
Spent a lot of time getting nowhere with Hyperram until found this note. Very glad that you all figured this out long ago...
Got MegaYume running on these new modules. Thinking this is the final test before ready to go out the door...
Also tried MegaYume on one of the modules that was made with the 1.8 V rated Hyperram. Amazingly, that works too. Go figure....
Having a bit of trouble with uSD. Need to troubleshoot some more, but seems flashing with program that flashes LEDs on P58 and P59 is somehow messing up the uSD for FlexProp.
Pretty sure worked perfect before flashed with this test code.
Solution for now is to run FSRW first.
FlexProp's uSD driver works after doing that for some reason...
Looking into having Gold Pheonix assemble some. Doing it myself is working, but slow going...
Issue is that HyperRam is tough to source at this time. Not sure if that's because in high demand, or because of low demand...
Newark has some Infineon versions. No idea if that will work or not, but probably?
It'll be low demand, same as the Prop2 stocking. Most embedded systems fit their RAM needs within the internal RAM of the uC. Those that don't will use heftier off-the-shelf SDRAM solutions like RPi or PC on a card. There will be some custom boards but mostly still based around SDRAM.
The more interesting ones will use MRAM for main working RAM rather than the NOR/SLC Flash alternative I've seen in uC block diagrams. But that's still not a HyperRAM solution.
Working on building up some inventory.
Some of these were going to be "Core" version without some parts, but have since decided that is a bad idea (because would compete with Parallax, and probably lose
New boards with through hole PLCC-84 socket are here.
Should be ready to go soon.
Think if these all sell in a reasonable amount of time, will get 100 assembled.
You can make the pins either analog input or digital I/O over I2C.
It'd be neat if could fit P1 plus 4 of these things on the module, no idea if that would fit though...
@Rayman That is a cool IC, and tiny, 4 of those won't take up much space, impossible to hand solder but Hot AIR should work OK, though Pick and Place would make it easier. I am guessing this would be used to supply the extra Channels not availble on the P1?
3D printed a fixture to pop out the stamp using the holes in the socket. Uses three of the four holes... Fourth has parts on bottom of board and not sure want to be pushing on them..
Seems to work. Save one from having to buy and extractor maybe...
You can make the pins either analog input or digital I/O over I2C.
It'd be neat if could fit P1 plus 4 of these things on the module, no idea if that would fit though...
I thought the P1 as the "MicroMite Companion" was a cool concept. I still have all the original files. Planning something similar but for the P2.
The RP2350B (QFN-80 package with 48 GPIO pins) specifically offers 8 ADC channels (pins that can be configured as analog inputs)
For my needs, this, alongside a KISS module would be perfect. It's a more refined (better voltage regulation) than the RPi device; fully open source and can be ordered from JLCPCB, fully assembled. My last five units came to US$77.00, delivered. The optional 8MB PSRAM device wasn't in stock but for now, I don't need it.
Still don't know exactly why FatFS based uSD access doesn't work after boot unless FSRW is run first.
But, just figured out that if flash SWaP module with this, it's all good:
Pub SuperMain()| r, s, bytes
'Try to mount a few times then give up if not successful
repeat 10
waitms(500)
r:=sd.mount_explicit(MISO, CLK, MOSI, CS)
if r<0
ser.dec(r)
ser.tx(13)
sd.release() 'see if this helps next attempt
else
quit 'escape from repeat loop if mounted
repeat
Guessing it is sd.release() that FatFS is missing...
Have to flash it with something. This might be it...
I wrote a replacement called "sdspi_bashed3.spin2" that fixes the multiple bugs. Someone else posted it to Obex.
I took the liberty to change the interface slightly at the same time. start_explicit() now receives a single longword pointer to memory that contains all four pin assignments. It makes the handling through FSRW more compact. EDIT: Oh, it also allows variable length array of pins. This is because I wanted to switch between two drivers with different number of pins. Namely my 4-bit SD mode driver.
User supplied pinsTable to FSRW looks like this:
byte[pinsTable][0] is the driver select index. A value of 1 selects sdspi_bashed3.spin2
byte[pinsTable][1] is DO pin (MISO)
byte[pinsTable][2] is DI pin (MOSI)
byte[pinsTable][3] is CS pin
byte[pinsTable][4] is CLK pin
I also modified readblocks() but since that wasn't being used, and I didn't test it either, it shouldn't have any impact.
PS: Including a speed tester program as well. This can be used to verify any other changes I might have made along the way.
My SD drivers are using debug() for reporting so also I've stripped the tester down to use debug() instead of SmartSerial.spin2. It's a lot more compact to read now.
EDIT: Changed defaults to use boot pins and SPI mode driver (sdspi_bashed3.spin2).
Looking at the dates, the 4-bit SD mode driver (sdsd_dma.spin2) I attached in post #356 above looks to be ported from the development version of sdsd.cc just after v0.8 was posted - https://forums.parallax.com/discussion/comment/1564719/#Comment_1564719
That should be all good. It was fully reliable by that stage. I've labelled it as v0.9 which probably corresponds to a small change that went into sdsd.cc v0.9 also.
Comments
Nice and simple solution.
With any luck it should resolve your melting socket issue now, and hopefully consistently.\
Yeah those PLCCs are tight chips to remove - first time around is a little concerning how much force is needed.
This SMT PLCC socket is especially tight. Think going to replace with the through hole version.
Plus, like the gold contacts can get with through hole..
And, there's the holes that might be able to use to push SWaP module out of the socket...
Now have a rig for testing all the P2 pins...
Helped me find a couple hard to spot solder bridges...
Guess final test will be for the hyperram... Have to dig up something for that...
Think @Wuerfel_21 posted an emulator code here, might use that...
Should just be able to use the latest emulators and/or the RAM test program, they all support HyperRAM. For the Winbond one, the latency setting needs to be increased by 1 from the default.
Spent a lot of time getting nowhere with Hyperram until found this note. Very glad that you all figured this out long ago...
Got MegaYume running on these new modules. Thinking this is the final test before ready to go out the door...
Also tried MegaYume on one of the modules that was made with the 1.8 V rated Hyperram. Amazingly, that works too. Go figure....
Having a bit of trouble with uSD. Need to troubleshoot some more, but seems flashing with program that flashes LEDs on P58 and P59 is somehow messing up the uSD for FlexProp.
Pretty sure worked perfect before flashed with this test code.
Solution for now is to run FSRW first.
FlexProp's uSD driver works after doing that for some reason...
Makes me wonder if hyperram is actually binned only by speed and not really voltage.
There’s no way a real 1.8 v part should survive 3.3v , right?
You could be right. Maybe not performance binned but just use a common die with autodetect that selects the pin drive strength accordingly.
Looking into having Gold Pheonix assemble some. Doing it myself is working, but slow going...
Issue is that HyperRam is tough to source at this time. Not sure if that's because in high demand, or because of low demand...
Newark has some Infineon versions. No idea if that will work or not, but probably?
Told them to get P2 from Digikey, but they came back with Digikey is almost out of P2.
Looks like only 39 left...
Mouser still has some though...
It'll be low demand, same as the Prop2 stocking. Most embedded systems fit their RAM needs within the internal RAM of the uC. Those that don't will use heftier off-the-shelf SDRAM solutions like RPi or PC on a card. There will be some custom boards but mostly still based around SDRAM.
The more interesting ones will use MRAM for main working RAM rather than the NOR/SLC Flash alternative I've seen in uC block diagrams. But that's still not a HyperRAM solution.
Working on building up some inventory.
Some of these were going to be "Core" version without some parts, but have since decided that is a bad idea (because would compete with Parallax, and probably lose
New boards with through hole PLCC-84 socket are here.
Should be ready to go soon.
Think if these all sell in a reasonable amount of time, will get 100 assembled.
Forgot about tariffs for a second... Looks like 8-layer PCB faces a 170% tariff... Almost doubles the price
Thinking about P1 version of this module. Seems need some extra I/O.
This chip here looks cool: https://www.ti.com/lit/ds/symlink/tla2528.pdf
You can make the pins either analog input or digital I/O over I2C.
It'd be neat if could fit P1 plus 4 of these things on the module, no idea if that would fit though...
@Rayman That is a cool IC, and tiny, 4 of those won't take up much space, impossible to hand solder but Hot AIR should work OK, though Pick and Place would make it easier. I am guessing this would be used to supply the extra Channels not availble on the P1?
@lab_ges That would be the idea...
Assembled the first new SWaP carrier board. Seems good so far...
Added a vertical QWIIC connector after seeing one on one of @JonnyMac boards...
3D printed a fixture to pop out the stamp using the holes in the socket. Uses three of the four holes... Fourth has parts on bottom of board and not sure want to be pushing on them..
Seems to work. Save one from having to buy and extractor maybe...
Well done.
I thought the P1 as the "MicroMite Companion" was a cool concept. I still have all the original files. Planning something similar but for the P2.
For my needs, this, alongside a KISS module would be perfect. It's a more refined (better voltage regulation) than the RPi device; fully open source and can be ordered from JLCPCB, fully assembled. My last five units came to US$77.00, delivered. The optional 8MB PSRAM device wasn't in stock but for now, I don't need it.
Still don't know exactly why FatFS based uSD access doesn't work after boot unless FSRW is run first.
But, just figured out that if flash SWaP module with this, it's all good:
Pub SuperMain()| r, s, bytes 'Try to mount a few times then give up if not successful repeat 10 waitms(500) r:=sd.mount_explicit(MISO, CLK, MOSI, CS) if r<0 ser.dec(r) ser.tx(13) sd.release() 'see if this helps next attempt else quit 'escape from repeat loop if mounted repeatGuessing it is sd.release() that FatFS is missing...
Have to flash it with something. This might be it...
"sdspi_bashed2.spin2" is a buggy driver. Don't use it, ever.
That's right, you fixed something with the writing part and posted an improved version in OBEX, as I recall...
I wrote a replacement called "sdspi_bashed3.spin2" that fixes the multiple bugs. Someone else posted it to Obex.
I took the liberty to change the interface slightly at the same time. start_explicit() now receives a single longword pointer to memory that contains all four pin assignments. It makes the handling through FSRW more compact. EDIT: Oh, it also allows variable length array of pins. This is because I wanted to switch between two drivers with different number of pins. Namely my 4-bit SD mode driver.
User supplied pinsTable to FSRW looks like this:
byte[pinsTable][0] is the driver select index. A value of 1 selects sdspi_bashed3.spin2
byte[pinsTable][1] is DO pin (MISO)
byte[pinsTable][2] is DI pin (MOSI)
byte[pinsTable][3] is CS pin
byte[pinsTable][4] is CLK pin
I also modified readblocks() but since that wasn't being used, and I didn't test it either, it shouldn't have any impact.
PS: Including a speed tester program as well. This can be used to verify any other changes I might have made along the way.
PPS: Including the 4-bit driver too.
That's probably more complicated than you'd like, sorry.
It's not hard to revert the driver to four pin number parameters. Original FSRW itself wasn't buggy.
Excellent, thanks @evanh
This should do it:
PUB start_explicit(iDO, iCLK, iDI, iCS) do_pin := iDO di_pin := iDI cs_pin := iCS clk_pin := iCLK debug("SD Driver (1-bit SPI Mode) Start Up") debug("Assign pins: ",udec(do_pin, di_pin, cs_pin, clk_pin))My SD drivers are using debug() for reporting so also I've stripped the tester down to use debug() instead of SmartSerial.spin2. It's a lot more compact to read now.
EDIT: Changed defaults to use boot pins and SPI mode driver (sdspi_bashed3.spin2).
Looking at the dates, the 4-bit SD mode driver (sdsd_dma.spin2) I attached in post #356 above looks to be ported from the development version of sdsd.cc just after v0.8 was posted - https://forums.parallax.com/discussion/comment/1564719/#Comment_1564719
That should be all good. It was fully reliable by that stage. I've labelled it as v0.9 which probably corresponds to a small change that went into sdsd.cc v0.9 also.