I am using tinyOs (nesC) for communication between telosB motes. I am unable to send a 1D array of more that 20 bytes size to the receiver even if I initialize it using uint32_t. Can anyone help?
There's TOSH_DATA_LENGTH constant that defines the maximum size of a single message. Try redefining it, according to the instructions that can be found here.
Related
I am attempting to address 16 bytes on an SRAM chip using 74595 to load memory and then read it later. My issue is the addressing to the memory is 4 bits that I want to control from the Arduino. I would prefer a method to write the decimal value out as binary to the 4 lines at once, but not sure of the best or most efficient method.
I'm currently working on STM32H747XI (Portenta H7). I'am programming the ADC1 with the DMA1 to get 16bits data at 1Msps.
I'm sorry, I can't share my entire code but I will therefore try to describe my configuration as precisely as possible.
I'm using the ADC1 trigged by a 1MHz timer. The ADC is working in continus mode with the DMA circular and double buffer mode. I tryed direct mode and burst with a full FIFO. I have no DMA error interrupe and no ADC overrun.
My peripheral are running but I'm stuck front of two issues. First issue, I'am doing buffer of 8192 uint16_t and I send it on the USB CDC with the arduino function USBserial.Write(buf,len). In this case, USB transfer going right but I have some missing data in my buffer. The DMA increments memory but doesn't write. So I don't have missing sample but the value is false (it belongs to the old buffer).
You can see the data plot below :
transfer with buffer of 8192 samples
If I double the buffer size, this issue is fixed but another comes. The USB VPC transfer fail if the data buffer is longer than 16384 byte. Some data are cut. I tried to solve this with differents sending and delays but it doesn't work. I still have the same kind of cut.
Here the data plot of the same script with a longer buffer : transfer withe buffer of 16384 sample (32768 byte)
Thank you for your help. I remain available.
For a fast check try to disable data cache. You're probably not managing cache correctly or you haven't disable caching in the memory space where you're using DMA.
Peripherals are not aware of cache so you must manage it manually. You have also to align buffers to cache lines in this case.
Refer to AN4839
I am trying to send a mavlink command for instance
GPS_RTCM_DATA ( #233 )
flags uint8_t
len uint8_t
data uint8_t[180] RTCM message (may be fragmented)
https://mavlink.io/en/messages/common.html#GPS_RTCM_DATA
I understand uint8_ would be in a single byte unsigned int.
What does the [180] means?
The uint8_t[180] in the MAVLink GPS_RTCM_DATA message means that the data field can contain up to 180 bytes.
Beware that RTCM messages can be bigger than 180 bytes and be fragmented in
more than one GPS_RTCM_DATA message.
You can check the flags field as stated in the mavlink documentation:
LSB: 1 means message is fragmented, next 2 bits are the fragment ID,
the remaining 5 bits are used for the sequence ID. Messages are only
to be flushed to the GPS when the entire message has been
reconstructed on the autopilot. The fragment ID specifies which order
the fragments should be assembled into a buffer, while the sequence ID
is used to detect a mismatch between different buffers. The buffer is
considered fully reconstructed when either all 4 fragments are
present, or all the fragments before the first fragment with a non
full payload is received. This management is used to ensure that
normal GPS operation doesn't corrupt RTCM data, and to recover from a
unreliable transport delivery order.
I tried every but it doesn't work. Except putting it as a 180 byte arrays. The data might be only 30 bytes for example. But input with the other 150 0x00 bytes in this way, the python program accepts my command. Strangely so. I can't explain why but in this case it works.
I am using PIN to instrument my application binary and generating a list of addresses (more specifically memory reads) made by the application. I have an instrumentation routine, which passes the IARG_MEMORYREAD_SIZE, IARG_MEMORYREAD_EA as arguments. However,I want to infer the type information of the application variable based on memory size being read.
For example,
If PIN observes a memory read of 4 bytes, how can I conclude what type of data is being accessed. Is it int/float ? Similarly, for 8 byte data, how would I know if the data is a double variable or a pointer type variable.
There is no way you can infer the type of the operand just by its size. I even doubt you can do it in a reliable manner with the instruction.
i tried this example:
http://arduino.cc/en/Reference/WireRead
But if i send less than 6 bytes from the slave the master still tries to read all 6 bytes and then the read function outputs -1/255. So actually the available function is kinda useless in this case, i could rather use a for till 6.
Any idea what i am doing wrong or how i can solve this? I cannot simply just filter all 255 values because sometimes i send them. I just dont understand the library behaviour here.
Edit: The weird thing is the read function returns an int, not a byte. So i can see if its -1 or 255. And its definitly 255 instead of -1. If i try to read 7 times instead of using the available function the last reading then is -1. Does the slave send wrong bytes or do i maybe need a pullup or whats going on here?
My solution is to read until read is -1 instead of using the available function. But there must be another solution.
While this seems akward, it is the expected behaviour. The I2C protocoll does not provide any means of the slave to end the requested transmission.
The length is solely defined by the quantity parameter given to Wire.requestFrom. This way the master decides, and have to know, how much bytes the slave will send. Wire.available only signals if the previously given length is reached.
To provide variable length messages, you may chose a delimiter character, like \0 for string transmissions, or prepend the message with a byte storing the number of bytes following and stop reading if the told amount is reached.