Messages

1

µTasker general / Re: Finding device with DHCP IP address

« on: December 03, 2009, 08:45:31 AM »

I have no idea about how Lantronix software works, but a co-worker suggested the following: If your user case allows to run a tool on a PC, it would be simple to either send a some kind of broadcast message to the local network asking all BrandX devices to identify themselves to the sender. Alternatively, you could brobe some obscure port and if you get correctly formatted answer, you found the device. There is only 254 addresses to brobe, that doesn't take very long.

Now, if I just want to type something like "local.coffeemachine" on a browser, things get hairy.

2

ATMEL^TM AT91SAM7X and AVR32 / Re: AVR32 UC3 Device Overview

« on: November 30, 2009, 03:35:58 PM »

AT32UC3A0512 in 144pin LQFP at Digi-Key: $7.20

3

µTasker general / Re: Scheduling algorithm used in utasker

« on: October 27, 2009, 12:23:44 PM »

Hi Mark,

Any updates or ideas on this front? In other words, could you change the simulator so, that there is a function for a task to call or some other solution to keep the simulation running even if a task doesn't return for a while? (I can put in scheduling calls in my tasks, but I can't make them run to the end in reasonable time.)

Regards,

Juha

4

ATMEL^TM AT91SAM7X and AVR32 / Re: uTasker V1.4 AVR32 project

« on: September 15, 2009, 08:03:53 AM »

Hi Mark,

If I just enable the LCD support on config.h, and do a clean and rebuild, the LCD works on the simulator. However, the LCD on EVK1100 is onSPI bus, so it is not very compatible with the current simulator; i didn't even bother trying, I'm sure it wouldn't work.

Is it possible to use the simulator on higher level? In this case we are talking about LCD, but you can take the question in general. Can the peripherals and functions be simulated on an API interface level. For example, use two different versions of "LCD_WriteCharacter(...)" (or whatever the "API" call is), one for simulator and another target? The motivation for this would be that the in my experience, the low level functions are relatively easy to build on target, the real issues are on the application logic and functionality, where the simulator helps enormously. Also, this would make it much easier to adapt the simulator to different hardware. In this case, I could take the LCD interface routines directly out of the Atmel provided stuff and not bother you with the details of an exotic LCD module.

Also, where are the API calls documented?

Cheers,

Juha

5

µTasker general / Re: Scheduling algorithm used in utasker

« on: September 11, 2009, 09:20:25 AM »

Hi Mark,

Thank you for the explanation. For this trick to work in the simulator, could the timer etc. simulation part be put in a routine of their own, let's say "SimulateInterrupts()"? Then the wait loop would become

while (IsSomethingReady()==FALSE)
{
#ifdef _WINDOWS
  SimulateInterrupts();
#endif
  uTaskerSchedule(); // let other tasks run
};

?

6

ATMEL^TM AT91SAM7X and AVR32 / Re: uTasker V1.4 AVR32 project

« on: September 09, 2009, 08:00:11 AM »

Hi Mark,

Thank you! Changing the pin got the network up and running! Now, I don't need to go and buy another board.  The rest of the differences look small enough that I can deal with them (number and location of buttons, different display and so on). Another issue solved.

7

µTasker general / Re: Scheduling algorithm used in utasker

« on: September 09, 2009, 07:33:31 AM »

>...(also the simulator can not work with it)...

Why not? (And can I overcome this somehow?)

>... in most cases it is possible to wait on an event rather than polling ...

But as I understand it, the task still has to run to the end.( This has more to do with the general design philosophy than the scheduling algorithm itself.) A co-operative multitasking is just fine in most cases, and neatly avoids the complications of a pre-emptive multitasking. Still, in my opinion/application, the requirement for the task to run to end is a big, (hopefully) unnecessary complication. As you said, it can be worked around with a state machine, but when the application conducts a kind of dialog with outside world, the state machine fast gets tens, if not hundreds of states and the code is a nightmare to read and maintain. I much rather write say something-wait for response-choose action-say something more-wait new response etc. style, where at each wait, other tasks get to run.

8

µTasker general / Re: Simulating custom peripherals?

« on: September 09, 2009, 07:19:21 AM »

Thank you! At first look, the com0com seems to be just what is needed for this task. Problem solved.

9

µTasker general / Re: Simulating custom peripherals?

« on: September 08, 2009, 01:20:11 PM »

