Robert Mugabe and ZANU-PF must go by force

BastardIt is long overdue for Robert Mugabe and his gang of thieves and crooks. He must go. They have wrecked what was once called “a jewel in Africa” (Julius Nyerere). Zimbabwe used to be a shining example of progress. It has become a cesspool of lawlessness, violence, hate and indiscriminate abuse of power.

 

Many people have advocated that Mugabe and his fellows should go. Just look at all the people that fled the country, or at the protests facing Zimbabwe’s embassies around the globe. Their cause is sympathetic but hopeless. Mugabe has no shame and will resort to any measure to keep himself in place. Nothing will change, because Mugabe knows that as long as he controls the means to violence, he will get what he want.

 

In the 1970s, the only way Mugabe and ZANU-PF were able to penetrate into Rhodesia was by forcefully bullying the peasant population into submission. Anyone who didn’t cooperate was tortured or killed in front of others. People were stuck between a rock and a hard place – the Rhodesian security forces and Mugabe’s ‘liberation’ fighters. Only, the hard place was harder than the rock – Mugabe was much more brutal than the security forces. Even during the 1980 elections, he could never have won without massive intimidation of the voters, especially in the Shona areas. He found out for himself, that as long as he was more brutal than the others, then he would win.

He did the same thing in the 1980s, when his Matabele comrades in arms found out what he really was – a lowly jackal and a turncoat. He murdered many thousands of  Matabeles to secure his position.

The only thing he really respected, because they stood in his path to tyranny and dictatorship, were the Rhodesian security forces. They nearly killed him. He hated them and he hated Ian Smith, but he also respected them because they answered his language of force with counter force. Smith’s presence in politics in the early 1980s probably kept him from going all-out like he did in the 1990s and 2000s.

He is hated by his people. Ian Smith said, in 2003, that if he and Mugabe were to walk into a black Harare township together, only one would come out alive. Smith was confident enough to do it. Mugabe isn’t. He hurries along in his huge motorcade.

So, there you have a dictator who is afraid, who is reviled by his people and everybody is desperate for a change. What can be done about it. A protest? Nothing will change. More drastic measures must be taken.

I say, let’s get rid of him and his thieves.  I say, let us complete their task and stand up against Mugabe. Let him feel the power of the gun. Let him run into the bush with armed units after him. Rise and dismiss the dictator. Kill him and all his cronies in the most ferocious way possible.

Zimbabwe needs new men of steel, like Ian Smith or Ron Reid Daly, who are willing to take up arms against Mugabe. A new Chimurenga must take place, but this time, to restore the values that were buried when Rhodesia disappeared.

 

 

 

TI’s new Cortex-M4 line versus the rest

Recently I received an email from Texas Instruments (TI) in which they announced the availability of their new Cortex-M4 line. I really like many products TI makes. When I spoke to TI people at Nürnberg’s Embedded World fair last March, I was thrilled to hear TI would release a Cortex-M4 part in autumn 2011.

I have used their LM3S9B96 processor and am very satisfied with it – excellent peripherals, very good DMA controller, lots of memory and the inclusion of Stellarisware and SafeRTOS in ROM in the chip. I sort of expected the extension of their Cortex-M3 family with Cortex-M4 based microcontrollers that would be faster and  just as well, or better, equipped. To my disappointment, that is not the case:

  • The new Cortex-M4 line (Blizzard) is not faster than the Tempest class Cortex-M3.
  • The new Blizzard class has less internal memory (32K vs 96K).
  • The new Blizzard class has no external bus interface.
  • The new Blizzard class has no Ethernet MAC/PHY like the Tempest class.

The only things going for it seem to be the internal EEPROM, the DSP additions in the core and the fact that the IC is produced using a 65 nm process.

So, why would I use the new Blizzard class instead of the Tempest class? I see no major compelling reasons to migrate. In fact, I think that many if not most DSP style calculations can easily be done on the Tempest class if you use the IQMath library, which is used to map floating point calculations onto fixed-point ones.

