Hi David You wrote:
> Can you elaborate on what kind of graphics support you're thinking of? > We have no support for images. It would be nice to have a graphical menu like the standard Lego firmware. This needs support for some sort of image format. It would be nice to support png, but we will probably need to go for something simpler, like the format used to display the lejos start-up logo, or the format used by the Lego firmware. The limited Java graphics we have is done by setting pixels in a buffer in Java code and then overwriting the buffer used by the C LCD driver. This is rather slow, and means text and graphics do not co-exist very well. At the mimimum we need setPixel in C. It would probably be better to re-implement the methods for drawing lines, rectangles, ovals, etc. and the "fill" versions of them in C. We did look at other native implementations of Java graphics, but they were all a bit too complex. Most of this is not too hard - it just has not been done yet. >> Another problem is that the flash (ROM) versions of lejos NXJ has some >> problems, particularly when writing to flash memory. This seems to be >> related to the AVR link. I think I now have a solution to this, but it is >> not a very satisfactory solution. > > I think I can imagine the problem. Does the AVR link die while > writing? That happens on the kernel I helped develop as well, when the > system gets flooded with interrupts, enough to starve the lower > priority handler that does the link synchronization. Is it something > similar? > Yes, it is something like that. Waiting for the TWI link to the AVR to become idle, before switching off interrupts solved the problem of losing the AVR link, although it still occasionally happened. The problem is that flashing from the ROM version worked on some NXTs but not on others. Also different values of FMCN is the range 50-54 worked on different NXTs, but the theoretically correct value of 72 as used by the Lego firmware did not work. I have solved the problem by doing the following in flash_write_page :- 1. Mask the low priority interrupt that processes the AVR link. 2. Wait for the 1 millisecond interrupt to occur. 3. Call the AVR process directly 4. Wait for the TWI link to become idle 5. Wait for the 1 millisecond timer again 6. Disable all interrupts. 7. flash the block 8. Enable interrupts 9. Switch low priority interupt back on I don't really understand exactly what the problem was or why this fixes it, but there must be a better fix. This fix works on all NXTs tested so far, and works with FMCN=72 on ROM and RAM versions. >> Other drivers including the USB driver and Bluetooth driver need some >> more >> work on them. > > We have an interrupt-driver USB driver that mostly works (though it > also still needs work). The USB driver I wrote works fine, but is not interrupt driven and relies on the Java code calling usbRead frequently. I had difficulty making it work reliably, interrupt driven. It currently does not return a unique serial number. I probably need to make it return a serial number based on the bluetooth address, like the Lego version does, if it is to work with the standard Lego PC software, and with multiple NXTs connected by USB. > The Bluetooth driver is probably going to be > developed as part of a school project next term, so we could get it > to work with lejos as well. > Again the Bluetooth driver we have works well enough but has limitations. It is DMA driven like the Lego version. The C code is minimal and all the message protocol with the BC4 chip is handled in Java. The limitations are that data messages must have a two-byte length header, and this is inconvenient for Java streams. Also the MSB of the length is ignored, so messages are limited to 256 bytes. >> It would good to write a driver for the high-speed serial comms >> capability >> on sensor port 4. > > Are there any peripherals that take advantage of this yet? Developing > drivers is always more fun when there is something to drive on the > other end :-). > Charles's plan was to use this for fast NXT-to-NXT communication. > What about scheduling? Currently the scheduler is built into the VM. > Is there any point in bringing that down to the C level? Personally, > I'm planning to do this on my kernel, as the objective is to be able > to run C tasks, but I don't know how much use this would be to NXJ. > I think this would be rather a big change for NXJ, and not something we would contemplate at the moment. Is your kernel available as open source? BTW, are you subscribed to the developers list? Most of this discussion is probably more relevant to that list. Lawrie ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Lejos-discussion mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/lejos-discussion
