Archive for the ‘software’ Category

Dynatek 6080RS serial spec

Wednesday, August 3rd, 2011

Since the readme.doc of the Dynatek 6080RS multimeter came on a diskette (yes the thing is ancient) and its serial communication protocol is non existent on the net, I thought I’d make a little contribution to humanity ;) I’ve been searching for months and only today ran into the diskette again (and to my surprise the diskette was still functioning perfectly! Should have bought a lottery ticket instead =)). Made a quick pdf with layout and corrected spelling. Who knows it’s useful to anyone else.

Dynatec 6080RS serial spec

US export regulations

Wednesday, April 20th, 2011

Going to play around with a Coolrunner-II CPLD so I thought it would be a good idea to get Xilinx’ free ISE WebPACK. Guess what, that was a bad idea. The US wants my home address and phone number:

US export regulations require that your First Name, Last Name, Company Name and Shipping Address be verified before Xilinx can fulfill your request. Please provide accurate and complete information for immediate processing. Sorry, addresses with Post Office Boxes and names/addresses with Non-Roman Characters with accents such as grave, tilde or colon are not supported by US export compliance systems.

Fucking nazis…. No way I’ll give them the requested info. Hell they already monitor my bank transactions (do they really think any half decent terrorist uses the ‘system’ and risk a big fat red flag behind their name!?). Filling in bogus info does the trick just fine ;)

On a related matter, Mouser does not sell Xilinx products. Looks like an alternative CPLD is needed for any future development.

Lots-o-markers

Saturday, April 2nd, 2011

Lots-o-markers (sorry no fancy visual thing… can’t insert a map in WordPress?)

Just a 5 minute experiment to see what our public transport peeps have been up to. Seems they opened up their data through an XML based API. Besides it’s a good excuse to take a quick look at Google Maps’ API.

Should ATI still burn in hell? Very likely so!

Sunday, February 27th, 2011

There’s probably a week’s worth of ranting about ATI’s and NVIDIA’s proprietary gfx card drivers, but for now I’m keeping it short. A short introduction is in order. Years ago I knew exactly which card was needed to get the best performance. It took time reading up and keeping up-to-date with all the latest developments. Since then my interests changed from knowing the exact details to something along these lines: I don’t care how it works as long as it works as you can reasonably expect (and I expect a lot by default. If you can’t deliver a decent piece of hardware, software or service, please do the world a favor and burn down your company as quickly as you can. Stopping myself here, as this is also one of those subjects I can go on about for days).

Anywaaaay… all those years ago I bought ATI gfx cards for the simple reason that they were the fastest. Not that you’d ever notice this in a real life usage, but synthetic benchmarks ruled. But as you know a decent piece of hardware is only half the story. So imagine you’ve got this sexy (the nerdy kind of sexy, not the erotic variant) piece of hardware lying in front of you, you wipe the drool of you chin, you plug it in and boot the latest Linux kernel. Next is installing ATI’s latest driver only to discover you’ve ended up in hell. It may have been years ago, but my mind still bears the scars of agony and frustration… hours on end. For this alone ATI deserves to burn in hell for all eternity (which is a pretty pointless thought if you don’t believe in heaven and hell (but the creation of an artificial hell would be most welcome. We could stuff all those greedy corporate bastards there. Maybe even a webcam and some running man style show for our entertainment to watch (which in turn we would watch via networks run by the same corporate bastards and thus negating the entire idea… anywaaaaay :)))).

Long story short I swore never to use ATI again. Since that time I’ve switched to NVIDIA on systems that required high performance 3D and embedded Intel for everything else. While NVIDIA cards also come with a proprietary driver, their installation process was (or is) much less frustrating. Intel on the other hand sucks for 3D, but just works for everything else. For non-gaming purposes, Intel is a blessing and I can highly recommend it if you don’t want to fiddle around. Now fast forward to 2 weeks ago when I ordered the MicroServer. Never thought of the ATI horror and focused on a card that fit and satisfies the max power limitation (25W for the PCIe x16 slot). And from what I’ve read ATI’s Linux support is still something to cry about. Don’t care about 3D, but for HTPC usage hardware decoding support is more or less mandatory.

So when all components have arrived I’ll be attempting to get a Radeon HD 5450 GPU up and running. This GPU has an UVD2 video engine (UVD = Unified Video Decoder) and uses the XvBA (X-Video Bitstream Acceleration) API. The UVD 2 engine features full bitstream decoding of H.264/MPEG-4 AVC, VC-1 and MPEG2 video streams. If rumours are correct it sucks balls compared to NVIDIA’s Video Decode and Presentation API for Unix (VDPAU). Rumour also has it that this proprietary crap has to do with DRM. Just as you think your hatred of a certain technology can’t get any deeper, it does. In any case I’m already preparing for some torture and if all else fails I’m just gonna get a GeForce G 210 or GT 220 card (only realistic options considering the 25W PCIe limitation).

Btw, anyone else thinks writing your entire company name in capital letters makes you think of sad 16 year olds screaming for attention on the net?

Wake up Keil

