Author Topic: General comments as new user  (Read 10449 times)

Offline aaronlawrence

  • Jr. Member
  • **
  • Posts: 66
    • View Profile
General comments as new user
« on: December 30, 2009, 06:42:16 AM »
Hi,
Some comments on my experience as a new user.

1) There is no guidance in the docs on how to port uTasker to your own hardware.
The tutorials work through the demo on standard eval hardware, and adding software, but don't deal at all with the critical task of fitting it to your own hardware.
I'm gradually figuring it out from the config.h and other stuff but it's not very clear.
For example: where and how to I set up clocks? Ports? Timers? Interrupts?

2) The forum search sucks - it always searches for parts of words. For example, if I search for "hang" it also finds "changing".

3) The demo app is really too complex.
While it contains a lot of features and does work out of the box (which is initially encouraging) there is simlpy too much in the demo app for starting up. It also feels kind of monolithic, rather than modular.

Merry Christmas!! B)
Cheers

Aaron

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
Re: General comments as new user
« Reply #1 on: December 30, 2009, 04:28:18 PM »
Hi Aaron

1) The tutorial is specifically for working through the basics of the project in the simulator and on a standard board and details about customising it to other hardware is more suitable in other documents.
- your are right that there is no specific document for configuring to different hardware. For the moment I suggest using the other thread http://www.utasker.com/forum/index.php?topic=783.msg3466#msg3466 be used as a basis for a reference building up such content.
- there are several documents dedicated to specific topics (http://www.utasker.com/docs/uTasker/uTaskerHWTimers.PDF should give some details about timers, for example - note also that some details are quite HW specific and therefore there are usually appendixes giving examples on different targets)
- when something is missing (which it will always be) ask in the forum and you will always get a fast answer. Documents are also often created as direct requests for particular information - if no one asks for a particular document it probably won't be written since it does represent quite a large work effort and new developments take priority when there is no indication that effort invested elsewhere will be of interest.
- the demo project usually includes a particular module illustrating certain peripherals - these also work in the simulator - more a 'learning-by-doing' approach... eg.
- the file Port_Interrupts.h contains port interrupt demonstrations which can be activated or deactivated by the defines at the start of the file. In this case IRQ_TEST to enable or disable.
- the file ADC_Timers.h contains ADC and timer tests (they are together because timers are often used as ADC triggers), whereby there are a number of tests - all configured by defines at the start of the file. Note that the basic support for the peripherals can usually be enabled and disabled in the file app_hw_xxxx.h (app_hw_lpc23xx.h in your case) - SUPPORT_ADC, for example,  specifically enables all ADC support in the project.

2) Unfortunately I can't change anything in the forum since this is from Simple Machines. However I also found that this property of the search is not optimal. There is an advance search guide at http://docs.simplemachines.org/index.php?topic=58 which shows how to work with quotes to match phrases, etc. but it doesn't look as though they have a search for complete words only.
I also posted a comment about this there - they also have a forum where such themes can be handled. The forum is updated regularly with new SW from Simple Machines so this may improve with time.

3) Yes, this is something which is often said. It is a difficult subject because on the one hand some people may be a bit overwhelmed by it but others disappointed when it is simplified. On top of this, a very large amount of users do use the project as base for their own developments (there are in fact quite a number of products containing most of the standard application as platform for additional functionality). Also I have had feedback from some users who have started with a stripped down version and ended up building most of the removed functionality back in because it is usually needed anyway...

On a side note, the complete project runs on at least 7 processor families (fully compatible - it needs no adjusting apart from the correct processor define and the corresponding compiler) and one central project simplifies the management of all packages considerably. This is the main reason that it is solved that way - other solutions would vastly increase the overhead. This may not be of much concern for users of a single package but is an important overall properly.

However there is no problem with taking the demo project and accepting what it does (either stripped down by removing defines in config.h or not) and adding your own task. Simply work in your own task - the rest will generally not disturb it - to do your own work until you understand what you want to keep and what not. There is also a document with details about this here: http://www.utasker.com/docs/uTasker/uTaskerV1.3_user_guide.PDF

