Netburner Carrier Board and RTS/CTS

[Ridgeglider]

Tod you are correct that writestring uses the \0 to find the end of the string it's passed, but that that it does not send the terminator, and so technically it does not actually send the string... If your new WriteStringWithTerminator is based on writesstring() be aware that writestring() does not always send ALL the chars before the terminator, so you need to check the the return value to see if it matches the length of the original string. I think writestring is defined to send at least one char, but not all.

[tod]

Dave thanks for the tip on Docklight, that and the USB Tap they talk about seem like they could save me a lot of time in the future.

Ridgeglider, I did just use writestring() followed by sending the \0 , while I'm checking that the length of the string equals the number of bytes sent I don't have any recovery code in place (yet). So far writestring() has always sent the entire string. But I guess writestring() is like the stock market, past performance is no guarantee of future success.

[Ccoder]

Tod I see your problem is resolved. Is this a new touch-screen? The reason I ask is I was considring a NB for a project and was wondering how easy a typical screen is to interface to the debug port on a NB. I assume you are able to develop nice menus on the touch-screen?

Just as a note, I have a cheap 9pin inline LED line indicator that really helps when working on RS-232 troubles or development.

[tod]

CC,
This is a fairly new touchscreen from Matrix Orbita the GTT480272A. I just took a screen shot with an inexpensive camera of the simple interface I built so you can get an idea of what it looks like. This is all dreaded "programmer" artwork that I created. There is a low level library that lets you load fonts, draw strings, graphics, define touch regions etc. A Touch region can have an up and down graphic. In my interface you can select any digit and the led under that digit will "light" and then the up down arrows will change the value at the selected decade. The freq switch just goes between two settings and the LED is green or white/gray (off). If you wanted something like a drop down menu you would have to program it yourself.

If you're interested in this touchscreen I would recommend reading the first half of my blog entry, when you get to the part on C# techniques, scroll to the end and take note of the manual errata that I mention to save yourself some pain. I got everthing working from a PC under C# first (it was just easier - but it still took two weeks and one firmware upgrade). Now I'm translating it all to C++ on the NetBurner. Pretty simple for the most part, I haven't started on the touch screen responder piece in the NB yet.

[Ccoder]

Tod, so very nice T-screen and I reviewed your blog, good info.

Seemed like alot of coding to display a message. I may have been distracted by the C#, although it looks alot like C++. I think the GTT is probably high-end with really nice drawing capabilities. We maybe in search of more basic text based screen which may could be interfaced with more basic calls, etc. Thanks

[tod]

When my library is done it will be a lot easier to program! Of course I wrote it in C++, not C so most unenlightened embedded platforms won't be able to use it. I find Matrix Orbital's decision to use binary byte streams instead of ascii commands questionable. I suppose it is marginally faster but it comes at a price in terms of complexity. I think at a minimum they could have provided a wrapper library for a lot of the calls. On the plus side the display is gorgeous. It looks much better in real-life than my photo. I think in the long run these kinds of displays are the way to go, they reduce a lot of recurring manufacturing expense by getting rid of knobs and switches, panel cut outs, silk screening etc. You pay once for some non-recurring software engineering (and who doesn't want to support a programmer).

While trying to do some of the things I did in C# in C++ I had to get better at STL programming and finally grok those bind1st and mem_fun adapters. I'll have a blog about that soon.

[tod]

OK - it turns out that to get reliable behavior from this touchscreen I really do need RTS/CTS enabled. It took me a little while to figure out exactly how to do this on the DEV-100 board. Since I think it's somewhat less than intuitive and of possible use to other programmers I wrote up the process, in a blog post and created a link to it in the wiki. I welcome any feedback and corrections from anyone willing to take a look at it, thanks.

[rnixon]

As v8dave said, \n or \r\n is common for an ascii terminated string.
The writestring() function sends an ascii string, and as you know a \0 is an ascii terminator in C. But there are two different things; one is a programming language terminator for an ascii string, and the other a protocol terminator for a string.
If you are sending binary then terminators are not used unless there is an escape sequence, because in binary what you want as a terminator could show up in the data. For example, 0 might be perfectly valid as data, and if that was your terminator the protocol would fail.

[v8dave]

Hi Tod,

I have just downloaded the protocol manual for your display and you can't use any writestring commands to talk to it. You need to send it binary only so you need to use a function that expects a pointer to a buffer and then a length to send. If you look at page 10 of the manual there is a command to read the protocol version.

Command sequence: 254 00

To get it to send the 00, you need to put these 2 values in a char buffer and then send it with something like:

Code: Select all

Buffer[0] = 254;
Buffer[1] = 0;
Len = 2;
writeall(fd, Buffer, Len);

This will then write out the data to the device for you with the terminating zero. This is how I have done the RTU code for Modbus which is binary based.

I appreciate you may already know this but if someone else is following this thread or picked up one of these displays it may help them out.

Dave...


[EDIT] Actually, you can send using writestring but only for when display normal text. For commands you have to use the above.

[tod]

I should have been a little more clear about what I was asking since this thread has spanned a couple of topics. The writestring issue was resolved a while ago. The NB writestring() function works as far as it goes but it doesn't send the \0 terminator so I just have a wrapper for it that does. I could have used the full binary approach but since the strings I want to write out are std::string variables it was just cleaner in my mind to write it out using the writestring approach and that works.
BUT
Once I had everything (reading from and writing to the display) "working" the performance was still unreliable. I could run some basic unit tests and they would pass. However, when I went to read multiple key touches I didn't always get the correct binary string. Sometimes I wouldn't get the starting value of 252 other times I wouldn't get the second character of 135. I knew it would be unacceptable to have to click multiple times on an icon to get a response. Less frequently the write to the display would screw up (but always tied to reading from the display).

That was when I decided to explore more about RTS/CTS. Once I did the steps I talk about in the blog article everything started working flawlessly. It was a dramatic difference in reliability. What I was after in the last post was any feedback about the blog post itself. I'm not sure I use the right terminology when talking about schematic labels and some of it I figured out by just "hunting" around on the schematic and maybe there is a logic to how you find things that I could add. At any rate I appreciate you guys taking the time to help me out.