Also, when comparing the Blizzard class to competing offerings from other manufacturers, it doesn’t really impress me:

  • Freescale has been offering their Kinetis controller for a while. Running at 150 MHz (the K70 type) and equipped with many useful peripherals (among them, a LCD controller) this seems better equipped than the Blizzard class, and almost twice as fast.
  • NXP will soon be releasing the LPC4000 family, which will run at 180 MHz and which has a Cortex-M4 together with a Cortex-M0 on board. Again, in terms of raw performance, this one leaves the Blizzard class kicking in the dust.
  • ST recently released their STM32F4 series. This stunning Cortex-M4  microcontroller runs (from flash) at 168 MHz – more than double the speed of the Blizzard class. It has loads of memory, many peripherals, an external bus and so on. I seriously doubt TI’s Blizzard class will beat this one.
I hope TI will follow suit and release a Cortex-M4 offering with a performance similar to or better than the ones above. If not, I think they will not compete well in the Cortex-M4 class arena.

Using new and delete in C++ on Cortex-M3

A nice way to precisely time the instantiation of an object in C++  is to use the new and delete operators. Normally, an global object is instantiated at a undefined time – the compiler decides on this, not a language standard.

Whilst delete would not be of great use in an embedded system without good memory management (the easiest implementation would be the  BGET package), new can be used efficiently to cater for a linear instantiation where the user decides when to instantiate.

If you want to use C++ without the bloat, you’re probably forced to provide your own new and delete routines. On Cortex-M3, this can be tricky.

Although the core supports unaligned memory access, unaligned multiple LDM, STM, LDRD and STRD calls will cause a Usage Fault exception. Also, using unaligned data decreases performance. When instantiating a class with a multitude of variables listed in the class, the allocated memory block could well be unaligned. Also, code could conceivably be generated that will execute a number of LDM or LDRD instructions, for example, in the constructor of the object.  It is therefore imperative that a new call will always return an aligned block of data.

A simple way to implement new and delete would be like this :

static void * toewijzing(const size_t size) /* let op: size geeft het aantal bytes aan */
{
    static UInt8 *heap_ptr = (UInt8 *)(__bss_end);
    const UInt8 *base = heap_ptr;       /*  Point to end of heap.  */
    const UInt8 *eindeSRAM = (const UInt8 *)__TOP_STACK;        

    if ((heap_ptr+size) < eindeSRAM)
    {
        heap_ptr += size;       /*  Increase heap met size aantal bytes  */
    }
    else
    {
        while(1);
        KiwandaAssert(0);
    }

    return((void *)base);               /*  Return pointer to start of new heap area.  */
}

void * operator new(size_t size) /* let op: size geeft het aantal bytes aan */
{
    return(toewijzing(size));
} 

void * operator new[](size_t size)
{
    return(toewijzing(size));
} 

void operator delete(void * ptr)
{
    // free(ptr);
} 

void operator delete[](void * ptr)
{
    //free(ptr);
}

The linker will provide the location of the end of the used SRAM space (__bss_end) and the end of the SRAM block (__TOP_STACK).  An example would be the following Linker Load file, used for the Energy Micro EFM32G880F64 processor:

************************************************************************
ARM Cortex M-3 standaard microcontroller loadscript.
Memory I/O adressen, aangepast aan eigenschappen
van de Energy Micro EFM32G880F64 Microcontroller

Alle aanpassingen in dit bestand zijn
(c) 2008-2011 Kiwanda Embedded Systemen
Voor alle overige software geldt het copyright van Atmel

$Id: efm32g880f64.ld 3041 2011-08-28 20:29:52Z oldenburgh $
************************************************************************/

OUTPUT_FORMAT("elf32-littlearm", "elf32-littlearm", "elf32-littlearm")
OUTPUT_ARCH(arm)

MEMORY
{
  FLASH (rx)   : ORIGIN = 0x00000000, LENGTH = 64K
  DATA (rw)    : ORIGIN = 0x20000000, LENGTH = 16K
}

__TOP_STACK    = ORIGIN(DATA) + LENGTH(DATA);

/* Section Definitions */