There is an IR remote. for that, a keyboard might be enough, but the customer might want to see a group of buttons. Then there is an on-screen display. On Visual C++, the RichTextBox component has (more than) enough functionality for that. There is also an existing processor, that I don't really know how to simulate, maybe a Form with buttons, checkboxes etc to set and retrieve the status and send messages when changed. There are also a few buttons and a maybe a potentiometer or a slider (and an LCD, but that is there already).

10

µTasker general / Re: Scheduling algorithm used in utasker

« on: September 08, 2009, 01:00:39 PM »

The scheduling can be found in uTaskerSchedule() in uTasker.c.

It is based on state-event operation, where it is expected that each task only runs for a short time and always runs to the end.

In principle, and in normal operation, yes, but... I haven't actually tried this yet, but I did spend some time yesterday reading the code,  and I think it is possible for a task not to run at the end. I am on a different computer so I might get the details wrong (I don't have the code here to reference), but:

The scheduler calls the tasks only if they are ready to run. So, if a have a lengthy operation or have to wait for something, I think I can do this:

state= GetStateOfThisTask();  // remember the state
SetStateOfThisTask(STOP); // so the scheduler doesn't call
InitiateSomething();
while (IsSomethingReady()==FALSE)
{
  uTaskerSchedule(); // let other tasks run
};
SetStateOfThisTask(state);   // restore state

Am I missing something? I hope not, I want to do this. 

11

ATMEL^TM AT91SAM7X and AVR32 / uTasker as an AVR32 Studio project?

« on: September 08, 2009, 12:12:44 PM »

The simulator is great, but I think it is overly optimistic to think that I wouldn't need the JTAG ICE at all when the hardware arrives and I need to get all the peripherals working. Has anybody converted the AVR32 package to an AVR32 Studio project yet? I could do that myself (and I will, if I need to), but if I can save a day(?) of work by asking, I will be very grateful.

12

ATMEL^TM AT91SAM7X and AVR32 / Re: uTasker V1.4 AVR32 project

« on: September 08, 2009, 12:07:43 PM »

Hi Mark,

Thank you and congratulations for a really impressive package! Any plans to support the EVK1100? (Or should I just go and buy another board? ) I tried the package on EVK1100 as is, and it mostly worked. A LED blinked and serial port was talking to me. However, the network interface didn't work. I didn't (yet) try to modify the package for the LCD, but based on how well the system works otherwise, I don't think that would be that big an issue.

13

µTasker general / Simulating custom peripherals?

« on: September 08, 2009, 12:00:46 PM »

As noted in the filesystem replacement post, I am leaning towards picking Utasker for my next project, one of the main reasons being the really great simulator. However, the simulator obviously doesn't know about the peripherals in my project. How could I expand the simulator myself?

It is trivial to write something like

void AccessCustomDevice(...)
{
#ifdef _WINDOWS
  AccessSimulatedCustomDevice(...)
#else
  AccessRealCustomDevice(...)
#endif
}
The issue is how to write the AccessSimulatedCustomDevice(). It is up to me to decide how accurate simulation code I want to write (probably not very ), but how would I integrate that to the rest of the simulator? I am using Visual C++, and that is about the level I know how to do windows programming. However, the simulator isn't really a Visual C++ application. It does run under it and gives us a nice development environment, but there are no forms or other widgets. But maybe it is easily expandable? Am I hoping too much?

14

µTasker general / Replacement for uFileSystem?

« on: September 08, 2009, 11:47:25 AM »

Hi,

I am evaluating the uTasker for my next project, and so far, it looks like a winner. However, there are couple of issues I need to find or create. The application needs a filesystem with long filenames (at least 8.3, preferably true long) and directory structure; there is no way around this. There are filesystem libraries around (FAT and non-FAT). So, assuming the existence of a working filesystem library, could the uTasker system be made to work with that? Has anybody done that, and maybe could give me some guidance? If Mark is working with something like that, could you tell us about it? (I would hate to do a lot of work and next week, learn about an official, supported implementation of same...)

The web server, FTP and (if I decide it is needed) USB mass storage parts are likely those that need most work. I guess I could have an SPI chip in the hardware (not done yet) or modify the imaginary filesystem code to put aside a block for uFileSystem for parameter system and firmware updates. What else do I need to have a look at?

Thank you for your input!