CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug Reports on this forum. Send them to support@ccsinfo.com

[SOLVED] internal oscillator with PIC18F45K80
Goto page Previous  1, 2, 3
 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
Ttelmah



Joined: 11 Mar 2010
Posts: 12516

View user's profile Send private message

PostPosted: Tue Oct 10, 2017 1:25 am     Reply with quote

Seriously the USB support is not going to be much use without data.
Are you going to be able to program it a USB stack?.
Using it as a slave device will be dependant on having the VID/PID, and drivers for these ID's. Do you trust them to have drivers that work?.
You are a braver man than I, if you think that a chip with this little data given, is going to let you easily use it's features....
silelis



Joined: 12 Jun 2007
Posts: 57

View user's profile Send private message

PostPosted: Tue Oct 10, 2017 5:56 am     Reply with quote

The au7860 chip is Chinese but used by me brick is working and delivered by Polish developer.
Ttelmah



Joined: 11 Mar 2010
Posts: 12516

View user's profile Send private message

PostPosted: Tue Oct 10, 2017 6:26 am     Reply with quote

So ask the Polish developer for some better data.
silelis



Joined: 12 Jun 2007
Posts: 57

View user's profile Send private message

PostPosted: Tue Oct 10, 2017 6:35 am     Reply with quote

The data which he have also are very poor. The Chinese developer do not make good support. I saw the au7860 sdk and in my opinion it is miracle that Polish developer wrote the firmware (the chip is only in one-time programmable version).

I have decided to use this brick because it have usb, mp3, wma and is final. I have only to write driver. Unless there are some problems.

As I said before. My proposition is to suspend a thread for a while so I will make BSS138 LLC and give you my feedback.

Also I will try more crystal frequencies.
silelis



Joined: 12 Jun 2007
Posts: 57

View user's profile Send private message

PostPosted: Mon Oct 23, 2017 12:53 pm     Reply with quote

Hello once again,

I have tested it with BSS138 LLC and 14.7456 MHz crystal.

With this crystal even worse because the answer is:
Code:

??jUIQf?.3


For #use delay (crystal=14.7456MHz, clock=58.9824MHz), answer is:
Code:
k c???tsk


For #use delay (crystal=12MHz, clock=48MHz,fast_start), answer is:
Code:
??jUIQf?.3


And it should be "START v1.3".
The result is still the same. Any ideas??
temtronic



Joined: 01 Jul 2010
Posts: 5755
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Mon Oct 23, 2017 1:39 pm     Reply with quote

Really you need to go back to 'square one'.
Show us your program,small and complete , that doesn't work.
IF 'START V1.3' is supposed to be seen as serial data, say to a PC, then we need to know the hardware as well.
silelis



Joined: 12 Jun 2007
Posts: 57

View user's profile Send private message

PostPosted: Mon Oct 23, 2017 2:00 pm     Reply with quote

Ok.

So from the beginning.

Software:

main.h
Code:

#include <18F4520.h>
#device ADC=10


#fuses HS,NOWDT,NOPROTECT,NOLVP
#use delay (crystal=20MHz, clock=20MHz,fast_start) //to jest z forum

#use rs232(baud=38400,parity=N,xmit=PIN_b7,rcv=PIN_b6,bits=8,stream=Dbg) //some debugger port (via PICKIT2) it is like display

#define UART_BUFFER_SIZE 35
#use rs232(UART1, baud=57600,parity=N, bits=8,RECEIVE_BUFFER=UART_BUFFER_SIZE, stream=Hrdw, BRGH1OK, errors) //the port where mp3 is connected to


main.c
Code:

#include <main.h>

#define BUFFER_SIZE 251
BYTE buffer[BUFFER_SIZE];
BYTE next_in = 0;
BYTE next_out = 0;
int1 buffer_overflow = FALSE;
int1 int_rda_STATEMENT = FALSE;

#int_rda
void serial_isr() {
   int t;

   buffer[next_in]=fgetc(Hrdw);
   t=next_in;
   next_in=(next_in+1) % BUFFER_SIZE;
   if(next_in==next_out)
   {
     next_in=t;           // Buffer full !!
     buffer_overflow = TRUE;
   }
   int_rda_STATEMENT = TRUE;
     
}

#define bkbhit (next_in!=next_out)

BYTE bgetc() {
   BYTE c;

   while(!bkbhit) ;
   c=buffer[next_out];
   next_out=(next_out+1) % BUFFER_SIZE;
   return(c);
}

