I already read the datasheet and google but I still don't understand something.
In my case, I set PIN RC6 of a PIC18F26K20 in INPUT mode:
TRISCbits.TRISC6 = 1;
Then I read the value with PORT and LATCH and I have different value!
v1 = LATCbits.LATC6;
v2 = PORTCbits.RC6;
v1 gives me 0 where v2 gives 1.
Is it normal?
In which case we have to use PORT and in which case LATCH?
The latch is the output latch onto which values are written. The port is the voltage at the actual pin.
There are a few situations where they can be different. The one that I've encountered most frequently is if you have a pin (accidentally) shorted to ground. If you set the latch high, the latch will read high, but the port will read low because the voltage on the pin is still approximately ground.
Another situation leading to what you've described is when the port pin hasn't been configured correctly. I (and everyone I work with) have spent many hours trying to figure out why our PIC isn't working to expectations, to eventually find out that we glossed over turning off the analog modules, for instance. Make sure you go over the section I/O Ports -> PORT?, TRIS?, and LAT? registers in the datasheet. You can get more info in the Microchip wiki page which explains about reading the wrong value immediately after you write an output on a pin connected to a capacitive load.
That wiki page also explains:
A read of the port latch register returns the settings of the output drivers, whilst a read of the port register returns the logic levels seen on the pins.
Also, here's a snippet from the I/O Ports section on the 18F14K50 (which ought to be the same as the rest of the 18F series):
Each port has three registers for its
operation. These registers are:
TRIS register (data direction register)
PORT register (reads the levels on the pins of the device)
LAT register (output latch)
So in most situations, you will write to the latch and read from the port.
I'll adapt my answer from Electrical Engineering.
Let's use the picture from manual:
When you write a bit in a I/O pin, you're storing this bit from Data Bus to the Data Register (D-FlipFlop). If TRISx of this bit is 0, so data from Q of the Data Register will be in the I/O pin. Write in LATx or PORTx is the same. See below in red:
On the other hand, read from LATx is different of read from PORTx.
When you're reading from LATx, you're reading what is in the Data Register (D-FlipFlop). See picture below in green:
And when you read from PORTx, you're reading the actual I/O pin value. See below in blue:
PIC uses read-modify-write to write operations and this can be a problem, so they use this shadow register to avoid it.
Here's a useful summary from the datasheet.
11.2.3 LAT Registers
The LATx register associated with an I/O pin eliminates the problems that could occur with
read-modify-write instructions. A read of the LATx register returns the values held in the port
output latches, instead of the values on the I/O pins. A read-modify-write operation on the LAT
register, associated with an I/O port, avoids the possibility of writing the input pin values into the
port latches. A write to the LATx register has the same effect as a write to the PORTx register.
The differences between the PORT and LAT registers can be summarized as follows:
A write to the PORTx register
writes the data value to the port
latch.
A write to the LATx
register writes the data value to the
port latch.
A read of the PORTx
register reads the data value on the
I/O pin.
A read of the LATx
register reads the data value held in
the port latch.
Yes, it's normal to read PORTx and LATx and occasionally find they have different values.
When you want to read whether some external hardware is driving a pin high or low, you must set the pin to input mode (with TRIS or the DIR register), and you must read PORTx. That read tells you if the actual voltage at the pin is high or low.
When you want to drive a pin high or low, you must set the pin to output (with TRIS or the DIR register); you should write the bit to the LATx register.
(Writing that bit to the PORTx register may seem to do the right thing: that pin will -- eventually -- go high or low as commanded. But there are many cases -- such as when some other pin on that port is connected to an open-collector bus -- that writing to one bit of the the PORTx register will mess up the state of the other pins on that port, leading to difficult-to-debug problems).
Open Circuits: read before write
My recommendation is to regard the PORT values as read-only. The LAT values may be read or written, but the value read will be the last value written, not the input value of the pin.
On older PICs, the LATx values didn't exist; the only way to write to a port was via the PORTx registers. Curiously, some of the really old PICs, back from the General Instruments (pre-Microchip) days, supported LATx, but Microchip didn't add that feature until the PIC18x line.
A write to the PORTx register writes the data value to the port latch.
A write to the LATx register writes the data value to the port latch.
A read of the PORTx register reads the data value on the I/O pin.
A read of the LATx register reads the data value on the port latch.
Use LATx: to write to an output pin
Use PORTx: to read an input pin
For all PICs with LATx registers, all INPUT must be from PORTx and all OUTPUT should be to LATx, which totally avoids the problem of flipping bits when you write to a single bit of the port.
I recently experienced that writing on PORTx Ri (e.g. PORTC RC1) of PIC18F14K50 is ineffective when another PORTx Rj (e.g. PORTC RC0) was already set.
I observed a peek in the oscilloscope on PORTx Ri but I was unable to sustain the output.
This issue has vanished as soon as I was writing on LATx.
LATx writing looks mandatory on PIC18 and PORTx writing prohibited.
It is always recommended to write to LAT, read from PORT, the reason is when the port is used as output, bit operation of PORT will do read modify write instruction.
Read modify write Instruction have some pitfalls, based on the output capacitance (rise time of the port pins) which may set the port pins to wrong value, when two consecutive READ modify WRITE instruction is executed.
So always write to LAT and read from PORT (input pins)
Related
I'm trying to send data over BLE from my iPhone to an ESP32 board. I'm developing in flutter platform and I'm using flutter_reactive_ble library.
My iPhone can connect to the other device and it can also send 1 byte using writeCharacterisiticWithResponse function. But when I try to send my real data which is large (>7000 bytes), it then gives me the error:
flutter: Error occured when writing 9f714672-888c-4450-845f-602c1331cdeb :
Exception: GenericFailure<WriteCharacteristicFailure>(
code: WriteCharacteristicFailure.unknown,
message: "Error Domain=CBATTErrorDomain Code=17
"Resources are insufficient."
UserInfo={NSLocalizedDescription=Resources are insufficient.}")
I tried searching for this error but didn't find additional info, even in Apple Developer website. It just says:
Resources are insufficient to complete the ATT request.
What does this error really means? Which resources are not sufficient and how to work around this problem?
This is almost certainly larger than this characteristic's maximum value length (which is probably on the order of 10s of bytes, not 1000s of bytes). Before writing, you need to call maximumWriteValueLength(for:) to see how much data can be written. If you're trying to send serial data over a characteristic (which is common, but not really what they were designed for), you'll need to break your data up into chunks and reassemble them on the peripheral. You will likely either need an "end" indicator of some kind, or you will need to send the length of the payload first so that the receiver knows how much to excpect.
First of all, a characteristic value cannot be larger than 512 bytes. This is set by the ATT standard (Bluetooth Core Specification v5.3, Vol 3, Part F (ATT), section 3.2.9). This number has been set arbitrarily by the protocol designers and does not map to any technical limitation of the protocol.
So, don't send 7000 bytes in a single write. You need to keep it at most 512 to be standard compliant.
If you say that it works with another Bluetooth stack running on the GATT server, then I guess CoreBluetooth does not enforce/check the maximum length of 512 bytes on the client side (I haven't tested). Therefore I also guess the error code you see was sent by the remote device rather than by CoreBluetooth locally as a pre-check.
There are three different common ways of writing a characteristic on the protocol level (Bluetooth Core Specification v5.3, Vol 3, Part G (GATT), section 4.9 Characteristic Value Write):
Write Without Response (4.9.1)
Write Characteristic Value (4.9.3)
Write Long Characteristic Values (4.9.4)
Number one is unidirectional and does not result in a response packet. It uses a single ATT_WRITE_CMD packet where the value must be at most ATT_MTU-3 bytes in length. This length can be retrieved using maximumWriteValueLength(for:) with .withoutResponse. The requestMtu method in flutter_reactive_ble uses this method internally. If you execute many writes of this type rapidly, be sure to add flow control to avoid CoreBluetooth dropping outgoing packets before they are sent. This can be done through peripheralIsReadyToSendWriteWithoutResponse by simply always waiting for this callback after each write, before you write the next packet. Unfortunately, it seems flutter_reactive_ble does not implement this flow control mechanism.
Number two uses a single ATT_WRITE_REQ where the value must be at most ATT_MTU-3 bytes in length, just as above. Use the same approach as above to retrieve that maximum length (note that maximumWriteValueLength with .withResponse always returns 512 and is not what you want). Here however, either an ATT_WRITE_RSP will be returned on success or an error packet will be received with an error code. Only one ATT transaction can be outstanding at a time, which significantly lowers throughput compared to Write Without Response.
Number three uses a sequence of multiple ATT_PREPARE_WRITE_REQ packets (containing offset and value) followed by an ATT_EXECUTE_WRITE_REQ. The maximum length of the value in each each chunk is ATT_MTU-5. Each _REQ packet also requires a corresponding _RSP packet before it can continue (alternatively, an error code could be sent by the remote device). This approach is used when the characteristic value to be written is too long to be sent using a single ATT_WRITE_REQ.
For any of the above write methods, you are always also limited by the maximum attribute size of 512 bytes as per the specification.
Any Bluetooth stack I know of transparently chooses between "Write Characteristic Value" and "Write Long Characteristic Values" when you tell it to write with response, depending on the value length and MTU. Server side it's a bit different. Some stacks put the burden on the user to combine all packets but it seems nimble handles that on its own. From what I can see in the source code (https://github.com/apache/mynewt-nimble/blob/26ccb8af1f3ea6ad81d5d7cbb762747c6e06a24b/nimble/host/src/ble_att_svr.c#L2099) it can return the "Insufficient Resources" error code when it tries to allocate memory but fails (most likely due to too much buffered data). This is what might happen for you. To answer your first actual question, the standard itself does not say anything else about this error code than simply "Insufficient Resources to complete the request".
The error has nothing to do with LE Data Length extension, which is simply an optimization for a lower layer (BLE Link Layer) that does not affect the functionality of the host stack. The L2CAP layer will take care of the reassembling of smaller link layer packets if necessary, and must always support up to the negotiated MTU without overflowing any buffers.
Now, to answer your second question, if you send very large amounts of data (7000 bytes), you must divide the data in multiple chunks and come up with a way to correctly be able to combine them. Each chunk is written as a full characteristic value. When you do this, be sure to send values at most of size ATT_MTU-3 (but never larger than 512 bytes), to avoid the inefficient overheads of "Write Long Characteristic Values". It's then up to your application code to make sure you don't run out of memory in case too much data is sent.
I'm working on a dual OS system with STM32F103, I have two separate program that programmed on different FLASH locations. if both of the programs are the same, the only way to know which of them running is just by its start vector address.
But How I Can Read The Current Program Start Vector Address in STM32 ???
After reading the comments, it sounds like what you have/want is a bootloader. If your goal here is to have two different applications, one to do your main processing and real time handling and the other to just program new firmware, then you want to make a bootloader in your default boot flash space.
Bootloaders fundamentally do a few things, everything else is extra.
Check itself using some type of data integrity check like a CRC.
Checks the application
Jumps to the application.
Bootloaders will also program applications in the app space and verify they are programmed correctly before jumping as well. Colin gave some good advice about appending a CRC to the hex file before it is programmed in flash space to verify the applications.
There are a few things to look out for. The first would be the linker script and this is extremely important. A linker script will be used to map input objects to output objects and then determine based upon that script, what memory space they go into. For both of your applications, you need to create a memory map of how you want both programs to sit inside of the flash space. From this point, you can then make linker scripts for both programs so that a hex file can be generated within the parameters of what you deem acceptable flash space for the program. Each project you have will have its own linker script. An example would look something like this:
LR_IROM1 0x08000000 0x00010000 { ; load region size_region
ER_IROM1 0x08000000 0x00010000 { ; load address = execution address
*.o (RESET, +First)
*(InRoot$$Sections)
.ANY (+RO)
}
RW_IRAM1 0x20000000 0x00018000 { ; RW data
.ANY (+RW +ZI)
}
}
This will give RAM for the application to use as well as a starting point for the application.
After that, you can start the bootloader and give it information about where the application space lies for jumping and programming. Once again this is all determined by you from your memory map and both applications' linker scripts. You are going to need to add a separate entry inside of the linker for your CRC and length for a comparison of the calculated versus stored as well. Whatever tool you use to append the CRC to the hex file and have it programmed to flash space, remember to note the location and make it known to the linker script so you can reference those addresses to check integrity later.
After you check everything and it is determined that it is okay to go to the application, you can use some ARM assembly to jump to the starting application address. Before jumping, make sure to disable all peripherals and interrupts that were enabled in the bootloader. As Colin mentioned, these will share RAM, so it is important you de-initialize all used, otherwise, you'll end up with a hard fault.
At this point, the program used another hex file laid out by a linker script, so it should begin executing as planned, as long as you have the correct vector table offset, which gets into your question fully.
As far as your question on the "Flash vector address", I think what your really mean is your interrupt vector table address. An interrupt vector table is a data structure in memory that maps interrupt requests to the addresses of interrupt handlers. This is where the PC register grabs the next available instruction address upon hardware interrupt triggers, for example. You can see this by keeping track of the ARM pipeline in a few lines of assembly code. Each entry of this table is a handler's address. This offset must be aligned with your application, otherwise you will never go into the main function and the program will sit in the application space, but have nothing to do since all handlers addresses are unknown. This is what the SCB->VTOR is for. It is a vector interrupt table offset address register. In this case, there are a few things you can do. Luckily, these are hard-coded inside of STM generated files inside of the file "system_stm32(xx)xx.c" (xx is your microcontroller variant). There is a define for something called VECT_TAB_OFFSET which is the offset in the memory map of the vector table and is assigned to the SCB->VTOR register with the value that is chosen. Your interrupt vector table will always lie at the starting address of your main application, so for the bootloader it can be 0x00, but for the application, it will be the subtraction of the starting address of the application space, and the first addressable flash address of the microcontroller.
/************************* Miscellaneous Configuration ************************/
/*!< Uncomment the following line if you need to relocate your vector Table in
Internal SRAM. */
/* #define VECT_TAB_SRAM */
#define VECT_TAB_OFFSET 0x00 /*!< Vector Table base offset field.
This value must be a multiple of 0x200. */
/******************************************************************************/
Make sure you understand what is expected from the micro side using STM documentation before programming things. Vector tables in this chip can only be in multiples of 0x200. But to answer your question, this address can be determined by a few things. Your memory map, and eventually, you will have a hard-coded reference to it as a define. You can figure it out from there.
Hope this helps and good luck to you on your application.
I have read already lot of specs and code about UART, but I cannot find any indication on how to find by software interface if the transmit FIFO is full. There is an interrupt when the FIFO is empty. Then I can write at least N characters, where N is the fifo size. But when I have written these N characters, a number of them have already been sent. So I can in fact write more than N characters, but there is no FIFO full interrupt. The specs says that when the fifo is full indeed the TXREADY pin on the chip is inverted. Is there a way to find this by software ? The Line Status Register bit only says that the fifo is not empty, which does not mean it is full...
Anyone can help ? I want to write characters until the fifo is full...
Looks to me also that they neglected this, but most people get by with the thing as it is. The usual way to use it is to get an interrupt, fill the FIFO (normally very fast compared to serial data rate) and then return.
There is a situation where it seems to me that what you are asking for could be nice...if transmitting in a polling mode...you want to send 10 bytes, your polling shows the FIFO is not empty, so you have not way to know if you can send them all or not...either you wait there until it is empty, which sort of defeats the purpose of the FIFO, or you continue polling other stuff until you get back to checking for FIFO empty, and maybe that slows your overall transmission rate. Guess it is not a very usual way to operate, so nobody worries about it.
The 16550D datasheet says the following:
The transmitter holding register interrupt (02) occurs when the XMIT
FIFO is empty; it is cleared as soon as the transmitter holding
register is written to (1 to 16 characters may be written to the XMIT
FIFO while servicing this interrupt) or the IIR is read.
This means that when the Line Status Register register (port base + 5) indicates Transmitter Empty condition (in bit 5), the transmit FIFO is completely empty and you may write up to 16 bytes to the transmitter holding register (port base + 0). It is important not to write more than 16 bytes between occurrences of the transmitter empty bit being set.
If you don't need to write 16 bytes at the point when you received the IRQ (or saw the transmitter register empty bit set, if polling), you can either keep track of how many bytes you wrote since the last transmitter empty state, or, just defer writing further bytes until the next transmitter empty state.
Well, even Embarcadero states that it is not guaranteed to return accurate result of the bytes ready to read in the socket buffer, but if you look at it, when you place -1 at Socket.ReceiveBuf (this is what ReceiveLength wraps) it calls ioctlsocket with FIONREAD to determine the amount of data pending in the network's input buffer that can be read from socket s.
so, how is it not safe or bad ?
e.g: ioctlsocket(Socket.SocketHandle, FIONREAD, Longint(i));
The documentation you mention specifically says (emphasis mine)
Note: ReceiveLength is not guaranteed to be accurate for streaming socket connections.
This means that the length is not known ahead of time because it's being supplied by a stream of data. Obviously, if you don't know how big the data is that's being sent ahead of time, you can't properly set the length the client should expect.
Consider it like generic code to copy a file. If you don't know ahead of time how big the file is you'll be copying, you can't predict how many bytes you'll be copying. In the case of the socket, the stream size that's supplying the socket isn't known in advance (for instance, for data being generated real-time and sent), so there's no way to inform the client socket how much to expect.
When I connect 8051 to an external memory, should I change the RD and WR signals in software or is this made by processor itself when I use the MOVX command?
For example I will read from some location at memory,
;CLR RD
MOV DPTR,#SOMELOCATION
MOVX A,#DPTR
is CLR read command required here or processor just clears that itself by looking if the code is
MOVX A,#DPTR ;or
MOVX #DPTR,A
If the processor has RD and WR lines, then yes, the processor will pulse the write line with timing as described in the data sheet as it executes the "movx #dptr,A" instruction. In addition, ALE would have been pulsed to latch the low byte of the address for the memory.
If for some reason it was necessary to operate the chip write using a clear bit instruction as you state above, you are doing it in the wrong place. You would need to set up address and data THEN pulse write low, then return it high, before any other change in address and data.