0

I'm currently working on some C code to forward CAN messages via bluetooth and vice versa (µC stuff). The problem is that my paired bluetooth device uses '00' as a command and my bluetooth library is using a char[] to buffer the string when receiving from BT. This inevitably terminates the string, because it interprets the command as a NULL character. Also, any empty data byte in a CAN frame would cause the same problem.

I was able to solve the problem when going from CAN to BT by storing the CAN message in a byte array and sending a series of bytes followed by a CR to the BT module, but the other way round isn't that easy, as the BT library is using all sorts of string based commands.

Is there an easy way to prevent the NULL to cause an unwanted termination or do I have to rewrite the whole library to a suitable data type, and which one would work best in this case? Any ideas appreciated!

Kristian Krajewski
  • 3
  • 1
  • Not using C would be best, but using a library with a sane API would be good. A lib that usues null-terminated arrays for a binary stream is just sucky:( – Martin James Jun 24 '15 at 09:40
  • Unfortunately this is not an option. But I can see your point, I guess the original author of the BT library had something else in mind. – Kristian Krajewski Jun 24 '15 at 09:43

1 Answers1

1

There is no "string" type in C; what you call a string in C really is just a char *, which is just a series of bytes, too. Whenever you pass such a series of bytes to a string handling function (whether part of the standard C library or not), those functions will consider any embedded NULL as a string termination, and end processing there. That doesn't mean your binary data ends at that location, however.

Your problem isn't that your library gets you strings, it's that you're confusing binary data with strings. You're not dealing with strings, you're dealing with binary data. If it helps, you can cast the char * variables to void * variables; this isn't strictly necessary, but it may help you remember that it's binary data. Then, use a packed struct (if the data has fixed offsets) or write a custom parser function (if not) to deal with the data going in or out of your CAN bus.

Wouter Verhelst
  • 1,269
  • 1
  • 12
  • 27
  • Yeah, I guess my wording was a bit off there, but thanks anyway for clarifying. I'm aware that the binary data is there but it's being misinterpreted. When you say offsets, do you mean as in fixed positioning within the array? So I guess I have to dig deeper into the library and replace the data handling part? – Kristian Krajewski Jun 24 '15 at 09:27
  • Hmm. I'm not entirely sure I understand what your problem is. You talk about bluetooth and CAN, but you don't explain how there's a problem. Surely your bluetooth library and your CAN library both understand binary arrays? i.e., you can hand them both a pointer and a length, and they will head off with the data? If not, you need to talk to whoever wrote the library and get them to fix it. – Wouter Verhelst Jun 24 '15 at 10:01
  • That's the point, the BT lib obviously can't handle null bytes within the stream. I'll give the author a call and see what he has to say about this. The problem, put simply, is that any null char will cut off the end of the message. Thanks anyway for the feedback! I'd upvote, but apparently I can't until I reach a certain rep. – Kristian Krajewski Jun 24 '15 at 11:03