SECTIONS
{
  /* first section is .text which is used for code */

  . = ORIGIN(FLASH);
  .text :
  {
        KEEP(*(.cortexm3vectors))      /* core exceptions */
        KEEP(*(.geckovectors))          /* efm32 exceptions */
        . = ALIGN(4);
        KEEP(*(.init))
        CREATE_OBJECT_SYMBOLS
        *(.text .text.*)                   /* C en C++ code */
        *(.gnu.linkonce.t.*)
        *(.glue_7)
        *(.glue_7t)
        *(.vfp11_veneer)
        *(.ARM.extab* .gnu.linkonce.armextab.*)
        *(.gcc_except_table)
        . = ALIGN(4);
   } >FLASH

__exidx_start = .;
.ARM.exidx   : { *(.ARM.exidx* .gnu.linkonce.armexidx.*) }
__exidx_end = .;

   . = ALIGN(4);

        .rodata : ALIGN (4)
        {
                *(.rodata .rodata.* .gnu.linkonce.r.*)

                . = ALIGN(4);
                KEEP(*(.init))

                . = ALIGN(4);
                __preinit_array_start = .;
                KEEP (*(.preinit_array))
                __preinit_array_end = .;

                . = ALIGN(4);
                __init_array_start = .;
                KEEP (*(SORT(.init_array.*)))
                KEEP (*(.init_array))
                __init_array_end = .;

                . = ALIGN(4);
                KEEP(*(.fini))

                . = ALIGN(4);
                __fini_array_start = .;
                KEEP (*(.fini_array))
                KEEP (*(SORT(.fini_array.*)))
                __fini_array_end = .;

                . = ALIGN(0x4);

                __CTOR_LIST__ = .;
                LONG((__CTOR_END__ - __CTOR_LIST__) / 4 - 2)
                *(.ctors)
                LONG(0)
                __CTOR_END__ = .;
                __DTOR_LIST__ = .;
                LONG((__DTOR_END__ - __DTOR_LIST__) / 4 - 2)
                *(.dtors)
                LONG(0)
                __DTOR_END__ = .;

                . = ALIGN(0x4);

                KEEP (*crtbegin.o(.ctors))
                KEEP (*(EXCLUDE_FILE (*crtend.o) .ctors))
                KEEP (*(SORT(.ctors.*)))
                KEEP (*crtend.o(.ctors))

                . = ALIGN(0x4);
                KEEP (*crtbegin.o(.dtors))
                KEEP (*(EXCLUDE_FILE (*crtend.o) .dtors))
                KEEP (*(SORT(.dtors.*)))
                KEEP (*crtend.o(.dtors))

                *(.init .init.*)
                *(.fini .fini.*)

                PROVIDE_HIDDEN (__preinit_array_start = .);
                KEEP (*(.preinit_array))
                PROVIDE_HIDDEN (__preinit_array_end = .);
                PROVIDE_HIDDEN (__init_array_start = .);
                KEEP (*(SORT(.init_array.*)))
                KEEP (*(.init_array))
                PROVIDE_HIDDEN (__init_array_end = .);
                PROVIDE_HIDDEN (__fini_array_start = .);
                KEEP (*(.fini_array))
                KEEP (*(SORT(.fini_array.*)))
                PROVIDE_HIDDEN (__fini_array_end = .);

                . = ALIGN (8);
                *(.rom)
                *(.rom.b)

        } >FLASH

   . = ALIGN(4);
   _etext = . ;
   PROVIDE (etext = .);

  /* .data section which is used for initialized data */

   _bdata = . ;
   PROVIDE (bdata = .);

  .data : AT(_bdata)
  {
    _data = . ;
    *(.data)            /* normale data */
    *(.data.*)        

    SORT(CONSTRUCTORS)
    . = ALIGN(4);
  } >DATA

   _edata = . ;
   PROVIDE (edata = .);

  . = ALIGN(4);

  /* .bss section which is used for uninitialized data */
  .bss(NOLOAD) :
  {
    _bss = . ;
    __bss_start = . ;
    __bss_start__ = . ;
    *(.bss)
    *(.bss.*)
    *(COMMON)
   __bss_end__ = . ;
   __bss_end   = . ;
   PROVIDE (_ebss = .) ;
  } >DATA

  . = ALIGN(4);

   _end = .;
   PROVIDE (end = .);    /* einde intern geheugen */

  /* Stabs debugging sections.  */
  .stab          0 : { *(.stab) }
  .stabstr       0 : { *(.stabstr) }
  .stab.excl     0 : { *(.stab.excl) }
  .stab.exclstr  0 : { *(.stab.exclstr) }
  .stab.index    0 : { *(.stab.index) }
  .stab.indexstr 0 : { *(.stab.indexstr) }
  .comment       0 : { *(.comment) }
  /* DWARF debug sections.
     Symbols in the DWARF debugging sections are relative to the beginning
     of the section so we begin them at 0.  */
  /* DWARF 1 */
  .debug          0 : { *(.debug) }
  .line           0 : { *(.line) }
   *(.data)            /* normale data */
    *(.data.*)        

    SORT(CONSTRUCTORS)
    . = ALIGN(4);
  } >DATA

   _edata = . ;
   PROVIDE (edata = .);

  . = ALIGN(4);

  /* .bss section which is used for uninitialized data */
  .bss(NOLOAD) :
  {
    _bss = . ;
    __bss_start = . ;
    __bss_start__ = . ;
    *(.bss)
    *(.bss.*)
    *(COMMON)
   __bss_end__ = . ;
   __bss_end   = . ;
   PROVIDE (_ebss = .) ;
  } >DATA

  . = ALIGN(4);

   _end = .;
   PROVIDE (end = .);    /* einde intern geheugen */

  /* Stabs debugging sections.  */
  .stab          0 : { *(.stab) }
  .stabstr       0 : { *(.stabstr) }
  .stab.excl     0 : { *(.stab.excl) }
  .stab.exclstr  0 : { *(.stab.exclstr) }
  .stab.index    0 : { *(.stab.index) }
  .stab.indexstr 0 : { *(.stab.indexstr) }
  .comment       0 : { *(.comment) }
  /* DWARF debug sections.
     Symbols in the DWARF debugging sections are relative to the beginning
     of the section so we begin them at 0.  */
  /* DWARF 1 */
  .debug          0 : { *(.debug) }
  .line           0 : { *(.line) }
  /* GNU DWARF 1 extensions */
  .debug_srcinfo  0 : { *(.debug_srcinfo) }
  .debug_sfnames  0 : { *(.debug_sfnames) }
  /* DWARF 1.1 and DWARF 2 */
  .debug_aranges  0 : { *(.debug_aranges) }
  .debug_pubnames 0 : { *(.debug_pubnames) }
  /* DWARF 2 */
  .debug_info     0 : { *(.debug_info .gnu.linkonce.wi.*) }
  .debug_abbrev   0 : { *(.debug_abbrev) }
  .debug_line     0 : { *(.debug_line) }
  .debug_frame    0 : { *(.debug_frame) }
  .debug_str      0 : { *(.debug_str) }
  .debug_loc      0 : { *(.debug_loc) }
  .debug_macinfo  0 : { *(.debug_macinfo) }
  /* SGI/MIPS DWARF 2 extensions */
  .debug_weaknames 0 : { *(.debug_weaknames) }
  .debug_funcnames 0 : { *(.debug_funcnames) }
  .debug_typenames 0 : { *(.debug_typenames) }
  .debug_varnames  0 : { *(.debug_varnames) }

} /* einde secties */