#ZERO_RAM
void main()
{

   enable_interrupts(int_rda);
   enable_interrupts(global);
   delay_ms(500);
   fprintf(Dbg,"\r\n\Running...\r\n"); //I always power on mp3 after this command
   
   do {         
         if (int_rda_STATEMENT == TRUE)
         {           
            BYTE TEMP_next_in=next_in;

            delay_ms(100);
            while(TEMP_next_in!=next_in){       //wait till all byte are received       
               TEMP_next_in = next_in;
               delay_ms(100);
            }

            if(buffer_overflow == TRUE)
            {
            buffer_overflow = FALSE;
            fprintf(Dbg, "!!! UART OVERFLOWED, repeat command \r\n");
            }     
           
            fprintf(Dbg, "UART data: ");     // start to write received data
            while(bkbhit)
            {
              fputc(bgetc(), Dbg);
            }
            int_rda_STATEMENT = FALSE;
            fputs("",Dbg); 
           
            next_in = 0;
            next_out = 0;
         }   
   } while (TRUE);
}


The device is simple mp3 is connected to PIC18f4520 via hardware UART pins.

As LLC I use BSS138

And the mp3. I do not have schematics. Only brd:
- eagle brd file
- png file

R12(1kohm)-R14 and R11 (1kohm)-R13 are some kind of voltage divider that developer design but the R14 and R13 (connected to ground) are not soldered so on the UART lines there are R12 and R11 (1kohm).
Ttelmah



Joined: 11 Mar 2010
Posts: 12516

View user's profile Send private message

PostPosted: Mon Oct 23, 2017 2:15 pm     Reply with quote

251.....

No.

Using the code as posted, the buffer size _must_ be a binary size. 2, 4, 8, 16, 32, 64, 128 etc. bytes. It must _not_ be an odd size like 251 bytes.

This has been covered here hundreds of times.

Then you have a second huge problem. You have two interrupt driven buffers cascaded on one another. You cannot do this. You need either to use the buffer supplied with #use RS232, _or_ your own buffer. Not both.
It's inherently give garbage doing this, with the second handler being called after the first, and holding the code inside the interrupt handler while this is done. At reasonably high data rates this is a formula for disaster.
temtronic



Joined: 01 Jul 2010
Posts: 5755
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Mon Oct 23, 2017 3:48 pm     Reply with quote

Eliminate the MP3 device and PIC 'debugger' device for test purposes....

Use Two PCs, one connected to the PIC as 'Hrdw' the other as 'Debug'. That way you've got CONTROL over the data being sent. It is basic hardware troubleshooting, confirming the hardware works as well as the simple PIC serial program.

Until you can confirm this works, do NOT connect the MP3 device.

Jay
silelis



Joined: 12 Jun 2007
Posts: 57

View user's profile Send private message

PostPosted: Mon Oct 23, 2017 11:07 pm     Reply with quote

Ttelmah wrote:
251.....

No.

Using the code as posted, the buffer size _must_ be a binary size. 2, 4, 8, 16, 32, 64, 128 etc. bytes. It must _not_ be an odd size like 251 bytes.

This has been covered here hundreds of times.

Then you have a second huge problem. You have two interrupt driven buffers cascaded on one another. You cannot do this. You need either to use the buffer supplied with #use RS232, _or_ your own buffer. Not both.
It's inherently give garbage doing this, with the second handler being called after the first, and holding the code inside the interrupt handler while this is done. At reasonably high data rates this is a formula for disaster.


Ok. Few explanations.
The uart hardware buffer is "UART_BUFFER_SIZE" which in my code is 35 but I will try with 32 value.

The #BUFFER_SIZE 251 is a value of my software buffer where I rewrite data from hardware buffer. Its value is because of mp3 paskage size.

temtronic wrote:
Eliminate the MP3 device and PIC 'debugger' device for test purposes....

Use Two PCs, one connected to the PIC as 'Hrdw' the other as 'Debug'. That way you've got CONTROL over the data being sent. It is basic hardware troubleshooting, confirming the hardware works as well as the simple PIC serial program.

Until you can confirm this works, do NOT connect the MP3 device.
Jay


The routine works perfectly in this solution (I mean 2 PC uarts). For some reason the problem is only with mp3 device... :/
jeremiah



Joined: 20 Jul 2010
Posts: 966

View user's profile Send private message

PostPosted: Tue Oct 24, 2017 7:16 am     Reply with quote

silelis wrote:

Ok. Few explanations.
The uart hardware buffer is "UART_BUFFER_SIZE" which in my code is 35 but I will try with 32 value.

The #BUFFER_SIZE 251 is a value of my software buffer where I rewrite data from hardware buffer. Its value is because of mp3 paskage size.
/


