#oggstreamer – Release of OggStreamerSDK-RC1

here is the release of the OggStreamerSDK-RC1 – for the first time we are able to have a whole integrated SDK which supplies all the Files / Applications needed for the complete OggStreamer Firmware.

If you want to experiment yourself I put together the info on the Wiki:

OggStremaer SDK RC1

Note it is RC1 and still has a number of flaws, please have a look at our ticketsystem:

RC1 Flaws Tickets

happy OggStreamer – hacking 😉

#oggstreamer – BETA 1 Released

Hi out there here is the Release of BETA 1 Software:

BETA 1 Introduces the following enhancements:

• WebGUI for Configuration
• autoreconnect for IceCast2
• Integration in the OggStreamer SDK
• Title, Description and Genre Options for IceCast2
• stm8flash (update the STM8 Firmware directly)
• In Setup-Mode Password is now defaulted to “PASS”
• optional Two Stage Mode (STOP/STREAM) instead of (STOP/MONITOR/STREAM)

The Java-Player is not installed anymore.

I put update instructions on the wiki if you want to update your OggStreamer to BETA 1. I only recommend this for persons with solid linux skills.

#oggstreamer – Linux SDK

I just finished the Integration of the OggStremear specific libaries and applications to the Lantronix XPortPro Linux SDK. Follow the instruction on the wiki if you want to install the SDK yourself.

Note that future updates of the SDK will most likely happen directly in the coresponding git repositories. The wiki also describes how to integrate the oggstreamer git repos to the build process.

#oggstreamer – WebGUIs first steps

A friend of mine together with is brother coded the WebGUI. It is a C-Programm running as a CGI on top of a webbrowser. It works with boa but this server lacks Authentification and SSL in its unpatched version – although there are patches for auth, SSL would require a sperate programm to tunnel the HTTPS requests. So I searched for alternative Webbrowsers – mongoose and hiawatha  seemed to be the most promising alternatives – unfortunately integrating this servers into the Lantronix XportPRO SDK is a bit of work. Then I found out that the axhttpd from the axTSL package ships already in the SDK. I tried this but i had to notice that the version shipped with the SDK has broken .htpasswd support. So this issue is not resolved yet but I think I will update the SDK to a newer axTSL Version …. tomorrow – This work of choosing and getting a Webserver running on this Platform is quite a pain –  ¡qué rollo! – I wish Lantronix had integrated a working solution for this kind of problem in their SDK …

So for now lets stick with a screen shot how the WebGUI looks like:

#oggstreamer – STM8 Firmware compiles with SDCC

