Weekly Updates 1 & 2

Well sorry for the delay, here we go:

I am working with the freeScale platform and a relayShield, i soldered pins to the freeScale to make easier to connect to the Shield. I am making a little library based in the BusOut class for controlling the relayShield. The general idea of the project can be seen in the diagram below. I am making some test right now. Hope to upload more photos this weekend. I have the code for tcp server working in my mbed platform with SSR so i just have to make some modifications to make it work with the freedom scale

Greetings

Legalaties Anyone ???

The questions are mounting faster than answers and I'm facing an increasingly confused dilemma (no not that one, he's fine ), perhaps quandry is a better word. To recap and expand: I've been porting Seeed Studios Arduino driver for their CAN-BUS shield which is subject to GNU/LGPL. I've also been looking at the mbed CAN code which is covered by the Apache licence. My ported and modified driver is clearly a derivative work from 2 sources subject to different license agreements so...

Questions

• Is it OK to use GNU/LGPL licensed source code in mbed libraries
• Is it OK to include 2 license agreements, GNU/LGPL and Apache
• Could I go to prison

Hi Boris,

1/ Perhaps you could publish your library and edit the wiki pages to let people know about your library too...

2/ You must get permission from the copyright holder to use any copyrighted material. The best thing to do would be to contact Sparkfun and Adafruit directly - they may grant you a licence to use their photos as it might be seen as free advertising (check that it is OK to advertise products on mbed.org first though ). You can always use your own photos of course.

Sophie x

Week 2 Update

I've updated my CAN-BUS Shield driver project Notebook page which has more details and photos : Sophie's Seeed CAN-BUS Library Notebook Page

This Week's Highlights:

• Seeed Studios' CAN-BUS Arduino Driver ported to the FRDM-KL25Z platform and all functions tested
• My improved CAN-BUS bitrate setting function can set 'any' (achievable) bitrate.
• I have wires to connect to my ECUs and can see CAN-BUS messages

Work In Progress

• Making the driver 'look and feel' more like an mbed driver
• Commenting the driver code for the Doxygen API documentation system

TO DO

• Publish Library for Seeed Studio CAN-BUS shield (preferrably before licensing issue has been resolved)
• Port Just4Trionic to FRDM-KL25Z system

Sophie x

Week 2 Update

A quick recap - I'm using the FRDM board with the SeeedStudio GPRS shield.

I've gotten some basic hello world code working with the shield, but it is not pretty! Unfortunately, The FRDM board uses the same pins for USBTX and USBRX as the shield uses for serial TX and RX. The shield can also use two software serial pins, but I didn't have much luck getting these to work.

Since I wanted to be able to play around with AT commands interactively, I needed to USBTX and USBRX free. So I ended up jumping the FRDM PTD3 and PTD2 into the shields serial communications. I put these jumpers into the pins where you can select between hardware or software serial since the middle row actually physically links the shield pins to the communications. Like it said, it's not pretty.

However, when I used this setup with the shield stacked up, the SIM900 kept powering down, so I ended up just jumping all the power/ground connections and ditching the stacking for now.

And below, the sample code I have running (based on the Arduino sample code). This allows you to open up a serial connection on your computer and send AT commands interactively to the board. It's a starting point at least.

#include "mbed.h"


Serial pc(USBTX, USBRX);        // Serial Connection to PC using usb   
Serial gprs(PTD3, PTD2);       // Software serial connection to GPRS.  For for hardware serial, use PTA1, PTA2

PwmOut red(LED_RED);
PwmOut blue(LED_BLUE); 
PwmOut green(LED_GREEN);

unsigned char buffer[64];       // buffer array for data recieve over serial port
int count=0;                    // counter for buffer array 

void setup() {
   gprs.baud(19200);             // the GPRS baud rate   
   pc.baud(19200);               // the PC serial baudrate
}

void clearBufferArray() {                       // Helper function for clearing out buffer when reading from GPRS
    for (int i=0; i<count;i++) { 
        buffer[i]=NULL;                         // clear all index of array with command NULL
    }
}
 
int main() {
    setup();
    
    red=1;
    blue=1;
    green=1;
    
    while (1) {                                 //  Run FOREVER!!!
    
        if (gprs.readable()) {                  // Is gprs sending any data to frdm board?
            red = 0;
            while(gprs.readable()) {            // reading data into char array 
                buffer[count++]=gprs.getc();    // writing data into array
                if(count == 64)break;
            }
            
            for (int i=0; i<count; i++) {
                pc.putc(buffer[i]);             // if no data transmission ends, write buffer to hardware serial port
            }
            clearBufferArray();                 // call clearBufferArray function to clear the storaged data from the array
            count = 0;                          // set counter of while loop to zero
        }       
        red = 1;
       
        if (pc.readable()) {                     // if data is available on hardwareserial port ==> data is comming from PC or notebook
            
            blue = 0;        
            while (pc.readable()) {
                buffer[count++]=pc.getc();
                if(count == 64)break;
            }
            
            for (int i=0; i<count; i++) {
                gprs.putc(buffer[i]);              // write it to the GPRS shield
            }
            clearBufferArray();
            count = 0;
        }
        
        blue = 1;
    }
    
}                                               //  End of main loop

