The WE link and the QE link are 2@0.05" pitch and 3@0.05" pitch vias (pad holes). They take 1.27mm (0.050") pin headers and 0.050" shunts.
Most users will not change these so the links will be permanent - normally you will just leave WE unconnected (EEPROM write protected) and QE linked on one side or other (QE side enables the onboard transistor reset circuit = Q(transistor) Enabled).
A warning though, the WE is a little difficult to solder as it has the eeprom mounted on the underside over the holes. This was not a design error - I just couldn't fit it anywhere else. To program the eeprom I just hold a pair of 0.050" pins shorted in the holes while programming the eeprom. You can use a low value resistor 1K or less in the holes and this should work just fine.
The 0.050" pin stakes and shunts are not cheap which is why I didn't supply them as standard.
On previous boards, I used vias at smaller spacing, or pads at smaller spacing. This time I decided that because I am forever swapping things and programming the eeprom, I would fit mine with pin header and links. Those tiny shunts are a PITA to put on though!
I don't know anything about the SX-48. What circuit would make sense?
For the most part, all the I/O would be brought out in the same way you did on this board. A padstack for a four pin header could serve as both the SX-Key programmer port and the connection point for a tiny crystal & capacitor daughterboard.
Maybe you could ask on the forum how many would be interested.
Well, the SX page isn't very active but it could be for various reasons, including the fact that DIP chips are no longer available. FWIW, the SX architecture and assembly language were not entirely user-friendly. Phil has commented on the awkwardness of the segmented RAM. For me, though, its small footprint, sub-microsecond deterministic interrupt, and lightning-fast clock rate trumped everything else. It could be made to do incredible things.
Add to that the fact that its purchase price is (last I checked) only 78¢ and you have a winning combination. Sure, the supply is static. But there are still tens of thousands to be had.
A bonus for those that ordered with the microSD card. I bought them this morning...
SanDisk microSDHC UHS-I Class 10 8GB with SD Adapter.
BTW I always recommend SanDisk as they have the best record on the forums. And buy from a reputable source, not eBay, as there are a lot of counterfeits out there.
The WE link and the QE link are 2@0.05" pitch and 3@0.05" pitch vias (pad holes). They take 1.27mm (0.050") pin headers and 0.050" shunts.
Most users will not change these so the links will be permanent - normally you will just leave WE unconnected (EEPROM write protected) and QE linked on one side or other (QE side enables the onboard transistor reset circuit = Q(transistor) Enabled).
A warning though, the WE is a little difficult to solder as it has the eeprom mounted on the underside over the holes. This was not a design error - I just couldn't fit it anywhere else. To program the eeprom I just hold a pair of 0.050" pins shorted in the holes while programming the eeprom. You can use a low value resistor 1K or less in the holes and this should work just fine.
The 0.050" pin stakes and shunts are not cheap which is why I didn't supply them as standard.
On previous boards, I used vias at smaller spacing, or pads at smaller spacing. This time I decided that because I am forever swapping things and programming the eeprom, I would fit mine with pin header and links. Those tiny shunts are a PITA to put on though!
What is the logic behind making the default be to have the EEPROM write protected? It seems like most people would want to be able to program the EEPROM and then maybe write protect it afterwards. If you haven't shipped my module yet, could you add the write enable jumper?
What is the logic behind making the default be to have the EEPROM write protected? It seems like most people would want to be able to program the EEPROM and then maybe write protect it afterwards. If you haven't shipped my module yet, could you add the write enable jumper?
Sure.
My logic is that the default program boots to the software on the microSD. Therefore, it is not necessary to change the boot code, just the code on the microSD. I expect that many users will not have a PropPlug, and may not even have a USB-TTL serial. So I don't want them accidentally corrupting the eeprom as they may have no way to re-program it. That is how I ship my RamBlade too.
For instance, you can use a Raspberry Pi as a terminal program to the prop board. And I have something else coming <wink><wink>
My logic is that the default program boots to the software on the microSD.
Okay, maybe I spoke too soon. I'm sure this is somewhere in the thread and I've missed it but what do I have to write to the SD card to get it to boot on reset?
Nicely done Ray, looks good. Have you ever tried to use solder pad jumpers? Normally I have what looks like a 0603 except the pads are very close together, close enough to bridge easily with solder (warm iron) or you can bridge it with a resistor.
I like the idea of locking the eeprom and booting from SD. What happens if it can't find the SD?
BTW, if you flip that microSD CS resistor off you can detect the card via its built-in pullup.
Nicely done Ray, looks good. Have you ever tried to use solder pad jumpers? Normally I have what looks like a 0603 except the pads are very close together, close enough to bridge easily with solder (warm iron) or you can bridge it with a resistor.
I like the idea of locking the eeprom and booting from SD. What happens if it can't find the SD?
BTW, if you flip that microSD CS resistor off you can detect the card via its built-in pullup.
Thanks Peter. Yes I have used solder jumpers - they are on my CpuBlade. But I want to be able to change the links easily, hence the 0.050" pin hdr pitch. I will be trying to see if solder bridging works although it is easy enough if you want a permanent solution.
If it cannot find the SD it just outputs an "!" every second IIRC.
Yes, I put the pullup resistor for CS on the board just in case. I use all the pullups on various boards to detect variants and then set the board type. This way I have one microSD card that I can plug into various boards and they just work - previously had 6.5MHz xtal hardcoded in the _hwdef.spin file but my aim is to do some form of checking as much as possible and then try and guess the speed.
BTW Do you have a link on checking if the xtal is x8 or x16? I am using 12MHz 1206.
{
┌──────────────────────────────────────────────────────────┐
│ CLKSET │
│(c) Copyright 2009 Philip C. Pilgrim (propeller@phipi.com)│
│ See end of file for terms of use. │
└──────────────────────────────────────────────────────────┘
This object determines whether a 5MHz or 10MHz crystal is
being used and sets the PLL accordingly for 80MHz operation.
The main program should use the following settings:
CON
_clkmode = xtal1 + pll8x
_xinfreq = 10_000_000
OBJ
clk : "clkset"
Then clk.set should be called first in the toplevel program.
If the crystal is determined to be 5MHz, the clkmode will be
changed to xtal1 + pll16x. clkfreq will still return 80_000_000.
Version History
───────────────
2009.05.23: WARNING: Trial, tentative, very alpha release!
}
PUB set
'' Automatically set the pll mode for a 5MHz or 10MHz crystal.
cognew(@setpll, 0)
DAT
org 0
setpll movi ctra,#%0_00001_011 'Set ctra for pll on no pin at x1.
movi frqa,#%0100_0000_0 'Set frqa for clk / 4 (= 20MHz w/ 10MHz crystal, i.e. too high).
add x,cnt 'Give PLL time to lock (if it can) and stabilize.
waitcnt x,#0
movi vcfg,#$40 'Configure video for discrete pins, but no pins enabled.
mov vscl,#$10 'Set for 16 clocks per frame.
waitvid 0,0 'Wait once to clear time.
neg x,cnt 'Read -cnt.
waitvid 0,0 'Wait 16 pll clocks = 64 processor clks.
add x,cnt 'Compute elapsed time.
cmp x,#$40 wz 'Is it really 64 clocks?
if_z mov x,#$6f ' Yes: Crystal is 5MHz. Set clock mode to XTAL1 and PLL16X.
if_z clkset x
cogid x 'Stop the cog: we're done.
cogstop x
x long $1_0000 '65536 clks for pll to stabilize.
{{
┌──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ TERMS OF USE: MIT License │
├──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation │
│files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, │
│modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software│
│is furnished to do so, subject to the following conditions: │
│ │
│The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.│
│ │
│THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE │
│WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR │
│COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, │
│ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. │
└──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘
}}
On the RamBlade I have been using propboot.bin although it first searches for autoexec.bat and if found used the first line only and searches for that file and if found runs it, if not then runs propboot.bin. This is based on PropCMD and fsrw IIRC.
On CpuBlade and RamBlade3 (CpuBlade + MemBlade) I have been using PropOS. This just runs itself until you enter an OS command at the SD:>
It does check the SD card but I would need to check what else it does.
I am working on PropOS currently to...
* shrink and understand Kyes PASM driver (also to convert to P2)
* self-detect more prop boards and also adjust the crystal frequency (currently this has to be recompiled after fixing _hwdef.spin
* make Kyes PASM driver cog resident with high hub interface
Then I can remake the boot file in eeprom work as discussed on the P2 forum
* validate MBR sector 0 for botloader - if valid, load and run, else
* validate FAT and look for "bootprop.bin" and if found load and run, else
* stop???
I see you found the schematic. All the info is on page 1 of this thread.
BTW, how is your two stage loader going?
What I would like to do (I worked on it some time ago but need to start over) from PropOS is...
(1) start a downloader program specifying a filename on the prop and wait for PropTool (or similar) to start a download
(2) start PropTool download (the reset line on the prop is disabled to prevent a reset)
(3) download the binary file and save it to a FAT16/32 file if Ctl-F11 (to eeprom) is specified. Perhaps later, or load into lower hub ram if Ctl-F10 (to hub) is specified on PropTool, and run it (.cmd as an os file, .bin as a non-os file which kills the os and other cogs).
I see you found the schematic. All the info is on page 1 of this thread.
BTW, how is your two stage loader going?
What I would like to do (I worked on it some time ago but need to start over) from PropOS is...
(1) start a downloader program specifying a filename on the prop and wait for PropTool (or similar) to start a download
(2) start PropTool download (the reset line on the prop is disabled to prevent a reset)
(3) download the binary file and save it to a FAT16/32 file if Ctl-F11 (to eeprom) is specified. Perhaps later, or load into lower hub ram if Ctl-F10 (to hub) is specified on PropTool, and run it (.cmd as an os file, .bin as a non-os file which kills the os and other cogs).
The two-stage loader I'm working on is invoked from the PC not from a program running on the Propeller. The first step is to use the Propeller ROM loader to load the second-stage loader. Then, the second-stage loader loads the user program and either starts it running or writes it to EEPROM. I guess the second-stage loader could be started from the Propeller end but I haven't really considered that option so far.
...
The two-stage loader I'm working on is invoked from the PC not from a program running on the Propeller. The first step is to use the Propeller ROM loader to load the second-stage loader. Then, the second-stage loader loads the user program and either starts it running or writes it to EEPROM. I guess the second-stage loader could be started from the Propeller end but I haven't really considered that option so far.
Yes. I understand what you are doing.
I am interested from a different point of view, for a different loader mechanism. But they are similar in some respects, and quite likely have similar problems.
...
The two-stage loader I'm working on is invoked from the PC not from a program running on the Propeller. The first step is to use the Propeller ROM loader to load the second-stage loader. Then, the second-stage loader loads the user program and either starts it running or writes it to EEPROM. I guess the second-stage loader could be started from the Propeller end but I haven't really considered that option so far.
Yes. I understand what you are doing.
I am interested from a different point of view, for a different loader mechanism. But they are similar in some respects, and quite likely have similar problems.
So the idea with yours is that some sort of server process would always be listening on P30/31 and respond to load requests?
...
The two-stage loader I'm working on is invoked from the PC not from a program running on the Propeller. The first step is to use the Propeller ROM loader to load the second-stage loader. Then, the second-stage loader loads the user program and either starts it running or writes it to EEPROM. I guess the second-stage loader could be started from the Propeller end but I haven't really considered that option so far.
Yes. I understand what you are doing.
I am interested from a different point of view, for a different loader mechanism. But they are similar in some respects, and quite likely have similar problems.
So the idea with yours is that some sort of server process would always be listening on P30/31 and respond to load requests?
No.
While running PropOS, I want to be able to download program files to the SD card and then run and test them. This requires that I don't reset the prop from the PC program. I want to be able to use any of the prop IDE's to do the download, rather than a specific program (I have a VB6 exe that does file transfers to PropOS and CPM too).
...
The two-stage loader I'm working on is invoked from the PC not from a program running on the Propeller. The first step is to use the Propeller ROM loader to load the second-stage loader. Then, the second-stage loader loads the user program and either starts it running or writes it to EEPROM. I guess the second-stage loader could be started from the Propeller end but I haven't really considered that option so far.
Yes. I understand what you are doing.
I am interested from a different point of view, for a different loader mechanism. But they are similar in some respects, and quite likely have similar problems.
So the idea with yours is that some sort of server process would always be listening on P30/31 and respond to load requests?
No.
While running PropOS, I want to be able to download program files to the SD card and then run and test them. This requires that I don't reset the prop from the PC program. I want to be able to use any of the prop IDE's to do the download, rather than a specific program (I have a VB6 exe that does file transfers to PropOS and CPM too).
Okay, so the download is initiated on the PC side? What protocol are you using? How does PropOS know that data coming across P31/30 is a download data vs. just console I/O? Or are you saying that the PC sends a PropOS command that starts the download on the Propeller side and then proceeds to send data sort of like the way xmodem used to work?
David,
From the serial connection to the pc via P30/31, running PropOS on the prop, run a command program (using PST on the PC)
SD:>DNLOAD <file name>
This runs the os program _dnload.cmd which acts like the rom boot loader on the prop.
It waits for the user to switch PC programs back to PropTool and (compile) and download a binary file to the prop. The PropOS download module will fool the PropTool downloader whereby download to hub ram (ie Ctl-F10) loads hub and then executes it, and download to eeprom (ie Ctl-F11) writes the binary file to the SD card.
With this setup, any standard PC downloader (PropTool, simpleide, etc) should work.
David,
From the serial connection to the pc via P30/31, running PropOS on the prop, run a command program (using PST on the PC)
SD:>DNLOAD <file name>
This runs the os program _dnload.cmd which acts like the rom boot loader on the prop.
It waits for the user to switch PC programs back to PropTool and (compile) and download a binary file to the prop. The PropOS download module will fool the PropTool downloader whereby download to hub ram (ie Ctl-F10) loads hub and then executes it, and download to eeprom (ie Ctl-F11) writes the binary file to the SD card.
With this setup, any standard PC downloader (PropTool, simpleide, etc) should work.
That sounds quite easy except for the fact that PropTool or SimpleIDE will reset the Propeller. I guess you could disconnect the DTR line from the Propeller reset pin.
David,
That's why the reset pin has a jumper
For development wire in a switch to Gnd to reset when the test program crashes. Otherwise no need to manually reset as the reboot command can perform a soft reset.
I have worked on it before and picked this up again yesterday. I need to get it running to move forward with debugging marks Sphinx compiler that I have been working on.
Comments
The WE link and the QE link are 2@0.05" pitch and 3@0.05" pitch vias (pad holes). They take 1.27mm (0.050") pin headers and 0.050" shunts.
Most users will not change these so the links will be permanent - normally you will just leave WE unconnected (EEPROM write protected) and QE linked on one side or other (QE side enables the onboard transistor reset circuit = Q(transistor) Enabled).
A warning though, the WE is a little difficult to solder as it has the eeprom mounted on the underside over the holes. This was not a design error - I just couldn't fit it anywhere else. To program the eeprom I just hold a pair of 0.050" pins shorted in the holes while programming the eeprom. You can use a low value resistor 1K or less in the holes and this should work just fine.
The 0.050" pin stakes and shunts are not cheap which is why I didn't supply them as standard.
On previous boards, I used vias at smaller spacing, or pads at smaller spacing. This time I decided that because I am forever swapping things and programming the eeprom, I would fit mine with pin header and links. Those tiny shunts are a PITA to put on though!
Add to that the fact that its purchase price is (last I checked) only 78¢ and you have a winning combination. Sure, the supply is static. But there are still tens of thousands to be had.
SanDisk microSDHC UHS-I Class 10 8GB with SD Adapter.
BTW I always recommend SanDisk as they have the best record on the forums. And buy from a reputable source, not eBay, as there are a lot of counterfeits out there.
My logic is that the default program boots to the software on the microSD. Therefore, it is not necessary to change the boot code, just the code on the microSD. I expect that many users will not have a PropPlug, and may not even have a USB-TTL serial. So I don't want them accidentally corrupting the eeprom as they may have no way to re-program it. That is how I ship my RamBlade too.
For instance, you can use a Raspberry Pi as a terminal program to the prop board. And I have something else coming <wink><wink>
I like the idea of locking the eeprom and booting from SD. What happens if it can't find the SD?
BTW, if you flip that microSD CS resistor off you can detect the card via its built-in pullup.
Thanks Peter. Yes I have used solder jumpers - they are on my CpuBlade. But I want to be able to change the links easily, hence the 0.050" pin hdr pitch. I will be trying to see if solder bridging works although it is easy enough if you want a permanent solution.
If it cannot find the SD it just outputs an "!" every second IIRC.
Yes, I put the pullup resistor for CS on the board just in case. I use all the pullups on various boards to detect variants and then set the board type. This way I have one microSD card that I can plug into various boards and they just work - previously had 6.5MHz xtal hardcoded in the _hwdef.spin file but my aim is to do some form of checking as much as possible and then try and guess the speed.
BTW Do you have a link on checking if the xtal is x8 or x16? I am using 12MHz 1206.
{ ┌──────────────────────────────────────────────────────────┐ │ CLKSET │ │(c) Copyright 2009 Philip C. Pilgrim (propeller@phipi.com)│ │ See end of file for terms of use. │ └──────────────────────────────────────────────────────────┘ This object determines whether a 5MHz or 10MHz crystal is being used and sets the PLL accordingly for 80MHz operation. The main program should use the following settings: CON _clkmode = xtal1 + pll8x _xinfreq = 10_000_000 OBJ clk : "clkset" Then clk.set should be called first in the toplevel program. If the crystal is determined to be 5MHz, the clkmode will be changed to xtal1 + pll16x. clkfreq will still return 80_000_000. Version History ─────────────── 2009.05.23: WARNING: Trial, tentative, very alpha release! } PUB set '' Automatically set the pll mode for a 5MHz or 10MHz crystal. cognew(@setpll, 0) DAT org 0 setpll movi ctra,#%0_00001_011 'Set ctra for pll on no pin at x1. movi frqa,#%0100_0000_0 'Set frqa for clk / 4 (= 20MHz w/ 10MHz crystal, i.e. too high). add x,cnt 'Give PLL time to lock (if it can) and stabilize. waitcnt x,#0 movi vcfg,#$40 'Configure video for discrete pins, but no pins enabled. mov vscl,#$10 'Set for 16 clocks per frame. waitvid 0,0 'Wait once to clear time. neg x,cnt 'Read -cnt. waitvid 0,0 'Wait 16 pll clocks = 64 processor clks. add x,cnt 'Compute elapsed time. cmp x,#$40 wz 'Is it really 64 clocks? if_z mov x,#$6f ' Yes: Crystal is 5MHz. Set clock mode to XTAL1 and PLL16X. if_z clkset x cogid x 'Stop the cog: we're done. cogstop x x long $1_0000 '65536 clks for pll to stabilize. {{ ┌──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐ │ TERMS OF USE: MIT License │ ├──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤ │Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation │ │files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, │ │modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software│ │is furnished to do so, subject to the following conditions: │ │ │ │The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.│ │ │ │THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE │ │WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR │ │COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, │ │ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. │ └──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘ }}On the RamBlade I have been using propboot.bin although it first searches for autoexec.bat and if found used the first line only and searches for that file and if found runs it, if not then runs propboot.bin. This is based on PropCMD and fsrw IIRC.
On CpuBlade and RamBlade3 (CpuBlade + MemBlade) I have been using PropOS. This just runs itself until you enter an OS command at the SD:>
It does check the SD card but I would need to check what else it does.
I am working on PropOS currently to...
* shrink and understand Kyes PASM driver (also to convert to P2)
* self-detect more prop boards and also adjust the crystal frequency (currently this has to be recompiled after fixing _hwdef.spin
* make Kyes PASM driver cog resident with high hub interface
Then I can remake the boot file in eeprom work as discussed on the P2 forum
* validate MBR sector 0 for botloader - if valid, load and run, else
* validate FAT and look for "bootprop.bin" and if found load and run, else
* stop???
Nevermind, it will do that anyway! DOH!!!
Sorry, been dealing with IT auditors all week - brain glazed over!
Here is the latest PropOS v0.84 code (source and compiler included) for the boards (same for both P8XBlade2 & CpuBlade7 - auto detects these)
Page 1
Yes it's tiny for sure.
I see you found the schematic. All the info is on page 1 of this thread.
BTW, how is your two stage loader going?
What I would like to do (I worked on it some time ago but need to start over) from PropOS is...
(1) start a downloader program specifying a filename on the prop and wait for PropTool (or similar) to start a download
(2) start PropTool download (the reset line on the prop is disabled to prevent a reset)
(3) download the binary file and save it to a FAT16/32 file if Ctl-F11 (to eeprom) is specified. Perhaps later, or load into lower hub ram if Ctl-F10 (to hub) is specified on PropTool, and run it (.cmd as an os file, .bin as a non-os file which kills the os and other cogs).
I am interested from a different point of view, for a different loader mechanism. But they are similar in some respects, and quite likely have similar problems.
While running PropOS, I want to be able to download program files to the SD card and then run and test them. This requires that I don't reset the prop from the PC program. I want to be able to use any of the prop IDE's to do the download, rather than a specific program (I have a VB6 exe that does file transfers to PropOS and CPM too).
From the serial connection to the pc via P30/31, running PropOS on the prop, run a command program (using PST on the PC)
SD:>DNLOAD <file name>
This runs the os program _dnload.cmd which acts like the rom boot loader on the prop.
It waits for the user to switch PC programs back to PropTool and (compile) and download a binary file to the prop. The PropOS download module will fool the PropTool downloader whereby download to hub ram (ie Ctl-F10) loads hub and then executes it, and download to eeprom (ie Ctl-F11) writes the binary file to the SD card.
With this setup, any standard PC downloader (PropTool, simpleide, etc) should work.
I may have 2-3 of the SX48 protoboards Parallax used to sell years ago. The kind that was $9.99 IIRC.
If you want them you can have them. Just send me a PM if you're interested.
That's why the reset pin has a jumper
For development wire in a switch to Gnd to reset when the test program crashes. Otherwise no need to manually reset as the reboot command can perform a soft reset.
I have worked on it before and picked this up again yesterday. I need to get it running to move forward with debugging marks Sphinx compiler that I have been working on.
What's required on an sx48 board? I have never used the sx.