Sunday, November 21st, 2010

“Security is a concern of all on-line consumers”… apparently not for Keil… Not exactly something you’d want to see from a company who’s ARM development suite costs over €4000.

Software HDCP encryption/decryption

Friday, October 1st, 2010

In the wake of the HDCP master key floating around on the net comes the first software implementation. Check the link for sourcecode and details.

HDCP Encryption/Decryption Code

Another milestone reached

Sunday, September 12th, 2010

Good news, SDIO is working, including an upgrade from Petit FatFs to FatFs.

Basically there were 2 problems. Some time ago I ripped some stuff from the breadboard to tidy things up a bit. Unfortunately this included a wire connecting the PSU to the right most power rail. As fate would have it this is where I attached the 3,3V of the SD card socket to a few days later. As long as the missing connection was well.. missing, the SD card was powered by the SDIO signal lines through the pull-up resistors. This resulted in unexplainable behaviour such a Kinston card to timeout at CMD8 and a Sandisk card never completing the voltage validation cycle.

The other thing were CRC errors during transfers. 25 MHz is simply too much for the current setup, which in all honesty isn’t really surprising given the long and poor connections. A real PCB and some pull-up resistor tweaking should make a speed increase possible. Currently it’s running at 4,2 MHz (simply because 0x0F is an easy to remember CLKDIV value ;)), but what this means in data throughput numbers… no idea yet.

Oh and it uses DMA, which also is a nice addition!

Hmmmz…

Sunday, September 5th, 2010

… It seems I must revise my post about the MCD Application Team. The more I get into the dirty SDIO details, the more their code starts to make sense. Also going from SPI to SDIO makes things a bit more complex, such as addressing the right card and querying the card for wide bus support.

Tsk tsk tsk MCD Application Team

Friday, September 3rd, 2010

Working hard on getting SDIO and FatFS up and running. Steadily making progress, but it’s not quite there yet. In the meantime I just want to give anyone else attempting this a minor note of warning – to get started quickly I looked at the SDIO example that comes with STM32′s peripheral lib, but quickly threw it out because the code is confusing.

I’m using the “Physical Layer Simplified Specification Version 2.00″ spec as a guideline on how to communicate with SD cards and it clearly outlines various states and which commands can supposed to be executed during those states.

What the MCD Application Team (a.k.a. the team behind STM32 code provided through ST’s website) has done is mix card states and even operating modes. For example placing Transfer State commands in the same function as Identification State code. While this can function perfectly fine, it does not correspond with the SD card spec making it not very logical to read. Could be quicker to just start from scratch ;)

And because I love diagrams:

Practical STM32 differences compared to AVR

Saturday, August 28th, 2010

I’ve been playing with the STM32 header board for a while now, so today I’d like to write about some practical differences between the STM32 and AVR. At first I wanted to use Cortex-M3 instead of STM32, but that wouldn’t be correct since the Cortex-M3 is only the core, while the peripherals is where most of the practical differences lie. Also note I’m talking about programming using C/C++, not assembly.

Clock signals

On an AVR you can simply set/clear a bit in the appropriate register to make a GPIO pin high or low. Not so on the STM32. While the concept of setting a bit remains the same (there are differences such as atomic write access, but you won’t notice those during normal usage), the difference is that they won’t do anything until you enable the corresponding peripheral. Before going any further take a look at the system architecture diagram:

As you can see in this diagram the STM32 has a couple of busses; an AHB and 2 APB busses. Each peripheral is connected to one of those busses and will only do something if it gets a clock signal. After a reset all clocks are disabled, including the system clock (please look up CMSIS’ SystemInit() function for info on enabling the Embedded Flash Interface, the PLL and SystemCoreClock). Before using a peripheral look up which bus it is connected to and set the corresponding bit in the RCC register to enable its clock signal. If for example you want to use GPIOA, you need to set the IOPAEN bit in the RCC_APB2ENR register. Another GPIO difference is that you must choose between 3 speeds; 2MHz, 10MHz or 50MHz.

But that’s not all concerning clock signals. Peripherals such as USARTs and SPI are mapped to the same pins as GPIO pins. Even though you can not use both at the same time, the GPIO pins have to be initialised as usual (clock enabled, input/output, speed and mode (floating/push-pull/etc)) as used by the used peripheral. On top of that you get clocks for the alternate function and the peripheral itself. That’s 3 clock signals total which all have to be enabled.

Shift registers

Another issue I ran into was the use of shift registers. Peripherals such as USART and SPI only have a data register on the AVR. Just write a byte to it and the AVR blocks until the byte is transmitted. The STM32 takes a slightly different approach. You write data to the data register which is blocking. Next the data is moved into a shift register for transmission and execution continues.

In reality this means that your code continues and for example deactivates the chip select signal of some other IC (e.g. the audio decoder in case of the music player) while data is still being transmitted. The result is a partial reception of the data and nothing happens. The solution is to wait for a status bit to clear before deactivating any chip select signal (in case of SPI; the BSY bit in the SPI_SR register as seen in the above diagram).

That’s it for now.