Messages

3181

NXP^TM M522XX, KINETIS and i.MX RT / Re: SW uploads to SPI FLASH

« on: August 22, 2007, 04:41:32 PM »

Hi Kremer

The uTasker (Bare-minimum) Boot loader works exactly as yours does. The boot loader itself is entirely useless - it needs to be loaded together with the first application and the application is then responsible for loading the new code to the correct SPI FLASH location in the correct format.

This means that the boot loader is as small as absolutely possible (that is where the "Bare-minimum" comes from since it really only does that what is absolutely necessary to ensure that the function works reliably). However it ensures that it is not possible for a card to be left in an unusable condition - it checks that the new code is really correct (checks a signature and CRC-16) and then deletes the old code. It then copies the new code to its operating position before again checking its contents to ensure that there was no error during the copy. Only then will it delete the backup of the code so that it doesn't try to load it again at the next reset.
This means that it can always recover should there be a crash or power down at any part of the update process.

The uTasker demo project supports upload of the new code via FTP and HTTP Post method. Before the code is posted it is converted using a supplied utility so add a signature and the CRC-16 (this ensures that no malicious code can be uploaded since only the owner of the Boot SW knows the matching signature - configured on a project basis). It can optionally encrypt the code content so that it can be distributed in a form where the machine code can not be read and reverse engineered).

The only thing that can go wrong is if the developer distributes a new application code which then doesn't allow a subsequent update - for example the code is faulty and doesn't run or crashes when uploads are attempted - or in which the upload support has been removed or forgotten... But since this should only happen in a development environment (before a new release is really made) it is easily corrected by loading the correction using BDM.

The second major advantage of being able to upload complete project code is in the fact that all code can be upgraded, including the operating system and the TCP/IP stack. I remember when first starting out with the technique I found a bug which would cause uploads of files from a certain size to fail - I was testing uploads via the Internet and the test device was in another town. By compiling a stripped down project but still with the upload support via HTTP Post I could get the upload size small enough that it avoided the error. The new code had the correction in it so subsequently I could upload the complete project correctly. It did take a bit of time to realsie what was going on and checking the correction in the uTasker simulator before risking it but it was a good feeling to have been able to do a remote correction like that - it always makes me think of the Mars missions where hardware and software errors in the devices on the planet must somehow be overcome (although on a rather more modest scale...).

The next M5223X service pack includes the SPI FLASH based uploader support plus various other stuff is planned for the end of this week.

I couldn't get hold of any m25P40 so have only the AT45DB support at the moment. I didn't look at the difference but if I can get hold of a couple I hope to be able to add them to it for the next time. I wonder whether Freescale has an offering (seeing as it is used to update the code to a Freescale processor...)?

Regards

Mark

3182

Freescale^TM MC9S12NE64 / Re: Current readings when MAC/PHY running?

« on: August 21, 2007, 11:53:03 AM »

Hi John

This value is consistent with my observations when the PHY is in 100M mode (200mA).
When operating in 10M mode the current consumption is more or less halved (100mA).

In fact I think that the 10M mode is quite efficient - I have observed that external PHYs often require more or less the same current consumption in both 10 and 100M modes. Eg. Davicom DM9161A states 92mA from 3V3 at 100M and 72mA at 10M.