You are missing what Ttelmah is trying to convey to you. Two separate issues:

1. Your
Code:

#define BUFFER_SIZE 251


Should be changed to a power of 2 such as 256. Why? Well it boils down to how CCS implemented the ISR. Take a look at this line in the ISR:
Code:

next_in=(next_in+1) % BUFFER_SIZE;


The use of the % (modulus) operator invokes a divide. This operation is extremely costly, especially if on a chip with no hardware divide. Even on chips that do have hardware divide it takes at 19 cycles (PIC24's/dsPICs).

However, if BUFFER_SIZE is a power of 2, then the % operation doesn't require a divide and is optimized to just an AND operation (1-2 cycles). This is less of an issue in main code, but in an ISR, you don't want to stay in it long.

2. You correctly tried using the ex_stisr.c as suggested, but while doing so you left the following line incorrectly:
Code:

#use rs232(UART1, baud=57600,parity=N, bits=8,RECEIVE_BUFFER=UART_BUFFER_SIZE, stream=Hrdw, BRGH1OK, errors)


The problem here is you are already supplying your own buffer (the ex_stisr.c code) AND you are asking CCS to supply a buffer. The two buffers together will produced either undefined or implementation defined behavior. What this means is even if it is working right now, it might cease to work as you modify your code or if you ever upgrade the compiler. You might change some of your code that involves the serial and the buffer stops working correctly. You say the errors start when you add in the mp3 serial code. It could be related to your use of the double buffering. To fix, change the line to:

Code:

#use rs232(UART1, baud=57600,parity=N, bits=8, stream=Hrdw, BRGH1OK, errors)


And actually try
Code:

#use rs232(UART1, baud=57600,parity=N, bits=8, stream=Hrdw, errors)


It is very rare to need to specify BRGH10K. If you do truly need to specify, then do so, but try it without first.

As a side note, temtronic is spot on with his advice. He isn't telling you to go to just one stream, he is saying keep two streams, but don't use the mp3 as one of them, switch it to some debug serial out so you can test and modify the code to be working both ends (and it is easier to verify both ends).

Finally, I haven't read through all the previous parts of the thread, have you used a scope and a simply LED toggle code to verify that your clock setup is being used by the compiler correctly?

I generally do a small test on my board:
Code:

#include <18F4520.h>
#device ADC=10


#fuses HS,NOWDT,NOPROTECT,NOLVP
#use delay (crystal=20MHz, clock=20MHz,fast_start) //to jest z forum

void main(void){
   while(TRUE){
      output_toggle(SOME_IO_LINE);
      delay_ms(500);
   }
}


Then you measure it on a scope to ensure it truly is a 1Hz square wave. If it is off enough, it will cause garbage characters on serial for certain baud rates (which baud rates depends on how off it is).

If it indeed works without the MP3 device as you say but then fails when the MP3 device is plugged in, then you might simply be seeing that the mp3 device is not at the baud rate you think it is.
Ttelmah



Joined: 11 Mar 2010
Posts: 12516

View user's profile Send private message

PostPosted: Tue Oct 24, 2017 11:23 am     Reply with quote

Also, the buffer pointers are int8's, so you can't use 256 as written.
The buffer though doesn't wan't/need to match the size of the data arriving. You make your buffer _bigger_ than the maximum amount you may ever fall behind the incoming data. So with GPRS strings that are 27, 30 or 34 bytes, you might well use a 64 byte buffer.
jeremiah



Joined: 20 Jul 2010
Posts: 966

View user's profile Send private message

PostPosted: Tue Oct 24, 2017 11:45 am     Reply with quote

Good catch. I'm used to the PIC24's where the default size is 16 bits.
Ttelmah



Joined: 11 Mar 2010
Posts: 12516

View user's profile Send private message

PostPosted: Tue Oct 24, 2017 1:17 pm     Reply with quote

and also (of course), though the buffer needs to be larger than the amount the code may fall behind the arriving data, in general it never needs to hold the entire packet.
Most packets are better handled 'on the fly', with you looking at the arriving data for keywords or particular markers and then knowing where to put the things that follow.
silelis



Joined: 12 Jun 2007
Posts: 57

View user's profile Send private message

PostPosted: Fri Oct 27, 2017 11:20 am     Reply with quote

I have made every code corrections as You advised.

Any other suggestions?

Code works perfectly with 57600 on FT232 communication but don't work with this mp3.

Alco mp3 communicates perfectly with FT232 with 57600. :///
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Goto page Previous  1, 2, 3
Page 3 of 3

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group