 |
 |
| View previous topic :: View next topic |
| Author |
Message |
Ttelmah
Joined: 11 Mar 2010
Posts: 19535
|
|
 Posted: Tue Oct 10, 2017 1:25 am |
 |
|
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: 68
Location: Poland, podlaskie district
|
|
| Posted: Tue Oct 10, 2017 5:56 am |
|
|
| The au7860 chip is Chinese but used by me brick is working and delivered by Polish developer. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19535
|
|
| Posted: Tue Oct 10, 2017 6:26 am |
|
|
| So ask the Polish developer for some better data. |
|
|
silelis
Joined: 12 Jun 2007
Posts: 68
Location: Poland, podlaskie district
|
|
| Posted: Tue Oct 10, 2017 6:35 am |
|
|
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: 68
Location: Poland, podlaskie district
|
|
| Posted: Mon Oct 23, 2017 12:53 pm |
|
|
Hello once again,
I have tested it with BSS138 LLC and 14.7456 MHz crystal.
With this crystal even worse because the answer is:
For #use delay (crystal=14.7456MHz, clock=58.9824MHz), answer is:
For #use delay (crystal=12MHz, clock=48MHz,fast_start), answer is:
And it should be "START v1.3".
The result is still the same. Any ideas?? |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9241
Location: Greensville,Ontario
|
|
| Posted: Mon Oct 23, 2017 1:39 pm |
|
|
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: 68
Location: Poland, podlaskie district
|
|
| Posted: Mon Oct 23, 2017 2:00 pm |
|
|
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: 19535
|
|
| Posted: Mon Oct 23, 2017 2:15 pm |
|
|
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: 9241
Location: Greensville,Ontario
|
|
| Posted: Mon Oct 23, 2017 3:48 pm |
|
|
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: 68
Location: Poland, podlaskie district
|
|
| Posted: Mon Oct 23, 2017 11:07 pm |
|
|
| 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: 1353
|
|
| Posted: Tue Oct 24, 2017 7:16 am |
|
|
| 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: 19535
|
|
| Posted: Tue Oct 24, 2017 11:23 am |
|
|
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: 1353
|
|
| Posted: Tue Oct 24, 2017 11:45 am |
|
|
| Good catch. I'm used to the PIC24's where the default size is 16 bits. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19535
|
|
| Posted: Tue Oct 24, 2017 1:17 pm |
|
|
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: 68
Location: Poland, podlaskie district
|
|
| Posted: Fri Oct 27, 2017 11:20 am |
|
|
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. :/// |
|
|
|
|
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
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
