Multiples modules reading same fifo - module

Is it possible to instantiate multiple modules to read from the same fifo assuming they are not reading at the same time, but take turns??
For example:
int _tmain(int argc, _TCHAR* argv[])
{
sc_fifo<int> PacketTx(24);
sc_fifo<int> PacketRx(20);
Transmit t1("Transmit");
t1.PacketRx(PacketRx);
t1.PacketTx(PacketTx);
Receive r1("Receive1");
r1.PacketTx(PacketRx);
r1.PacketRx(PacketTx);
Receive r2("Receive2");
r2.PacketTx(PacketRx);
r2.PacketRx(PacketTx);
sc_start();
return 0;
}

It is possible but you need to add synchronization signals to the module's.
For sample implementation closer to your requirement is available under SystemC source code from Accellera SystemC download page.
Download the "Core SystemC Language and Examples" zip file:
Unzip the file.
Navigate into the directory and look for "examples" directory.
Following example are much closer to your requirement:
examples/sysc/pkt_switch/
Note: This example does not use sc_fifo's but utilizes the sc_in/out port's.
examples/sysc/simple_bus/
Note: This example showcase the use-case to model CPU bus model. This example also currently does not utilize the sc_fifo.
But you can get much better ideas for your implementation details.

Related

Writing and Loading Code from QSPI Flash Memory from RP2040

I bought an RP2040 board with 16MB QSPI Flash Memory in the board:
The Flash Memory w25q128 is connected to QSPI dedicated pins of the RP2040:
I was finding out how to access this data from the RP2040 datasheet:
But I didn't find out how to:
Initialize XIP memory in rp2040 boot;
To flash/access data into the w25q128; and
Run instructions from the External Flash Memory.
I was looking for sample codes at GitHub but I didn't find anything useful for these two items I want.
I also found the 2.6.3.1 section of the RP2040 datasheet but I don't know if XIP cache is what I am looking for...
Does someone have done anything related to that? I am a newbie in this subject, so I would like to sorry if I did something wrong.
Thanks in advance!
In the datasheet there is an hint that this configuration is done by the SDK automatically if certain conditions are met:
Following the github link we get to the assembly source for the second stage bootloader. This answers the question on how to initialize the memory. It's not done by you (unless you are not using the SDK).
Here are the configuration steps:
SSI stands for Synchronous Serial Interface and it's what has to be configured to use the flash as XIP. It's described in the datasheet:

Gnuradio software source block

