Will Blight
Forum Replies Created
-
AuthorPosts
-
Will BlightParticipant
Hi Mike,
Could you provide the part number on the Flash IC. I’d like to look at the datasheet to see the current requirements. Our app runs off of a battery and I would to determine just how much more current the flash will use.Thanks,
Will.Will BlightParticipantHi Mike,
Yes that is the sample code I was referring to. I used the link button to embed the link in my original post but it did not show up in the actual post.That is the answer I was looking for.
Thanks.Will BlightParticipantHi Mike,
Your are correct. Can’t believe I made such a dumb mistake. I thought I had already changed the types. I am sure 4 hours sleep had nothing to do with it. Someone put more coffee on!Will.
May 19, 2016 at 11:42 am in reply to: MTSSerial write() functions not blocking as per library documentation #12609Will BlightParticipantTo finish off the configuration the stop bits can also be configured using.
USART2->CR2 |= USART_CR2_STOP_0;/*!<Bit 0 */ USART2->CR2 |= USART_CR2_STOP_1;/*!<Bit 1 */
May 19, 2016 at 11:39 am in reply to: MTSSerial write() functions not blocking as per library documentation #12608Will BlightParticipantHi Mike,
I finally got it working. You cannot change the the PCE bit after calling format. You need to replace the format function by setting each of the bits that format would normally set.// sp.format(8,SerialBase::Odd,1); USART2->CR1 |= USART_CR1_PCE; //enable parity USART2->CR1 |= USART_CR1_M; // set to 9 data bits USART2->CR1 |= USART_CR1_PS; //odd parity.
Thanks for the help.
Will.May 19, 2016 at 8:05 am in reply to: MTSSerial write() functions not blocking as per library documentation #12599Will BlightParticipantHi Mike,
I tried using 9 in the format call but it didn’t work. Literally, it didn’t work I had no serial communication using a 9. The function documentation states 5 to 8 bits. I have found the bit to use and the register:
USART_CR1 |= USART_CR1_PCE;
but I am not sure where to use the code. It doesn’t compile if just add it. I am searching through the library source code looking for the correct header files to add.But, the STM32F411xE can have up to 3 USARTs. Which USART I need to change will be related to the serial port object created. But how to access the registers of that object is unclear.
- This reply was modified 8 years, 6 months ago by Will Blight.
May 18, 2016 at 1:05 pm in reply to: MTSSerial write() functions not blocking as per library documentation #12561Will BlightParticipantHi Mike,
I tested everything again this morning and 1200 baud, no parity, 8 bit works fine. The problem is only with odd parity and I believe I know the reason.I am writing code to communicate with our sensors using the HART protocol.
HART requires 1200 baud, 8 data bits, odd parity and 1 stop bit. (I have a HART C++ library.)
I was testing the communication at different baud rates and parity settings all day yesterday. Your correct the code I provided did not use odd parity (my mistake, posted the wrong code).
Below is a better example of test code I was using.int main() { char Send_Buffer[160]; int i; bc_nce = 1; mts::MTSSerial sp(D1,D0); sp.baud(19200); sp.format(8,SerialBase::Odd,1); //sp.format(8,SerialBase::None,1); for (i=0; i< 10; i++) Send_Buffer[i] = i; wait(1); int sent = 0; for (i=0; i< 10; i++) { while (sp.writeable()==0) { /* wait for room in the buffer */ } while (sp.txFull()==true) { /* wait for room in the buffer */ } while (sent == 0) { sent = sp.write(Send_Buffer[i]); } sent = 0; } while (1) { } }
I think I have found what the problem is. When configuring the serial port with parity enabled, there are 2 options. In the STM32F411RE reference manual (see section 19.3.7 parity control) the USART frame can contain 7 or 8 data bits plus the parity bit. I have included the table from the reference manual below.
Table 84. Frame formats
Mbit PCE bit USART frame(1) 0 0 | SB | 8 bit data | STB | 0 1 | SB | 7-bit data | PB | STB | 1 0 | SB | 9-bit data | STB | 1 1 | SB | 8-bit data PB | STB |
Legends:
M: M bit, P: PCE bit, SB: start bit, STB: stop bit, PB: parity bit,The second and forth row have parity enabled. I need serial port configure like the forth row.
I believe the MTSSerial library is configuring the USART using the second row (7 data bits + parity bit). To test this theory I changed my PC software to expect 7 data bits plus an odd parity bit. The results: I received the data correctly every time.This would explain why the data appears corrupt and bytes are missing.
How do I set the M bit and the PCE bit from my C++ code? Where would I insert that into my code when using the MTSSerial library.
- This reply was modified 8 years, 6 months ago by Will Blight.
- This reply was modified 8 years, 6 months ago by Will Blight.
- This reply was modified 8 years, 6 months ago by Will Blight.
- This reply was modified 8 years, 6 months ago by Will Blight.
- This reply was modified 8 years, 6 months ago by Will Blight.
Will BlightParticipantHi Mike,
The rest of the code is from the examples. The HTML section is directly from the HTML example with the a slight change to use “GET” to post data.
The shutdown() function is the code from the low power example. I am basically waiting for the modem to shutdown so I can remove power from the board safely.I have thoroughly tested the application code. I use functions outside of the main loop to perform the work I need done. Using printf() with the development kit and my oscilloscope monitoring output pins I can see that my functions complete correctly. The problem is in the modem section.
I will remove the radio_reset from before the radio_pwr.
I see in the while loop code:
“while (radio->sendBasicCommand(“AT”, 1000) != MTS_SUCCESS)”that radio_reset is toggled off and on with a 10ms delay between. Is there a delay required between setting radio_pwr and setting radio_reset?
Will.
Will BlightParticipantI also wanted to use the USB port on the dragonfly to configure the unit in our production department when the dragonfly is enclosed in the sensor housing.
We have lots options for the future. Thanks for the suggestion about the TTL to USB.Will BlightParticipantHi Mike,
The dragonfly is attached to a sensor through the 40 pin connector. I could connect the sensor to the UDK2 and power the UDK2 board but I do not have a breakout cable.Will BlightParticipantHi Mike,
I was not communicating very well. I meant I want to send messages out the USB port so I could debug my app. I understand that the “debug messages” as provided in the example code use a specific port.
I checked the M4 documentation and it does support full OTG USB support but requires a dedicated 48MHz which the dragonfly board doesn’t have. So I am giving up on the USB port. It would have been a great option for configuring operational parameters.Will BlightParticipantHi Mike,
Thanks for the message. I have been using the J6 connector on the UDK2 board.The MTQ-H5 device guide Page 18, note section says:
“The USB port can switch between a connection to the radio or a connection to the processor. The USB selection is controlled via programming on the processor.”
There is a diagram showing the USB port connecting to the M4 and the Radio (same page).I am wondering how to do this, programmatically control the USB connection? Do I use A10?
The table starting on Page 15, shows STMicro pins and how the MTQ uses them.
Pin 43 (A10) is described as “USB Switch control, 0=Telit, 1=STM”.Will.
-
AuthorPosts