 | | Building and downloading NXT firmware
|
|
Hello Hackers, That's my first post to this group so I would like to introduce myself shortly: I'm a 34 year old german who has studied computer science some years ago. Being on the job for a few years I decided to go back to the university to get a (...) (17 years ago, 11-May-07, to lugnet.robotics.nxt.nxthacking)
|
| |
| | Deriving power from NXT® motor port A
|
|
This (URL) special cable> allows you to power external devices such as a a motor multiplexer or a wireless camera from your NXT. No need for external bulky battery box! (if your current consumption is low enough, 800mA max). Though plugged into NXT (...) (17 years ago, 25-Apr-07, to lugnet.robotics.nxt.nxthacking, FTX)
|
| |
| | Re: Using NXT Port 4 EIA-485
|
|
(...) Hi Juergen, Yes, I found this night the entries at Lego-Source-Code... and no line about P-NET-Protocol... My first thought was to implement a simple p-net-node at own MCU, but now I can try my own communication from NXT (master) to external (...) (17 years ago, 10-Apr-07, to lugnet.robotics.nxt, lugnet.robotics.nxt.nxthacking)
|
| |
| | Re: Using NXT Port 4 EIA-485
|
|
Hi Christian, (...) the RS-485 interface is directly connected to the AT91SAM7S USART, so you can choose the bit rate quite freely. (...) No, it is not necessary, P-Net is just a field bus which seems to be popular in Denmark, there are others which (...) (17 years ago, 10-Apr-07, to lugnet.robotics.nxt, lugnet.robotics.nxt.nxthacking)
|
| |
| | Re: Using NXT Port 4 EIA-485
|
|
(...) Hi, halfduplex is not the problem when connecting the NXT to an external MCU. My problem is the bitrate of 921,6 kbits/s. Simple cheap MCU like ATMega didn't support this bitrate (as far as I know). To add an external devices (e.g MCU+SD-Card (...) (17 years ago, 9-Apr-07, to lugnet.robotics.nxt, lugnet.robotics.nxt.nxthacking)
|
| |
| | RE: Using NXT Port 4 EIA-485
|
|
I've looked at implementing an interface for RobotC, but I've always struggled with why bother since there are no applications that connect to it. I wish LEGO had implemented an option to provide a logic level "RS-232" UART on port four. Yes, I (...) (17 years ago, 8-Apr-07, to lugnet.robotics.nxt, lugnet.robotics.nxt.nxthacking)
|
| |
| | Re: GCC vs. IAR compiler: Could GCC be tweaked to generate code as tight as IAR?
|
|
(...) I read a paper that attributed most of the code size increases in gcc generated code to the printf library - search for AN52-ARM-C-Benchmark.pdf to read the paper. Out of curiosity I built the firmware using the newlib libc and the gcc 4.1.1 (...) (17 years ago, 5-Apr-07, to lugnet.robotics.nxt.nxthacking)
|
| |
| | RE: Faster NXT LCD Screen Refresh
|
|
Change the init message for the LCD display driver to perform wrap around. Offset 12 in the following structure from 0x88 to 0x89. Otherwise it will keep overwriting the same line. Your code snippet doesn't show it, but I'm sure you kept the call (...) (17 years ago, 4-Apr-07, to lugnet.robotics.nxt.nxthacking)
|
| |
| | Re: Faster NXT LCD Screen Refresh
|
|
(...) Could you be a little more specific regarding the changes you made to this method: UBYTE DisplayUpdate(UWORD Height,UWORD Width,UBYTE *pImage) { static UWORD State = 0; static UWORD Line; if (State == 0) { if (DisplayWrite(CMD,(U...itString)) (...) (17 years ago, 4-Apr-07, to lugnet.robotics.nxt.nxthacking)
|
| |
| | NXT Bluetooth Message Performance
|
|
Any have any experience with communicating over Bluetooth with 'master' connected to more than one NXT? If so, can you share any performance results? My guess is that it is very slow. My expectation is that when there is one master NXT and two slave (...) (17 years ago, 4-Apr-07, to lugnet.robotics.nxt, lugnet.robotics.nxt.nxthacking)
|
| |
| | NXT-to-NXT Messaging
|
|
The following is a good topic for this list. It deals with NXT-to-NXT messaging. It's based on an original post in the "nxtasy" forums. There's lots of room for improvement / enhancement in the NXT-to-NXT messaging. Especially when more that two (...) (17 years ago, 2-Apr-07, to lugnet.robotics.nxt.nxthacking)
|
| |
| | Re: Enhanced standard NXT firmware
|
|
(...) That's great news, David. I'm glad that you are having success using the new CommExecuteFunction system call. I haven't had a chance to test it at all yet personally but I was very confident that it would just work seeing as how exposing it (...) (17 years ago, 28-Mar-07, to lugnet.robotics.nxt.nxthacking, lugnet.robotics, lugnet.robotics.nxt)
|
| |
| | Re: Enhanced standard NXT firmware
|
|
"John Hansen" <afanofosc@comcast.net> wrote in message news:JF0sGr.M2w@lugnet.com... (...) implement (...) big snip Great job John. And thank you especially for CommExecuteFunction. I couldn't believe that Lego didn't allow a way to make a Bluetooth (...) (17 years ago, 28-Mar-07, to lugnet.robotics.nxt.nxthacking, lugnet.robotics, lugnet.robotics.nxt)
|
| |
| | More firmware enhancements
|
|
I have implemented OP_WAIT and a variant of OP_WAIT which takes a variable rather than an immediate numeric value (which in nbc is called "waitv"). I also modified NBC to accept a command line switch that tells it whether the firmware supports waits (...) (17 years ago, 22-Mar-07, to lugnet.robotics.nxt.nxthacking)
|
| |
| | Re: Faster NXT LCD Screen Refresh
|
|
(...) Okay, there's a little more to it than this. If you have a display that supports greyscales, it can control the level of the voltage jolt that's applied to each pixel during the actual refresh cycle. That way you get a smoother display with (...) (17 years ago, 22-Mar-07, to lugnet.robotics.nxt.nxthacking, FTX)
|
| |
| | Re: Faster NXT LCD Screen Refresh
|
|
(...) So that is how you did it. I was wondering about this ever since I saw the announcement. Incidentally, this would have been great cross posted to .color as well. <</robotics/nxt/?n=539>> Doug (17 years ago, 22-Mar-07, to lugnet.robotics.nxt.nxthacking, FTX)
|
| |
| | Re: Faster NXT LCD Screen Refresh
|
|
(...) This kind of works. In the first instance, you get two identical shades of grey. In the second instance (and I've tried this) you'd be surprised to see that the difference in shades between the two greys is actually very small. You really need (...) (17 years ago, 22-Mar-07, to lugnet.robotics.nxt.nxthacking)
|
| |
| | Re: Faster NXT LCD Screen Refresh
|
|
(...) I already got one shade of grey out of it by flicking between two images at the current rate: (URL) I use all those spare cycles to mix and merge screen layers in real time, so this image has full parallax scrolling. I've been trying to do (...) (17 years ago, 22-Mar-07, to lugnet.robotics.nxt.nxthacking, FTX)
|
| |
| | Re: Faster NXT LCD Screen Refresh
|
|
(...) <snip> (...) This is really interesting. If I understand correctly, to get colors, or at least shades of grey, you have to refresh the screen quickly and the "darker" the pixel, the more often it shows up in the pattern. For example, let's say (...) (17 years ago, 22-Mar-07, to lugnet.robotics.nxt.nxthacking)
|
| |
| | Faster NXT LCD Screen Refresh
|
|
Here's a trick to get a faster rate on the LCD display refresh. It currently takes 16 milliseconds to refresh the NXT LCD. 16 "messages" are sent to the LCD. One message is sent per millisecond. There are two messages from the ARM to the LCD for (...) (17 years ago, 22-Mar-07, to lugnet.robotics.nxt.nxthacking)
|