When the size of the allocated block is not a multiple of 4, the next allocated block will be unaligned. In order to prevent this, allocation must always be done at multiples of 4 bytes. The next example will show this:

static void * toewijzing(const size_t size) /* let op: size geeft het aantal bytes aan */
{
    static UInt8 *heap_ptr = (UInt8 *)(__bss_end);
    const UInt8 *base = heap_ptr;       /*  Point to end of heap.  */
    const UInt8 *eindeSRAM = (const UInt8 *)__TOP_STACK;        

    if ((heap_ptr+size) < eindeSRAM)
    {
        heap_ptr += size;       /*  Increase heap met size aantal bytes en eindig op 32 bit boundary */

        while (((unsigned int)heap_ptr & 0x3) != 0)   /* bit 0 en 1 = 0 --> stappen in 4 * byte = 32 bytes */
            heap_ptr++;
    }
    else
    {
        while(1);
        KiwandaAssert(0);
    }

    return((void *)base);               /*  Return pointer to start of new heap area.  */
}

void * operator new(size_t size) /* let op: size geeft het aantal bytes aan */
{
    return(toewijzing(size));
} 

void * operator new[](size_t size)
{
    return(toewijzing(size));
} 

void operator delete(void * ptr)
{
     /* not applicable in embedded application */
} 

