I'm a bit confused with how the immediate of UJ-Types are decoded / encoded.
Chapter 2.3 of https://content.riscv.org/wp-content/uploads/2016/06/riscv-spec-v2.1.pdf got me slightly more confused than I was before.
For example, I'd like to decode the instruction 0300006f which I know is of type UJ.
Any help would be appreciated.
Figured it out.
The immediate is 20 bits. Namely, bits 31 to 12 in the scrambled order: imm[20|10:1|11|19:12]. This is left shifted by 1 and sign extended to obtain the immediate.
Related
I'm reading in a stream of data, 64 bytes to be exact. I want to read 16 bits starting at the 480th bit of the incoming data. Unfortunately, I do not know what the incoming data type is, it's a bunch of random characters/boxes. Reading it in as an unsigned short (v), I get the number I am looking for, which for this example is 13.
my $satt_id = unpack("x60v1"), $msgdata); #$satt_id == 13
This results in $satt_id == 13, which is 00000000 00001101.
If I pull the data as 16 bits (b or B), the string does not reflect the value of 13, but rather is byte-swapped or reversed.
my $satt_idb = unpack("x60b16", $msgdata); #satt_idb == "10110000 00000000"
my $satt_idB = unpack("x60B16", $msgdata); #satt_idB == "00001101 00000000"
Why is this occurring? I want to alter the data and resend out the message, which would be relatively easy if all of the message elements were the same size (16 bits, just pack back as it was unpacked), but some are 6, 4, 2, and 1 bits. Should I just use little-endian b and then reverse? After altering the data reverse it back to original order and then pack it back as b?
Completely separate and not perl related, but this haunted me in a different utility. I just conceded by swapping the values in the Enum designation. It worked, just wasn't very viable when the amount of bits got higher than 4 (16 different values).
Thanks!
EDIT: I'm guessing this is just related to binary notation? Apparently starts from the right? So $satt_idb is correct, if you read right to left. So to make it more user friendly, just reverse, alter, then reverse again and repack?
EDIT2: Basically I'm trying to make a user-friendly method of editing messages coming through a data stream. As I mentioned in the comments, if I want to edit a single bit from 0 to 1 (which in the message represents something as true/false), I don't want the user to have to worry about editing the octet of data received, just select from a dropdown of true/false.
If it works with v, it means the data is in little-endian byte order, which means
0b0000000000001101
is stored as
0b00001101 0b00000000
which is what you got.
Should I just use little-endian b and then reverse?
No. You are likely doing something incorrect if you are converting the numbers to a text representation (binary).
If you did somehow want the binary representation of the number, you could use
sprintf("%16b", $num)
I am trying to program an ISL12022M RTC and am having trouble interpreting the register map (self taught with little experience). The documentation says that the RTC registers (SC,MN,HR,DT,MO,YR,DW) are BCD representations. In order to allow write capabilitiy into the RTC registers the WRTC bit(bit 6 of address 08h is set to '1'.The map looks like this:
The FAQ example from the Intersil site tells me that to set the WRTC bit I need to send DEh (slave address) 08h (register address) and 41 (Enable WRTC bit, other bits remain in default). Why not hex? Why 41 and not 40? And what does SC22 in SC bit 6, SC21 in bit 5, etc. mean?
Datasheet
Example
I've read the documentation until I can't see anymore and I've searched until I am just getting more confused. Any help is appreciated.
Well, it looks like these values in the map are nibbles. The range for the first register is 0 - 59. When represented in BCD, 4 bits are needed for the digit in the ones place and three bits are needed for the 10's place. So, bits 0 - 3 belong to the first nibble; bit 0 = SC(register name)1(first nibble)0(first bit). Bits 4, 5 and 6 belong to the second nibble. Bit 4 = SC(register name)2(second nibble)0(first bit). Bit 7 is not needed.
The example sheet from Intersil has a typo; the WRTC value needs to be 40h or 41h.
I'm collecting 802.11 packets using scapy on Ubuntu 16.04 (4.4 kernel). The RadioTap headers for my packets have the following present flags:
present=TSFT+Flags+Rate+Channel+dBm_AntSignal+b14+b29+Ext
Given the description of RadioTap, I would expect Channel to start on the 10th byte following the header and preceding fields (8 for TSFT + 1 each for Flags and Rate). Channel has an alignment of 2, so there is no need for padding. Yet this is what is in the undecoded portion of the packet:
notdecoded=' \x08\x00\x00\x00\x00\x00\x00f\xc0 \x02\x00\x00\x00\x00\x10\x02l\t\xa0\x00\xa9\x00\x00\x00\xa9\x00'
In this case the channel number actually appears at bytes 18-19 ('l\t' = 2412), and im not sure exactly what byte contains the dBm signal strength.
Anyone have an idea as to what i'm missing?
Found the answer after digging into the spec a bit deeper:
Scapy doesn't parse extended headers as signified by bit-32 (though it did tell me about them by stating +Ext above). Those extra headers are stuffed on the front of 'notdecoded' section of the packet. I think scapy should, at minimum, remove those extended headers from not-decoded to avoid future confusion.
In this particular case there are two extra 32 bit extended bitmap headers, accounting for the extra 8 bytes.
If someone wants to write an answer up with more detail, ill accept it, otherwise i will clean this answer up and accept it for perpetuity.
I am working on a QR code encoding/decoding project.
I have been read through the ISO/IEC 18004 (2006) and some tutorials ( http://www.thonky.com/guides/
http://www.matchadesign.com/_blog/Matcha_Design_Blog/post/QR_Code_Demystified_-_Part_1/
http://www.swetake.com/qr/qr1_en.html
)
The ISO documentation and those very nice tutorials helped me a lot. But there’s still one thing I can’t understand, that’s how we can calculate the number of data/error blocks when creating a QR code at Version 3 or higher.
The image below is from the ISO/IEC 18004 – 2006:
A version 7-H (H is error correction capacity level ) symbol that has 66 data codewords and 130 error codewords. They split both of them into 5 blocks.
The document says that the n blocks number (in this case n = 5 ) can be calculated from Table 9 (ISO 18004) according to the version and error correction level. But it seems like I can’t get that number. Please show me how I can calculate it.
Now I got it. All needed information for block splitting actually is at Table 9 of the ISO/IEC 18004 document. Just because of my careless reading.
How do I interpret dwParam1 from the midiInProc delegate into midi status message like note-off, or note-on, control change?
Because as long i try dwParam1 is 254, and is not equal to note-off or anything else.
You won't necessarily receive note-offs from every input device. IIRC it is legal for a device to send a note-on with volume=0 as a substitute for note-off. Also a drum stream (from a drum machine and/or on MIDI channel 10) I believe commonly contains only note-ons, no note-offs.
Given that your question mentions dwParam1 and midiInProc, I'm assuming this is for Windows. When you receive MIM_DATA in your midiInProc, you can parse dwParam1 as follows:
For the status byte (command and channel), use LOBYTE(dwParam1).
For the first data byte, use HIBYTE(dwParam1).
If applicable, for the second data byte, use LOBYTE(HIWORD(dwParam1)).
I'm not entirely sure what you are asking, but I think you are trying to figure out how to interpret MIDI data.
I suggest this resource:
http://www.midi.org/techspecs/midimessages.php
MIDI messages related to notes are differentiated by the first 4 bits, not by the whole byte. The last four bits of the first byte specify the channel.
The answer by #Conrad Albrecht is mostly right, but I wanted to chip in with an answer (instead of a comment), as I think that the original poster is probably being confused by MIDI running status.
If you are seeing bytes which don't resemble normal MIDI status bytes, you can assume that they are of the same type as the previous byte which you received. Therefore it is not only legal, but very common, to use MIDI note on events with velocity of 0 as a substitute for MIDI note offs.
You should just interpret these bytes as the normal second two bytes of a MIDI note on event.