@Julie, there indeed has been a bit of a discussion about that issue.

That said it might be handy to use USBSerial, then you send your serial data over the second USB port.

Weeks 1 & 2 Update

Hey guys! Sorry for my lack of post, work's been kind of crazy the last few weeks. Oh the joys of USB! Anyway, work on the Seeed Studio 2.8'' TFT Touch Shield V2.0 has been going good. I just recently finished documenting the process for modifying the shield to work on the FRDM-KL25Z, which I've attached to this post. Since then, I've noticed a couple users have beat me to it and published libraries for the shield. No fair, lol! So I'll be testing those tonight and might use them to finish the component page. If anybody has been following my NeatGUI library, I'm just putting the finishing touches on a driver for the ILI9341 controller which will be included in the next release.

Step 1: Arduinoifying your FRDM board

The first step to interfacing any Arduino shield with the FRDM-KL25Z is soldering female header strips to the outer row of holes. Depending on the kind of header strips you have, breaking them apart may prove to be a bit messy. Don't forget your safety glasses!

Step 2: Configuring your TFT Shield

Some of the control signals for the TFT Shield are not connected to the Arduino headers by default. Instead, they connect to a small 2x3 header, which isn't present on the FRDM-KL25Z. Fortunately for us, there are 3 solder jumpers, P1, P2, and P3, that will connect the signals when bridged. Simply heat them up with a soldering iron and bridge them together. While we're at it, lets change the BACKLIGHT jumper from ON to D7. This will allow us to control the backlight in software.

Step 3: Success!

That's it, snap the two boards together and you're good to go!

1. I'd suggest taking your own pics or looking for images with permissive usage rights
2. You can publish a fork of the library and submit a pull request to Simon or you can use your fork'd version in the components page

1. It's OK but certainly not perfered. If so - please use a <<warning>> or <<info>> tag to make this clear in the component entry
2. Yes it OK to re-write especially if you enhance or optimize the code.

Could you use InterruptIn to handle this? Check the notes in the link first to make sure the buttons are wired to pins with this functionallity

Keep the questions coming and please make sure any gotchas that you found are documented in the component entry or have a link to a personal notebook page so the next person doesn't get caught figuring out the same things!!

I am having problems using FRDM with windows 8.1. It keeps removing and reinserting itself. and every time it does a file named "fail" is created on the file system with the content "TIMEOUT" in it. Anybody have any idea on why it is happening and how could this be fixed?

Leo

Hi Leo - We are aware that only the mbed LPC11U24 and mbed LPC1768 currently work with Windows 8 (and 8.1). We are looking into this and will have an update soon. The short term fix is to use pre-Win8 OS

I have added the Seeed Studio SD Card Shield V4.0 to the component database http://mbed.org/components/Seeed-Studio-SD-Card-shield-V40/.

just got data uploading to xively via wifi broad. It's awesome!

Weeks 3 and 4 Update

I've updated my CAN-BUS Shield driver project Notebook page which has more details and photos : Sophie's Seeed CAN-BUS Library Notebook Page

Thanks Sam and with that a re-writing I have been... I noticed you dodged question 3 though so I'll be keeping a weather eye out for the boys in blue .

This Week's Highlights:

• Re-writing and testing the CAN-BUS Shield driver with the same look and feel as an mbed driver, about half done
• Learning more of the C++ language (hey it keeps my bullet point count up!)

Work In Progress

• Finishing off the remaining functions
• Completing Doxygen API documentation

TO DO

• Create a Component page for the Seeed Studios CAN-BUS Shield
• Publish an Apache licensed library for Seeed Studio CAN-BUS shield
• I aim to do publish in the next 7 days even if incomplete

Some Time in the Future

Port Just4Trionic to FRDM-KL25Z system

The Inevitable Questions Section

1. I don't understand the attach functions, could anyone shed some light on the subject and/or share some web-links?
2. I had wanted to split my driver library into seeed_can, containing a SEEED_CAN class and functions and seeed_can_api, containing all of the driver functions but I can't work out how to tell seeed_can_api about the port pins and SPI interface declared in seeed_can. Can anyone share a method of passing this information from one cpp file to another?

Thanks in advance , Sophie x

1. Could you specify which part you don't understand? There are generally two attach functions, one for a normal function, one a bit more complicated for a function called upon an object of a class. Often it is easiest to use the FunctionPointer class (standard within mbed) to do the attaching (you just make a FunctionPointer object, and in your attach functions you call the FunctionPointer attach functions). Then when you want the function to be called, you do functionpointer.call().

2. The seeed_can_api would be pure C functions? Or also a class? If they are C functions you will need to send the interface as function argument. You can wrap the different things you need to send it in a structure, so you only need a single argument for that.

Thanks for your tips Erik

1. Makes some sense to me, at least I grasp enough to know what I'm trying to achieve and what to search for help with. I've written a little test program using Ticker's attach function to reset a Timer to help me understand what's what, but Im not sure which is the FunctionPointer object; 'minute' or 'void resetTimestamp()' ?