void operator delete[](void * ptr)
{
    /* not applicable in embedded application */
}

Advancing the heap_ptr to the next aligned address will prevent unaligned allocation to take place. The price paid for this is the loss of, at most, 3 bytes in between two allocated blocks. Since most systems have SRAM memory equal to or in excess of 16 KBytes, this won’t pose a major problem. During design of a class, careful placement of the data members will also prevent unaligned variables. Simply stated, group your equal variables together (for example, all unsigned char or unsigned short) and pad them, if necessary,  at the end with a dummy variable to grow to the 32 bit boundary:

UInt8 var1;
UInt16 var2[3];

/* total = 8+2*16 = 40 bits  -> we need 24 bits padding */
UInt8 padding[3];

This will prevent costly unaligned acces.

VVD verbaast mij al weer

Opnieuw een bericht dat mij ongelofelijk voorkomt:

“Dit betekent niks voor het Nederlandse debat”, zegt VVD-Kamerlid René Leegte. „Duitsland wil 25 procent duurzame energie opwekken. Dan zullen ze moeten importeren en laat je niks wijsmaken: dat wordt Franse kernenergie.”

Meneer Leegte (zijn naam beschrijft goed zijn denkproces) vergeet dat wij als Nederland voor een zeer groot gedeelte van onze welvaart en stabiliteit afhankelijk zijn van wat er in Duitsland gebeurt. Dat “dit niets betekent” is dan ook een lege kreet, want wat in Duitsland wordt besloten heeft altijd gevolgen voor ons. Hij sluit slechts de ogen voor het feit dat, hoe zeer hij ook een tweede Fukushima- of Tsjernobylachtige centrale in ons land wil plaatsen (waarom eigenlijk?) we links worden ingehaald door een aantal belangrijke buurlanden.

En waar is het élan gebleven? “Ze zullen wel kernenergie gaan importeren………” wat een misselijkmakende negatieve pessimistische blik op de toekomst. Vergeten wordt waar het technisch vernunft van de Duitsers toe in staat is. Je kunt beter goed proberen dan fout blijven doorgaan, maar meneer Leegte vindt fout doorgaan een echt liberaal standpunt.

Wij moeten ook het roer wenden en mee gaan doen met het Duitse initiatief. Dat levert kennis, inkomenst en en een schonere wereld op. In plaats daarvan wil de VVD (waar ik lid van ben)  als een stel conservatieve oude verstilde zakken ons geld in de bouw van een kerncentrale steken, want iets anders durven ze niet. Maar met zo’n renteniersmentalieit komen we er niet.

 

 

Compiling and linking C++ code on Cortex-M3 without exception handling and RTTI

Most embedded software is written in C, and software written for ARM Cortex-M3 devices is no exception (pun intended).

C has many qualities – small, clean, relatively easy to learn and above all a superior interface for performing low-level hardware operations – try writing a routine for manipulating I/O memory  in Algol or Fortran …… Why, then, divert to C++ and its supposed steeper learning curve? The answer lies in the size of the software project you write.

The price for using C becomes painfully apparent when projects grow beyond the “hello world” stage – the boundary usually lies around 1200-1500 lines of code. Writing a “hello world” demo in C is feasible and maintaining the source code is not hard. “Hello world” applications are in the order of 10-30 KBytes of Flash on Cortex-M3.

However, many Cortex-M3 devices typically offer more than 256 KByte of Flash, up to 2048 KBytes of Flash. A typical “serious” project for such a device would employ a number of serial interfaces, would perhaps include an embdded web server, would do floating point calculations and would interact with a user through buttons or a touch screen. Such a project would require ten thousand lines of C code or more, which translates into upward of 200 Kbytes of flash programmable binary code. Maintaining order in this code, which is centered around C’s function-oriented set-up, is awkward and error-prone. Doing so with a large developer team is even harder, as I know from experience. In C, devices typically use structs which contain init and state information, but how do you know if and where all information is filled out correctly in 15000 lines of code? Also, manually calling init functions and combining common code into lower level function/data sets requires a lot of discipline from a development team. Most experienced C programmers confronted with situation will start to write code defensively, in an object-oriented approach, in order to prevent errors and bugs. In a way, they use C++features without using the proper tools.

