Show Posts
Pages: 1 ... 54 55 [56] 57 58 ... 110
826  Development / Other Software Development / Re: RTOS candidates for Cortex M3/M4 duino boards. on: November 23, 2012, 12:29:04 pm
The classroom version of using state machines is great.  In practice not so much.

The idea is that you design with something like UML state diagrams.  Once you totally understand the problem, you implement the solution possibly with the help of some tools.  You then live happily ever after.

The problem is that you never understand the real world while you are drawing state charts.  Systems evolve and the real world is messy.

The end result is that the code to implement state machines is not readable so you need or should go back to the design documents to make changes.

This just doesn't work well in the development of large embedded systems.

This article, that is selling a tool for state machines, hits on a lot of the problems but this type of tool doesn't solve them in the real world.

At one point I was a principal in a start-up company that promoted a state machine approach to embedded systems.  After leaving the company I went back to building large embedded systems for big science projects.  I found once again that tools like QP are not nearly as important as fundamental knowledge of the problem to be solved.  Having a PhD in physics trumps use of any tool when you are dealing with a Large Hadron Collider.
827  Development / Other Software Development / RTOS candidates for Cortex M3/M4 duino boards. on: November 20, 2012, 12:53:29 pm
I have ported ChibiOS/RT and FreeRTOS to Teensy 3.0 as libraries.  This allows mixing Teensy software with RTOS functions.

I am now working on ports for Due. It looks like Due will also be able to support these RTOSs as Arduino libraries.

I am also looking at other possible RTOS candidates.  Here are my criteria for candidates.
Active development

Supports Cortex M3/M4

Open Source

Free version available

OS Website has forum with activity

Here is my current list of candidates.  Some of these would not be easy to port to Due.


CooCox CoOS





First, are there other good candidates that satisfy the above criteria?

Second, what features would other RTOSs have that are not covered by ChibiOS/RT and FreeRTOS?

Clearly QP is different since it is state-machine based.  In the past I was a fan of state-machines in embedded systems but I am less enthusiastic now.

It's interesting that after making the above list, I found this list  It has many of the same systems.
828  Products / Arduino Due / Re: RTOS hooks on: November 20, 2012, 11:16:31 am


I understand this may not be supported in the future or may change.

Soon after I get my Due, I will post a version of ChibiOS/RT and FreeRTOS for Due with a number of examples.

I also have a version of SdFat ready for testing.  I have optimized it for chips with large memory.

I wish there were fast native SPI functions for reading and writing blocks of memory on Due.  On Teensy 3.0 with 24 MHz native SPI I get file read and write rates over 2 MB/sec for large reads and writes.  Due should be even faster but I plan to use the official SPI library
829  Products / Arduino Due / Re: RTOS hooks on: November 19, 2012, 06:54:09 pm

That sounds great.  Teensy 3.0 has these three weak handlers, SVC_Handler, PendSV_Handler, and SysTick_Handler.

The only question is how to handle SysTick.  In Teensy 3.0 I replace the handler with one that that duplicates the Teensy 3.0 functionality and the RTOS needs.

I want the standard Arduino functionality to continue to work and have the option for a few high priority tasks and ISRs to use the RTOS functionality.

This way an ISR can cause a high priority task to execute in about 3 microseconds while loop() does low priority stuff like a normal Arduino sketch.
830  Products / Arduino Due / RTOS hooks on: November 18, 2012, 07:17:02 pm
It would be nice to have hooks in Due so popular RTOSs could be ported to Due as libraries.

The main requirement is to have access to the SVC_Handler, PendSV_Handler, and SysTick_Handler vectors.

A call to a weak dummy function at the end of these handles would be sufficient.  Currently SVC_Handler and PendSV_Handler are just for() loops that stop execution.

I understand that full preemptive RTOSs are not appropriate for most Arduino users but a few advanced users want the functionally of a full RTOS.

There are a lot of first class open source RTOSs that would run well on Due.