Yesterday sdcc (version #8699) produced a first useable Firmware for the STM8 uC used in the OggStreamer – it still needs some testing but it is feaseable that we can use sdcc as OpenSource compiler for the stm8.

#oggstreamer – OpenSource Compiler for STM8 called SDCC

I happily follow the progress of SDCC starting to support the STM8 Family of microcontrollers. SDCC is a compiler targeting smaller uCs like 8051, Z80, HC08, PIC and recently there was progress porting the compiler to STM8. It is currently only available in the snapshots. I tried compiling the OggStreamer’s STM8-Firmware with SDCC and after some fiddling around the code it compiled – but it doesn’t work at the moment. So I decided to do something less complex and I took portions of the original sources and modified them to run a simple LED Test, which nevertheless already uses a Timer Interrupt and does some lowlevel initialization.

As we now have an OpenSource alternative for the STM8-Compiler I will be able to create one complete OggStreamer SDK.

The impressive result are some blinking LEDs: (SDCC Version #8680)

#oggstreamer – STM8 UART Flasher for Linux

I just completed a rough Version 0.3 of stm8flash – a handy little tool that allows you to programm a STM8 over a serial uart interface (using the STM8 internal bootloader)

The software is based upon stm32flash written by Geoffrey McRae – many thanks to you that way. STM is using a similar Bootloader-Protocol for the STM32s and STM8s which made porting the flashertool not so difficult.

The stm8flash can be downloaded via sourceforge. It works as desired for my 32K STM8S105 device. But it is only designed to work with 32K devices so far. Also it is currently using the so-called “Reply” Mode, which is available on STM8A-128K, STM8S-32K, STM8S-128K and STM8L-64K. If you want to use this tool in non reply mode, then take a look at stm8.c and search for “REPLY” – it should be fairly easy to adapted to the other devices as well.

stm8flash also introduces a new flag “-d”, which stands for using the DTR-Line to trigger a device reset. (Arduino-Style 😉 )

Maybe in future somebody could try to merge stm32flash and stm8flash as the share a lot of common code.
What was really helpful for debugging the code and get the thing running, was a SALEAE Logic-Analyzer (with Software RS-232 decode functionality). It is definitely a powerful tool for such tasks.

Further this step just marks the first Milestone for the ongoing NetIdee-Project. 🙂

#oggstreamer – restore system state after powerfail

Here are my thoughts on how to utilise the EEPROM for storing the system state. The main Idea behind the following “algorithm” is that we record the numbers of how often the button is pressed. Further we use a Power Cycle ID (short PCID) and a cyclic buffer to store the state.

The PCID is incremented (+1 mod 256) everytime the device is powered up. Due to the mod 256 The PCID ranges from 0 to 255 and after 255 starts again at 0.

The cyclic buffer holds 254 bytes and the buffer pointer is incremented (+1 mod 255) everytime when a byte is written.

What now happens it that everytime we press the button (remark this presented algorithm only works for devices with one button) we write the PCID at the pointer of the cyclic buffer. Additionally the PCID is also written everytime the device is powered up.

I will give now an example with an reduced 15 bytes buffer:

0,1,1,2,2,2,3,3,3,3,4,5,6,7,8

so what story does this buffer tells us, well
at first power up there was no button pressed – at 2nd the button was pressed one time, at 3rd two times, at 4th 3 times – then the device was powered up 5 times without a pressed button.

By reading the cyclic buffer we also find out what the last PCID was. In our case 8 was the last PCID, because 8 > 0 – we further have carefully choosen our cyclic buffer to be 254 bytes long – so even if we warp around from 256 to 0 we (at worst case) have possibility to obain the last PCID because the difference hast to be greater or equal to two.

PCID = x[i] where (x[i mod 255] – x[(i + 1) mod 255]) mod 256 >= 2

In this way we can determin our last PCID and we also know how often the button was pressed before the last power cycle and therefore we can restore our system state.

As our buffer holds 254 bytes and we have assured 300 000 writecycles in our EEPROM – this translates to apr. 76 Mio button activations. – way more than the mechanics of the button would be able to handle. UPDATE: looking in the STM8 Datasheet it shows that we have a stoarage granularity of 4 Bytes. – this needs to be taken into account when implementing the cyclic buffer (for example to blow up the buffer from 255 bytes up to 1020 bytes)

#oggstreamer – patch for correct 44100, 22050 and 11025 samplerate

I just implemented a feature for the STM8 firmware to allow the usage of Patches for the Audio DSP – provided by VLSI.

It is known that in its unpatched state the VS1063 has some sligtly samplerate issues with 44100, 22050, and 11025 samplerates (about 2% 0,23% Error) – VLSI published a patch to overcome this issue. This is now integrated in the stm8 firmware. More specifically the patch from the .plg File is stored at Offset 0xa006. At 0xa000 the Firmware is looking for the Magicstring “VlSi” and at 0xa004 the size of the patch in words is stored.

If you ever wondered what endianness is used to store larger than 8bit values on the STM8 I can tell you that using the IAR compiler the STM8 is Big Endian.

I also observed some strange behaviour with the OggStreamer Hardware loading the patch sometimes pushed the VS1063 into a deadlock (DREQ-Line was hold low) – for more infos check the vsdsp-forum.

There are already some OggStreamers out in the wild – to update these devices without disassembling and reprogramming them with an ST-Link the stm8flasher tool is needed, which is already in the pipeline.

With this update it will be possible to do pitch-correct streaming for all datarates (8000, 11025, 16000, 22050, 24000, 32000, 44100 and 48000)

#oggstreamer – uC STM8 flasher, sighttpd MaxListeners

Lately there was not very much progress going on at this project. A couple of OggStreamers are out in the wild and doing their job.

On the Software-Side: I adjusted sighttpd – to add a MaxListeners-Feature. This allows to limit the number of clients – so that the Server rejects Clients instead of going into Denial of Service. You can find the patch in the repository. I hope that this patch once tested could find its way back into the sighttpd mainline.

Further I came across the great stm32flash application. This is a flasher application for the internal Bootloader for the STM32 series. I would need exactly that for the STM8 series. Fortunately those two series have a very similar bootloader protocol. I forked the stm32flash to work on a stm8flash application – but it is currently not working. It would be great for the future if the stm32flash and stm8flash application could merge together.