I'm trying to read data on a serial communication "COM1", using ADA based on RS 422,
as the following.
S_Port : Serial_Port;
Buffer : Ada.Streams.Stream_Element_Array(1..150);
GNAT.Serial_Communications.Open(Port => S_Port,Name => "COM1");
GNAT.Serial_Communications.Set(
Port => S_Port, Parity => Even, Block => False,
TimeOut => 4.0
);
GNAT.Serial_Communications.Read(S_Port,Buffer,Last);
The problem is that although the value of 'Last' changes from 9 to 27, the buffer has
much more than 9 or 27 bytes. I thought I can use 'Last' to mark the end of a message,
but that is not the case?
Also I can't seem to have an unbounded buffer to use the READ function, and must
define a certain size?
Thanks in advance.
I've not worked with this, but the fact that Last is changing values suggests that data is in fact being read in.
Assuming that's happening, since you're reading into a fixed size buffer, there's going to be junk in it unless you initialize the whole thing first. The elements in indices 1..Last will be overwritten, and the rest will be left as the original garbage values.
So the data that was read in is available in Buffer(1 .. Last).
Related
I am trying to map a region of fpga memory to host system,
resource0 = os.open("/sys/bus/pci/devices/0000:0b:00.0/resource0", os.O_RDWR | os.O_SYNC)
resource_size = os.fstat(resource0).st_size
mem = mmap.mmap(resource0, 65536, flags=mmap.MAP_SHARED, prot=mmap.PROT_WRITE|mmap.PROT_READ, offset= 0 )
If i flush my host page with
mem.flush()
then print the contents
the data is same as before,
nothing is getting cleared from page
print(mem[0:131072])
mem.flush()
print(mem[0:131072])
as i read on python mmap docs , it says it clears then content,
https://docs.python.org/3.6/library/mmap.html
but when i test it remains same
i am using python 3.6.9
Why do you expect flush to clear a page?
https://docs.python.org/2/library/mmap.html
flush([offset, size])
Flushes changes made to the in-memory copy of a file back to disk. Without use of this call there is no guarantee that changes are written back before the object is destroyed. If offset and size are specified, only changes to the given range of bytes will be flushed to disk; otherwise, the whole extent of the mapping is flushed. offset must be a multiple of the PAGESIZE or ALLOCATIONGRANULARITY.
So if you want to clear anything you have to assign a new value first and then write it to the memory i.e. flush it.
Assume that a CPU pointer(cpu_ptr_) already exists, then I create a buffer for gpu(cl_gpu_mem_). The problem is that when I map the gpu buffer to a cpu pointer(mapped_ptr), the mapped_ptr is not equal to the original pointer (cpu_ptr_), which causes that CHECK_EQ(mapped_ptr, cpu_ptr_) raises an error.
cl_gpu_mem_ = clCreateBuffer(ctx.handle().get(),
CL_MEM_READ_WRITE | CL_MEM_USE_HOST_PTR,
size_, cpu_ptr_, &err);
void *mapped_ptr = clEnqueueMapBuffer(
ctx.get_queue().handle().get(),
cl_gpu_mem_,
true,
CL_MAP_READ | CL_MAP_WRITE,
0, size_, 0, NULL, NULL, NULL);
CHECK_EQ(mapped_ptr, cpu_ptr_)
<< "Device claims it supports zero copy"
<< " but failed to create correct user ptr buffer";
I don't know why this error occurs at all. Would you please give me any advice for this problem, or any solution to it. Thank you very much.
OpenCL implementations are free to mirror the host pointer (making it non-zero copy). On devices that support true zero copy (e.g. Intel GPU), there are still typically constraints that impose whether we can really use that host allocation directory or must mirror it. On Intel the host address must be page aligned and a the length must be a multiple of 128 bytes (an even cacheline). (I typically just page align both.) I am not sure what AMD and other's requirements are.
Look into aligned_alloc or overallocate a couple extra pages via and use a page boundary for the base.
I'm following the sparkfun tutorial for connecting an arduino to electric imp. I only have one arduino and imp, so I'm trying to get whatever I type in the arduino serial monitor to display in the imp node using server.show().
I've modified one of the functions in the sparkfun code to look like this:
function pollUart()
{
imp.wakeup(0.00001, pollUart.bindenv(this)); // schedule the next poll in 10us
local byte = hardware.uart57.read(); // read the UART buffer
// This will return -1 if there is no data to be read.
while (byte != -1) // otherwise, we keep reading until there is no data to be read.
{
// server.log(format("%c", byte)); // send the character out to the server log. Optional, great for debugging
// impeeOutput.set(byte); // send the valid character out the impee's outputPort
server.show(byte)
byte = hardware.uart57.read(); // read from the UART buffer again (not sure if it's a valid character yet)
toggleTxLED(); // Toggle the TX LED
}
}
server.show(byte) is only displaying seemingly random numbers. I have an idea of why this is, I just don't know how to fix it because I'm not that familiar with UARTs and squirrel.
local byte = hardware.uart57.read(); reads in the ascii characters from the arduino in byte form (I think), and they're not being 'translated' into their ascii characters before I use server.show(byte).
How do I do this in squirrel?
Also, I think polling every 10us is the wrong way to go here. I'd like to only poll when there's new information, but I also don't know how to do that in squirrel. Can someone point me to an example where this happens?
Thanks!
I think you are passing the wrong data type to the show method of the server object. The electric imp docs state that it takes a string, server.show(string). I think that local is the correct type to receive the value from hardware.uart57.read(). You can tell from the docs as well. So, you need to find a way to cast your byte to a string. I bet you could find the answer here. From what I read Squirrel use's Unicode so there is a probably a function that takes Unicode bytes and loads them into a string object.
I am working on an opencl project and I have run into an issue where if I try and send data to from the cpu to global memory then sometimes it locks up the application. This happens sporadically. I can run it x times in a row and the next time it locks. It only appears to be happening if I try and send data that is not 32 bits wide. For example, I can send float and int just fine, but when I try short, char, or half then I get random lockups. It is not dying with badly initialized data or something, because it does run, just not all the time. I also put some logging in and found that it is always locking up just after attempting to write one of these non-standard size data arrays. I am running on an NVIDIA GeForce GT 330M. Below is a snippet of the code I am running to send the data. I am using the c++ interface on the host side.
cl_half *m_aryTest;
shared_ptr< cl::Buffer > m_bufTest;
m_aryTest = new cl_half[m_iNeuronCount];
m_bufTest = shared_ptr<cl::Buffer>( new cl::Buffer(m_lpNervousSystem->ActiveContext(), CL_MEM_READ_ONLY | CL_MEM_USE_HOST_PTR, sizeof(m_aryTest)*m_iNeuronCount, m_aryTest));
kernel.setArg(8, *(m_bufTest.get()));
printf("m_bufTest.\n");
m_lpQueue->enqueueWriteBuffer(*(m_bufTest.get()), CL_TRUE, 0, sizeof(m_aryTest)*m_iNeuronCount, m_aryTest, NULL, NULL);
Does anyone have any ideas on why this is happening?
Thanks
Is there are a standard accepted way to byte-swap UUIDs for transmission over a network (or file storage)? (I want to send/store the 16 raw bytes rather than convert the UUID to a string representation.)
I thought at first I should partition the UUID into 4 32-bit integers and call htonl on each of them, but that didn't smell right. A UUID has internal structure (from RFC 4122):
typedef struct {
unsigned32 time_low;
unsigned16 time_mid;
unsigned16 time_hi_and_version;
unsigned8 clock_seq_hi_and_reserved;
unsigned8 clock_seq_low;
byte node[6];
} uuid_t;
Would it be correct to do:
...
uuid.time_low = htonl( uuid.time_low );
uuid.time_mid = htons( uuid.time_mid );
uuid.time_hi_and_version = htons( uuid.time_high_and_version );
/* other fields are represented as bytes and shouldn't be swapped */
....
before writing, and then the correpsonding ntoh...calls after reading at the other end?
Thanks.
Yes, that is the correct thing to do.
Each number (time_low, time_mid, time_hi_and_version) are subject to byte ordering. the node field is not. clock_seq_hi_and_reserved and clock_seq_low are also subject to byte ordering, but they are each one byte, so it doesn't matter.
Of course, it is up to you to make sure that you choose the right ordering on both ends, or understand what the ordering is on the other end if you don't control it. Microsoft of course uses little endian for their UUIDs. You can see Microsoft's definition of a UUID here.