Ethernet for DSP
09 Jun 2023 - 20:34
December 06, 2006 (E. Tanke): Testing of data transfer rates for BSM to linux and VMS
- Data transfer for 32 channels by 523000 words of 32 bit
- VMS: with 4kB transfer size (i.e. "packet size" of 1k words of 32 bits), transfer time was ~ 27 minutes
- with 4kB transfer size, transfer time was ~ 27 minutes
- with 32kB transfer size, transfer time was ~ 3 minutes 30 sec
- with 64kB transfer size, transfer time was ~ 2 minutes 8 sec
- The current status is that with transfer sizes > 4 kB, transfers from/to VMS are not yet reliable
December 20, 2006 (C.Strohman): Program that does simple transactions with ColdFire equipped CBI devices.
- The goal is to have the ability to do, on the Linux systems, the stuff we do with 'fff vxgetn/vxputn' or .COM files on the VMS systems. To try it out, you need to define a client command and use a ColdFire server with the correct code.
- First create a client command: alias cbi_cmd ~crs/RTEMS_coldfire/cbi_net/cbi_cmd/linux/users/cbi_cmd
- Second, either use a ColdFire that has been programmed (klybpm11, klybpm08, cbi-cf06) or program one with the file: ~crs/RTEMS_coldfire/cbi_net/server/rtems/o-optimize/cbi_net_server.exe
- First, enter the command 'cbi_cmd --help' to have a look at the 'help': cbi_cmd --help
Usage: cbi_cmd [OPTION...]
cbi_cmd -- A program to send commands to a Cornell CBI device
-a, --address=ADDRESS Address for 'read' or 'write' operation
-d, --data=DATA Data for 'write' operations
-f, --flash Perform a FLASH programming operation
-i, --infile=INFILE Input filename for programming DSP FLASH
-n, --node=NODE !ColdFire node name
-o, --outfile=OUTFILE Output filename for results from 'read'
-r, --read Perform a 'read' operation
-v, --verbose Produce verbose output
-w, --write Perform a 'write' operation
-?, --help Give this help list
--usage Give a short usage message
-V, --version Print program version
- Mandatory or optional arguments to long options are also mandatory or optional for any corresponding short options.
- The program processes the supplied options and arguments in sequence. For example, to program the FLASH on node 'klybpm11' with the contents of the file 'timing_test.ldr', one could issue the command:
- cbi_cmd -n klybpm11 -i timing_test.ldr -f
- The -f, -r, and -w options perform operations using parameters set by the -a, -d, -i, and -n options.
- Suppose you want to disable the DSP, reprogram the FLASH, and re-enable the DSP. We know that there is a bug that requires the DSP to be enabled, then disabled, and then enabled again the first time after power has been applied. And we don't know whether power has just been applied.
- cbi_cmd -n klybpm11 -a 0x10040001 -d 0 -w -i timing_test.ldr -f -d 1 -w -d 0 -w -d 1 -w will:
- 1. write 0 to 0x10040001
- 2. program the flash with the contents of 'timing_test.ldr'
- 3. write 1 to 0x10040001
- 4. write 0 to 0x10040001
- 5. write 1 to 0x10040001
- Both -a and -d accept either decimal or hexadecimal. Hex needs to be preceded by '0x' as shown in the example.
- A script can be used to hold common sequences. Lines can be continued for clarity. This is the contents of a script that examines the first 2 locations in the SRAM:
cbi_cmd -n klybpm11 \
-a 0x0c080000 -r \
-a 0x0c080001 -r
- Try it out and let me know what doesn't work and what features you might want added. The -o and -v options don't do anything yet. I plan to add some of the following features:
- 1. Support reading and writing more than 1 word at a time
- 2. Add options for:
- 'columns' (number of columns for data display [read op only])
- 'incadr' (increment the address for each operation)
- 'incdat' (increment the data for each operation [write op only])
- 'wordsize' (16-bit vs. 32 bit)
- 'repeat' (how many words to read or write)
- 'pause' (sleep for some interval)
- 'format' (decimal or hex or binary)
- 3. Add symbolic addresses for common registers and memory locations. The translation information will be read from a file. For instance, translate '-a DSP_RESET' to '-a 0x10040001'.
- 4. Implement the 'reset_card' operation
- 5. Implement 'initialize_card' operation
- 6. Do something nice with 'verbose'
- Report bugs to firstname.lastname@example.org
January 09, 2007 (C.Strohman): CBI_NET packet read
- I have implemented packet read operations for CBI_NET on the ColdFire. The packet write operations does not yet work.
- I updated the CVS repository for both client and server code. I'll leave it to Tim to build an 'official' server executable that has the appropriate version number, and to download to any of the ColdFire boards. I moved my 'cbi_cmd' program. It is now: ~crs/cbi_net/VMS_devel/cbi_net/progs/cbi_cmd/cbi_cmd Be sure to redefine any aliases that you use to run this program.
- An example of reading with packet operations follows. It uses packet tag #5:
- 1. First, initialize the PACKET START ADDRESS TABLE. I'm using packet tag #5. The data structure associated with tag #5 is located at the beginning of the SRAM. So the address in the address table is '0x10001005' and the data to be written is first address of the SRAM or '0x0c080000'. In normal operation, the DSP will usually initialize the tables with the addresses and sizes of its data structures.
- cbi_cmd -n klybpm11 -a 0x10001005 -d 0x0c080000 -w
- 2. Next, initialize the PACKET SIZE TABLE location associated with packet tag #5. I'll pick an arbitrary size of 12 words. So the address in the size table is '0x10010005' and the data to be written is 12. The maximum size is 4095 (not 4096!).
- cbi_cmd -n klybpm11 -a 0x10010005 -d 12 -w -r
- 3. Now I can read the data using the packet options that 'cbi_cmd' supports. I specify the tag number with the '--pt=5' option and the read function with the '--pr' option. After the first packet is read, I set the 'more' bit with the '--pm' option, the do two more packet reads.
- cbi_cmd -n klybpm11 --pt=5 --pr --pm --pr --pr
- The result looks like:
- @0X0C080000: 0X2FB90A5F 0X774D76DB 0X1AD59C9C 0XB7D72F55 0XDB2FB5DB 0XD77945D7 0X7B467FBB 0X9F8896F6
- @0X0C080008: 0XE28AD61B 0X57AD383A 0XE4BBB775 0X491BAFAF
- @0X0C08000C: 0XB94305EF 0X2E395F67 0X8C905BF6 0X2A2A7ED4 0X8996F4FA 0X5BB2E9BF 0X7E5FEEEF 0X6CDEE6CA
- @0X0C080014: 0XB9FBD5DA 0XE1A22A99 0X7BE69AB2 0XACA7EF73
- @0X0C080018: 0XDEE4ED57 0XDDA8FEFE 0X7ABE5AC9 0XDD43AEBD 0X5DDAFF3C 0X33D94B80 0X2F8931A9 0X35A5D45B
- @0X0C080020: 0X5350AB2F 0XB2948F38 0X2925F3DB 0X97EAC94D
- The cbi_cmd tool is now also in CVS.
- It requires a library, either static or shared which contains the CBI_NET core code. To build the libraries one has to check out the VMS_devel/cbi_net/client/linux tree and issue a
gmake -f Makefile.local lib which will create both a shared and a static library.
- The cbi_net command gets build after having checked out the VMS_devel/cbi_net/tools/cbi_net tree by issuing a
gmake -f Makefile.local.
- There's also a README file in that directory which pretty much covers the same information as on this page. Currently a static executable is being build only for the Linux platform. Shared libs are support but requires the LD_LIBRARY_PATH set to where the shared lib is located.
- Also only the core can be build currently by using the standard CESR Makefile scheme using the Makefile.CESR instead of Makefile.local. This still needs to be adjusted once correct locations for the CBI_NET code etc have been determined.
October 8, 2007 (Matt Rendina): CBI_NET code moved from CVS to Subversion
- I have moved the cbi_net tree from CVS (/VMS_devel/cbi_net) to SVN (/trunk/cbi_net). All the changes that were made to the CVS version of cbi_net since the major repository migration are now in the official SVN version. Please use that version from now on. If you have any questions, please let me (Matt) know.