Serial pc(USBTX, USBRX);                                                // USB serial port TTYACM0
Ticker minute;
Timer timestamp;

void resetTimestamp()
{
    timestamp.reset();
}
int main()
{
    minute.attach(&resetTimestamp, 60.0);
    while (1) {
        printf("time: %05d", i, timestamp.read_ms());
        pc.getc();
    }
}

2. Yes, seeed_can_api contains pure C functions and using a struct made perfect sense right up to the moment I tried to actually do it. At the moment my class constructor looks like this:

private:
    SPI         _spi;
    DigitalOut  _ncs;    
    DigitalIn   _irq;

SEEED_CAN::SEEED_CAN(PinName ncs) :
    _spi(SEEED_CAN_MOSI, SEEED_CAN_MISO, SEEED_CAN_CLK),
    _ncs(ncs),
    _irq(SEEED_CAN_IRQ),
irq(SEEED_CAN_IRQ)
{
    // Make sure CS is high
    _ncs = 1;
    // Set up the spi interface
    _spi.format(8, 3);
    _spi.frequency(1000000);
    mcp2515_init(100000);
}

But as soon as I replace _spi, _ncs, _irq with a struct:

struct Seeed_MCP_CAN_Shield {
    SPI         spi;
    DigitalOut  ncs;
    DigitalIn   irq;
};
typedef struct Seeed_MCP_CAN_Shield _can;

and change the constructor to:

SEEED_CAN::SEEED_CAN(PinName ncs) :
    _can.spi(SEEED_CAN_MOSI, SEEED_CAN_MISO, SEEED_CAN_CLK),
    _can.ncs(ncs),
    _can.irq(SEEED_CAN_IRQ)
{
etc...

I get these errors and haven't been able to resolve them:

and so on for _can.ncs and _can.irq. I think the answer may lie in understanding Initailising base classes and members (C++ only) but it goes way above my head. I'd like to work out how to do this but if not I'll stick with what I have - a huge C++ file with public and private sections...

Any help much appreciated , Sophie x

How do I fork a library on mbed.org? On the original library page I see the number of fork'd projects, but nothing like "new fork" or such. I've imported the library and made my changes - is there anything like a "save back as fork'd" in the online IDE?

@Boris, If you import the original library, do your changes, and publish it again it will automatically ask if you want to fork it.

@Sophie. Regarding point 1, have a look at for example: http://mbed.org/users/Sissors/code/RTC/docs/tip/. There FunctionPointers are used to set interrupt functions. FunctionPointers are a real class, you make an object of them in your functions, and you can use that to call interrupts.

Point 2, I haven't done it like that before myself, so maybe I am talking nonsense. However I think it is a good idea to just keep your SPI objects, etc seperate. Then make a structure with pointers to those objects. Advantage besides that you shouldn't get the error, is that you only have to give those functions a few pointers, instead of copying the entire objects.

Done. Thanks very much!

Week 5 Update

I've updated my CAN-BUS Shield driver project Notebook page which has more details and photos : Sophie's Seeed CAN-BUS Library Notebook Page

Thanks again for yoru star pointers Erik . Point 2: I was eventually able to work this out, in essence I needed to include an initialiser with the struct:

 /// Type definition to hold a Seeed Studios CAN-BUS Shield connections and resources structure
   struct Seeed_MCP_CAN_Shield {
        SPI             spi;
        DigitalOut      ncs;
        InterruptIn     irq;
        Seeed_MCP_CAN_Shield(SPI _spi_, DigitalOut _ncs_, InterruptIn _irq_) :
            spi(_spi_),
            ncs(_ncs_),
            irq(_irq_)
        {}
    };
    typedef struct Seeed_MCP_CAN_Shield can_t;

Point 1 still has me stumped, despite your hints and following Andy Kirkham's FunctionPointer Cookbook article almost to the letter still no joy although using InterruptIn works!

This Week's Highlights:

A busy week culminating in publishing:

• An Apache licensed SEEED_CAN Library.
• A sample Seeed_CAN 'HelloWorld' program.
• A Seeed Studios CAN-BUS Shield Component page.

Work In Progress

• Getting the 'attach' functions working
• Tidying up and improving Doxygen API documentation

TO DO

• Port Just4Trionic to FRDM-KL25Z system
• A HID USB device interface for faster BIN file transfer and programming since the FRDM-KL25Z does not have a storage disk
• Maybe porting this OBDII Cookbook project

Sophie x

Week 6 Update

I've updated the CAN-BUS Shield Component and my Notebook pages which have more details and photos .

This Week's Highlights:

I've released an update to the library:

• Interrupts and 'attach' functions are now working, see the Week 6 entry on my notebook page for more details...
• A number of new functions and additions to others to extend the API's capabilities.

Work In Progress

• Getting the 'attach' functions working.
• Improving Doxygen API documentation.
• Porting Just4Trionic using USB HID interface instead of virtual USB COM port for communication and file transfers.

TO DO

• Maybe porting this OBDII Cookbook project

Sophie x