There are devices which are better though - the well known CS8900A required 55mA from 5V (MAC + PHY), but this is only 10M with no processor. On the other hand there are also worse - the Microchip ENC28J60 (SPI) interfaced requires typically 120mA..180mA in 10M mode (doesn't support 100M) and again this is without any controlling processor.

It is a fact that the NE64 gets quite hot so good thermal dissipation is important in the PCB design.

I have also used the NE64 with an external PHY (EXTERNAL_PHY_USED can be passed as a parameter when initialising the Ethernet interface) and in this case the device stays cool, confirming that it is the PHY which requires the power when operating.

Regards

Mark

3183

ATMEL^TM AT91SAM7X and AVR32 / Re: Using Open Source Tools with SAM7X and uTasker project

« on: August 14, 2007, 07:40:35 PM »

Emerson

I have the feeling that you are still not using the SAM7X.c file in the GNU_YAGARTO.zip.
Have you copied the sam7x.c to the hardware\sam7x directory?

If I open the file sam7x.c I find the following lines there where it is flagging an error and a warning:
Line 150 -   //#endif
Line 629 -                 else {
Line 629 is also in the interrupt routine PortB_Interrupt() and not in EMAC_Interrupt(), which begins at line 673.

Therefore it does look as you are compiling a different version of the code.

I will be Skype-Online this evening if it helps.

Regards

Mark
PS. Did the Olimex binary run on your board?

3184

ATMEL^TM AT91SAM7X and AVR32 / Re: Using Open Source Tools with SAM7X and uTasker project

« on: August 14, 2007, 12:16:00 PM »

Hi Emerson

The Rowley project uses libarm_enable_irq() but these are not found in the GCC as installed by YAGARTO - they are probably routines special to the Rowley libraries (although I haven't studied this).
Therefore SAM7X.c uses __irq_dis() and __irq_en() which are then supplied in the startup_gnu.s file.

I have just added my (development) version of sam7x.c, which I used to compile, to the zip file. The file is protected by the standard SAM7X project password so can be opened by all uTasker SAM7X users.

I just loaded the bin file to my AT91SAM7X-EK to see whether there is life and it started. I could load the web pages to its FTP server and then browse to its web server. So it doesn't look too bad at all. (Just as well since I haven't received the JTAG debugger yet...!)

I have rebuilt for the Olimex board (which you are using) and sent a binary to your private Email address - I don't have such a board here so couldn't check - you can load it using SAM-BA to see whether it also runs.

Good luck

Mark


P.S. For the YAGARTO build use the standard SAM7X project and service packs!

3185

ATMEL^TM AT91SAM7X and AVR32 / Re: Using Open Source Tools with SAM7X and uTasker project

« on: August 13, 2007, 11:50:32 PM »

Hi All

I have successfully compiled one of the demo projects in James Lynch's tutorial package but am still waiting to receive the Olimex JTAG debugger. I have had to change for the ARM-USB-Tiny (rather than the ARM-USB-OCD) due to the fact that the local supplier has only the Tiny in stock and Olimex is on holiday until the beginning of September. Never mind - I don't expect any disadvantages with it.

Here is a guide as to how to create a project in Eclipse for the uTasker. There are in fact different ways to do it (like importing all files to the Eclipse workspace) but this is the one that I prefer because it uses the project files directly - one word of warning is that the project view in Eclipse is not a project view as in VisualStudio (which users' of the uTasker simulator know well) where the project folders are virtual folders and the files are those included in the project (their actual location can be anywhere), but this is the REAL FILE SYSTEM on your PC. If you delete a file from the project it will be deleted from your hard disk, and not simply removed from the project!! You need to be a bit careful at the beginning but once you realise this you can use it as a sort of explorer to manipulate things on the hard drive.

1. Start Eclipe and set the working directory to anywher you would like it to be (this will be used as scratch pad and not for real project files).

2. File | New | Project...
Choose standard make C project

3. Enter the project name - such as "uTaskerV1.3"  (without the quotes)
but uncheck "use default location" and set the  uTasker directory as location. This will use the real directory directly rather than making a copy to the local workspace.

4. The further settings seem to be fine without any further configuration changes so click on "Finish" and the uTasker project will magically appear in the project view.
If you expand the project directory you will see that it contains all files and documents, etc. Don't worry that the project is going to build everything seen there because we will specify a make file to be used which defines the build details.

5. If you expand the sub-directories in the project view: Applications .. uTaskerV1.3 .. GNU_SAM7X the make file will be seen (it is called makefile and must have this name to work with Eclipse - as far as I can see).
Unless you have received a version of the project with GNU support from me directly (this is not yet included in the standard project and service packs) the GNU_SAM7X sub-directory will not be there. You can get a zipped version of this directory from the following link: http://www.uTasker.com/software/SAM7X/GNU_YAGARTO.zip
This also includes a startup file for use with GNN called startup_gnu.s and a development version of SAM7X.c. Place these in your directory \Hardware\SAM7X

To set this as the make file for building the project do the following:
In the make view (on the right hand side) expand the sub-directories again to the GNU_SAM7X directory and then right click your mouse.
Choose "Add make target" to make an 'all' build. This will allows a standard build, which will involve compiling only files which need to be compiled since they have either been modified or a header that they depend on has.
A green target will appear with the name 'all'
Then repeat but name the make taget 'clean' (make name and make target in the create dialog).
A second green target will appear with the name 'clean' and can be used to delete all objects in preparation for a re-build of the project.

6. Double click on the 'all' to build the uTasker project using the GNU compiler.

This will generate an S19 output and a binary output and show the size of the code and RAM use.
It also creates a project map file in the target directory Applications\uTaskerV1.3\GNU_SAM7X
The memory script file used for the build is called uTaskerV1.3.ld, also in the target directory.

Note that you may get a warning or two when compiling the standard project, which have been resolved in my working version. These are not serious warnings and just point out that parentheses could be used to help code clarity.
I don't know yet whether this build actually runs on the target - this will be the next thing to find out!

Good luck!!

Mark

Added note on 14.8.2007:

One small change to the standard Eclipse set up which I found useful was the following:
Initially changed files were not being saved when I compiled, and this can cause silly operator errors when not noticed (new build not including latest changes...).
So that modified files are automatically saved when rebuilding, the set up can be modified by opening
Windows | Preferences -> in Preferences dialog expand "General" and select "Workspace" then check "Save automatically before build".

Save this setting and then modified files are automatically saved when the project is built.

3186

Luminary Micro ^TM LM3SXXXX / Cortex M3 based processor with integrated EMAC + PHY

« on: August 13, 2007, 06:01:45 PM »

Hi All

Some one pointed out to me a chip from Luminary Micro (http://www.luminarymicro.com/home/home.html).
It is from their Stellaris family of processor with 25MHz / 50MHz Cortex^TM-M3 (new ARM) in 100 pin LQFP.
16..64k RAM and 64..256k FLASH.
Internal 10/100MHz EMAC + PHY!!
Various peripherals including UART, I2C, ADC, SPI, RTC - 5V tolerant I/Os etc.

Who knows more about it or has even ordered the evaluation board?

It sounds good - but is it too good to be true? It seems very new...

Any comments??

Regards

Mark

3187

NXP^TM M522XX, KINETIS and i.MX RT / SW uploads to SPI FLASH

« on: August 13, 2007, 12:05:29 AM »

Hi All

I have managed to add a boot loader to the M5223X demo project which allows SW uploads to an external SPI FLASH.
It posts the file to the start of SPI FLASH and the boot loader reads this and programs it to program FLASH.
I believe that it is compatible with AT45DB011B, AT45DB021B, AT45DB041B, AT45DB041D, AT45DB081B, AT45DB081D, AT45DB161D but I have only actually tested with AT45DB041B.
An encryption option is also included so that the distributed code is not readable at any stage until it is extracted by the boot loader to its final destination in FLASH.

I have had to increase the boot loader space to 4k since the SPI driver and FLASH driver are needed at the same time and the 2k mark was easily passed…

What I haven’t done is used the SPI FLASH for anything other than the SW upload so the application will still have to sort the general use out itself. My solution was to define a file (HS.bin in the demo project) which is diverted to the SPI FLASH rather than the internal FLASH file system. This works fine for the SW upload but is far from a general solution for application data saving and retrieval along side an internal file system!!

Nevertheless it enables full 256k (minus Bootloader and any file system space) SW uploads and so opens up some interesting new possibilities. This should be included in the next M5223X SP.

Regards

Mark

P.S. See also the general discussion about external SPI FLASH in  http://www.utasker.com/forum/index.php?topic=4.0

3188

µTasker general / Re: External EEPROM alternative to M95xxx

« on: August 13, 2007, 12:02:49 AM »

Hi All

I have managed to add a boot loader to the demo project (presently for the M5223X Coldfire) which allows SW uploads to an external SPI FLASH.
It posts the file to the start of SPI FLASH and the boot loader reads this and programs it to program FLASH.
I believe that it is compatible with AT45DB011B, AT45DB021B, AT45DB041B, AT45DB041D, AT45DB081B, AT45DB081D, AT45DB161D but I have only actually tested with AT45DB041B.
An encryption option is also included so that the distributed code is not readable at any stage until it is extracted by the boot loader to its final destination in FLASH.

I have had to increase the boot loader space to 4k since the SPI driver and FLASH driver are needed at the same time and the 2k mark was easily passed…

What I haven’t done is used the SPI FLASH for anything other than the SW upload so the application will still have to sort the general use out itself. My solution was to define a file (HS.bin in the demo project) which is diverted to the SPI FLASH rather than the internal FLASH file system. This works fine for the SW upload but is far from a general solution for application data saving and retrieval along side an internal file system!!

Nevertheless it enables full 256k (minus Bootloader and any file system space) SW uploads and so opens up some interesting new possibilities. This shoudl be included in the next M5223X SP.

Regards

Mark

3189

NXP^TM M522XX, KINETIS and i.MX RT / RTC in M5223X

« on: August 12, 2007, 09:51:55 PM »

Hi All

On the one hand the RTC (Real Time Clock) in the M5223X is a bit disappointing - normally one thinks of a battery backed up device with 32kHz crystal, time of day, week day, day, month, year and automatic months and leap year adjustments - but on the other hand it could well come in handy in certain applications.

The RTC is clocked by a 1Hz clock which is derived from the local crystal (25MHz typically) and is only operational when the CPU is powered. It is not designed for keeping the time but rather counting elapsed time - however it can be set to a known time, for example from the information from a Time Server.

So it was time that it became supported in the uTasker project. Here is a brief of how the new interface can be used and how it can be tested in the demo project. The new support will be included in the next service pack or is available on demand (in development version) before then. The simulator has also be updated to include the RTC.

Features

• The time (Day count from 0...64k, hours, minutes and seconds) can be set
• The present time can be read back - to nearest second
• A seconds interrupt can be configured
• A minutes interrupt can be configured
• A hours interrupt can be configured
• A days interrupt can be configured
• An alarm interrupt can be configured (matching day, hour, minute and second)
• A stopwatch interrupt can be configured (from 1 to 60 minutes, to the nearest minute)

These are more or less the capabilities of the RTC in the M5223X so the driver allows each to be simply configured. All of the events are interrupt events and any combination can be used at the same time - for example an alarm can be set, the stopwatch can be running and any of the other periodic interrupts can also be used [like seconds and hours]. Each event is dispatched to its own interrupt handler.

The easiest way to see how to use the interface is to try out the following demo code.

1. Add the define  SUPPORT_RTC to app_hw_m5223x.h
2. Enable define RTC_TEST in application.c

The following subroutine will be called to start the test.

Code: [Select]

static void fnTestRTC(void)
{
    RTC_SETUP rtc_setup;

    CONFIG_TIMER_TEST_LEDS();                                            // drive some LEDs for visibility
    TIMER_TEST_LED_ON();
    TIMER_TEST_LED2_ON();

    rtc_setup.command = RTC_TIME_SETTING;                                // set the present time to the RTC (this could be collected from a timer server and is a fixed value here)
    rtc_setup.usDays    = 5;
    rtc_setup.hours     = 3;
    rtc_setup.ucMinutes = 23;
    rtc_setup.ucSeconds = 53;

    fnConfigureRTC((void *)&rtc_setup);                                  // set the time

    rtc_setup.command = RTC_TICK_MIN;                                    // configure periodic interrupts - once a minute
    rtc_setup.int_handler = test_minute_tick;
    fnConfigureRTC((void *)&rtc_setup);                                  // set a minute interrupt rate (first expected after 7 seconds)

    rtc_setup.command = RTC_ALARM_TIME;                                  // set an alarm time
    rtc_setup.int_handler = test_alarm;
    rtc_setup.ucMinutes = 24;
    rtc_setup.ucSeconds = 14;
    fnConfigureRTC((void *)&rtc_setup);                                  // set an alarm interrupt rate (expected after 21 seconds)

    rtc_setup.command = RTC_STOPWATCH_GO;                                // set a stop watch time (minutes to nearest minute)
    rtc_setup.int_handler = test_stopwatch;
    rtc_setup.ucMinutes = 2;                                             
    fnConfigureRTC((void *)&rtc_setup);                                  // set 2 minute stop watch (expected after 67 seconds)   
}
Each event is given an interrupt handler which is called from the corresponding interrupt dispatched when the event occurs. For example test_minute_tick() is set to be called when the minute interrupt occurs.

Code: [Select]

// Interrupt once a minute
//
static void test_minute_tick(void)
{
    static int iBlick = 0;

    RTC_SETUP rtc_setup;
    rtc_setup.command = RTC_GET_TIME;

    fnConfigureRTC((void *)&rtc_setup);                                  // get the present time

    if (iBlick == 0) {
        iBlick = 1;
        TIMER_TEST_LED_OFF();
    }
    else {
        iBlick = 0;
        TIMER_TEST_LED_ON();
    }
}
When an alarm time occurs:

Code: [Select]

// Interrupt at alarm time
//
static void test_alarm(void)
{
    RTC_SETUP rtc_setup;
    rtc_setup.command = RTC_GET_TIME;

    fnConfigureRTC((void *)&rtc_setup);                                  // get the present time

    TIMER_TEST_LED_ON();
    TIMER_TEST_LED2_OFF();
}
and when the stopwatch counts down:

Code: [Select]

// Interrupt at stopwatch count down
//
static void test_stopwatch(void)
{
    RTC_SETUP rtc_setup;
    rtc_setup.command = (RTC_TICK_MIN | RTC_DISABLE);

    fnConfigureRTC((void *)&rtc_setup);                                  // disable further minute TICKs

    rtc_setup.command = RTC_TICK_SEC;                                    // change to second TICKs
    rtc_setup.int_handler = test_minute_tick;                            // re-use this interrupt routine
   
    fnConfigureRTC((void *)&rtc_setup);

    TIMER_TEST_LED2_ON();
}

The interrupt dispatcher is also so constructed that the Stopwatch and Alarm events are true single shot events so the user doesn't need to undertake any thing to ensure that there will not be multiple events generated over time.

Two LEDs are used to visualise the test process. The test works in the simulator or on the target boards and this is what it does - as defined by the configuration code and the interrupt handling as above:

1. The time is set to Day 5: Hour 3: Minute 23: Second 53 [5:3:23:53]
2. A minute interrupt is configured - the first is expected after just 7 seconds, when the minute counter overflows from 59 to 0.
3. An alarm time is set for 5:3:24:14. Therefore the alarm interrupt is expected 14s after the first minute interrupt.
4. A 2 minute stopwatch is started. Since the stop watch has a minute resolution it will count down the first time after only 7s and then will fire on the second minute - 46s after the alarm interrupt.
5. The stopwatch interrupt disables further minute interrupts, so only one minute interrupt is expected.
6. All interrups (excluding the stopwatch) read the present time (using the debugger the present time can be checked).
7. The stopwatch interrupt also enable a second interrupt (using the same handling code as the minute interrupt) so afterwards an interrupt once a second is expected.

The LEDs make this visible and so they do the following:

5:3:23:53 - LED 4:3 = ON:ON
5:3:24:00 - LED 4:3 = ON:OFF  (Minute interrupt)
5:3:24:14 - LED 4:3 = OFF:ON  (Alarm interrupt)
5:3:25:00 - LED 4:3 = ON:ON  (Stopwatch interrupt - clears minute interrupt and starts second interrupt
5:3:25:01 - LED 4:3 = ON:OFF (Second interrupt)
5:3:25:02 - LED 4:3 = ON:ON (Second Interrupt)
5:3:25:03 - LED 4:3 = ON:OFF (Second interrupt)
5:3:25:04 - LED 4:3 = ON:ON (Second Interrupt)
... etc. LED 1 will toggle every second.

Summary of commands used with fnConfigureRTC():
RTC_TIME_SETTING - pass the time to be set
RTC_TICK_SEC - enable seconds interrupt
RTC_TICK_MIN - enable minutes interrupt
RTC_TICK_HOUR - enable hours interrupt
RTC_TICK_DAY - enable days interrupt
RTC_ALARM_TIME - pass an alarm time and enable alarm interrupt
RTC_STOPWATCH_GO - pass stopwatch count down time (minutes) and enable stopwatch interrupt
RTC_GET_TIME - collect the present time
RTC_DISABLE - set together with other command to disable rather than enable interrupst (eg. RTC_ALARM_TIME  | RTC_DISABLE will disable the Alarm before it goes off)

Expect the support in the M5223X SP5 which will be available quite shortly.

Regards

Mark

3190

ATMEL^TM AT91SAM7X and AVR32 / Re: Using Open Source Tools with SAM7X and uTasker project

« on: August 10, 2007, 12:45:45 PM »

Emerson

James Lynch says that all of the JTAG tools he tried work well. The 'Wiggler' using the parallel port is however somewhat slower than the USB types - it can sometimes have problems with ground loops. The wiggler is however the least expensive solution (as long as your PC still has a parallel port) and it is possible to also build one yourself - there are probably various circuits for it in the Internet. In my case I have ordered the USB one because it should allow faster work.

Regards

Mark

3191

ATMEL^TM AT91SAM7X and AVR32 / Using Open Source Tools with SAM7X and uTasker project

« on: August 09, 2007, 11:16:12 PM »

Hi All

I am in the process of porting the uTasker SAM7X project to work with the tool chain as decribed by James Lynch in his article "Using Open Source Tools for AT91SAM7S Cross Development revision C".

This article and some tutorial files can be loaded from the ATMEL web site - the article is very readable and gives some background to the development of the various tools and a clear step-by-step of installing and getting them running. Therefore it is not worth me giving too much detail here since it is all available in neat and tidy form there. To get the document and the files simply do the following:
1. Go to the web site www.at91.com
2. Click on the register "Documents"
3. Find the document "Using Open Source Tools for AT91SAM7S Cross Development" and click on it.
4. It appears by itself under the title "Key Resources" so click on it again.
5. This will cause "Source package" as download option to appear. Click on this to download a 12.4MByte ZIP file.
In the zip file you will find the famous document (8.6M) which you can follow to obtain all software and install the Eclipse IDE.

This uses the YAGARTO package which is an extremely simple set of 4 executables which install the GCC compiler and libraries, plus all other bits and pieces necessary. It works under Windows without the need for Cygwin or any tedious searching for the various components needed. You can read more about the history of this in James Lynch's article - but it is really easy to use so do have ago.

In fact I have used Eclipse before (for the Coldfire) and I have also compiled the uTasker project with GCC but this path seems the best way to go to ensure that the complete package is really simple and useable.

I can't say how long that it will take until everything is finalised. The uTasker project will run on the ATMEL EVAL board when built with GCC but I know that Emerson had difficulties with this package so it is an oppertunity to clean up and solve any special problems involved.

One important subject is the JTAG debugger used. I studied the various options which are supported by the package and found that the Segger J-Link which I use together with my IAR compiler and IDE will work but it requires another license to work with the debugger [GDB server software]. This license costs $261 (on top of the J-Link price which retails stand-alone for $327). It is repackaged as the ATMEL SAM-ICE JTAG for $129, including the necessary GDB server software. So if you don't have one and want to use it then it seems logical to get the ATMEL offerings. One strange thing about the J-Link GBD server is that it can not program FLASH and so needs either another J-Flash software for $525 or the ATMEL SAM-BA utility.

Anyway I decided that it would be a good idea to try out another solution so have ordered the Olimex ARM-USB-OCD which also works very well (according to James) and is compatible with the OpenOCD daemon which is included in the package. This costs $69.95 and there is a smaller Hobbyist/Student version called the ARM-USB-Tiny for $49.95 (without the serial interface and 5V supply output that the OCD version has). I hope that this will arrive shortly so that I can confirm that it works correctly. In any case it seems to be a more sensible choice seeing as the SAM7X is most popular in the educational world and so will probably be the preferred parts due to its affordable price.

I will report here again as soon as I have some results. If anyone else is interested in being involved just let me known.

Regards

Mark

3192

ATMEL^TM AT91SAM7X and AVR32 / Re: porting uTasker to the winarmgcc

« on: August 09, 2007, 10:36:23 PM »

Hi Emerson

I have just installed the tool chain as described in James Lynch's latest "Using Open Source Tools for AT91SAM7S Cross Development revision C". I will create a new thread with more details to see whether we can get this working correctly with the uTasker project.

Regards

Mark

3193

µTasker general / Re: SSH / SSL

« on: August 08, 2007, 09:41:38 AM »

Hi

I don't know what the space requirements will be (it depends on which functions are used, and which ones these then also require) but this will be known once the required routines are linked into a test project. Most of the algorithms work with temporary memory on heap so the RAM requirements can only really be determined by running these routines (OpenSSL runs on a PC so I tend to use a manipulated malloc version to monitor this. On the target it is best to calculate about +20..30% RAM overhead due to memory holes which inevitably occur in the malloc managements.)

OpenSSL has been written by experts who have ensured that the code doesn't compromise security - that means that the code tends to be conservative. It is however not advisable to change things without detailed knowledge of the process that it is performing. The possible result of incorrect use of the available library routines or of changes to code are security holes in the system which compromises its usefulness. These holes can probably be detected by knowledgable hackers but not necessarily identified by programmers who are using the code incorrectly.

The use of the library involves some knowledge of the security issues involved and adherence to its guidelines to ensure that its purpose is retained. Therefore generally the program size will be dictated by the functions used in their standard form, with probably limited capability of code size optimisations.

Regards

Mark

3194

µTasker general / Re: SSH / SSL

« on: August 07, 2007, 09:13:13 PM »

Hi

Encryption is a complicated and wide topic so a general answer is not that easy.
Typically OpenSSL is used as the base of many such tasks - this is a complete open source library containing a wide range of the algorithms required and can be freely compiled and linked into any project (it is C-code - see the book "OpenSSL Network security with OpenSSL" published by O'Reilly - ISBN: 0-596-00270-X).

There are some uTasker based projects (POS) which have used parts of this, but not for encryption of a HTTP connection (HTTPS).

For small footprint devices the required memory space (both FLASH code space and RAM work space) can be a bit restrictive and some of the algorithms are rather processor intensive. For this reason an SSL tunneling technique may be suitable in some cases, which offloads the effort to a proxy. Take a look at the open source STUNNEL project at www.stunnel.org and its Internet draft at http://muffin.doit.org/docs/rfc/tunneling_ssl.html. This allows the devices themselves to use standard and simple unsecured HTTP connections within a secure SSL environment.

Regards

Mark

3195

NXP^TM M522XX, KINETIS and i.MX RT / Re: uTasker and USB host Implementation

« on: August 07, 2007, 12:25:44 PM »

Hi Neil

I took a look at the FTDI USB-UART kit.

From what I understand it allows a DIP format module to be located on your board with RS232 (I think at logic level) to be connected to the local processor, where the modul is either supplied locally or powered from the USB bus (when connected).

The processor communicates using normal UART to a host (PC with virtual COM) as if the UART were connected directly to a standard COM port. Possibly the baud rate can also be set a bit higher than a normal COM port as well.

The main advantage that I see of using such a module is that it allows PCs with no COM port to be connected via USB to use typical serial protocols. Of course if the processor can not do USB itself (or the software development investment is too high) it is a practical solution.

I too have a project where I have a serial protocol communicating with a PC program which was developed some time ago. The processor has recently migrated to a SAM7X with integrated USB. This is used to program the boot software (which is practical since it is very fast, a nice 'modern' solution, is in fact cheaper than RS232 since the USB socket on the board costs less that the otherwise necessary RS232 level converter and needs no further components since the USB PHY is also integrated in the chip). Also using USB for communication with the PC program is something which is being talked about.
1. because a lot of new PCs just don't have COM ports any more
2. because it is nice for marketing to write it on their feature list

As I mentioned, I am preparing to integrate a USB stack (initially on the M5222X) into the uTasker project (I have read several books and have several development boards ready and am in the process of ordering a USB analyser) but I don't intend to use it just yet for the PC communication in the SAM7X project. There are 2 main reasons.
1. The cards are in a fairly large machine and have two RS232 interfaces. I will hide a RS232-USB converter (one with a 1m cable and true RS232 which are very cheap in every PC shop) in the machine with a USB socket in the housing. This will allow users with no COM to connect using a straight USB cable (the user could also connect the RS232-USB converter to the RS232 interface if he/she wants) but from a marketing point of view he/she should usually believe that the straight cabel is enough...
2. I use RS232-USB adapters (the cheap ones from the local PC shop) and have found them quite good, but not perfect. Sometimes it is necessary to unplug them and plug them again - one that I have can hang in XOFF mode and then that is the only solution to get it going again. Basically I don't trust USB due to experience with unreliability, whereas the old fashioned COM ports have never given problems.

I believe that the FTDI USB-UART kit can be considered to be equivalent to my USB-RS232 cable (but smaller and located on the board without RS232 converter). I don't know about reliability. Once I understand the details better I hope to have the chance to analyse some of the USB problems that I have encountered to get an idea about where their cause is and whether they are due to bugs in the devices themselves, the host or basic flaws in USB itself.

Regards

Mark