Question on include files and problem with serial LCD/USB program

[Christopher4187]

Research for my current project has pointed me to many C coding examples. I didn't quite understand it at first but the multiple files for one program is a great idea and I wanted to create the same for PBP. I searched on here and found some threads that discussed it. Took me a couple of tries but it works great. In fact, I'm on an include overload as I've separated many subroutines and put them in include files. It's the best thing I've learned for PBP in quite a while and for anyone who hasn't tried it I highly suggest it, especially if your code is quite long. Scrolling up and down to find a certain spot in your code can get to be a real hassle but the include file solves it perfectly.

I'm not sure if this is possible but I need to ask this question. Is there any way to put the include files in a folder other than PBP? Putting them into other folders would be awesome but I wasn't able to figure that part out, if it's possible. Still using 2.50B.

My other question is regarding a serial LCD and a USB program that uses VB6. Each of them works but when I put the serout2 command into the code the USB will no longer recognize the device. I've tried sprinkling usbservice commands into my code but that doesn't help. Besides, I can't see a serout2 command taking a ton of time to execute. It seems to me this shouldn't be and there's a problem in my code but I don't understand why it's not working. It would be nice if my customers had a seamless transition (i.e. hot plugging) between using a laptop and using the LCD screen. Anyone have experience with something like this or heard of a similar issue.

[HenrikOlsson]

