Well, sure… But for games it would be nice to have both.
Hello Guys,
I’m James - from Love Electronics. Firstly I’d like to thank GHI for welcoming me to your community and taking an interest in the Love Electronics range of .NET Gadgeteer products.
I’m glad you are interested in the Argon board. Some of you have great questions that I have have not detailed on the product announcement. I deliberately kept this more ‘to the point’ than have the post turn into a full product specification. I am working on a Wiki for the mainboard that will detail more specific information about the board and its capabilities.
To address some of your questions, @ Dejan asked what the max refresh rate on a 800x600 display. The Argon board supports displays up to 1024x768 resolution. The colour space is limited to 16bits (5:6:5) because the .NET Gadgeteer specification on the LCD interface. The good point about this is it trades image detail (colour reproduction) for speed and memory. Memory is not an issue, but the reduced data means we can make more use of the available bandwidth.
The maximum refresh rate is a function of many aspects, as the percent of memory bus time that gets eaten up fetching video display data takes away from the total bandwidth of the bus. Meaning refreshing the screen at its maximum possible rate will leave little time left for your application to pull data from the external memory. Getting a good balance however is easy. Lets give an example. If Dejan is wanting to operate a 800x600 TFT display at 16bbp, we have a framebuffer of 937.5KB that needs to get sent to the video every refresh. So what we can do now is choose the refresh rate we want the screen to operate at. Lets pick 32Hz to provide nice fluid movements to any graphics we have displayed. This means we need to be sending 29.3MB of data to the screen each second. This amount of data consumes 48% of dynamic memory (RAM) bandwith at the 60Mhz rate we are operating it at.
This is a significant chunk, however depending on your type of operation this could be quite valid. Unless you are doing very memory intensive writes you will experience no slow down here, as the only way of consuming this amount of memory bandwidth (which the LCD interfaces with very efficiently). This shows you can operate a 800x600 display with 16bbp colour information using less than half of the memory bandwidth of the board. If we are able to increase our memory access speed (something I am trying very hard to do with the current test boards) to 120Mhz, we could run the same screen at 64Hz consuming the same percentage of bandwidth! If you keep your refresh rate of 32Hz you consume as little as 23% of the memory bandwidth. As you can see - increasing memory bus speed is something we will be working very hard on before the release of the Argon R1, this is also the main consideration behind the high bus width (32 bits) of the memory interface. Although this has increased part cost and layer count we felt it was worth the decrease in margin. I have attached an image of the display operating at 64Hz on an 800x600 display when the memory bus is driven at 120Mhz.
Secondly, @ devhammer - to address the point about Analog interfaces. This was a tough choice to only support one Analog port, and to share it with the Touch controller. As you probably know, the touch controller requires analog pins, so it makes sense for them to be on the same socket. We did have enough pins to create a seperate Analog interface and Touch interface, but not for two Analog ports. Thus I decided that they should be combined. It seemed to me that the main use of the Analog Inputs were for user input, rather than sensor input. This input is much better described via the touch screen than a joypad or similar. For sensors - more and more sensors are moving to a digital interface, especially I2C. I thought rather than expose sensitive measurements over electrically noisy Gadgeteer cables, we should move to supporting more I2C sockets for this sensitive information. This is one of the reasons we have 3 I2C sockets on the Argon R1. Many of our modules coming in the next few months will be based on I2C.
Thank you all for the great feedback. If anyone does have any more issues with pre-ordering your boards, you’re welcome to contact me at info@ loveelectronics.co.uk
Kind Regards,
James Carter
Welcome James!
+1 to @ Architect
Welcome, James!
And thank you for providing some of the thinking behind the design. It helps to understand the reasoning, and it’s great to have more players in the Gadgeteer ecosystem. 
Welcome James…and great work BTW.
And have you guys noticed that it is OSH as well… 
@ Jay Jay,
Thats right, the schematics will be released when the board is shipped, and the software and drivers will be downloadable for you to compile yourself and make changes if you wish.
The LPC1788 .NET Micro Framework will be open source, free for hobby use but licensed for commercial usage.
James, thanks for the great info! Welcome to the forum. BTW, I didn’t see any support forums on your site. Where should people go to ask further questions & get support once the boards start shipping?
Good luck and thanks for helping grow the NETMF / Gadgeteer community!
Hi Ian,
Thanks for the feedback. I shall be putting up a support forum up in the coming weeks, at the moment we are fully focused on getting as much functionality written into the Argon R1 mainboard as we can before its release.
James
loveelectronics welcome and thanks for your answers. I have another question about LCD
You are say that your device support up to 1024x768 resolution. Do this mean that I can use custom resolution for example 1280x480 or is strictly limited to fixed resolution?
1024x768 = buffer size 1572864
1280x480 = buffer size 1228800
so my resolution will eat less memory than 1024x768…
@ Dejan,
Sorry about the below post, this was not researched properly. The LPC1788 LCD controller accepts line widths up to 1024, as this is a 6bit register value. Depending on how you drive the display (if you use DCLK instead of V_SYNC and H_SYNC) you may be able to trick the controller into driving this display, you would require some creative memory block allocation.
If I can find a screen with a similar resolution I shall investigate this.
It is worth saying that using up over 60% of the memory bandwidth with the LCD is not advisable. When driving large displays the refresh rate will need to come down.
Regards,
James
I have not attempted a custom resolution like this but I can think of no reason why this should not work.
If you want more information about LCD screen bandwidth you can download the calculator on the LPC1788 page from NXP. Just set the dynamic external memory bus to 32 bits and the memory speed to 60Mhz.
Here is the link to the download from NXP: http://ics.nxp.com/support/documents/microcontrollers/xls/lpc178x.lcd.bus.load.calculator.xls
Edit: Because the max width is greater than 1024 I will have to check the datasheet for you.
@ loveelectronics,
Great Site! its not often i come to site that is to the point, easy to navigate, with clear and concise info, and looks great.
So my complements to you on all that.
Any plans on making plugin modules yet ?
Ethernet, USB, TFT LCD & >200MHZ options are a must.
Something along the lines us possibly of using a mini PCI connector like this.
The board looks neat. Tons of memory, which is nice.
I didn’t catch the licensing details on this one.
Is it using an existing port of NETMF and Gadgeteer? If not, is that being contributed back?
Hardware design appears to be OSH due to the logo. Where can we find the design files/schematic?
Thanks! And congratulations on joining the .NET Gadgeteer community with a great first offering.
Pete
Hi Pete,
I’m glad you like the board. Thanks for welcoming me to the community.
The board is open source hardware, the schematics will be uploaded when the product is shipped. The port is a custom port for the LPC17XX Cortex-M3 line of microcontrollers from NXP.
This port is being contributed under a custom license and so will not be in the NETMF codebase. The code will be available for users to compile their own versions of the NETMF, however customers wishing to create products with the port will be subject to licensing.
Kind Regards,
James Carter
Bummer, but thanks for at least making it available for individual/hobby use.
Pete
@ Pete
Sorry to disappoint - but as GHI will attest - there is a lot of work that goes into a port.
This shouldn’t restrict any users that want to add their own native drivers into their own Gadgeteer boards, as you will be able to download the code and recompile it. It is just commercial products based on LPC17XX have the opportunity to save themselves some time and purchase this our port rather than re-write it over a few months.
@ James
I think it’s great. By chance, what compiler does your port support?
Thanks godefroi. We are optimizing the code for GCC. We personally are using Rowley Crossworks, as I like the debugger and IDE. I’m aware that there are more efficient compilers, however I get very good results with GCC optimized through Crossworks.
You do not need a Crossworks license to compile the code, as it should compile with any GCC compiler. If you are looking for an IDE to write native code and debug directly on the Argon mainboard (have you seen the optional SWD for JTAG connector?) you won’t go wrong with Crossworks (especially as you’ll be able to download our projects so you can press F5 and debug code immediately).
Can you please provide more details about that option? I only see free evaluation version, which means you will need a license after evaluation is over (30-days).
@ James: that’s a great feature, thanks!
@ Architect
To compile the code you can use any GCC compiler. To debug the native code via Crossworks you do need a license. If you have another debugger you of course can use that.
Hope that makes sense.