 | | 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)
|
| |
| | pbLua Beta 3 - Available
|
|
All, pbLua beta 3 is available now at: (URL) This new version has the bug in the regulation fixed, and the default motor mode is brake, not float. I've also updated the API docs to correct errors (there are probably more) and added an install doc (...) (17 years ago, 22-Mar-07, to lugnet.robotics.nxt, lugnet.robotics.nxt.nxthacking)
|
| |
| | Re: The standard NXT firmware & the case of the missing opcodes
|
|
(...) I guess what I'm saying is '<<=', 'OP_ASL' and 'OP_LSL' are all the same thing (zero fill). '>>=' means either 'OP_ASR' (smear fill) or 'OP_LSR' (zero fill) depending on whether your target is signed or not. If you wanted direct equivalents (...) (17 years ago, 21-Mar-07, to lugnet.robotics.nxt.nxthacking)
|
| |
| | Re: The standard NXT firmware & the case of the missing opcodes
|
|
(...) Having used shifts in Z80 assembly before, I can see the uses of the different types. However, I can't see how I'd want anything other than arithmetical in the NBC opcodes. The only times I used logical, rotating, or with-carry-bit shifts was (...) (17 years ago, 21-Mar-07, to lugnet.robotics.nxt.nxthacking)
|
| |
| | The standard NXT firmware & the case of the missing opcodes
|
|
There are several opcodes defined in c_cmd_bytecodes.h which are missing from the VM implementation in c_cmd.c Here are the ones that are not implemented: //Family: Bit manipulation #define OP_CMNT 0x0A // dest, src #define OP_LSL 0x0B // dest, src (...) (17 years ago, 21-Mar-07, to lugnet.robotics.nxt.nxthacking)
|
| |
| | Re: Enhanced standard NXT firmware
|
|
... (...) Hi John, I just tried to load it and just tested the "Try-me" light sensor. It worked fine. Not so much help, but I can try some more another day. Good work. Rasmus (...) (17 years ago, 19-Mar-07, to lugnet.robotics.nxt.nxthacking, lugnet.robotics, lugnet.robotics.nxt)
|
| |
| | Missing links?
|
|
Hi guys, Are there missing any links in the "stable" section (the one with the links to RobotC, pbLua NBC etc) to the left of the forum (most likely since I put them there...)? I don't know if all can edit it but otherwise you can probably write to (...) (17 years ago, 18-Mar-07, to lugnet.robotics.nxt.nxthacking)
|
| |
| | Re: Enhanced standard NXT firmware
|
|
(...) I would have liked to have one permanently, but it seems a little steep. Last summer I got a limited edition (32KB or something) along with the an AT91 evaluation board. (...) Perhaps Section 5.1 is useful: (URL) I just tried to post but it (...) (17 years ago, 17-Mar-07, to lugnet.robotics.nxt.nxthacking, lugnet.robotics, lugnet.robotics.nxt)
|
| |
| | Re: Enhanced standard NXT firmware
|
|
(...) It actually was not a very big deal. I was familiar with the firmware source code since I had looked at it quite a bit since it was released, trying to figure out how to get it to compile with GCC. All the RIC bug fixes were things I figured (...) (17 years ago, 17-Mar-07, to lugnet.robotics.nxt.nxthacking, lugnet.robotics, lugnet.robotics.nxt)
|
| |
| | Re: Enhanced standard NXT firmware
|
|
(...) <snipped description> Holy crap John! You've been really busy! For anyone poking around in this forum, I can say that what John has done is pretty significant. I have written my own firmware for the brick so I know how much work must have gone (...) (17 years ago, 17-Mar-07, to lugnet.robotics.nxt.nxthacking, lugnet.robotics, lugnet.robotics.nxt)
|
| |
| | Enhanced standard NXT firmware
|
|
Over the past couple days I have used the IAR Embedded Workbench to implement some enhancements and bug fixes for the standard NXT firmware. The bug fixes are as follows: 1. RIC drawing code incorrectly checked the size of the OP_LINE structure for (...) (17 years ago, 16-Mar-07, to lugnet.robotics.nxt.nxthacking, lugnet.robotics, lugnet.robotics.nxt)
|
| |
| | Re: GCC vs. IAR compiler: Could GCC be tweaked to generate code as tight as IAR?
|
|
(...) OK. This is good info!!! It is hard to guess that this was the way to do it. It also makes some sense for LEGO to use their file manager to do this rather than having a second tool replicate a filemanager on the host and insert it at compile (...) (17 years ago, 15-Mar-07, to lugnet.robotics.nxt.nxthacking)
|
| |
| | Re: GCC vs. IAR compiler: Could GCC be tweaked to generate code as tight as IAR?
|
|
(...) Hi Dick Swan, That is a nice flexible way of doing it. I will see if I can figure it out in gcc. Thanks for the idea. (...) Well...I have -=Os on, which are all size reducing features. The actual "problem" can also be this packed stuff that we (...) (17 years ago, 15-Mar-07, to lugnet.robotics.nxt.nxthacking)
|
| |
| | Re: GCC vs. IAR compiler: Could GCC be tweaked to generate code as tight as IAR?
|
|
(...) LEGO is using a slightly older version of IAR Embedded Workbench. Maybe that explains it. Or maybe its a 1.03 vs 1.04 source code difference. (...) I have been told that the following is the standard operating procedure for generating the (...) (17 years ago, 15-Mar-07, to lugnet.robotics.nxt.nxthacking)
|
| |
| | Re: GCC vs. IAR compiler: Could GCC be tweaked to generate code as tight as IAR?
|
|
Regarrding overwriting the flash system. I encountered the problem of flash file system overwriting user code as well. It's because it is hard coded in the code the starting address of the file system. There's a constant named "STARTOFUSERFLASH" (...) (17 years ago, 14-Mar-07, to lugnet.robotics.nxt.nxthacking)
|
| |
| | Re: GCC vs. IAR compiler: Could GCC be tweaked to generate code as tight as IAR?
|
|
... (...) I have not done that. Well, just a little bit:-). The best one (not surprisingly) is the "-Os" optimization, which does this "Optimize for size. -Os enables all -O2 optimizations that do not typically increase code size." (...) I tried (...) (17 years ago, 14-Mar-07, to lugnet.robotics.nxt.nxthacking)
|
