PullMoll: You have hit the BIG Propeller question. That thought about reclaiming HUB space "lost" to COG code is a theme that has been recurring since
the dawn of the Propeller. So far without resolution.
Seems to me that it really needs some help from the Prop Tool or BST or whatever.
There should be a way to compile a project that contains almost 32K of Spin code PLUS multiple lumps of up to 2K of PASM code.
The Spin code would end up in the image file and hence in HUB when the Prop is booted.
The PASM binary code would be emitted to multiple "COG image" files. These would end up on SD card or whatever. Alternatively they could be placed in the high end of a 64K EEPROM
In the Spin code is a wrapper around COGNEW that fetches the appropriate COG binary from SD or EEPROM to a buffer, as you say, and starts the cog with it.
This would all hang together in much the same way as overlaying linkers did in the days of memory limited 8 and 16 bit machines.
Of course not all COG code would be excluded from HUB, you need an SD driver for example. So the needs to be a way to tell the PropTool which it can exclude from HUB space.
This could probably all be done with the Prop tool/BST now in some clunky way.
Somewhere there is a program that is an PASM only assembler for the Prop. Is it PropASM or such? It emits no spin byte codes at all (Well just a couple to get the first PASM COG started)
Perhaps that could be pressed into service to assemble "overlaid" COG modules separately.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
It strikes me that if a 2K buffer space is required for loading the cog images into this would be ideally initialised with the pasm SD block driver/EEPROM i2c driver on boot.
Then once that code is running it can overwrite it's own cog code space with whatever new PASM you want to load.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nathan
"Free as in freedom, beer gratefully accepted though."
Juggling PASM blocks into COGs from SD could get a bit tricky if they have any linkage to anything in VAR or DAT sections that are in HUB.
Seems to me that all separately assembled COG "blobs" would have to get all their knowledge of the "host" environment via PAR.
I know some of my COG code would need modifying to work like that as it has linkage to variables in VAR or DAT in HUB.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
True, you could always have the launcher spin routine patch the cog image before the cog start is called.
So you load a 2K file from disk, write for example, a pin mask or something to a static offset from the start of the cog buffer in Hub,
then you call cog_new to start it running.
There needs to be a way to request a cog load (something along the lines of fetch_cog("NAME.PSM")) that gets the cog image so that the
loading method is abstracted from the start() routines of the various spin objects. Trouble is this would need to be called from inside multiple
low - level objects.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nathan
"Free as in freedom, beer gratefully accepted though."
I've just got some new wireless modules. $20 each from Sure Electronics (a bit hard to find on ebay stores.ebay.com/sureelectronics1 and then search for transceiver and pick the one that looks like the photo attached)
9600 baud and 100% reliability. Managed to do a remote login to a propeller board as well as send and receive files via xmodem.
There is nothing wrong with the Yishi modules I've been using except that the baud rate is factory programmed and I went for 1200 and it is a bit tedious for file transfers. The Sure ones are programmable.
On that subiect I talked some time ago.
But not any one answered my Posts.
1. To that we needs some initial structure in Begining else END of that "blobs" That describe "PAR pointer address" for its Variables that can be simple to edit for diferent needs.
2. Need START spin stub Loader that have posibility to change Loading parameters from other Objects with that - initial structure in Begining else END of that "blobs".
3. Maybe even that we need Discution On some usage of HUB ram areas for diferent DRIVERS that are totaly PASM and only communicate with all SPIN code with theirs VARIABLES.
-- To that we need structure for signaling Of activites in that Drivers type "DATA available flags, BUSY, FREE to INPUT data from other procedure"
Regards
Christoffer J
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty. For every stupid question there is at least one intelligent answer. Don't guess - ask instead. If you don't ask you won't know. If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
heater said...
Oh yes propasm. Written in Java, I forget by whom. See attachment.
Use it as:
# java -jar propasm.jar some_prog.pasm
You will need to something like the following at the beginning of the PASM source:
.clkmode xtal1 x8
.xinfreq 10000000
org 0
There you go, create all the COG "overlays" in SD you like.
You can also use BSTC to do that. If there is any Spin code after the fit $1f0, it doesn't hurt. The cog is always initialized with $1F0 bytes. The only real problem is relocation of any referenced DAT objects. They would still have to live somewhere in the cog RAM (think of a font for the VGA/TV drivers) and their addresses would need a fixup. Actually one can know the addresses of a separately compiled cog PASM + DAT section elements, but you cannot relocate that automatically. Some references may be as #offset, as long as the address overlaps the cog RAM, some may be as word/long @object or even @@@object. I think without help from the compiler (or assembler) producing a relocation map we're lost.
BTW: Why is this window so wide? Looks like one post's lines aren't broken down at a reasonable width.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
1) It needs to compile all Spin and PASM as normal but not put the resulting PASM blobs into the binary file. This means a lot more space for Spin in the binary EEPROM image.
2) It needs to write out the PASM binary blobs to separate files for later loading from SD into the Prop.
Actually if it did that for us it would solve all the linkage problems. Those blobs emitted to separate files would already be have their linkage to any DAT areas set up OK. Pretty much as normal.
BradC, pretty please.....
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
My thinking was to compile that "blobs" as separate files. With all nessesary INFO included Simpler in Begining of that PASM.BIN
file BUT BETTER in END of that file that will have correct always 2KB and last LONGS that are not loaded to COG used as WORK info.
BUT to that we need mods to compiler else find metods to compile that and generate with existing compiler's.
Regards
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty. For every stupid question there is at least one intelligent answer. Don't guess - ask instead. If you don't ask you won't know. If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sphinx already compiles each file to an .SOB file so I think this may be halfway there. mpark can answer further - might be better to continue on the SphinxOS thread??
I have also done some work to make some of the drivers self-contained and substitutable in SphinxOS. e.g. FDX, KBD, TV.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
ATTACH some Constants at END of that .BIN betwen $1F0 and $1FF that describe PAR addres for Variable area for that "blobs".
And maybe some other INFO we can need in that area for particular DRIVER.
AS last LONGS are not loaded to COG we can use that area in 2KB space to that and have them correct 2KB to be posible to load-
from any EEPROM/FLASH memory area to that 2KB space You describe for that handle of loading Drivers.
Regards
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty. For every stupid question there is at least one intelligent answer. Don't guess - ask instead. If you don't ask you won't know. If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
MAYBE we can open sepatate THREAD to that discution.
You Can initialise it and have LINK to starting in this thread of that discution.
And we can talk on all aspects that need's for it in that separate thread
Regards
Christoffer J
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty. For every stupid question there is at least one intelligent answer. Don't guess - ask instead. If you don't ask you won't know. If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
hairymnstr: I don't think a pragma is the thing. Spin already has PUB, VAR, DAT...blocks.
Why not just have a new block type for these PASM blobs? Call it "EXT" for external or "OVL" for overlay or whatever.
So:
EXT mydriver.bin
Would put the following PASM stuff into the file mydriver.bin up to the start of the next block type or 2K whichever comes first. Not into the EEPROM image.
>> "We'd still need to do some adjustments as when the binary blob is loaded it will be in the cog loader buffer not where it was compiled from."
Fortunately there are no references from Spin code into a running COG. It's in a different address space totally in the COG.
That only leaves the issue of how we some times tweak a few things in the DAT block prior to loading it into a COG.
This could be handled by defining a parameter area at the start or end of COG code in a standard way. I think that is what Sapieha is suggesting.
Looks to me that if we could convince BradC to add this "small" feature into BST then we could define a standard in the way code is written to take care of the rest.
i.e. EXT sections emitted into separate files and left out of the EEPROM image.
PLUS making labels inside EXT sections private so that Spin code does not try to link to it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Ps. In my opinion . END of that "2KB blobs" is optimal place for that DAT info on - Name, PAR, and what else we need in that block.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty. For every stupid question there is at least one intelligent answer. Don't guess - ask instead. If you don't ask you won't know. If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
With BSTC, the command line tool. You of course have to gather the "#define"s from the top level file and add them as -Dname to the command. Then you select -b for binary and it will compile the spin file, of course plus all dependencies, into a *.binary file. Apropos dependencies: cross references between BLOBs are going to be complicated. Should the loader know if a dependency is already loaded or must be loaded and resolve linkage to that cog/DAT? ... wheww. The longer I think about it, the less easy it all seems.
heater said...
1) It needs to compile all Spin and PASM as normal but not put the resulting PASM blobs into the binary file. This means a lot more space for Spin in the binary EEPROM image.
Well, for example I would compile trs80_video.spin as a separate binary, because it has no external dependencies. There is some kind of header in the binary file which seems to have pointers to the Spin methods in the file. After that header $1f0 bytes are the cog image, and the following bytes are DAT, until an the first Spin metjod offset that is noted in the header.
heater said...
2) It needs to write out the PASM binary blobs to separate files for later loading from SD into the Prop.
You can separate the cog Image data out of the binary files without too much trouble.
heater said...
Actually if it did that for us it would solve all the linkage problems. Those blobs emitted to separate files would already be have their linkage to any DAT areas set up OK. Pretty much as normal.
Yes, except for any cross references that are compiled into one binary. Separating a multiple source binary into separate blobs looks a little more complicated.
heater said...
BradC, pretty please.....
I think he said he's busy until 18th of next month...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
COG PASM data block's not have any headers to SPIN.
All communication betwen Spin and COG-PASM determines by PAR register Loaded in COG.
Regards
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty. For every stupid question there is at least one intelligent answer. Don't guess - ask instead. If you don't ask you won't know. If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
COG PASM data block's not have any headers to SPIN.
All communication betwen Spin and COG-PASM determines by PAR register Loaded in COG.
Regards
Well, not the COG image ...but the binary output generated by BSTC has some headers! It's not starting with the raw COG image, but some longs ($20 bytes in case of trs80_video.spin) where some of them point to offsets within the file where obviously Spin code resides.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Hi pullmoll
.
It is for that I we discused with heather that that needs some mods to BST, BSTC that can generate RAW PASM-.BIN without that Header.
That offsets are not nessesary if we write drivers in litle diferent maner.
And most of Drivers already not use that offsets. Them are only to GIVE driver correct parameters to RUN.
That can be placed in INFO block we discusing on and loaded by LOADER in correct placess
Regards
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty. For every stupid question there is at least one intelligent answer. Don't guess - ask instead. If you don't ask you won't know. If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
BTW: as an example, see the Debug 1pinTV demo. The driver is in 1 cog and the data is filled to $1F0 and the following 16 longs are also defined as $0 so that if the screen buffer is 2000 (80x25) then this space will be reserved in hub. This is the sort of thing you are discussing - putting references, etc in the 16 longs following the cog space.
The cog dat code should be seperated from the cog 'blob' - I have done this in SphinxOS where the calling mechanism is a standalone spin block. See inx_in.spin and inx.out.spin files in SphinxOS.
The load mechanism could be inbuilt in SphinxOS which would serve a lot of development basis. This is where I have been working towards for ZiCog. I am almost there to be able to substitute the I/O for ZiCog by SphinxOS without ZiCog being aware of the change. This means I can either boot SphinxOS and ZiCog to use a serial (ie PC or other prop running VT100) or a TV/KBD combo (either 1pin or normal pins).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Inspired by your discussions earlier and the idea of an RS485 bus with a heap of boards on (from the PropCade thread), when tidying up this evening I came across a discarded proto-board and a Microchip ENC28J60 SPI ethernet PHY/MAC. It took a couple of hours but I currently have it sitting next to me reading twitter with a Cat6 cable plugged in.
This is fairly cheap hardware (~£10 for parts) and the PropTCP stack seems fairly mature, however, there's unlikely to be room in the DracBlade for enough code to get this working.
My suggestion is this: a propeller internet gateway server.
A simple board with no VGA/Keyboard one of these ethernet controller ICs and a connection to some sort of multidrop serial bus (e.g. your wireless mesh protocol, an RS485 bus, an XBee module etc) The sole purpose of this prop is to route messages from the internet to devices on the local network and the inverse. If we can encapsulate enough of the TCP/IP in the gateway controller, the devices in the network could use a much lighter protocol with lower processing and memory overheads.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nathan
"Free as in freedom, beer gratefully accepted though."
First Heater, now Hairy... people keep outing my future products!
(above is more or less tongue and cheek... neither heater nor hairymnstr had any idea about my future products)
I've got something like that coming. That's all I will say for now. I even have working boards, from a previous generation design.
You are absolutely correct, the PropTCP stack is great.
hairymnstr said...
Right, back to the subject of networking.
Inspired by your discussions earlier and the idea of an RS485 bus with a heap of boards on (from the PropCade thread), when tidying up this evening I came across a discarded proto-board and a Microchip ENC28J60 SPI ethernet PHY/MAC. It took a couple of hours but I currently have it sitting next to me reading twitter with a Cat6 cable plugged in.
This is fairly cheap hardware (~£10 for parts) and the PropTCP stack seems fairly mature, however, there's unlikely to be room in the DracBlade for enough code to get this working.
My suggestion is this: a propeller internet gateway server.
A simple board with no VGA/Keyboard one of these ethernet controller ICs and a connection to some sort of multidrop serial bus (e.g. your wireless mesh protocol, an RS485 bus, an XBee module etc) The sole purpose of this prop is to route messages from the internet to devices on the local network and the inverse. If we can encapsulate enough of the TCP/IP in the gateway controller, the devices in the network could use a much lighter protocol with lower processing and memory overheads.
:-S Sorry Bill. I've had this one in the planning for about 2 years now, hence why all the parts were in my spare parts tin. Just haven't got around to it.
Should be interesting commercial versus open... who will win?
In the end I hope both of us as I'm sure we'll end up with different markets and applications.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nathan
"Free as in freedom, beer gratefully accepted though."
I tend to sell my "mass market" boards for not much more than a reasonable PCB price + the qty.1 parts costs at Digikey + a small markup... at least for the forum specials [noparse]:)[/noparse]
My boards are open to the extent that they are fully documented, people just can't copy them and sell them. I have a mortage [noparse]:)[/noparse] and doing this is now my "day job".
Take a peek at the Ybox2 - I have two of them. Neat little board, I got them because that was Harrison's development platform for PropTCP.
While my boards are commercial, and yours open source, I think everyone will win
hairymnstr said...
:-S Sorry Bill. I've had this one in the planning for about 2 years now, hence why all the parts were in my spare parts tin. Just haven't got around to it.
Should be interesting commercial versus open... who will win?
In the end I hope both of us as I'm sure we'll end up with different markets and applications.
I've been pondering ways to get old CP/M computers into a wireless network. Consider - worst case scenario you are logging into a remote machine and somehow it runs some code and jumps into a bit of data and finds a HALT and stops working. How do you reset a machine from the other side of the world? I'm thinking there is a minimum of 'magic packet' commands that have to sit above CP/M.
RESET
WHO
LOGON
LOGOFF
So - you issue a RESET command and that physically resets the old computer. An old school relay if needs be on the reset button. WHO replies with the name of the board. LOGON/LOGOFF ensures that only one board is talking when sending out 'raw' bytes (ie bytes not wrapped up in packets). Raw bytes are needed to get a new board into the network, even if the only thing you do with the raw bytes is type the name of the program you want to run and carriage return.
I've been thinking about a little board that you plug into the serial port of an old CP/M computer and it acts as a gateway between the computer and the network. It can be very simple - a propeller, max232 and a relay for the reset. No need for external memory or even a display. If you send a LOGON command it passes data through until either LOGOFF or until no data for a while.
But your idea has me thinking even more. How about we put your little microchip ethernet on that board too? And add 7 pins for the wireless module as well.
Now this becomes a small universal data translator. Use it to get your old CP/M computer networked to your Propeller CP/M board and to other legacy computers. Also, use it as a bridge between the internet and a wireless network. Say a bunch of text comes back from Twitter. This module might wrap that up in a packet with a destination and checksum and send it out wirelessly and it will go to the correct place.
I've got the packet router software working too, so if data is in packets it will bounce around a network till it goes where it is meant to.
So then I don't think it matters if your code does not fit in a dracblade. Don't try to run all the other things as they are not needed.
One other thought. I'm talking to the radio module with RS232, but the modules can be software configured as RS232 or TTL or RS485. So if you want RS485 that isn't even any new hardware - just a quick reprogram of the board.
(as an aside, the packet protocol is pretty simple - start byte, number of bytes, source, destination, message type, data bytes, checksum, end byte).
Yeah a universal router/comms board is an idea I've been pondering for some time. Ethernet, wireless, serial. Should be eminently do-able. I think I'll start tinkering a bit more after the Easter break.
I have a protoboard with the Ethernet MAC/PHY and a MAX202 here now and a pile of XBee modules in a box and a trio of Dracblades to play the part of nodes. Should be interesting work.
@Bill, yeah it's the YBox2 firmware (modified for my hardware) that I'm running now.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nathan
"Free as in freedom, beer gratefully accepted though."
Great. Ideally it should work with different types of wireless modules, though I've found the buffer size is important and most have a buffer of 64 bytes and xmodem needs 131. However if the bytes are gobbled up fast enough it does not matter. xmodem in assembly can eat them up as fast as 19200, though the sbasic version of xmodem was struggling at 9600. Xbee would be nice to add.
Wireless is not necessary though. You can network boards with a wired RS232 link and a null modem cable (which is simply a female to female D9 with pins 2 and 3 swapped, and pin 5 GND going straight through).
If you can turn Twitter into serial bytes at 9600 baud that would be pretty amazing.
@hairymnstr - I've uploaded your smallspinfiles code as the main code on page 1. I added a few more things myself - a new #ifdef so you can turn off the LCD and all its code with one comment and a few more things, see the comments section. I'm doing more testing with the wireless link - wordstar is now fast enough you can actually use it to type letters via wireless. 9600 baud is the same speed my terminal ran 20 years ago and that got me all the way through University!
Addit - more testing 2nd April, baud rate at 9600 now tested with file transfers and with remote DIR and remore wordstar, and remote mbasic. All very stable.
Comments
the dawn of the Propeller. So far without resolution.
Seems to me that it really needs some help from the Prop Tool or BST or whatever.
There should be a way to compile a project that contains almost 32K of Spin code PLUS multiple lumps of up to 2K of PASM code.
The Spin code would end up in the image file and hence in HUB when the Prop is booted.
The PASM binary code would be emitted to multiple "COG image" files. These would end up on SD card or whatever. Alternatively they could be placed in the high end of a 64K EEPROM
In the Spin code is a wrapper around COGNEW that fetches the appropriate COG binary from SD or EEPROM to a buffer, as you say, and starts the cog with it.
This would all hang together in much the same way as overlaying linkers did in the days of memory limited 8 and 16 bit machines.
Of course not all COG code would be excluded from HUB, you need an SD driver for example. So the needs to be a way to tell the PropTool which it can exclude from HUB space.
This could probably all be done with the Prop tool/BST now in some clunky way.
Somewhere there is a program that is an PASM only assembler for the Prop. Is it PropASM or such? It emits no spin byte codes at all (Well just a couple to get the first PASM COG started)
Perhaps that could be pressed into service to assemble "overlaid" COG modules separately.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Use it as:
# java -jar propasm.jar some_prog.pasm
You will need to something like the following at the beginning of the PASM source:
.clkmode xtal1 x8 .xinfreq 10000000 org 0There you go, create all the COG "overlays" in SD you like.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Then once that code is running it can overwrite it's own cog code space with whatever new PASM you want to load.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nathan
"Free as in freedom, beer gratefully accepted though."
Juggling PASM blocks into COGs from SD could get a bit tricky if they have any linkage to anything in VAR or DAT sections that are in HUB.
Seems to me that all separately assembled COG "blobs" would have to get all their knowledge of the "host" environment via PAR.
I know some of my COG code would need modifying to work like that as it has linkage to variables in VAR or DAT in HUB.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
So you load a 2K file from disk, write for example, a pin mask or something to a static offset from the start of the cog buffer in Hub,
then you call cog_new to start it running.
There needs to be a way to request a cog load (something along the lines of fetch_cog("NAME.PSM")) that gets the cog image so that the
loading method is abstracted from the start() routines of the various spin objects. Trouble is this would need to be called from inside multiple
low - level objects.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nathan
"Free as in freedom, beer gratefully accepted though."
I've just got some new wireless modules. $20 each from Sure Electronics (a bit hard to find on ebay stores.ebay.com/sureelectronics1 and then search for transceiver and pick the one that looks like the photo attached)
or go direct to one of the listings cgi.ebay.com/2xWireless-RF-Transceiver-431-478MHz-GFSK-Data-Transfer_W0QQitemZ350334728051QQcmdZViewItemQQptZLH_DefaultDomain_0?hash=item519193b773 or do the buy it now (varies $35 to $45 depending on the day)
9600 baud and 100% reliability. Managed to do a remote login to a propeller board as well as send and receive files via xmodem.
There is nothing wrong with the Yishi modules I've been using except that the baud rate is factory programmed and I went for 1200 and it is a bit tedious for file transfers. The Sure ones are programmable.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
On that subiect I talked some time ago.
But not any one answered my Posts.
1. To that we needs some initial structure in Begining else END of that "blobs" That describe "PAR pointer address" for its Variables that can be simple to edit for diferent needs.
2. Need START spin stub Loader that have posibility to change Loading parameters from other Objects with that - initial structure in Begining else END of that "blobs".
3. Maybe even that we need Discution On some usage of HUB ram areas for diferent DRIVERS that are totaly PASM and only communicate with all SPIN code with theirs VARIABLES.
-- To that we need structure for signaling Of activites in that Drivers type "DATA available flags, BUSY, FREE to INPUT data from other procedure"
Regards
Christoffer J
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
You can also use BSTC to do that. If there is any Spin code after the fit $1f0, it doesn't hurt. The cog is always initialized with $1F0 bytes. The only real problem is relocation of any referenced DAT objects. They would still have to live somewhere in the cog RAM (think of a font for the VGA/TV drivers) and their addresses would need a fixup. Actually one can know the addresses of a separately compiled cog PASM + DAT section elements, but you cannot relocate that automatically. Some references may be as #offset, as long as the address overlaps the cog RAM, some may be as word/long @object or even @@@object. I think without help from the compiler (or assembler) producing a relocation map we're lost.
BTW: Why is this window so wide? Looks like one post's lines aren't broken down at a reasonable width.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
1) It needs to compile all Spin and PASM as normal but not put the resulting PASM blobs into the binary file. This means a lot more space for Spin in the binary EEPROM image.
2) It needs to write out the PASM binary blobs to separate files for later loading from SD into the Prop.
Actually if it did that for us it would solve all the linkage problems. Those blobs emitted to separate files would already be have their linkage to any DAT areas set up OK. Pretty much as normal.
BradC, pretty please.....
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
My thinking was to compile that "blobs" as separate files. With all nessesary INFO included Simpler in Begining of that PASM.BIN
file BUT BETTER in END of that file that will have correct always 2KB and last LONGS that are not loaded to COG used as WORK info.
BUT to that we need mods to compiler else find metods to compile that and generate with existing compiler's.
Regards
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
pub start ... #pragma PASM driver org 0 entry ... fit $1F0 #pragma ENDPASMso that would output the code between PASM and ENDPASM in a file called driver.??? and not include it in the eeprom image
We'd still need to do some adjustments as when the binary blob is loaded it will be in the cog loader buffer not where it was compiled from.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nathan
"Free as in freedom, beer gratefully accepted though."
I have also done some work to make some of the drivers self-contained and substitutable in SphinxOS. e.g. FDX, KBD, TV.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
YOU are next correct - BUT it neds one thing to.
ATTACH some Constants at END of that .BIN betwen $1F0 and $1FF that describe PAR addres for Variable area for that "blobs".
And maybe some other INFO we can need in that area for particular DRIVER.
AS last LONGS are not loaded to COG we can use that area in 2KB space to that and have them correct 2KB to be posible to load-
from any EEPROM/FLASH memory area to that 2KB space You describe for that handle of loading Drivers.
Regards
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
MAYBE we can open sepatate THREAD to that discution.
You Can initialise it and have LINK to starting in this thread of that discution.
And we can talk on all aspects that need's for it in that separate thread
Regards
Christoffer J
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
Why not just have a new block type for these PASM blobs? Call it "EXT" for external or "OVL" for overlay or whatever.
So:
EXT mydriver.bin
Would put the following PASM stuff into the file mydriver.bin up to the start of the next block type or 2K whichever comes first. Not into the EEPROM image.
>> "We'd still need to do some adjustments as when the binary blob is loaded it will be in the cog loader buffer not where it was compiled from."
Fortunately there are no references from Spin code into a running COG. It's in a different address space totally in the COG.
That only leaves the issue of how we some times tweak a few things in the DAT block prior to loading it into a COG.
This could be handled by defining a parameter area at the start or end of COG code in a standard way. I think that is what Sapieha is suggesting.
Looks to me that if we could convince BradC to add this "small" feature into BST then we could define a standard in the way code is written to take care of the rest.
i.e. EXT sections emitted into separate files and left out of the EEPROM image.
PLUS making labels inside EXT sections private so that Spin code does not try to link to it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I was thinking in C when I said #pragma, a new EXT type makes more sense in the SPIN/PASM language.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nathan
"Free as in freedom, beer gratefully accepted though."
THANKS.
You understand me Correctly.
Regards
Christoffer
Ps. In my opinion . END of that "2KB blobs" is optimal place for that DAT info on - Name, PAR, and what else we need in that block.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
Well, for example I would compile trs80_video.spin as a separate binary, because it has no external dependencies. There is some kind of header in the binary file which seems to have pointers to the Spin methods in the file. After that header $1f0 bytes are the cog image, and the following bytes are DAT, until an the first Spin metjod offset that is noted in the header.
You can separate the cog Image data out of the binary files without too much trouble.
Yes, except for any cross references that are compiled into one binary. Separating a multiple source binary into separate blobs looks a little more complicated.
I think he said he's busy until 18th of next month...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
COG PASM data block's not have any headers to SPIN.
All communication betwen Spin and COG-PASM determines by PAR register Loaded in COG.
Regards
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
Well, not the COG image ...but the binary output generated by BSTC has some headers! It's not starting with the raw COG image, but some longs ($20 bytes in case of trs80_video.spin) where some of them point to offsets within the file where obviously Spin code resides.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
.
It is for that I we discused with heather that that needs some mods to BST, BSTC that can generate RAW PASM-.BIN without that Header.
That offsets are not nessesary if we write drivers in litle diferent maner.
And most of Drivers already not use that offsets. Them are only to GIVE driver correct parameters to RUN.
That can be placed in INFO block we discusing on and loaded by LOADER in correct placess
Regards
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
BTW: as an example, see the Debug 1pinTV demo. The driver is in 1 cog and the data is filled to $1F0 and the following 16 longs are also defined as $0 so that if the screen buffer is 2000 (80x25) then this space will be reserved in hub. This is the sort of thing you are discussing - putting references, etc in the 16 longs following the cog space.
The cog dat code should be seperated from the cog 'blob' - I have done this in SphinxOS where the calling mechanism is a standalone spin block. See inx_in.spin and inx.out.spin files in SphinxOS.
The load mechanism could be inbuilt in SphinxOS which would serve a lot of development basis. This is where I have been working towards for ZiCog. I am almost there to be able to substitute the I/O for ZiCog by SphinxOS without ZiCog being aware of the change. This means I can either boot SphinxOS and ZiCog to use a serial (ie PC or other prop running VT100) or a TV/KBD combo (either 1pin or normal pins).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
Inspired by your discussions earlier and the idea of an RS485 bus with a heap of boards on (from the PropCade thread), when tidying up this evening I came across a discarded proto-board and a Microchip ENC28J60 SPI ethernet PHY/MAC. It took a couple of hours but I currently have it sitting next to me reading twitter with a Cat6 cable plugged in.
This is fairly cheap hardware (~£10 for parts) and the PropTCP stack seems fairly mature, however, there's unlikely to be room in the DracBlade for enough code to get this working.
My suggestion is this: a propeller internet gateway server.
A simple board with no VGA/Keyboard one of these ethernet controller ICs and a connection to some sort of multidrop serial bus (e.g. your wireless mesh protocol, an RS485 bus, an XBee module etc) The sole purpose of this prop is to route messages from the internet to devices on the local network and the inverse. If we can encapsulate enough of the TCP/IP in the gateway controller, the devices in the network could use a much lighter protocol with lower processing and memory overheads.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nathan
"Free as in freedom, beer gratefully accepted though."
First Heater, now Hairy... people keep outing my future products!
(above is more or less tongue and cheek... neither heater nor hairymnstr had any idea about my future products)
I've got something like that coming. That's all I will say for now. I even have working boards, from a previous generation design.
You are absolutely correct, the PropTCP stack is great.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com 5.0" VGA LCD in stock!
Morpheus dual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory/IO kit $89.95, both kits $189.95 SerPlug $9.95
Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz
Las - Large model assembler Largos - upcoming nano operating system
Post Edited (Bill Henning) : 3/31/2010 10:57:24 PM GMT
Should be interesting commercial versus open... who will win?
In the end I hope both of us as I'm sure we'll end up with different markets and applications.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nathan
"Free as in freedom, beer gratefully accepted though."
I tend to sell my "mass market" boards for not much more than a reasonable PCB price + the qty.1 parts costs at Digikey + a small markup... at least for the forum specials [noparse]:)[/noparse]
My boards are open to the extent that they are fully documented, people just can't copy them and sell them. I have a mortage [noparse]:)[/noparse] and doing this is now my "day job".
Take a peek at the Ybox2 - I have two of them. Neat little board, I got them because that was Harrison's development platform for PropTCP.
While my boards are commercial, and yours open source, I think everyone will win
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com 5.0" VGA LCD in stock!
Morpheus dual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory/IO kit $89.95, both kits $189.95 SerPlug $9.95
Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz
Las - Large model assembler Largos - upcoming nano operating system
I've been pondering ways to get old CP/M computers into a wireless network. Consider - worst case scenario you are logging into a remote machine and somehow it runs some code and jumps into a bit of data and finds a HALT and stops working. How do you reset a machine from the other side of the world? I'm thinking there is a minimum of 'magic packet' commands that have to sit above CP/M.
RESET
WHO
LOGON
LOGOFF
So - you issue a RESET command and that physically resets the old computer. An old school relay if needs be on the reset button. WHO replies with the name of the board. LOGON/LOGOFF ensures that only one board is talking when sending out 'raw' bytes (ie bytes not wrapped up in packets). Raw bytes are needed to get a new board into the network, even if the only thing you do with the raw bytes is type the name of the program you want to run and carriage return.
I've been thinking about a little board that you plug into the serial port of an old CP/M computer and it acts as a gateway between the computer and the network. It can be very simple - a propeller, max232 and a relay for the reset. No need for external memory or even a display. If you send a LOGON command it passes data through until either LOGOFF or until no data for a while.
But your idea has me thinking even more. How about we put your little microchip ethernet on that board too? And add 7 pins for the wireless module as well.
Now this becomes a small universal data translator. Use it to get your old CP/M computer networked to your Propeller CP/M board and to other legacy computers. Also, use it as a bridge between the internet and a wireless network. Say a bunch of text comes back from Twitter. This module might wrap that up in a packet with a destination and checksum and send it out wirelessly and it will go to the correct place.
I've got the packet router software working too, so if data is in packets it will bounce around a network till it goes where it is meant to.
So then I don't think it matters if your code does not fit in a dracblade. Don't try to run all the other things as they are not needed.
One other thought. I'm talking to the radio module with RS232, but the modules can be software configured as RS232 or TTL or RS485. So if you want RS485 that isn't even any new hardware - just a quick reprogram of the board.
(as an aside, the packet protocol is pretty simple - start byte, number of bytes, source, destination, message type, data bytes, checksum, end byte).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Post Edited (Dr_Acula) : 3/31/2010 11:14:33 PM GMT
I have a protoboard with the Ethernet MAC/PHY and a MAX202 here now and a pile of XBee modules in a box and a trio of Dracblades to play the part of nodes. Should be interesting work.
@Bill, yeah it's the YBox2 firmware (modified for my hardware) that I'm running now.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nathan
"Free as in freedom, beer gratefully accepted though."
Wireless is not necessary though. You can network boards with a wired RS232 link and a null modem cable (which is simply a female to female D9 with pins 2 and 3 swapped, and pin 5 GND going straight through).
If you can turn Twitter into serial bytes at 9600 baud that would be pretty amazing.
Radio modules here www.sureelectronics.net/goods.php?id=1053
@hairymnstr - I've uploaded your smallspinfiles code as the main code on page 1. I added a few more things myself - a new #ifdef so you can turn off the LCD and all its code with one comment and a few more things, see the comments section. I'm doing more testing with the wireless link - wordstar is now fast enough you can actually use it to type letters via wireless. 9600 baud is the same speed my terminal ran 20 years ago and that got me all the way through University!
Addit - more testing 2nd April, baud rate at 9600 now tested with file transfers and with remote DIR and remore wordstar, and remote mbasic. All very stable.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Post Edited (Dr_Acula) : 4/1/2010 1:47:50 PM GMT