Posts by christian.moll


    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


    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

    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

    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 to convert the PCM to 16kHz µlaw.

    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 Micha,

    okay found the problem. I was not started with fresh sources in the last attempt from yesterday. There were the lines

    1. //Baudrate bug
    2. if(port->line == 0 && (rd_regl(port, S3C2410_UBRDIV) >= 0x1B1)) {
    3. udelay(500);
    4. }

    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.



    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


    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...


    Case 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.


    So 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?

    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


    /* 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.

    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

    With setserial -a I get:


    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