FCM Newby


#1

Hi,

i have a problem understanding the FCM, i have it running, i can open the flow for v24 serial link and get every thing running correctly.
questions

  1. must the switch state be in data mode for v24 link to receive data?
  2. if it must how do you discriminate from the strings you need in the returned data to the strings you don’t?

scenario:

  1. need to send to external meter
  2. captures meter response and packet in buffer for later sms
  3. send <1> to meter
  4. capture meter response and packet in buffer for later sms
  5. send <5>,cr> to meter
  6. capture meter response and packet in buffer for later sms
  7. quit operation and send packet to requesting user.

sending and listning in of the uart for each individual steps is were my confusion comes in.

in a seperate micro environment this would have been easy to do as you just send a char and wat for the incoming strings and manipulate it as it comes in.

can any body shed some light here for me please. hope my request makes sense.
regards
CC


#2

If it’s not in Data mode, everything is passed to the AT Command interpreter to be handled as AT Commands.

It’s exactly the same in Open-AT:

  • Incoming data arrives via the Data handler (analaguous to a microcontroller’s interrupt handler);
  • Use adl_fcmSendData to send data - the clue is in the name!

#3

thanks for the answers Awneil,

the send and receiving is ok throught the FCM, the problem experienced is that when data comes back i can’t discriminate char for char it seems to come in as a block of data placed in the *data buffer with the length Datalen. what i find dificult is sending one request and waiting for the feedback and then send the net request.

does this mean i have to set up a seperate FCM flow functions for each request and its feedback???

regards
cc


#4

Yes, that is the correct (and documented) behaviour.

Why not?
You have the buffer; you know its length - so you can just step through it byte-by-byte! 8)

Exactly as if a “normal” microcontroller’s UART interrupt handler were putting the received bytes into a buffer…

As above, you just need to step through the received buffer(s) until you’ve seen a complete response.

Not at all.

It’s possible that a response will be delivered in more than one Data event; so you will need some sort of state machine to collect response bytes until you get a complete response - but that’s no different to what you’d do on a “normal” microcontroller.

Hint: the ADL_FCM_EVENT_MEM_RELEASE event is effectively the “Tx Done” indication…


#5

In fact, it is very much like dealing with a UART with a built-in FIFO - you get an Event when the FIFO is “full”, or when some bytes have been received and it’s not full, but there’s been a sufficient delay with no further characters received.