Skip to main content

Posts

Showing posts from June, 2013

Odd git SourceForge problems

A user emailed me today asking if I could push out some changes to a network packet analysis and creation library that I created and maintain, Packet.Net . These changes were included in the last release packages I pushed our a few months ago but apparently weren't in the git repository on SourceForge. This didn't make a lot of sense because I use some scripts that build binary and source release zip files by doing a git export of a specified tag from the remote repository on SourceForge. Plus I'm usually pretty careful to push everything out in case something happens to my laptop. Went to the SourceForge code browser web page where you can browse the repository from a web browser and sure enough there were tags and commits were missing, when compared to my local development repository/directory. I ran git status from my development directory and it showed up to date. Ran a push but it said the same. Even tried a force push but git didn't take any action. I suspecte

Review of "The Winds of War" and "War and Remembrance" by Herman Wouk(unabridged audio book version)

After signing up up for a trial account to Audible , we, myself and my fiancee, downloaded a few sample books, including "The Winds of War" and "War and Remembrance" by Herman Wouk . She actually picked those two books based on their high ratings. This is a review of the unabridged audio versions of these two books. "The Winds of War" and "War and Remembrance" are works of historical fiction, starting in the 1930s and ending in the 1940s. Covering the period that led up to and including WWII, the books explore a time of conflict that was to decide who would rule much of the world. I had apprehensions about historical fiction when starting this book. Some historical fiction can deviate from history or generalize events and I was concerned about learning historically inaccurate information. I consider misinformation to be almost worse than not knowing the history at all. Wouk has taken great care to be historically accurate. In his

Plug in Prius

2013 Toyota Plug-in-prius I recently upgraded from a 2001 Acura Integra to a 2013 Toyota Prius plug in. The Integra was getting older, mpg wasn't great and the dealer was offering a pretty good trade-in, a big discount on Plug-in-prius (PiP) and  0% financing. The good Mpg is excellent. Even without the plug in battery the car gets about 60 mpg if you stay in the 65-70 mph range. This basically matches the regular Prius even though the larger Li battery pack adds a hundred or more pounds. With the ev battery fully charged I get about 80 mpg on my 35 mile 40 minute trip. Oh, and the pip displays helpful trip summary after being powered off: Plug-in-prius trip summary Side decal The touch screen on the in car system works relatively well. It appears to be a resistive touch screen though. Resistive touch screens are being replaced by by surface and projected capacitance technologies. Resistive only detects single touches, requires harder touches, and takes more

FreeRTOS + newlib (gcc toolchain) on the STM32F103 (Cortex-M3)

Here are some of the steps to get FreeRTOS and newlib (gcc) to work correctly on the STM32F10x, a Cortex-M3 ARM processor. Configure the priority bits Per  the FreeRTOS page about the Cortex M3 and M4 , the priority bits should be assigned to be preempt priority by calling NVIC_PriorityGroupConfig( NVIC_PriorityGroup_4 );  If you or any start up related code you are using isn't doing this you may end up with odd behavior or bus faults. Map FreeRTOS tasking functions to CMSIS vector handlers Per this post  you'll want to map the FreeRTOS handlers for vPortSVCHandler, xPortPendSVHandler and xPortSysTickHandler to the CMSIS handlers. A readelf of the elf file of my example application was showing the default interrupt handler was being used for those interrupts, which meant FreeRTOS wasn't handling the interrupts it needed to function correctly. The CMSIS default handlers are weakly bound so having other definitions with the same names will override these, causing the

Debugging an imprecise bus access fault on a Cortex-M3

This information may apply to other cortex series processors but is written from practical experience with the Cortex-M3. Imprecise bus access faults are ambiguous, as noted by the term "imprecise". Compared to precise bus errors, imprecise errors are much trickier to debug and especially so without a deep understanding of arm processors and assembly language. Imprecise and precise flags are found in the BusFault status register, a byte in the CFSR (Configurable Fault Status Register). BusFault status register bits The definition for imprecise and precise bits is: [2] IMPRECISERR Imprecise data bus error: 0 = no imprecise data bus error 1 = a data bus error has occurred, but the return address in the stack frame is not related to the instruction that caused the error. When the processor sets this bit to 1, it does not write a fault address to the BFAR. This is an asynchronous fault. Therefore, if it is detected when the priority of the current pr