. Welcome to the 4D Systems Forum. You have to before you can post: click the Sign Up link above to proceed. To start viewing messages, select the forum category that you want to visit from the selection below. You can only create a post inside one of the forum categories. Do your best to select a forum category that is most relevant to your question. You can only download attachments in posts when you are logged in.

Merry Xmas - Happy New Year Please note that forum and Ticket support will be slower to respond over the upcoming Christmas/New Year break. 4D Systems is officially closed from End Of Business Friday 22nd December - Open again Monday 8th January 2018. Thanks for your understanding - and Happy Holidays! I am using the display in 4DGL mode.

Proton Basic Serial Interrupts

I am using serin to capture data from a PIC. Here is my problem. If I power up both devices, I have a 5 second delay on the PIC so the display has ample time to power up before the PIC does anything. Once the PIC is up and running, it will send data all day along the serial output but the display won't see it. If I power everything up with the USB-MB5 connected to the display, using the Terminal inside of the 4DGL IDE, I can make the dislpay do exactly what I expect it to do with the PIC data by sending it data manually.

Without a power cycle, I can now unplug the MB5 Tx and plug in the PIC Tx and the display will show my PIC data. I know I am missing something obvious to get them to sync but I don't know what. The PIC Clock is at 8Mhz so the Baud is set at 4800 since it is doubled with the clock. I use setbaud(BAUD9600) on the display APP. I have tried sending an AutoBaud command although this made no sense to me and it still doesn't work. Solidworks 2005 spo serial number.

The baud rate does not seem to be an issue since it reads the data perfectly once I trigger the display with the Terminal. Man I feel like an idiot.

I tried sending the AutoBaud. I am certain that my serout was correct from the PIC since its like all the others that work and I could see the U on terminal. I think my mistake was in the check for acknowledgement. I'm not sure what I had but it wasn't correct. I temporarily changed it to look for anything other than 0 and accept it as the ack and it is working exactly as planned. I need to fix this but it is a solid step in the right direction! Thanks yet again for the quick response!!!

I have a new issue related to this. I have now determined that the display does not need an AUTOBAUD if I am not controlling it. I am simply using the TX and RX lines as serial data in and out. My problem was that since I am clocking the PIC at 8MHZ instead of the default 4MHZ, somehow the BAUD rate is half of what is expected. For example, if I set the BAUD on the display to 19200, I have to use a 9600 BAUD on the PIC end to TX and RX.

So now on to my new problem. I can send data to the display, buffer it and put it to the screen with no issues. I can use check characters on the display end, I can do pretty much anything I need to from PIC to DISPLAY. However, I am absolutely stuck going the other way.

I have seriously dumbed down my code on both ends and commented the crap out of them. Can someone please take a look and steer me in the right direction. FYI, I am using a PIC16F88 and yes I have searched the forums as much as I can. You can't search for PIC though because it is only 3 characters. I agree it takes a while to fill the buffer. I can watch it doing it nice and slow. Since I am only sending the 9 out once per buffer cycle, and I am checking for it on the PIC side every time I send a new character, I thought it would pick it up.

Won't the data stay on the input pin of the PIC until I go get it or it is replaced? And since it is being replaced every time with the same value. I didn't think this would matter. This may be a gross misconception on my part. I tried putting the PIC in a loop with an UNTIL statement but since I can't seem to determine how to read the data, it just gets stuck in that loop. Yes I have read it with the IDE terminal and the SEROUT is sending data.

Agreed, that is exactly what I am doing and don't understand why but here is what was happening: When transmitting at 84, the display will receive the data perfectly and display it exactly as received. If I tried to use the 84 on the SERIN2, the program would simply hang. I assumed that this was the cause so I changed it to inverted and the program would move past that point. I have since gone back to the 84 and put a time out and a loop back to the main.

I am pretty certain it was hanging because it was not getting the correct data stream in. So now I have dumbed down the program even more, I simply have the display repeatedly sending out data, it does nothing else but stream the same character over and over to the TX pin. The 4DGL IDE Terminal viewer shows me the data is going out.

On the PBP side, I set a SERIN2 with the same baud, (not inverted) and it does nothing but look for data on the incoming pin. The rest of the program is the same, I simply deleted all of the extraneous stuff. I still cannot see the data. I think I have a scope somewhere at work so I can scope the pin.

This will at least tell me that I am sending ones and zeroes in some format or another. One more question to help me along. I am fairly new at PIC programming. Is there a buffer on the pin by default? In other words.

Let's say I send a single byte from somewhere to the PIC. Will that byte stay in a buffer until I go get it? If it doesn't, is there a way to set up a buffer that will hold the data until I need it?