Finally, most packages now contain two applications. The demo application which tries to demonstrate most of the features and also contains many sub-demos which can be activated to show peripheral support (also for use as base for real work), and the serial loader project. The serial loader project is in fact also a good starting point for people who would like to start with something a bit smaller and simpler. It is a standalone project consisting or the watchdog task flashing an LED and a simple application task receiving input from a UART, which can of course be instead. By removing the application task you have a project just running the watchdog task, flashing an LED, which is about as simple as it gets... Generally I would suggest that this be used as alternative starting point, which should cover all tastes.

However there is a small problem in your case particular since you are using the LPC23XX project. This is just about the only project that is not supplied with the serial loader project due to the fact that the chips have an in-build serial loader....therefore it doesn't represent the solution that would otherwise have been ready. There is a new release planned for the 3rd. Jan 2010 including utFAT (SD-card) - see http://www.utasker.com/forum/index.php?topic=776.0 and I will see whether the serial loader can be added to the LPC2XXX package simple due to the fact that it can be used as simple project, rather than the fact than anyone would probably use it for boot loading (but maybe I'm wrong...;-)

Regards

Mark


Offline aaronlawrence

  • Jr. Member
  • **
  • Posts: 66
    • View Profile
Re: General comments as new user
« Reply #2 on: January 11, 2010, 11:58:17 PM »
Just an additional note here, the size of the demo project has also been a problem trying to isolate problems, because there is such a large amount of code. Even though a lot of it is compiled out, this is not obvious when examining the code so it's hard to tell which parts are really being used.

I've worked before on such projects, with massive #ifdef conditionals to handle multiple environments, and they are always painful to maintain.

I intend to delete most of the code from the uTasker sample project to get it down to a maintainable form...

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
Re: General comments as new user
« Reply #3 on: January 12, 2010, 12:23:07 AM »
Hi Aaron

The serial loader project was added to the package in the last release (about a week ago), with GCC build. This can be used as reference for a small project or starting point to add to.

Working with VisualStudio as editor helps projects with lots of #ifdef. It displays all non-active code as gray. Also it can shrink non-active code so that it is invisible (apart for a tab which can be clicked to expand it.

Regards

Mark

Offline dkg

  • Newbie
  • *
  • Posts: 48
    • View Profile
Re: General comments as new user
« Reply #4 on: January 12, 2010, 12:27:56 AM »
Working with VisualStudio as editor helps projects with lots of #ifdef. It displays all non-active code as gray. Also it can shrink non-active code so that it is invisible (apart for a tab which can be clicked to expand it.
Eclipse CDT does this too :)

Dave G.

Offline aaronlawrence

  • Jr. Member
  • **
  • Posts: 66
    • View Profile
Re: General comments as new user
« Reply #5 on: January 13, 2010, 06:42:25 AM »
Thank for the tips. Yes I know the IDE could be better, but Visual Studio doesn't offer integrated debugging on ARM does it? :)
In retrospect Eclipse might have been better than Rowley Crossworks but someone else went thru the selection process...

I've now deleted a lot of the code out of my project and its getting more managable.

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
Re: General comments as new user
« Reply #6 on: January 13, 2010, 02:01:50 PM »
Hi Aaron

I develop exclusively in VisualStudio (as do a lot of other people who have given feedback that this method has proved to work well for them too). That effectively means that all editing (at least) is performed there - the uTasker simulation project allows the code to be compiled (that is compiled with the VS C compiler and, optionally, with the GCC back-end so that there is always an executable available).

When debugging on the target (target debugging is typically a very small percentage of the overall work) then the favorite IDE is of course used - VS can not perform target debugging (the simulator can however run and test target code on the simulated device in 99% of cases and is much faster since there are no download times and the debugger has many features that are not [generally] available on a target).

While the IDE's own editors are getting always better they still can't really match with the VS editor in terms of features and ease of use (in my opinion, but with practice one certainly gets more out of one's favorite).

Basically, whether IAR, Keil, Crossworks or whatever else is used as debugging IDE, there is nothing stopping editing the code in another editor - if this has advantages. Once editing is complete just switch to the IDE window, compile, load and debug...

Regards

Mark