Author Topic: General Comments  (Read 6576 times)

Offline beethoven62

  • Newbie
  • *
  • Posts: 11
    • View Profile
General Comments
« on: December 20, 2008, 08:05:44 PM »
Hi Mark,

I want to thank you for your previous and continuing support. I think uTasker is very promising. I had a few comments about the code that I hope you find useful. I've implemented or will be implementing them in my version of your code:

1) I've added the following to my header files so that I can mix C and C++ code. In addition, I make sure a header file is not included more than once in uTasker:

#ifndef __<HEADER FILE NAME>__
#define __<HEADER FILE NAME>__

#ifdef __cplusplus
extern "C"
{
#endif

<HEADER FILE CODE>

#ifdef __cplusplus
}
#endif

#endif    // #ifndef __<HEADER FILE NAME>__

2) uTasker has many many #ifdef directives or its cousins in the code. I found this rather confusing in trying to read the code. Especially in the SAM7X.c file. I've decided to break up files such as the SAM7X.c file into various files. Each of these files will contain one specific part of the system. For example, I am pulling out anything related to the timer peripheral into a file called, tc.cpp; anything related to the PWM controller to another file called, pwmc.cpp (similar to the ATMEL library files - AT91lib). This can be extended to higher level functions in uTasker. Yes, this will create many more files than you have now, but I believe it will eliminate many of the #ifdef directives. A file with a descriptive name is more visible that these directives. Also, instead of commenting in or commenting out a definition for a specific feature of uTasker, you can simply include or not include a file with this feature in a project build.

3) I've added the debug serial port DBGU to my code by modifying uTasker a bit. I can make this available to you if you wish.

4) I've been hoping to see a new service pack for the SAM7 that includes USB support. I plan to write this code if necessary. I can make this available to you as well.

Again, I find uTasker to be a wonderful project and I hope you continue your good work. I just want to be helpful in making it better.

Happy Holidays,

Johnas

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
Re: General Comments
« Reply #1 on: December 21, 2008, 12:39:50 AM »
Hi Johnas

Many thanks for your comments. I will review your ideas in more detail and see whether some of them can find their way into future versions of the project. Yes, there are a lot of defines. This may be a little overwhelming sometimes. It is certainly a result of the project growth over the years (at the beginning it was hardly noticeable but as the features and variations increase so does the complexity of maintaining a single project which can be fully configured for various needs - most permutations are possible and tested - and also for various processors. The same code can be compiled to run on various processor types and hardware. As the code grows the need for additional splitting into more manageable blocks also grows so improvement potential certainly exists (in the active development version there are already some new files to help this, but mainly for the simulator at the moment).

Note also that originally some evaluation versions of compilers also limited the number of files allowed in a project and this was also a reason why peripheral splitting was avoided. I believe that this restriction has now been removed from all evaluation resp. special edition compilers which the project supports so is no longer relevant.

The SAM7X development version now includes support for the debug unit. As you have probably found out yourself, it is very similar to the other UARTS apart from slight restrictions on the character lengths supported. Interrupt and DMA driven mode code is otherwise virtually identical (a special detail being that the DBGU interrupt is shared with the PIT interrupt [SYSIRQ]).

Note the following new USB document: http://www.utasker.com/docs/uTasker/uTaskerV1.3_USB_Demo.PDF
The USB development is split into 2 parts;
- the generic USB driver (which is hardware independent, transparently supports little and big-endian architectures and so reusable with various processors - but since different USB controllers use rather different operating methods this took a long time to reach the 'generic' state; i.e. a lot of experimenting and optimisation);
- and the HW driver (this is the part which belongs to the specific USB controller found in the chip).

The USB controllers can be very different from another and basically represent a completely new development and learning curve. The Coldfire HW driver is fully DMA based and very flexible with 16 fully configurable endpoints, but requires the SW to handle many details. The SAM7X controller is FIFO based and supports up to 6 endpoints with restricted uses (in terms of operating modes and FIFO sizes) but the HW controller handles several details autonomously (this is sometimes an advantage but sometimes a disadvantage since various operating details are only discovered by a lot of testing and trial-and-error).

In terms of the SAM7X SP4 version, there are 3 main problems which do require solving before it is released:

1) Although the USB demo basically does what it should there is sometimes a bad frame received when testing with streaming data from the USB endpoint to the RS232 bridge output (this is the most difficult direction due to the fact that the USB host wants to send the data as fast as possible but the RS232 output speed limitation requires flow control to be implemented). It is probably that the receiver ping-pong buffers are getting swapped (that is, the data in the two ping-pong buffers is somehow reassembled in the wrong order - this was a complication which also had to be solved in the Coldfire project). This needs to be analysed in more detail and a suitable correction found.

2) When streaming is preformed in both directions at the same time the flow control in the USB host->device direction negatively influences the speed of the device->host operation. This results in the throughput in the device->host direction to reduce noticeably, although no data content error results. This effect is not present in the Coldfire project so there must be a cause at the hardware level which needs to be identified and corrected.

3) The new Wireshark and Port simulation (used for USB simulation) support allows simulation files to be search and saved, making the simulator much more user friendly. But the GetOpenFileName() method used to open the file searching dialog sometimes causes an exception. Sometimes it works well and sometimes it crashes and will not operate correctly until the PC is started again (at least on Vista based laptop). On the Internet there are many discussions about problems with this function, including many horror stories about its use. None of the recommended fixes to the discussed problems have led to any improvements until now so this problem is causing a lot of lost time and delaying finalisation of the release. Any experienced Windows programmers are welcome to jump in here and offer a helping hand!!

If you are interested in helping iron out the last couple of USB difficulties in the SAM7X project you are welcome to the development code. This may be more useful than starting a new development, especially if you have not a great deal of USB development experience (the present development state represents work over a period of around 18 months and so probably a couple of man-months full time investment). I found the USB development many times more complicated than other driver developments and conceptional understanding a long process (maybe it just doesn't suit my thinking mechanism so well?)

You are welcome to contact me directly if this would be interesting for you.

Glad you are enjoying the project and thanks for the feedback!

Regards

Mark


PS. The new SP will also include new projects for Keil uVision3 and IAR5.2, in addition to the existing IAR4, Rowley and stand-along GCC. This should then cover most development platforms and thus promote the acceptance of the SAM7X project (getting to know the new IDEs and setting up new projects for all processor [not just SAM7x but also Luminary and NXP] is rather time consuming...).

PPS. I presently do not have a USB VID /PID agreement for the uTasker project with the SAM7X but will be looking into this with ATMEL (not a necessity for the SP release though). There is a VID/PID for the Coldfire project (see - http://www.utasker.com/forum/index.php?topic=352.msg1415#msg1415). An agreement is presently being accessed by Luminary Micro for the LM3Sxxxx project, where the port is planned around mid-January 2009.

« Last Edit: December 21, 2008, 01:00:16 AM by mark »

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
Re: General Comments
« Reply #2 on: December 29, 2008, 10:59:47 PM »
Hi Johnas

Please see the following for an update of the project status:

http://www.utasker.com/forum/index.php?topic=478.0

Regards

Mark