 | | Re: is it possible to remove lnp_handler while running ?
|
|
heh.. tried that.. no luck :( sigh..after yet a couple of hours trying to figgure this out, im 99,99% sure that the problem is in lnp_addressing_write. could this be that the function is not thread safe ? but then again i have protected the function (...) (22 years ago, 16-Jul-02, to lugnet.robotics.rcx.legos)
|
| |
| | Re: is it possible to remove lnp_handler while running ?
|
|
"kenneth johansen" <kennethj@stud.cs.uit.no> wrote in message news:3D343FAA.172476....uit.no... (...) I imagine you could just do something like lnp_addressing_set_handler( PORT, (lnp_addressing_handler_t) NULL ); I'm also curious as to why (...) (22 years ago, 16-Jul-02, to lugnet.robotics.rcx.legos)
|
| |
| | is it possible to remove lnp_handler while running ?
|
|
another dumb question about lnp:) i was wondering if it possible to do something like lnp_addressing_remov...,handler); as opposed to lnp_addressing_set_h...,handler); after much debugging i think i have traced my problem to the fact that (...) (22 years ago, 16-Jul-02, to lugnet.robotics.rcx.legos)
|
| |
| | Re: Re: Scheduler patch
|
|
I have been thinking (and toying with some ideas) concerning tthe wakeup checking. It might be possible to do wakeup checking more often then between each timeslice. This would make msleep more accurate and provide better sensor handling. I know (...) (22 years ago, 16-Jul-02, to lugnet.robotics.rcx.legos)
|
| |
| | Re: Re: Scheduler patch
|
|
(...) Yea you're right. I wasn't thinking. /Joel (22 years ago, 16-Jul-02, to lugnet.robotics.rcx.legos)
|
| |
| | Re: detecting memory leaks
|
|
I've been experimenting with memory leak detection in the wake of recent discussions, and have some additional thoughts, including a potential kernel patch issue. This msg is a bit long, appologies. The proposed method of checking for memory leaks (...) (22 years ago, 16-Jul-02, to lugnet.robotics.rcx.legos)
|
| |
| | yet another question about lnp
|
|
thanx to mark falco and albert huang for helping me out with lnp_init. But now i have another problem. if i execute lnp_addressing_write at approximately the same time as i recieve data on the serial port, lnp_addressing_write does not return.. the (...) (22 years ago, 15-Jul-02, to lugnet.robotics.rcx.legos)
|
| |
| | Re: whats up with lnp_init?
|
|
(...) I ran into this when using the LNP library to emulate LNP in the RCX as part of emuLegOS (URL) emuLegOS contains a thread safe wrapper for the LNP library. It should be fairly simple to extract that code into your own library for use in non (...) (22 years ago, 15-Jul-02, to lugnet.robotics.rcx.legos)
|
| |
| | Re: whats up with lnp_init?
|
|
"kenneth johansen" <kennethj@stud.cs.uit.no> wrote in message news:3D31CF01.37F981....uit.no... (...) Kenneth, I'm not sure if I remember correctly, but lnpd as it is right now might not fare so well with reentrant code (i.e. pthreads) because the (...) (22 years ago, 15-Jul-02, to lugnet.robotics.rcx.legos)
|
| |
| | Re: RCX to RCX communication
|
|
"Luke Ma" <Luke_Ma@brown.edu> wrote in message news:Gz83nF.7D9@lugnet.com... (...) and (...) outputs. (...) eep. erm... we never posted RCX-RCX sample code up. never gave any of the students two bricks. and the LNP code up on our website has our own (...) (22 years ago, 15-Jul-02, to lugnet.robotics.rcx.legos)
|
| |
| | Running legOS under DJGPP Status
|
|
With increase discussion about running legOS under DJGPP I started investigating this process. The following is a status report of where I am and the steps I took to get there. Beware that I have jumped around some, left some tasks unfinished, and (...) (22 years ago, 14-Jul-02, to lugnet.robotics.rcx.legos)
|
| |
| | whats up with lnp_init?
|
|
i have 2 threads (pthreads), 1 that sends and 1 that recieves on my PC. both of these runs in while(1) sentences. so.. i thought lnp_init was to be run only once, but unless i run the lnp_init routine each time i want to send a message nothing get (...) (22 years ago, 14-Jul-02, to lugnet.robotics.rcx.legos)
|
| |
| | *** legOS new name - reminder ***
|
|
What is the better name for legOS? Is it osmOS or brickOS? Make up your mind and send your vote, either for brickOS or for osmOS, with the usual identification phrase, to legOS-namepoll@gmx.de The last day for your vote is Thursday, 18th. Regards, (...) (22 years ago, 14-Jul-02, to lugnet.robotics.rcx.legos)
|
| |
| | Re: RCX to RCX communication
|
|
(...) Mark, I was a TA(Teaching Assistant) for a course at Brown University that invovled building robots with the mindstorms kit. Go to the web site: (URL) and click on the link to take you to the normal page. Then go to the "LegOS" section fo the (...) (22 years ago, 14-Jul-02, to lugnet.robotics.rcx.legos)
|
| |
| | RCX to RCX communication
|
|
I have studied the sources on the WEB for LNP but have not found any examples of C or C++ code for RCX to RCX communication. I have two RCXs and would like to build something that takes advantage of 6 inputs and 6 outputs. Do you have a sample you (...) (22 years ago, 14-Jul-02, to lugnet.robotics.rcx.legos)
|
| |
| | Re: detecting memory leaks
|
|
In case anyone attempts to use the mm_defrag() posted previously... you will need the following update to mm_try_join() //! check for free blocks after this one and join them if possible /* \param ptr pointer to size field of current block \return (...) (22 years ago, 13-Jul-02, to lugnet.robotics.rcx.legos)
|
| |
| | Re: detecting memory leaks
|
|
Jason, Excellent points! I like where this is going. "Jason Clark" wrote <snip> (...) See below. (...) then (...) Yes, it uses mm_try_join() --- here it is: //! defragment free blocks /*! use mm_try_join on each free block of memory */ void (...) (22 years ago, 12-Jul-02, to lugnet.robotics.rcx.legos)
|
| |
| | Re: detecting memory leaks
|
|
(...) Please, post. (...) I'm guessing you defrag using mm_try_join()? malloc() uses this to defrag the beginning of the pool until it finds a big enough block (which can then be split again if its too big); Defragging during idle would save this (...) (22 years ago, 12-Jul-02, to lugnet.robotics.rcx.legos)
|
| |
| | Re: anyone know how to check free space on RCX?
|
|
(...) Thanks for conducting the test... being 200+ miles away from my RCX this was bugging me :). My sources (gcc-2.95.2) have the same #define... but with the following about 120 lines earlier: /* Make int's 32 bits. */ #define TARGET_INT32 (...) (22 years ago, 12-Jul-02, to lugnet.robotics.rcx.legos)
|
| |
| | Re: anyone know how to check free space on RCX?
|
|
John A. Tamplin, Jason Clark, Jochen Hoenicke and Michael J Ash: Thank you all for addressing these issues! It all make sense after reading the preceeding messages. I appologize for causing confusion. I am glad, however, to get it straight. ??So (...) (22 years ago, 12-Jul-02, to lugnet.robotics.rcx.legos)
|
| |
| | detecting memory leaks
|
|
In the thread "anyone know how to check free space on RCX?" the issue of checking for memory leaks was raised. I wanted to mention that I have some code that may help in that area. I wrote a function for the memory manager called mm_defrag() It (...) (22 years ago, 12-Jul-02, to lugnet.robotics.rcx.legos)
|
| |
| | Re: anyone know how to check free space on RCX?
|
|
(...) The header is ok, but int is 2 bytes = 16 bit. You can check this with this highly optimized program: #include <conio.h> int main(int argc, char *argv[]) { lcd_int( sizeof( int ) ); for(;;) ; return 0; } And in the kernel sources, mm.c says (...) (22 years ago, 12-Jul-02, to lugnet.robotics.rcx.legos)
|
| |
| | Re: anyone know how to check free space on RCX?
|
|
(...) This can't be right. I'm about 99% sure that all of the ints I've used with my legOS programs have been 2 bytes. When using LNP to send RCX ints to a PC, for example, you have to use short on the PC end of things to make it all work right. (...) (22 years ago, 12-Jul-02, to lugnet.robotics.rcx.legos)
|
| |
| | Re: anyone know how to check free space on RCX?
|
|
(...) My sources (gcc-3.0) say: #define INT_TYPE_SIZE (TARGET_INT32 ? 32 : 16) A short experiment revealed that sizeof(short)=sizeof(int)=2, sizeof(long)=4. So int is normally 16bit. Only with the switch "-mint32" I get 32 bit ints. This is with a (...) (22 years ago, 12-Jul-02, to lugnet.robotics.rcx.legos)
|
| |
| | Re: anyone know how to check free space on RCX?
|
|
(...) According to config/h8300/h8300.h in the gcc sources, int is 32bit for the h8 cross compiler. I believe the reason mm_free_mem() returns an int is because the memory manager stores the size of each free block as size_t, which is defined in (...) (22 years ago, 12-Jul-02, to lugnet.robotics.rcx.legos)
|
| |
| | Re: anyone know how to check free space on RCX?
|
|
(...) int is defined as the natural width of the processor, which on a 16-bit processor is 16 bits. longs are 64 bits on some machines as well, so you can't assume it is always 32 bits -- if your code cares, use sizeof. (...) 32-bit math on the H8 (...) (22 years ago, 12-Jul-02, to lugnet.robotics.rcx.legos)
|
| |
| | Re: anyone know how to check free space on RCX?
|
|
That is very interesting Jason. It is interesting that mm_free_mem() returns a 16bit value using a 32bit return code. Both int and long are 32bit value on most computers/compilers these days; short would be a 16bit value; and char would be an 8bit (...) (22 years ago, 11-Jul-02, to lugnet.robotics.rcx.legos)
|
| |
| | Re: anyone know how to check free space on RCX?
|
|
While the declaration for mm_free_mem is int mm_free_mem(void) The fact is that the RCX has only 32K of memory available. 32K in hex is 0x8000... there's never a need for more than 4 digits in hex. Looking at key_handler() in kernel/program.c (the (...) (22 years ago, 11-Jul-02, to lugnet.robotics.rcx.legos)
|
| |
| | Re: HOWTO Demo.c
|
|
Brilliant! Brilliant! It works! Many Thanks to Micheal Obenland and also to Steve Hassenplug Best Regards Shehryar "Michael Obenland" <obenland@t-online.de> wrote in message news:Gz1xAM.Inn@lugnet.com... (...) some (...) ---...--- (...) ---...--- (...) (22 years ago, 11-Jul-02, to lugnet.robotics.rcx.legos)
|
| |
| | Re: anyone know how to check free space on RCX?
|
|
Albert Huang, Sorry for the confusion. "most significant" = upper 16 bits and "least significant" = lower 16 bits (the free memory is a 32 bit value). If you write the values out, you will get the 32 bit value (both values are hex) ... for example: (...) (22 years ago, 11-Jul-02, to lugnet.robotics.rcx.legos)
|
| |
| | Re: anyone know how to check free space on RCX?
|
|
(...) v0.2.6) When you press the View button (with no program running) LegOS will (...) Joseph, what do you mean by most significant / least significant? I'm under the impression that those two calls just display the same value, in decimal first and (...) (22 years ago, 11-Jul-02, to lugnet.robotics.rcx.legos)
|
| |
| | RE: Re: Scheduler patch
|
|
Can someone please tell me how to unsubscribe from this group! Thanks, - Subir -----Original Message----- From: news-gateway@lugnet.com [mailto:news-gateway...net.com]On Behalf Of Ed Manlove Sent: Wednesday, July 10, 2002 8:49 PM To: (...) (22 years ago, 11-Jul-02, to lugnet.robotics.rcx.legos)
|
| |
| | Re: Re: Scheduler patch
|
|
Joseph, Not to add too much work load, if you have a chance could you give an overview of the proposals out there for the task scheduling and sensor modifications (if any). This could be simply a quick list of lugnet.robotics.rcx.legos threads which (...) (22 years ago, 11-Jul-02, to lugnet.robotics.rcx.legos)
|
| |
| | Re: HOWTO Demo.c
|
|
(...) Well, that's much easier than all the crap I was going through. I guess it helps if you actually know what you're talking about. Thanks Steve (22 years ago, 10-Jul-02, to lugnet.robotics.rcx.legos)
|
| |
| | Re: HOWTO Demo.c
|
|
To solve your problems with demo.c, you sent me your source. There are some problems with it, but I think they are intresting enough to say something about them. The big problem you get with your program is caused by your main function: ---...--- (...) (22 years ago, 10-Jul-02, to lugnet.robotics.rcx.legos)
|
| |
| | ***legOS new name : deadline is 18.07.***
|
|
As Steve mentioned, the 23.07. is too late for the announcement of the new name at Brickfest. I think it would be great to do so, so I decided to make the deadline at Thursday, 18.07. I will publish the new name around midnight of the 18.07 and (...) (22 years ago, 10-Jul-02, to lugnet.robotics.rcx.legos)
|
| |
| | lnp error message..huh?
|
|
woolley thnx for the tip on checking the RCX memory.. now i have another question.. after having run continous messages back and forth between the RCX and my program on my PC for ~10 minutes. i get this error message: ---...--- Transmit error: (...) (22 years ago, 10-Jul-02, to lugnet.robotics.rcx.legos)
|
| |
| | Re: Re: Scheduler patch
|
|
(...) I'd built a maze solver. When the solver makes a step (for example forward) it uses the light sensor to search for a wall and the rotation sensor to measure the distance it has traveled. If a wall is hit, the solver steps back until it reaches (...) (22 years ago, 10-Jul-02, to lugnet.robotics.rcx.legos)
|
| |
| | Re: Re: Scheduler patch
|
|
"Joel Uddén" wrote (...) not (...) Actually, each task gets equal "wakeup" checking. The only difference between a low priority task and a high priority task is that the high priority task gets a larger time-slice when it is awake. This is not an (...) (22 years ago, 10-Jul-02, to lugnet.robotics.rcx.legos)
|
| |
| | Re: Re: Scheduler patch
|
|
(...) Thanks for the link, your solution of proportional timeslicing is more straightforward than mine which I like. The only downside would be that a high prioritized process would have it's wakeup conditions checked less frequently than a low (...) (22 years ago, 10-Jul-02, to lugnet.robotics.rcx.legos)
|