C++ offers everything you need to maintain order in larger embedded programs. Object Oriented programming was a focal point when the language was invented, without sacrificing backwards compatibility with existing C code. Device information is maintained in the class container, togerther with all necessary functions. Common code can be brought into lower base classes, enabling the sharing of the code by virtue of the inheritance mechanism of C++. It is easy to define a base interface prototype in C++ which can be used in your application code, and then use polymorphism to link your interface prototype to your device implementation. Code migration becomes very easy – your application can be brought from, let’s say STM32 to LM3S, and the only thing that you must do is develop a new interface implementation.

Problems occur when C++ is used indiscriminately. The ambivalence of many C programmers towards C++ is based on the fact that a lot of things are included in your C++ binary (bloat) which you don’t need and use.  It is important, though, to understand two things about the superset of features that C++ has with regards to C:

  • There are compile-time enhancements in C++, such as classes, virtual functions or namespaces, which are completely benign and which in most cases will not contribute to bloat. They are part of the framework that enables programmers to scale their software concepts to larger dimensions without losing overview. In larger programs, C++ will most likely lead to more compact code – see this example at GCC compiler family, but this story is also applicable to KEIL and IAR users.

    Compile your code with the -fno-rtti -fno-exceptions flags (the others such as -ggdb aren’t relevant to this discussion but I included them anyway). My compiler lives on a FreeBSD system and is therefore placed in /usr/local/bin. I named it arm-eabi instead of the more common arm-none-eabi. This may be different on your system. When using Linux, for example, every distro seems to have its own peculiar spot to place applications.

    In order to prevent using exception handling and rtti at compile time:

    /usr/local/bin/arm-eabi-g++ -mthumb -c -pipe -mcpu=cortex-m3
    -mno-thumb-interwork -mapcs-frame -funsigned-char
    -fno-threadsafe-statics -Wall -Wimplicit -Wpointer-arith
    -Wswitch -Wredundant-decls -Wreturn-type -Wshadow
    -Wunused -Werror -Winline -ggdb -fno-inline
    -fno-stack-protector -fno-rtti -fno-exceptions
    -fno-unwind-tables  -Wa,-adhlns=LISTFILE -o OBJECTFILE CPPFILE

    LISTFILE, OBJECTFILE AND CPPFILE are of course to be properly named by you.

    This stops C++ from automatically inserting exception handling (and all other stdc++ library components) in your object file. But, this isn’t the complete solution! Even with the insertion of  -fno-exceptions at compile time, you will still get exception handling (and therefore bloat) when using C++ features such as new or delete. You will need to instruct the linker that it, too, should avoid all bloat components.

    At the linking stage, use the -nostdlib option to instruct the linker to omit any library file it would automatically add – in C++‘s case, libstc++.a . I use partial linking, and the linker command for that would be:

     

    /usr/local/bin/arm-eabi-g++
    -Wl,-Ur -nostdlib -Wl,Map=MAPFILE
    -o OBJCTFILE1 OBJECTFILE2 ...

     

    At the final linking step, or at the main linking step if you don’t use partial linking, you must compensate for the missing library components that you would want to include, for instance memcpy or assert. The standard C library provides many of these things and fills the missings references in most cases. Such a linking step would be like:

    /usr/local/bin/arm-eabi-g++ -mcpu=cortex-m3 -nostdlib
    -msoft-float -nostartfiles -fno-rtti -fno-exceptions
    -Wl,--cref -Wl,-Map=MAPFILE -Wl,-TLINKERSCRIPT -o ELFFILE
    -lc -lgcc -lm

    Functionality not found in libc.a such as new or delete must be provided by you – this is the price you pay for not using libstdc++! This, however, is not very difficult to do. In C++, you can use overloaded methods to insert your own version of new and delete:. I have an article that outlines how to write these functions.

     

     

