Hello,
thank you for providing the document.
Best Christian
Posts by christian.moll
-
-
Hello,
as it is Friday now I like to ask to give at least any feedback to my questions. No feedback implies to me that the PicoCom4 is not RoHS compliant at all.
Christian Moll
-
Hello,
I am searching the F&S page for the RoHS compliance for PicoCom4 modules, but can't find anything.
Can you please provide it to us, as without it is quiet hard to do a serious CE certification for a medical product.Sincerely yours,
Christian Moll
-
Hello again,
as we use the pins used by the SD card interface of the picocom4 for enabling some sub-modules it would be nice to have a version of nboot that doesn't toggle or pull-up these pins.
They are pulled down by resistors but are toggled during boot time. After about 500ms the patched uboot pulls them down again. But the 500ms are not helping for our application.Best Christian Moll
-
Hello,
we did some more research on that problem and found a strange block in sound/soc/samsung/s3c24xx_picocom4.c which is obviously a copy of sound/soc/samsung/s3c24xx_simtec.c
Display MoreCode- switch (params_format(params)) {
- case SNDRV_PCM_FORMAT_S8:
- bfs = 16;
- rfs = 256;
- break;
- case SNDRV_PCM_FORMAT_S16_LE:
- bfs = 32;
- rfs = 256;
- break;
- case SNDRV_PCM_FORMAT_S18_3LE:
- case SNDRV_PCM_FORMAT_S20_3LE:
- case SNDRV_PCM_FORMAT_S24_LE:
- bfs = 48;
- rfs = 512;
- break;
- default:
- return -EINVAL;
- }
- switch (params_rate(params)) {
- case 8000:
- case 11025:
- case 16000:
- case 22050:
- return -EINVAL;
- case 32000:
- psr = 7; //5
- break;
- case 44100:
- psr = 7; //5
- break;
- case 48000:
- psr = 7; //3
- break;
- case 64000:
- case 88200:
- case 96000:
- return -EINVAL;
- default:
- return -EINVAL;
- }
could this be the reason for the problem? How to determine a prescaler (psr) for low kHz sampling rates?
Sorry but this problem could be a show stopper for our product. BTW 8kHz worked fine on the picocom2.Best Christian
-
Hello,
any news how to play a 8kHz PCM or µ-law file with aplay? We can't find out why it doesn't playback on our system.
A sample file is very appreciated.Best Christian
-
It is a very nice codec for voice output. We decided to use it because we started our development on picocom2 with 32MB of flash. And our device is voice guided in several languages. So it was nice that we can compress the PCM up to 1:20 and more.
The other problem is that we use Java on our device and there is no direct access to amixer to change volume, so we scale the signal sending to a named pipe. And the named pipe is playbacked by aplay. But I was not able to convert a PCM or µlaw to something with less than 44100Hz played by aplay.
We convert with sox, e.g. sox welcome-message.wav -t au -r 16000 -e mu-law test.au to convert the PCM to 16kHz µlaw.
Display MoreCode- aplay test.au
- Playing Sparc Audio 'test.au' : Mu-Law, Rate 16000 Hz, Mono
- aplay: set_params:1166: Unable to install hw params:
- ACCESS: RW_INTERLEAVED
- FORMAT: MU_LAW
- SUBFORMAT: STD
- SAMPLE_BITS: 8
- FRAME_BITS: 8
- CHANNELS: 1
- RATE: 16000
- PERIOD_TIME: 125000
- PERIOD_SIZE: 2000
- PERIOD_BYTES: 2000
- PERIODS: 4
- BUFFER_TIME: 500000
- BUFFER_SIZE: 8000
- BUFFER_BYTES: 8000
- TICK_TIME: 0
Can you provide a wav file with less than 44100Hz?
Best Christian
-
Hello again,
is it possible to play sounds in aplay, (or any other player) that are µlaw coded or pcm, with less than 44100Hz? We are struggling with performance problems as there are some other tasks beside the audio output.
Best Christian
-
Hello,
is there any possibility to test the RAM and Flash?
Thanks in advance
Christian Moll
-
Hello Micha,
okay found the problem. I was not started with fresh sources in the last attempt from yesterday. There were the lines
commented. I managed to do all the patches necessary to run our capacitive touch and display and it seams to run now without a flair.
Thanks for your help.
Christian
-
Hello,
something is different on the two systems. I have done the hole thing today two times with different PicoCOM4 boards. Both have the the buildroot and uboot 1.4 installed. Everything is default.
Kernel is patched as you described and the inittab is edited. in init.d I removed the S01fssetup.I tested on first board without telnet and with it. But I guess it is only for remote access, I normally use the ssh server that is already running.
If I do so the ttySAC1 doesn't speak at all independent of the set speed. ttySAC0 is working as expected.
Interesting is that I can run the simpleserial example two times the third time it hangs on closing the interface. I expect its buffer is full or something like that.Maybe you can send me your Kernel Image and I can test it.
Best Christian
-
Hi,
is this issue closed for F&S or can we hope for a solution?
Sincerely yours
Christian Moll
-
Hello,
thanks for the patch. I applied it, but didn't made it better. The ttySAC0 doesn't talk at all now. Openening and setting baud in terminos still gives the right answers, but the test message is now not send and simpleserial example doesn't close the port any more.
On ttySAC1 is sending data out, but the closing of the port hangs the simpleserial example too.
Any educated guess?
Christian Moll
-
Seams so.
I repeated the hole experiment.
1. new PicoCOM4
2. I installed the 1.4 Kernel provided by F&S
3. I installed the buildrootFS 1.4 provided by F&S
4. set root password to access by ssh, deleted S99.. S35... and S01fs... scripts in /etc/init.d
5. changed bootargs console to console=tty0
6. commented out the the getty line in /etc/inittab. (removed it to be sure it has not a side effect)
7. reboot the system and executed the simpleserial example. See source code below...QuoteCase 2: You don't set "console=ttySAC1,sss" in U-Boot
Then the kernel will not open the serial console and in V1.4 there will also be no getty on the serial port. So the speed of ttySAC1 will remain at the default speed, i.e. the speed set in U-Boot.
The example states that the baud rate was 9600! In the u-boot the baud is set to 38400!
The example also states that the speed is set to 115200bps, and writes "Testmessage" to the port.
I record this "Testmessage" with a logic-analyzer. It has some nice protocol analysis features like determine the baud rate and what data where in the stream.
It says the speed is ~38400bps and the Message was "Testmessage". If I set it to 1115200bps it only gets crap as incoming message.As you can see below the port is set to 115200 8N1.
QuoteSo using a serial port is always:
1. open the port --> fopen(...)
2. set transfer speed and other transmission parameters --> initport(...)
3. use the port-->write(...)
4. close the port-->close(...)Looks like the example is doing as you described.
To summarize.
1. Buad rate set in u-boot doesn't have an effect on default baud rate when console=<virtual console> is set in bootargs. Terminos claims that it is 9600 on first open.
2. Setting baud rate with terminos claims the right buad is set, but in real it stays on the rate set in u-boot.If I repeat the experiment with a different baud rate set in u-boot. That baud rate will be the measured value by the logic analyzer.
So why is the the speed not set? Why is the first speed read out of the port 9600 and not the one from the u-boot?
Display MoreC- /* ser.c
- */
- #include <stdio.h> /* Standard input/output definitions */
- #include <string.h> /* String function definitions */
- #include <unistd.h> /* UNIX standard function definitions */
- #include <fcntl.h> /* File control definitions */
- #include <termios.h> /* POSIX terminal control definitions */
- int getbaud(int fd) {
- struct termios termAttr;
- int inputSpeed = -1;
- speed_t baudRate;
- tcgetattr(fd, &termAttr);
- /* Get the input speed. */
- baudRate = cfgetispeed(&termAttr);
- switch (baudRate) {
- case B0: inputSpeed = 0; break;
- case B50: inputSpeed = 50; break;
- case B110: inputSpeed = 110; break;
- case B134: inputSpeed = 134; break;
- case B150: inputSpeed = 150; break;
- case B200: inputSpeed = 200; break;
- case B300: inputSpeed = 300; break;
- case B600: inputSpeed = 600; break;
- case B1200: inputSpeed = 1200; break;
- case B1800: inputSpeed = 1800; break;
- case B2400: inputSpeed = 2400; break;
- case B4800: inputSpeed = 4800; break;
- case B9600: inputSpeed = 9600; break;
- case B19200: inputSpeed = 19200; break;
- case B38400: inputSpeed = 38400; break;
- case B115200: inputSpeed = 115200; break;
- }
- return inputSpeed;
- }
- int initport(int fd) {
- struct termios options;
- // Get the current options for the port...
- tcgetattr(fd, &options);
- // Set the baud rates to 19200...
- cfsetispeed(&options, B115200);
- cfsetospeed(&options, B115200);
- // Enable the receiver and set local mode...
- options.c_cflag |= (CLOCAL | CREAD);
- options.c_cflag &= ~PARENB;
- options.c_cflag &= ~CSTOPB;
- options.c_cflag &= ~CSIZE;
- options.c_cflag |= CS8;
- // Set the new options for the port...
- tcsetattr(fd, TCSAFLUSH, &options); //TCSANOW
- return 1;
- }
- int main(int argc, char **argv) {
- int fd=-1;
- int ret=-1;
- //char sResult[254];
- char text[] = "Testmessage";
- fd = open("/dev/ttySAC1", O_RDWR | O_NOCTTY | O_NONBLOCK | O_SYNC);
- if (fd == -1) {
- perror("open_port: Unable to open /dev/ttySAC1 - ");
- return 1;
- }
- else {
- fcntl(fd, F_SETFL, 0);
- }
- printf("baud=%d \n", getbaud(fd));
- initport(fd);
- printf("baud=%d \n", getbaud(fd));
- ret = write(fd,text,11);
- printf("wrote %u bytes \n",ret);
- printf("reading from port...\n");
- /*ret = read(fd, &sResult, sizeof(sResult));
- sResult[ret-1] = 0x00;
- printf("read %u bytes from port. Message is %s\n", ret, sResult);
- */
- close(fd);
- return 0;
- }
-
Did some more research on the problem.
When I change
#define CONFIG_BAUDRATE 57600
in the picocom4.h of the uboot 1.4 sources.I have the baud rate of ttySAC1 afterwards on 57600 (also checked this by the logic analyzer)
Then I found a interesting comment in the file mach-picocom4.c of the Kernel
Quote/* UART1 is the debug port and it is already configured by the boot
loader U-Boot/NBoot; nothing to do here */looks for me that the console I set in the bootargs is not respected in total. In my understanding it should close the serial port I use to access the uboot and open the device I specified in the bootargs with the given speed. And the device not used for the console should be fully usable after Kernel is up.
-
That is clear to me. I use the simpleserial example to set the speed, write and read to the port. But when sniffing on the port I get always 38.4kbps independent from the speed I set in the example.
-
Thanks for your reply.
I redirected the kernel console to /dev/tty0 (no speed specified) by console=/dev/tty0
And disabled the framebuffer console support in the Kernel.
I commented the getty call in inittab.
I didn't change anything for the uboot.
I set the speed with the simpleserial example. Once to B19200 and once to B115200 (which I added to the switch case statement).When sniffing on the serial line with a logic analyzer I always get 38400 as a result for the outgoing stream.
Is it really necessary to change the speed on all stages? My understanding was that I only have to redirect the kernel console and set the speed I like to have via terminos API.Any idea?
Christian Moll
P.S.
With setserial -a I get:QuoteDisplay More
# setserial -a /dev/ttySAC0
/dev/ttySAC0, Line 0, UART: undefined, Port: 0x0000, IRQ: 70
Baud_base: 0, close_delay: 50, divisor: 0
closing_wait: 3000
Flags: spd_normal# setserial -a /dev/ttySAC1
/dev/ttySAC1, Line 1, UART: undefined, Port: 0x0000, IRQ: 73
Baud_base: 0, close_delay: 50, divisor: 0
closing_wait: 3000
Flags: spd_normal -
Hi,
we use the PicoCOM4 with a self compiled version of the latest 1.4 Kernel. And run now in the problem that the port ttySAC1 seams not to run on the right baud rate. I changed the serial example to cfsetispeed(&options, B115200);
cfsetospeed(&options, B115200);where case B115200: inputSpeed = 115200; break;
after opening the port I send known data to the port but only get crap. For control I read the stream with a logic analyzer in parallel. These data is correct. I notized that the logic analyzer determined the baud rate of some packages I send from the ttySAC1 to the test device is only 39215 bps.
Any idea where this behaviour comes from? I suspected the serial console in the kernel parameters, but redirecting the console to tty0 doesn't change anything.
Sincerely yours
Christian Moll
-
Hello,
yes this solved the problem. Thanks for the assistance.
Christian Moll
-
Hello,
just tried the patch, but I now become the error:
In .config it is commented CONFIG_TOUCHSCREEN_S3C2410