Paul Stoffregen provided these hooks for Teensy 3.0 and I ported ChibiOS/RT and FreeRTOS to Teensy 3.0 using these hooks.  I may port additional systems since I enjoy seeing how RTOSs are implemented and how they perform. 

I would like to provide these libraries to Due users in a way that would not require modification of the Arduino core.
831  Products / Arduino Due / Re: Mutex for task scheduler. on: November 17, 2012, 06:37:40 pm
Why not do a well designed kernel instead of growing it by software sprawl.  We have yield(), wait(), maybe Time-Triggered Cooperative (TTC) scheduling, a mutex, a way to wake a thread from an isr. Finally you will have the functionality of a true OS.

I started my career developing an OS for early multiprocessor supercomputers, CDC 6600 and others, in the late 1960s.  I have watched this haphazard growth of the OS happen at each level of computer, mainframe, minicomputer, PC, single board computer, single chip processors, ....

Now Arduino is doing the same drill.

832  Development / Other Software Development / Re: ChibiOS/RT and FreeRTOS for Teensy 3.0 on: November 17, 2012, 09:41:01 am
I have been posting additional information about use of these RTOSs here
833  Development / Other Software Development / ChibiOS/RT and FreeRTOS for Teensy 3.0 on: November 16, 2012, 11:29:09 am
I have posted a first beta of two Real Time Operating System kernels for Teensy 3.0 as

These systems are packaged as Arduino libraries so they can be used with other Arduino software. Since these are preemptive kernels, careful design is required to avoid problems with normally single-threaded Arduino software.

These RTOSs must be used with the beta8 version of the Teensy 3.0 software.

ChibiOS/RT is version 2.4.2

FreeRTOS is version 7.3.0

Warning: If this is your first use of a RTOS, you will likely experience the pain of my bugs and problems that are inherent to preemptive RTOSs. Please read the warnings in the included html documentation.

Four examples are included with each system. These example are described in the html included with the libraries.
834  Using Arduino / Storage / Re: Random Error Codes on: November 02, 2012, 10:19:59 am
The SparkFun microSD shields uses pin 8 for SD chip select.  Sometimes it will almost work with the wrong chip select pin.  This happens if pin 8 floats low.

Try changing this line
const uint8_t chipSelect = SS;
to this
const uint8_t chipSelect = 8;
835  Products / Arduino Due / Incorrect type for link() in syscalls.h prevents use of unistd.h on: October 30, 2012, 08:59:26 pm
The link() stub for newlib in syscalls.h has the wrong type and causes a conflicts with the correct definition in unistd.h. 

Here is an example sketch:

#include <unistd.h>
void setup() {
void loop() {}

That results in this error:
D:\\arduino-1.5\hardware\arduino\sam\cores\arduino/syscalls.h:43: error: declaration of C function 'int link(char*, char*)' conflicts with
D:\arduino-1.5\hardware\tools\g++_arm_none_eabi\bin\../lib/gcc/arm-none-eabi/4.4.1/../../../../arm-none-eabi/include/sys/unistd.h:107: error: previous declaration 'int link(const char*, const char*)' here

Changing the definition in syscalls.h to this:
extern int link(const  char *cOld, const char *cNew ) ;

And the implementation in syscalls_sam3.c to this:
extern int link(const char *cOld, const char *cNew )
    return -1 ;

Seems to fix the problem.
836  Using Arduino / Storage / Re: SD examples and chip select definition on: October 28, 2012, 11:00:00 am
The SD library has a long history and many of the examples are out of date or just plain wrong.

This comment is wrong.
  // On the Ethernet Shield, CS is pin 4. It's set as an output by default.
  // Note that even if it's not used as the CS pin, the hardware SS pin
  // (10 on most Arduino boards, 53 on the Mega) must be left as an output
  // or the SD library functions will not work.
  pinMode(10, OUTPUT);

The SD library always sets SS high as an output so no code is needed for that purpose.  Here is the code from Sd2Card.cpp in IDE version 1.01.
  // SS must be in output mode even it is not chip select
  pinMode(SS_PIN, OUTPUT);
  digitalWrite(SS_PIN, HIGH); // disable any SPI device using hardware SS pin

Future versions of the SD.h library will use the SPI.h library and it also makes SS as an output.  Here is code from the 1.5 SPI.h library.
  // Set SS to high so a connected chip will be "deselected" by default
  digitalWrite(SS, HIGH);

  // When the SS pin is set as OUTPUT, it can be used as
  // a general purpose output port (it doesn't influence
  // SPI operations).
  pinMode(SS, OUTPUT);

Here is the reason you may need to make some pins outputs and high.  If you have more than one device on the SPI bus, you must disable all devices other than the SD by making their chip select pin an output and high.

For the Ethernet shield, pin 10 is chip select for the Ethernet controller and pin 4 is chip select for the SD card.  So you should make pin 10 an output and set it high to disable the Ethernet controller, not because pin 10 is SS.

Much confusion results from the fact that on 328 Arduinos pin 10 is also SS.  On the Mega, people change the 10 to 53, the SS pin for the Mega, and then the SD on the Ethernet shield will not initialize.  The problem is that the Ethernet controller is no longer disabled on the Mega.

For the Ethernet shield you must always make pin 10 an output and high before initializing the SD card.  It has nothing to do with SS.

837  Development / Other Hardware Development / Re: Teensy 3.0 on: October 25, 2012, 09:39:06 pm
Yes you can connect it directly.
838  Using Arduino / Storage / Re: FAT16 vs FAT32 on: October 25, 2012, 06:36:34 am
Many of the fastest most reliable SD cards for embedded systems are small, 2GB or less, and based on SLC flash.  Larger SLC cards are available but are very expensive.
Due to the lower complexity in managing SLC flash, the write performance for SLC at the IC level is typically twice as fast. With controller multiplexing this can be reduced, but this accounts for the main delta in read speed versus write speed in retail flash products today.

SLC flash SDs last 20-100 times longer than consumer grade MLC flash SDs.
3-Bit MLC technology (a.k.a. TLC) has an exponentially lower number of program/erase cycles. SLC technology, targeting embedded and mission critical applications, will continue to maintain an emphasis on endurance and reliability.
839  Using Arduino / Storage / Re: FAT16 vs FAT32 on: October 24, 2012, 04:51:01 pm
First, the SD standard specifies that 2GB and smaller cards should be formatted FAT16 and very small cards are FAT12.

Cards larger than 2GB must be FAT32.

The practical reason is that SD cards perform better with large clusters.  Small clusters causes many accessed to the FAT (File Allocation Table) and SD cards don't tolerate random access well.  They are designed for contiguous reads and writes

I's best to format SD cards with the SD Association's formatter  This program aligns file structures with the internal flash chips for optimum performance.

OS format utilities do not always produce an optimal layout.
840  Using Arduino / Storage / Re: New SdFat optimized for Mega and Teensy 3.0 on: October 24, 2012, 04:41:20 pm
I don't use the chip select feature in the SPI module since SD transfers are so large.

To use this feature you must select the proper pin multiplexing mode with the Port Control Module.

See chapter 10 and 11 of the chip data sheet.
Chapter 10
Signal Multiplexing and Signal Descriptions
10.1 Introduction
To optimize functionality in small packages, pins have several functions available via
signal multiplexing. This chapter illustrates which of this device's signals are multiplexed
on which external pin.
The Port Control block controls which signal is present on the external pin. Reference
that chapter to find which register controls the operation of a specific pin.
Chapter 11
Port control and interrupts (PORT)
11.1 Introduction
For the chip-specific implementation details of this module's
instances see the chip configuration chapter.
11.1.1 Overview
The port control and interrupt (PORT) module provides support for port control, and
external interrupt functions. Most functions can be configured independently for each pin
in the 32-bit port and affect the pin regardless of its pin muxing state.
There is one instance of the PORT module for each port. Not all pins within each port are
implemented on a specific device.

I am not very knowledgeable about the Kinetis chip, Paul Stoffregen helped me configure the SPI to be compatible with his software for Teensy 3.0. 
Pages: 1 ... 54 55 [56] 57 58 ... 110