I'm currently trying to do some real-time signal-processing and I would like to use "gnuradio". I will be processing multiple channels of EEG which come in trough a custom interface (namely "Lab Streaming Layer"; LSL) in python.
Now my question is if there is an existing block already where you can kind of "push" samples into the signal-processing-graph during run-time? The only blocks I've found so far offer support for audio hardware, TCP-streams and files.
You will have to write your own block; that can be done in Python or C++, whatever is better for your case.
The GNU Radio Guided Tutorials (you should really read them in order from 1 to 5, at least) do explain how to do that.
Because we all know that people are lazy at reading, here's a rough preview of what you'll learn:
make a new Out-of-tree module: gr_modtool newmod sensorinterface, change into the newly generated directory: cd gr-sensorinterface
add a new source block: gr_modtool add eeg_sensor_source; the block type you'll want is "source"; you will be asked to fill in some block details.
edit the generated source file (in lib/ or python/, depending on which language you chose:
add a proper io signature: your output will probably have the size of float
edit the central work function; add code to get new samples, and copy those to the output_items buffer.
The guided tutorials are really nice!
The most flexible method is to write your own GNU Radio block, but there are several options for getting data into a flow graph without using any custom blocks. (Naming from the Python perspective.)
gnuradio.blocks.message_source, which takes data from a gnuradio.gr.msg_queue.
You can use a gnuradio.blocks.file_descriptor_source where the file descriptor is one end of a pipe.

Asking sample code for ISO 8583 verifone vx520

I want to know the sample code for sending message to server and get back response to verifone vx520 terminal using ISO 8583.
As noted in a comment on your question, this is not a code sharing site, so such an open-ended question is a bit difficult to answer, but perhaps I can get you started on the right foot.
First of all, let me start by suggesting that if you have control over the terminal code and the server that it will be talking to, I suggest you NOT use ISO8583. Yes, it's an industry standard and yes, it communicates data efficiently, BUT it is much more difficult to use than, say, VISA-1 or XML, or JSON etc. That means you have more opportunities for bugs to creep into your code. It also means that if something goes wrong, it takes a lot more effort to try and figure out what happened and try and fix it. I have used all these protocols and others besides and I'll tell you that ISO8583 is one of my least favorite to work with.
Assuming you do not have a choice and you must use ISO8583 then it's worth noting that ISO8583 is nothing but a specification on how to assemble data packets in order to communicate. There is nothing special about the Vx520 terminal (or any other VeriFone terminal) that would change how you would implement it verses how you might do so on any other C++ platform EXCEPT that VeriFone DOES provide you with a library for working with this spec that you are free to use or ignore as you see fit.
You don't need to use this library at all. You can roll your own and be just fine. You can find more information on the specification itself at Wikipedia, Code Project, and several other places (just ask your favorite search engine). Note that when I did my 8583 project, this library was not available to me. Perhaps I wouldn't have hated this protocol so much if I had had access to it... who knows?
If you are still reading this, then I'll assume that ISO8583 is a requirement (or you are a glutton for punishment) and that you are interested in trying out this engine that VeriFone has provided.
The first thing you will need to do (and hopefully, you have already done it) is to install ACT as part of the development suite (I also suggest you head over to DevNet and get the latest version of ACT before you get started...). Once installed, the library header can be found at %evoact%\include\iso8583.h. Documentation on how to use it can be found at %evoact%\docs. In particular, see chapter 6 of DOC00310_Verix_eVo_ACT_Programmers_Guide.pdf.
Obviously, trying to include a whole chapter's worth of information here would be out of scope, but to give you a high-level idea of how the engine works, allow me to share a couple excerpts:
This engine is designed to be table driven. A single routine is used
for the assembly and disassembly of ISO 8583 packets. The assembly and
disassembly of ISO 8583 packets is driven by the following structures:
Maps One or more collections of 64 bits that drive packet assembly and
indicate what is in a message.
Field table Defines all the fields used
by the application.
Convert table Defines data-conversion routines.
Variant tables Optional tables used to define variant fields.
The process_8583() routine is used for the assembly and disassembly of ISO
8583 packets.
An example of using process_8583() is given elsewhere as follows:
#include "appl8583.h"
int packet_sz;
void assemble_packet ()
{
packet_sz = process_8583 (0, field_table, test_map, buffer, sizeof( buffer));
printf ("\ fOUTPUT SIZE %d", packet_sz);
}
void disassemble_packet ()
{
packet_sz = process_8583 (1, field_table, test_map, buffer, packet_sz);
printf ("\ fINPUT NOT PROCESSED %d", packet_sz);
}
To incorporate this engine into an application, modify the APPL8583.C
and APPL8583.H files so that each has all the application variables
required in the bit map and set up the map properly. Compile
APPL8583.C and link it with your application and the ISO 8583 library.
Use the following procedures to transmit or receive an ISO 8583 packet
using the ISO 8583 Interface Engine:
To transmit an ISO 8583 packet
1 Set data values in the application variables for those to transmit.
2 Call the prot8583_main() routine. This constructs the complete
message and returns the number of bytes in the constructed message.
3 Call write() to transmit the message.
To receive a message
1 Call read() to receive the message.
2 Call the process_8583() routine. This results in all fields being
deposited into the application variables.
3 Use the values in the application variables.

Using Linux ioctl with Mono

I'm trying to do ioctl command through Mono framework, but I cant find what I'm looking for.
I'm trying to send command to a DVB card that has a kernel module. I hope someone can link or explain clearly how this can be done. Any example with Mono using kernel modules would be useful I guess.
Mono does not contain a wrapper for ioctl in Mono.Unix, because ioctl call parameters vary greatly and such a wrapper would be almost useless. You should declare a DllImport for each ioctl you need.
You probably don't need a helper library written in C, however, you may need it during development to extract actual values hidden behind different C preprocessor macros. For example, to expand C header:
#define FE_GET_INFO _IOR('o', 61, struct dvb_frontend_info)
compile and execute this helper:
#include <linux/dvb/frontend.h>
#include <stdio.h>
int main()
{
printf("const int FE_GET_INFO = %d;\n", FE_GET_INFO);
return 0;
}
A short mono mailing list discussion on the topic.
ioctl isn't supported by Mono AFAIK. Too OS-specific and parameter list depends on actual request. You could try DLLImport
Interop with Native Libraries
You should write a wrapper library for your exact calls. Look at how Mono.Unix wraps syscalls (google codesearch for Mono.Unix Syscall.cs) to get the idea. Then create a wrapper for each specific ioctl command, which uses your own representation of the data.
As jitter said - you'll need to DLLImport the ioctl itself.
Check for my similar question, and later question on the subject. In this case I'm trying to wrap the Videl4Linux interface, that could be of interest for you.
I really suggest those readings.

File I/O in a Linux kernel module

I'm writing a Linux kernel module that needs to open and read files. What's the best way to accomplish that?
Can I ask why are you trying to open a file?
I like to follow Linux development (out of curiosity, I'm not a kernel developer, I do Java), and I've seen discussion of this question before. I was able to find a LKML message about this, basically mentioning it's usually a bad idea. I'm almost positive that LWN covered it in the last year, but I'm having trouble finding the article.
If this is a private module (like for some custom hardware and the module won't be distributed) then you can do this, but I'm under the impression that if you are going to submit your code to the mainline then it may not be accepted.
Evan Teran mentioned sysfs, which seems like a good idea to me. If you really need to do harder custom stuff you could always make new ioctrls.
EDIT:
OK, I found the article I was looking for, it's from Linux Journal. It explains why doing this kind of stuff is generally a bad idea, then goes on to tell you exactly how to do it anyway.
assuming you can get pointers to the relavent function pointers to the open/read/close system calls, you can do something like this:
mm_segment_t fs = get_fs();
set_fs(KERNEL_DS);
fd = (*syscall_open)(file, flags, mode);
if(fd != -1) {
(*syscall_read)(fd, buf, size);
(*syscall_close)(fd);
}
set_fs(fs);
you will need to create the "syscall_*" function pointers I have shown though. I am sure there is a better way, but I believe that this would work.
Generally speaking, if you need to read/write files from a kernel module, you're doing something wrong architecturally.
There exist mechanisms (netlink for example - or just register a character device) to allow a kernel module to talk to a userspace helper process. That userspace helper process can do whatever it wants.
You could also implement a system call (or such like) to take a file descriptor opened in userspace and read/write it from the kernel.
This would probably be neater than trying to open files in kernel space.
There are some other things which already open files from kernel space, you could look at them (the loop driver springs to mind?).
/proc filesystem is also good for private use, and it's easy.
http://www.linuxtopia.org/online_books/Linux_Kernel_Module_Programming_Guide/x773.html
All of the kernel developers say that file I/O from kernel space is bad (especially if you're referring to these files by their paths) but the mainstream kernel does this when you load firmware. If you just need to read from files, use the
kernel_read_file_from_path(const char *path, void **buf, loff_t *size, loff_t max_size, enum kernel_read_file_id id)
function, which is what the firmware loader code uses, declared in include/linux/fs.h. This function returns a negative value on error.
I'm not really sure of the point of the id variable at the end, if you look at the code it's not really used, so just put something like READING_FIRMWARE there (no quotes).
buf is not null terminated, instead refer to its size in size. If you need it to be null terminated, create a string size + 1 bytes long and copy it over or rewrite the kernel_read_file() function (used by kernel_read_file_from_path(), defined in fs/exec.c) and add one to i_size where memory is allocated. (If you want to do this, you can redefine the kernel_read_file() function in your module with a different function name to avoid modifying the whole kernel.)
If you need to write to files, there is a kernel_write() function (analogous to kernel_read(), which is used by kernel_read_file() and therefore also by kernel_read_file_from_path()), but there is no kernel_write_file() or kernel_write_file_from_path() function. You can look at the code in the fs/exec.c file in the Linux kernel source tree where kernel_read_file() and kernel_read_file_from_path() are defined to write your own kernel_write_file() and kernel_write_file_from_path() functions that you can include in your module.
And as always, you can store a file's contents in a char pointer instead of a void pointer with this function by casting it.
You can also find some informations about sys_call_open in this Linux Kernel Module Programing Guide.