Hi Christopher,
The include files can be either in the same directory as the main source file (the one you're compiling "from") or in the root PBP folder. If you want to have them in any other place you need to specify the full path in your INCLUDE statement, like INCLUDE "D:\MyIncludes\ThisOrThatFile.pbp"

The manual says that USBSERVICE needs to be called at least every 10ms. SEROUT2 CAN take a conciderable amount of time depending on the baudrate and actual amount of data. Lets say you're sending 5 bytes at 2400 baud, each byte is 10bits including a start- and a stopbit so thats 50/2400=21ms. And that's for the actual bitbanging of the pin.

/Henrik.

[Christopher4187]

Hi Christopher,
The include files can be either in the same directory as the main source file (the one you're compiling "from") or in the root PBP folder. If you want to have them in any other place you need to specify the full path in your INCLUDE statement, like INCLUDE "D:\MyIncludes\ThisOrThatFile.pbp"

Awesome. It's the best thing since sliced bread!

The manual says that USBSERVICE needs to be called at least every 10ms. SEROUT2 CAN take a conciderable amount of time depending on the baudrate and actual amount of data. Lets say you're sending 5 bytes at 2400 baud, each byte is 10bits including a start- and a stopbit so thats 50/2400=21ms. And that's for the actual bitbanging of the pin.

Ouch. I guess that explains why it's not working. However, I'm using 9600 but it looks like I'm still over the 10mS limit. I'll have to see if I can rework my code just for the design phase. Would you happen to know how long parallel LCD's take to execute?

[HenrikOlsson]

Hi,
> Would you happen to know how long parallel LCD's take to execute?

No, not really since it depends on how fast the actual LCD module can handle the data and commands - or rather how fast you've told PBP that it can handle it. That's what the DEFINE LCD_COMMANDUS and LCD_DATAUS does. Then of course the actual processing takes a bit too - best thing you can do is to measure it.

Perhaps you can split your data output up in two or more section and call USBSERVICE in between?

SEROUT2 PortB.0, 84, ["This is "]    '8 bytes, atleast 8.3ms@9600
USBSERVICE
SEROUT2 PortB.0, 84, [" one part"]   '9 bytes, atleast 9.4ms@9600
USBSERVICE

Of course, using the USART would be best but I guess that's not possible for whatever reason.

/Henrik.

[Christopher4187]

Something doesn't seem right. I tried this:

USBSERVICE
SEROUT2 PORTD.3, $4054,[16,85,DEC RPM]
USBSERVICE

No dice. Then I took out the serout command and put a pause command in place of it. It works at 2mS, it's iffy at 3mS and from 4mS and above. For whatever reason, my max time in between usbservice commands is 2mS. Doesn't seem right.....

As far as the USART, I didn't use it for two reasons. The demo boards from Microchip use portc.7 for the SDO going to the MCP. Also, I typically use wireless communication and I use the USART for it so I always leave open the USART pins for future use.

If there's something else you can think of, let me know please. It's not critical to my design but it would be nice to have. I'm just trying to figure out the 2mS limit. The boards use a 20MhZ crystal and using HS and HSPLL seem to have no effect.

[Christopher4187]

Not sure if this means anything but if I don't define the oscillator "DEFINE OSC 20" and then I adjust the osc setting from HS to HSPLL the serout commands can stay in the program and the USB portion works. The only problem is now my LCD screen has garbage on it because the PIC isn't sending data at the right speed.

Correct me if I'm wrong but doesn't that mean that the PIC is working faster than it should because the OSC isn't defined. If so, is there a way to find the speed and adjust my LCD screen to match? Perhaps in the final design I should use a faster oscillator too.

[HenrikOlsson]

Hi,
Well, the manual says at least every 10ms... I wouldn't have expected 2ms either but if that what it takes then that is what it takes. I'm pretty sure THAT part has nothing to do with PBP really, it's just what's needed to have USB working.

As previosuly discussed the amount of time that your SEROUT2 statement takes at a certain baudrate depends on the amount of data. If RPM is 0-9 then you're sendning 3 bytes, if it's 10-99 you're sending 4 bytes, if it's 100-999 you're sedning 5 bytes and so on.

When you DEFINE OSC 20 (and asuming RPM needs 3 bytes) your SEROUT2 PORTD.3, $4054,[16,85,DEC RPM] statement will take 60/9600=6.25ms (+some for processing). If you RUN the PIC at 20MHz but doesn't tell the compiler that you are the compiler thinks it's running at 4MHz and calculates all the internal timing based on that. At 4MHz each cycles is 1us but at 20MHz each cycle is 200ns, the PIC is executing code 5 times faster then the compiler expected, your SEROUT2 statement is not sending at 9600baud, it's sending at 48000baud (or trying to, I don't think it'll actually work). So what previosuly took 6.25ms now only takes 1.25ms - which puts you inside the window for USBERVICE timeout.

Since you are running at 20MHz it's likely that SEROUT2 will work at 19200 or even 38400. At 38400 you're down to ~1.6ms for the above. You will need to check the documentation for your serial LCD if there's a way to change the buadrate. I'd expect some jumpers or dipswitches or perhaps it's software controlled. Do you have a link?

/Henrik.

[Christopher4187]

Since you are running at 20MHz it's likely that SEROUT2 will work at 19200 or even 38400. At 38400 you're down to ~1.6ms for the above. You will need to check the documentation for your serial LCD if there's a way to change the buadrate. I'd expect some jumpers or dipswitches or perhaps it's software controlled. Do you have a link?

/Henrik.

According to the datasheet, I can only use 9600 or 2400 baud. I bought a graphic LCD that will be here today but haven't looked at the documentation yet. The current screen I have is:

http://www.seetron.com/bpp420.html

The one I just bought is:

http://www.seetron.com/sgx120.html

Thanks again for the advice.

[HenrikOlsson]

Hi,
If you can't set the LCD to accept data at a faster rate then there's not much else to do than try to split the messages up. Perhaps you could do somethine like

Message VAR BYTE[20]
i VAR BYTE

ArrayWrite Message, [16, 85, DEC RPM, 0]
USBSERVICE
GOSUB SendIt

SendIt:
  i = 0
  While Message[i] <> 0
    USBSERVICE
    SEROUT2 Portd.3, $4054, Message[i]
    i = i + 1
  WEND
RETURN

That graphic LCD is also 9600baud max and my guess it needs even more data to be sent than the basic alphanumeric one so I wouldn't expect that to solve anything.

EDIT: Ooops, still 2.50...time for an upgrade perhaps? Since you learned to love using INLCUDE to structure your code you're going to like the conditional compilation features available in PBP3.