doc-helmut wrote:the biggest lack of NXC so far was missing a network protocol keeping off data corruption, data loss and providing transmission control and direct commands for all I/Os and to send/receive large data packets (up to 32760 bytes all at once) , peer-to-peer, even for large nets (like e.g., 32 NXTs by rs485), maybe requiring 1 brick as a dedicated net server.
This is something which simply will not work with the NXT. Period.
EV3 is another story - I think it will do it.
But as far as I know your expectations there is one thing to keep in mind - things will take some time. Not only for realising also for the communication itself. In other words: There is no wormhole and I never heard from software using the tunneling effect to speed up communication.
Bye Marvin
Bye Marvin
- "I think you ought to know I'm feeling very depressed." - (Android Marvin in "The Hitchhiker's Guide to the Galaxy" by Douglas Adams, 1978)
- "I think you ought to know I'm feeling very depressed." -
...Marvin?
I never heard from software using the tunneling effect to speed up communication.
imagine, communication was based on sort of particles....
This is something which simply will not work with the NXT. Period.
that was what I was afraid of (although JH once promised he would even try to change the fw for this issue.)
But for the NXT I abandoned all hope anyway.
mrblp wrote:
May I use the "standard" gcc-arm-linux-gnueabi which is included in ubuntu?
The main problem is libC dependencies (i.e., not backward compatible). My understanding (and I am not an expert) is that code compiled with an older libc will work with a system that has a newer libc but not the other way around. So if you build with a cross compiler that targets a newer libc than what comes with the EV3 OS then it will not work without some hacking. It is trivial to install the pre-built CodeSourceryLite distribution for Linux and use it. Guaranteed to produce binaries that run on the EV3.
Are you writing that one from scratch? Or is the new VM somewhat like the old one so you can adapt the nbc compiler?
Completely from scratch. There is nothing in the new VM like the NXT VM.
Do you know when this will be? I am very interested!
Sooner than LEGO wanted, apparently. As soon as I am told it is okay to release code derived from the LEGO EV3 firmware source code then I will get it online.
And to come back to the NXT: Will you ever publish the source code of the new firmware releases? I found the repository is still unchanged since 2012-02-somewhat and the test releases of the firmware are from 2013... OK, I am using leJOS for some time now but I am noisy
All changes to the enhanced NBC/NXC firmware that were not checked in to the mindboards source repository (is that where you are looking?) was lost when my external drive died back in March. I don't have the clear to EOL drawing options changes that I made anymore and I can't recall off-hand how I implemented that feature. Or the change to the strcat opcode. Probably other things I can't recall anymore.
afanofosc wrote:The main problem is libC dependencies (i.e., not backward compatible).
Oh yes, of course. It may work with the newer compiler - specially when the whole firmware including the linux system is compiled with it. But why not take the easy way by using the code-sourcery compiler? (Because I do not like free tools depending from companies...)
Completely from scratch. There is nothing in the new VM like the NXT VM.
The new vm is just half the lines the old one was I am still looking through it...
All changes to the enhanced NBC/NXC firmware that were not checked in to the mindboards source repository (is that where you are looking?) was lost when my external drive died back in March.
Oh no! Well, yes, that was where I am looking...
I don't have the clear to EOL drawing options changes that I made anymore and I can't recall off-hand how I implemented that feature. Or the change to the strcat opcode. Probably other things I can't recall anymore.
Perhaps we can help?
Bye Marvin
PS: I read about your sourceforge problems. Perhaps there is another option: Do you know savannah.gnu.org?
Bye Marvin
- "I think you ought to know I'm feeling very depressed." - (Android Marvin in "The Hitchhiker's Guide to the Galaxy" by Douglas Adams, 1978)
I uploaded a new test release zip of BricxCC tonight. It enables the "NXT Screen" tool which is currently called "Screen Capture" on the Tools menu.
In order to get this working with the standard EV3 firmware I had to resort to a bit of a hack. What I did is use BricxCC's support for writing and compiling native C arm-linux executables to create a small ELF binary that can be run on the EV3 to dump the /dev/fb0 frame buffer memory to an image file. I compiled/downloaded the "snapshot" binary to the /media/card folder on my EV3 (i.e., the root of the micro SD card) using BricxCC with one click. I could, alternatively, have saved the compiler output and then used the Explorer tool in BricxCC to drag and drop the snapshot binary from my PC to the EV3. With that binary on the EV3 I was able to add functionality to BricxCC so that it asks the EV3 firmware to launch the snapshot program via the System opcode and then upload the contents of the resulting snapshot.raw file to the PC and show its contents in the Screen Capture tool like I already was doing for the NXT.
Two things to keep in mind. First, at some point the standard LEGO firmware may disable the System opcode - there is a #define designed specifically for that purpose in the source code. Second, getting the screen image data this way takes a lot more time than just reading it directly from the display buffer via a firmware opcode like you can do with the NXT. It also appears to interrupt or otherwise cause the EV3 to refresh its display for some reason. As a result, I only allow auto refresh at much slower rates than for the NXT.
Please give it a try and let me know what you think.
I uploaded a new test release early this morning which improves the reliability of the Explorer tool when it comes to browsing different folders. Please consider downloading the new build and see if it changes your experience at all with respect to how the Explorer tool behaves.
Can you be a bit more specific about the problem? Is it a problem with the screen capture tool or the Explorer tool. It sounds like the Explorer tool but that it only happens when you are actively polling for screen image data? I highly recommend not polling very fast and it is possible that polling will interfere with other brick communication like browsing folders, depending on the timing of the events. Is this something where I should be able to reproduce the problem any time I browse folders in Explorer while polling in Screen Capture at 1 second intervals?
When I set to "Polling", I can not open the folder on EV3 brick, even I adjust the capture interval time from 1 sec to 5 secs. It opened and closed the folder automatically.
If I uncheck "Polling", I can open the folder and see the file list from the EV3 Brick screen.