Vrijheid van meningsuiting

Een kop uit de Telegraaf van vandaag:

VVD paait SGP

 

en verder in dit artikel :

“De VVD heeft haar handtekening weggehaald onder een wetsvoorstel dat zij eerder samen met D66 had ingediend om godslastering niet meer strafbaar te stellen.”

Ik ben in 2010 lid geworden va de VVD omdat ik ik vind dat iedereen in dit land mag zeggen wat hij of zij vindt, ongeacht het onderwerp. Met name de zich steeds meer roerende religieus geïnspireerde medemens moet in de openbare ruimte op afstand worden gehouden, omdat het algemeen belang (dus ook het belang van niet-gelovigen) niet gediend is met mondsnoeringen van welke aard dan ook.

De liberale beginselen onderschrijven dit volledig:

Vrijheid
Vrijheid van de mens is onmisbaar voor ontplooiing. We bedoelen dan vrijheid op geestelijk, staatkundig en materieel gebied. Deze vrijheid komt ieder mens toe, zonder enige discriminatie. De vrijheid moet zo groot mogelijk zijn. Er zijn wel grenzen aan persoonlijke vrijheid. De vrijheid van de een mag de vrijheid van de ander niet belemmeren. En we moeten oog hebben voor de belangen van toekomstige generaties.

Zolang ik bij godslastering niet verkondig dat anderen god niet mogen aanprijzen, belemmer ik hun niet in hun meningsuiting. Omgekeerd doen zij de religieuzen dit wel, door het strafrecht (niet niet de Sharia, maar ons onpartijdige, boven religies verheven strafrecht) in te zetten voor de vervolging van mensen met wie zij het niet eens zijn. Blijkbaar is hun vrijheid belangrijker dan mijn vrijheid. En nu schaart ook de liberale VVD zich in de rij van partijen die de vrijheid van meningsuiting van religieuzen belangrijker vinden dan die vrijheid van meningsuiting van anderen – de VVD laat deze discriminatie van een van haar eigen beginselen gewoon gebeuren.

Ik vind dat de VVD zich aan haar beginselen moet vasthouden bij de dagelijkse politieke besluitvorming. Als de partij zwicht voor de orthodoxe drammers van de SGP, dan zijn de eigen principes blijkbaar minder belangrijk dan de greep op de regeringsmacht.

 

 

 

 

Vrijheid van meningsuiting

Een kop uit de Telegraaf van vandaag:

VVD paait SGP

 

en verder in dit artikel :

“De VVD heeft haar handtekening weggehaald onder een wetsvoorstel dat zij eerder samen met D66 had ingediend om godslastering niet meer strafbaar te stellen.”

Ik ben in 2010 lid geworden va de VVD omdat ik ik vind dat iedereen in dit land mag zeggen wat hij of zij vindt, ongeacht het onderwerp. Met name de zich steeds meer roerende religieus geïnspireerde medemens moet in de openbare ruimte op afstand worden gehouden, omdat het algemeen belang (dus ook het belang van niet-gelovigen) niet gediend is met mondsnoeringen van welke aard dan ook.

De liberale beginselen onderschrijven dit volledig:

Vrijheid
Vrijheid van de mens is onmisbaar voor ontplooiing. We bedoelen dan vrijheid op geestelijk, staatkundig en materieel gebied. Deze vrijheid komt ieder mens toe, zonder enige discriminatie. De vrijheid moet zo groot mogelijk zijn. Er zijn wel grenzen aan persoonlijke vrijheid. De vrijheid van de een mag de vrijheid van de ander niet belemmeren. En we moeten oog hebben voor de belangen van toekomstige generaties.

Zolang ik bij godslastering niet verkondig dat anderen god niet mogen aanprijzen, belemmer ik hun niet in hun meningsuiting. Omgekeerd doen zij de religieuzen dit wel, door het strafrecht (niet niet de Sharia, maar ons onpartijdige, boven religies verheven strafrecht) in te zetten voor de vervolging van mensen met wie zij het niet eens zijn. Blijkbaar is hun vrijheid belangrijker dan mijn vrijheid. En nu schaart ook de liberale VVD zich in de rij van partijen die de vrijheid van meningsuiting van religieuzen belangrijker vinden dan die vrijheid van meningsuiting van anderen – de VVD laat deze discriminatie van een van haar eigen beginselen gewoon gebeuren.

