Kye said...
You missed my point. How do you tell a FAT FS system cog what to do using a mailbox rountine? Its not that simple. I'm not talking about low level get block and put block rountines. I'm talking about opening files and such.
Here are the files I use to communicate to the file system.· cfileio0.spin is used by the calling cog, and cfileio1.spin is the top object that runs the polling loop on the file system cog.
Bill, most of the cog will be FS agnostic, just providing sector read & write functions just as fsrw (well it is the sdspifemto equivalent... mb_rawb_spi). If there is space, we can add some Fat16/32 stuff - maybe directory. I doubt we can fit much more. mpark used 3 cogs for the full FAT16 code.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Kye said...
You missed my point. How do you tell a FAT FS system cog what to do using a mailbox rountine? Its not that simple. I'm not talking about low level get block and put block rountines. I'm talking about opening files and such.
This is why the mailbox can't be simply one long (unless current Propeller is the only target).
With a pointer however, you have a reference to a data-structure which can be anything.
Dave's code defines a fair and flexible idea and should be usable with PASM too.
I was going to suggest something similar with the addition of flags in service type.
I don't mind additional functionality - but here is the minimum functionality Largos expects:
- sd_open (basically initialize card)
- sd_read (read one sector)
- sd_write (write one sector)
- sd_ioctl (read/write SD specific info - card size, error count, error code etc)
- sd_close (basically unmount)
All SD access should release the SPI bus fully (it is OK if there is an IOCTL to keep SPI bus open for faster applications) so the bus is available between sd_* calls
The source code of the SD cog should have two subroutines called SELECT and RELEASE.
SELECT asserts /CS
RELEASE de-asserts /CS, and provides the necessary number of clocks to finish de-asserting /CS
The reason for this is that with these explicit routines being the only routines for selecting/de-selecting the SD it will be VERY easy to port the SD cog to different types of SPI multiplexers. Why is this important to me?
- PropCade uses a simpler multiplexing scheme that is reasonably compatible with existing drivers
- Morpheus+ uses a multiplexing scheme to add uSD, SPI memory and support the I/O on Mem* ... and it is not as simple as the PropCade scheme
- other boards use multiple /CS signals from the prop to support SPI peripherals
The generic mailbox format I use for my drivers is four consecutive longs:
command needs to be non-zero for the driver cog to do something, and when the driver cog is done, it clears command
Mind you, I myself depart from the generic usage (VMCOG for example) when necessary, but the key concept that NEVER varies is how mbox[noparse][[/noparse]0] != 0 means there is a command to process, and mbox[noparse][[/noparse]0] == 0 means the driver is ready to receive a command.
Later, after much more experimentation, I may standardize my mailbox more.
Generally, my drivers support the following minimum command set:
_open
_read
_write
_ioctl
_close
The above may seem familiar to some [noparse]:)[/noparse]
Cluso99 said...
Bill, most of the cog will be FS agnostic, just providing sector read & write functions just as fsrw (well it is the sdspifemto equivalent... mb_rawb_spi). If there is space, we can add some Fat16/32 stuff - maybe directory. I doubt we can fit much more. mpark used 3 cogs for the full FAT16 code.
This is why the mailbox can't be simply one long (unless current Propeller is the only target).
With a pointer however, you have a reference to a data-structure which can be anything.
Dave's code defines a fair and flexible idea and should be usable with PASM too.
I was going to suggest something similar with the addition of flags in service type.
a service type command field and flags
pointer to struct used with service type
Another thing that may be useful is a lock to make it cog-safe.
Dave Hein said...
Another thing that may be useful is a lock to make it cog-safe.
Yes, that is similar to the linux model for multiprocessing where spinlocks (yes
that's what they are really called) are used to ensure exclusive access.
Of course that would mean having a lockid semaphore in a data structure
passed by reference in the mailbox which means mailbox must a pointer
for such shared access.
I proposed a compromise on stdin/stdout and other device mailbox definitions.
Basically, there are 2 types of interfaces: character and stream (reference).
It would be nice if any of the mailboxes used by the system could be of either type.
I propose the MSB (bit 2**31) of the mailbox be used to disambiguate the type.
If the MSB is clear, then the mailbox is character based meaning, the long is the
mailbox and not a pointer; this allows one to spin on the mailbox bits if required.
If MSB is set, then the other 31 bits provide a reference pointer to the interface
data structure; this allows for a complex interface which can include locks.
So, that provides a solution for flexibility that is better than previously considered
regarding all mailboxes rather than certain mailboxes being some fixed type.
Can't be bit 31 of the command long, makes the spinner longer.
I had a different way...
mbox(1) is normally the source pointer
If it was a value between 0 and 255, it was a character
ie
mbox(1) := "H"
mbox[noparse][[/noparse]0] := _putch
and
mbox(1) := @a_string
mbox[noparse][[/noparse]0] := _puts
and
mbox(1) := @a_ptr
mbox(3) := len
mbox[noparse][[/noparse]0] := _write
and
mbox[noparse][[/noparse]0] := _getch
(if mbox(3) == 0, no timeout, otherwise mbox(3) = timeout_ms)
returns mbox(1), if 0..255 = valid character, if -1 = timeout or error
Comments
Dave
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
With a pointer however, you have a reference to a data-structure which can be anything.
Dave's code defines a fair and flexible idea and should be usable with PASM too.
I was going to suggest something similar with the addition of flags in service type.
Cheers.
--Steve
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
- sd_open (basically initialize card)
- sd_read (read one sector)
- sd_write (write one sector)
- sd_ioctl (read/write SD specific info - card size, error count, error code etc)
- sd_close (basically unmount)
All SD access should release the SPI bus fully (it is OK if there is an IOCTL to keep SPI bus open for faster applications) so the bus is available between sd_* calls
The source code of the SD cog should have two subroutines called SELECT and RELEASE.
SELECT asserts /CS
RELEASE de-asserts /CS, and provides the necessary number of clocks to finish de-asserting /CS
The reason for this is that with these explicit routines being the only routines for selecting/de-selecting the SD it will be VERY easy to port the SD cog to different types of SPI multiplexers. Why is this important to me?
- PropCade uses a simpler multiplexing scheme that is reasonably compatible with existing drivers
- Morpheus+ uses a multiplexing scheme to add uSD, SPI memory and support the I/O on Mem* ... and it is not as simple as the PropCade scheme
- other boards use multiple /CS signals from the prop to support SPI peripherals
The generic mailbox format I use for my drivers is four consecutive longs:
mbox[noparse][[/noparse]0] = command
mbox = source pointer
mbox = destination pointer
mbox = count
command needs to be non-zero for the driver cog to do something, and when the driver cog is done, it clears command
Mind you, I myself depart from the generic usage (VMCOG for example) when necessary, but the key concept that NEVER varies is how mbox[noparse][[/noparse]0] != 0 means there is a command to process, and mbox[noparse][[/noparse]0] == 0 means the driver is ready to receive a command.
Later, after much more experimentation, I may standardize my mailbox more.
Generally, my drivers support the following minimum command set:
_open
_read
_write
_ioctl
_close
The above may seem familiar to some [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
that's what they are really called) are used to ensure exclusive access.
Of course that would mean having a lockid semaphore in a data structure
passed by reference in the mailbox which means mailbox must a pointer
for such shared access.
I proposed a compromise on stdin/stdout and other device mailbox definitions.
Basically, there are 2 types of interfaces: character and stream (reference).
It would be nice if any of the mailboxes used by the system could be of either type.
I propose the MSB (bit 2**31) of the mailbox be used to disambiguate the type.
If the MSB is clear, then the mailbox is character based meaning, the long is the
mailbox and not a pointer; this allows one to spin on the mailbox bits if required.
If MSB is set, then the other 31 bits provide a reference pointer to the interface
data structure; this allows for a complex interface which can include locks.
So, that provides a solution for flexibility that is better than previously considered
regarding all mailboxes rather than certain mailboxes being some fixed type.
I hope this is acceptable.
Cheers,
--Steve
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
Can't be bit 31 of the command long, makes the spinner longer.
I had a different way...
The above is the Largos way [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system