This seems like a bit of magical timing to make this work. Cause even if I know that data is coming, to have the PIC looking at that pin at exactly the right millisecond seems to be a but of a stretch. I haven't even looked at interrupts yet but I suspect that I may be heading in that direction. I really need to look a little deeper into how this thing works.

Thanks again, Wade. I HAVE A GREEN LIGHT!!!! So I put the scope on it and found that it was not inverted.

However, I did find that the Display only puts out 3.3v. So I put the baud back to 84 on the SERIN2 and turned the internal pull up back on for that pin. I was getting frustrated when all of a sudden the green light came on. I reset the PIC and got nothing. I went to get a DR.Pepper and came back and the light was on again. Eventually I realized that I had answered my own question. The PIC does not save to a buffer.

So I was not giving it time to get a signal from the display. So I reworked the code to send the 8 data bytes quickly but pause for 5000 on the receive timeout. This worked immediately.

I removed all of the various pauses from the system and set my timeout to 100 and it still works fine. So now I see that I need to send my config data to the display and go into a repeat loop on the PIC waiting for the roundtrip from the display saying that it received the data plus the checksum etc.Then I can move on. The PIC will normally be receiving input from a joystick and the display. I am clearly going to need to use interrupts to tell the PIC that the display needs to send data. It can spend most of its time in a loop waiting for the joystick to change or the push button on the joystick to trigger.

Once again, thanks for the help, and over the weekend yet again. You guys are all great! Now if only I can get my 28PT back so I can start working with the touch screen:-( Wade.

I am using MicroCode Studio Plus. I finally had a chance to sit down with our resident PIC guru and he said the Hardware serial has a two byte buffer that will hold the last two bytes of data sent to it until it is retrieved or replaced with incoming data. So now I have to determine if I want to use interrupts or if I can get away with a periodic scan of that buffer to retrieve data.

Is two bytes going to be enough? I am not sure yet. On my display, keeping in mind that ultimately this is all done on a 28PT, I have multiple screens with buttons created in PS that will either be grey or green depending on status. Touching these buttons will change their status once some other PIC activities are complete. So, for the most part the buttons will either be set or not set (0,1) and I only have about 20 buttons, the hardware serial might very well work. The onyl other input to the PIC is a joystick. If I use the hardware, I will not interrupt whatever the joystick is doing.

There are certainly some advantages to this. My 28PT had to be replaced since it was cracked and I am waiting for it to arrive now. Until then I kind of have to fake it then I have to rework the code to fit the touch image functions. Oh well, I am learning a lot in the process.

Proton Basic Serial Interrupts Test

Hi I have started a new thread, can anybody tell me why the Code Below will not Output Serial under TX Interrupts. Where to start. I guess from the beginning. Since there isn't an OSC definition, I assume you're running at 4Mhz. And, with 4 Mhz, and BRGH (TXSTA.2) set to 0. The error rate for 9600 baud is 7%.

Proton Basic Serial Interrupts Numbers

That's really high. If you use HSERTXSTA 24, which sets BRGH to 1, the error rate goes to 0.16%. But then you manually set SPBRG to 25, which would be 2400 baud at 4mhz, so the 9600 gets discarded. INTCON =%10010000 Along with turning Global interrups on, also enables the External Interrupt INT. But the rest of the program doesn't use INT. 'PIE1.5 = 1 ' enable interrupt on usart receive This line is commented out, so the RX interrupt never gets enabled.

Proton Basic Serial Interrupts Model

PIE1.4 = 1 ' enable interrupt on usart transmit You cannot use Transmit interrupts with HSEROUT, they are not compatible. Just like the compiler would do, I'll stop there and report too many errors. Interesting idea. Even if i'm not the best one here in the serial data communication, i feel that you'll need more than 1 PIC for that depending the size of the data you need to send/receive to be really sure you don't miss anything. The internal USART have a buffer of 2 BYTES for incomming data. Maybe enough to stop your serial OUT. There's many way to see the solution here.

The first that spring to mind now is Sending your data bytes by byte, then check the USART interrupt flag for incomming data each time a byte is sent. Your data to be send may be store in a EEPROM, ARRAY, or, or, or,. Depending what else your project do. 2 PIC can be a solution or not. Example of serial interrupt: Should be enough to start.

EDIT: Sorry darrel didn't saw your post. The above example should help anyway Last edited by mistere; - 9th January 2006 at 23:56.

⇐ ⇐ Development Of The Nervous System Sanes 3rd Edition Pdf
⇒ ⇒ Psp Cps2 Cache Files Wikipedia