Ik vind dat de VVD zich aan haar beginselen moet vasthouden bij de dagelijkse politieke besluitvorming. Als de partij zwicht voor de orthodoxe drammers van de SGP, dan zijn de eigen principes blijkbaar minder belangrijk dan de greep op de regeringsmacht.

 

 

 

 

Casio calculators

Recently I purchased a new calculator because someone pointed out to me the truly amazing capabilities (natural textbook display) of Casio’s new fx-115ES calculator. Costing under €30, the calculator offers an astounding 403 functions, conversions and solvers. It also displays fractions as true fractions, in addition to the standards floating point display format.. It can handle tables for linear or cubic interpolation for which the data entry is pretty easy. It performs numerical differential and integration, and solves equations with Newton-Rapson. It can even do (limited) vector and matrix calculations.

Even though I am a big fan of Texas Instruments integrated circuits (especially  their MSP430  microcontrollers, their ADCs (ADS1178) and power ICs (TPS84620) ) I prefer Casio’s calculators over TI’s. They are not as bulky, you can get your results more quickly and they cost a lot less.

When I got the new calculator , I realised I had purchased the fx-115 before. The first model I got was the fx-115 in 1985, when I was in school. Later, it also served me well as a student at Delft University of Technology.  Looking for a model that would help me with complex numbers, I bought  the fx-115W when I worked at Oresis Communications in 2001. This was my main computational workhorse in the new millennium. And, this year I purchased the amazing fx-115ES. In a way I have been quite intimate with the fx-115 family for 26 years!

All calculators, including the 26 years old fx-115, still work flawlessly, a testimony to Casio’s build quality. Begin solar driven, I never had to replace a battery. The fx-115 now lives in a kitchen drawer and is used for domestic purposes.

My calculators are  (running :

CASIOFX115familie2

 

 

 

 

Casio calculators

Recently I purchased a new calculator because someone pointed out to me the truly amazing capabilities (natural textbook display) of Casio’s new fx-115ES calculator. Costing under €30, the calculator offers an astounding 403 functions, conversions and solvers. It also displays fractions as true fractions, in addition to the standards floating point display format.. It can handle tables for linear or cubic interpolation for which the data entry is pretty easy. It performs numerical differential and integration, and solves equations with Newton-Rapson. It can even do (limited) vector and matrix calculations.

Even though I am a big fan of Texas Instruments integrated circuits (especially  their MSP430  microcontrollers, their ADCs (ADS1178) and power ICs (TPS84620) ) I prefer Casio’s calculators over TI’s. They are not as bulky, you can get your results more quickly and they cost a lot less.

When I got the new calculator , I realised I had purchased the fx-115 before. The first model I got was the fx-115 in 1985, when I was in school. Later, it also served me well as a student at Delft University of Technology.  Looking for a model that would help me with complex numbers, I bought  the fx-115W when I worked at Oresis Communications in 2001. This was my main computational workhorse in the new millennium. And, this year I purchased the amazing fx-115ES. In a way I have been quite intimate with the fx-115 family for 26 years!

All calculators, including the 26 years old fx-115, still work flawlessly, a testimony to Casio’s build quality. Begin solar driven, I never had to replace a battery. The fx-115 now lives in a kitchen drawer and is used for domestic purposes.

My calculators are  (running :

CASIOFX115familie2

 

 

 

 

Don’t use the provider Llama Communications!

In early June 2005 I got an email from Llama Communications saying there were closing shop because of a bankruptcy. This caused me a lot of work, because domain registrations as well as email and www traffic were coming through Llamacom.

The person running the company,  Michael Grafft in West Des Moines, IA, was very emphatic but said he couldn’t do anything about it.

I switch to a local DNS registrator, Argeweb, and haven’t had any problems since switching. But Michael Grafft lied about Llamacom! They are still in business. Why they forced me out, I don’t know. He never answered my questions why or how things went wrong. So Michael, if you read this, why did you lie to me?