On 7/2/07, Lawrie Griffiths <[EMAIL PROTECTED]> wrote: > 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.
I see. It's a little annoying to implement because of the screen model that splits the screen vertically every eight pixels, but not infeasible, by a long way. > 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. Right, I see the problem. Writing to flash requires disabling interrupts, but the flash write cycle takes more than 3ms, which in turn times out the AVR link. > 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. Well, Lego presumably knows the specified FMCN value for the flash chip, so it's be good to use that. You're saying that it doesn't work from NXJ? That is weird. > 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. The fix you implemented does circumvent the issue I described: starting the flash write immediately after the TWI goes idle (ie. when a transaction with the coprocessor finishes) gives you a full 3ms window in which to complete the write cycle before the AVR hangs up the link. That lets you use the spec'd FMCN value to write to the flash. I'd have to think about it, but there must be a more elegant way of achieving the same result. > 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. Hmm, from my memory of the USB spec, I don't see what you mean by serial. From my memory, the only thing that mattered was accepting the bus address set by the host, and declaring the correct vendor/product ID. But I may be confused, as I didn't implement the USB driver in our kernel, just helped debug it. > 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. So this would be pushing functionality down from java into C, to better handle bit twiddling. > > 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. A very good point. We had in mind to try to do this over regular I2C, but using the high speed port would be awesome. > > 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. Understood. It's true that for NXJ, it's better to let the VM handle task switching. > Is your kernel available as open source? Not quite, the source code was kept on a private repository because of the constraints of having it be a school project. I'm in the process of migrating it to a publicly accessible server and slapping license information on the source. So, it'll soon be. And as I used NXJ as a code and structural reference when getting started, it seems only fair to have it be under the same license (I don't think there is any copied code), so that NXJ can have whatever extra stuff we did. > BTW, are you subscribed to the developers list? Most of this discussion is > probably more relevant to that list. I'm afraid that I completely missed the existence of a developer list, as it doesn't appear to be listed on the Lejos web site. Where can I sign up? - Dave ------------------------------------------------------------------------- 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
