 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : MMBasic 4.4 Beta 5
  Page 2 of 2 |
|||||
| Author | Message | ||||
| cwilt Senior Member  Joined: 20/03/2012 Location: United StatesPosts: 147 |
My be you could extend the idea of calling subs and functions to setpin and I2C interrupts too?  |
||||
MicroBlocks Guru  Joined: 12/05/2012 Location: ThailandPosts: 2209 |
I thought i would miss that functionality and in some very time critical things it is maybe the only way. Still it would be beyond the scope the Maximite. I found that adding a small PIC for that specific task and connect it with I2C so that the Maximite is the 'Master' is much easier to do. The reason the computers in the 80's had that ability was because the basic was well... pretty basic. Manipulating hardware was not built in the basic language and the only way to get special things done was using machine code routines. Think about screen, sound, hardware manipulations. In MMBasic you have those available in the MMBasic itself. Microblocks. Build with logic. |
||||
| MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
Geoff, do you realize that by doing that you are entering a possible new way of programming in the Maximite.  
Everything could be event driven, just like the most modern languages do. Just like for instance node.js but then in Basic. No more loops monitoring pins, keyboard input etc. Now where is that 'donate' button on your website! Microblocks. Build with logic. |
||||
| Dylan Regular Member  Joined: 17/06/2013 Location: NetherlandsPosts: 81 |
First of all, http://tzblox.com/Documents: d:\Websites\ASP.NET\4.0\tzblox.com\DocumentExplorer.aspx.cs( 250,19): warning CS0108: 'DocumentExplorer.GetType()' hides inherited member 'object.GetType()'. Use the new keyword if hiding was intended. As could also be found (ahem) at that website, the implementation of MM/DM VGA/composite output - the hard part, if you will - is DMA/SPI, bypassing the MIPS M4K core almost altogether. I intend to buy Lucio's next edition (which I believe will be reasonably soon). But having enjoyed the 80's with ZX81, Spectrum, BBC micro, etc. as a kid, any kind of Basic - despite my own personal preference for Pascal which actually compiles nicely - is good enough. With the proviso that it can somehow go that bit further, even if that means loading what could insensitively be called dynamic link libraries (hell comes next, of course). Please note that I see learning about "feersum ennjins" as more interesting than actually doing something with them ;) |
||||
| MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
@Geoff, Currently there is a topic to connect a TFT to the Colour Maximute (should also work with the Mono) The OP mentioned [quote] What should be possible easily is making the timing and resolution constants variable (like CONFIG VIDEO HOR VERT LINE...), also padding bytes on/off. This will fit most displays up to WQVGA, even those with portrait orientation. For those "upright" displays it may be convenient to swap the x/y coordinates in the pixel setting C routine as well. I'm not shure if every graphic routine in mmbasic uses solely this routine, but if, it should be quite easy to change screen orientation. [/quote] I think it would with that modification then be possible to have multiple kinds of TFT screens connected. Also the remark about turning around x and y to get a portrait screen to work would be super if that is possible. Microblocks. Build with logic. |
||||
kiiid Guru Joined: 11/05/2013 Location: United KingdomPosts: 671 |
Coming out in 2014 http://rittle.org -------------- |
||||
marcwolf Senior Member Joined: 08/06/2009 Location: AustraliaPosts: 119 |
Wow.. Look away for a couple of weeks and a lot more useful stuff is adden. Many thanks Geoff Dave Coding Coding Coding.. Keep those keyboards coding.. RAW CODE!!!!! |
||||
| plasma Guru Joined: 08/04/2012 Location: GermanyPosts: 437 |
thx geoff. |
||||
| MOBI Guru Joined: 02/12/2012 Location: AustraliaPosts: 819 |
I know it is off topic but, Pascal was my language of choice (I still prefer it probably because I'm used to it). The last lot I used was Borland Turbo - DOS based. What do you use and are there more modern "free" versions (read - limited trial versions). I've had a few google looks to no avail. David M. |
||||
BobD Guru Joined: 07/12/2011 Location: AustraliaPosts: 935 |
I started off my higher level languages with Borland Turbo Pascal on the Microbee (Z80) and then on the PC. It was very handy on the PC. I can recall way back there was a famous virus called Michaelangelo and it was set to go off on a certain day (6 March 1992). I had one of my guys write a program in TP to make a few noises on the PC speaker along with some screen fireworks and then had him put it up as a lan logon script to go off on the day. Comes the day and all of the team were on deck early and we could hear all (hundreds) of the PCs beeping as they started up. I had to do some quick talking to get out of that. The CFO had it in for me for a while after that. There is a freeware Pascal around. Some time back I was going to install it but I never got to do it. I'll have a look for it. edit I could not work out which Pascal I was looking at but there are a few freeware compilers in this Wikipedia article. |
||||
| paceman Guru Joined: 07/10/2011 Location: AustraliaPosts: 1328 |
Just looking back through this Geoff and I didn't mention that the PWM out is working correctly now with V4.4B5, i.e. good resolution (no 0.2mS pulse width jumps) and driving the servo smoothly. The test code left in there writes "period = XXXX dc = XXX" continuously to the screen but the PWM output still runs correctly. Greg |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3165 |
A few of notes. - Someone suggested implementing loadable compiled code segments (like DLLs in Windows). It would be an enormous job to do this so it is unlikely to happen any time soon. - I would rather not add support for specific TFT LCD displays because there are too many variants and I would not be able to test them. The best way to accommodate your particular display is to download the source, make the changes and re compile. - It is also not practical to make all the video timing parameters adjustable, there are too many combinations that would crash the PIC32 and render the Maximite unusable. - Some suggestions (like interrupt subroutines) are in the new beta 6 version. Geoff Geoff Graham - http://geoffg.net |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2290 |
you could allow the vga parameters to be changed in RAM, so that when power cycled the originals would always be restored. then, once someone had worked out their parameters, they could execute a command to save them as 'user' settings in EEPROM which would override the ROM settings. as a second level of safeguard, when the 'enable composite' pin is asserted have the non-standard (user/FLASH) parameters ignored. if someone gets really stuck, they can assert the composite select, and execute a command to wipe the user video settings so that the ROM ones are then used. it would be a whole lot more available than requiring someone to recompile the source, and allow people to tinker with settings on the fly, perhaps even using a basic program to do interactive configuration. |
||||
| MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
As i understand it, changing those parameters are not the only things that need to be changed. If you change some values you would need to tweak the code. This is i think however only true for when generating a VGA or composite signal. I have read a few TFT controller datasheets and find that the timing is done differently and has a wide range. Many TFT have a "dotclock", this synchronises the datatransfer taking out the time critical factor. As long as you provide the right number of clocks vsync and hsync it should work. This is what i understand from the datasheet and the TFT that was connected by one of TBS members. Getting a monitor via VGA is much more difficult because you have no dotclock to synchronise the transfer of data. The timing has to be very exact because the dotclock in the monitor is running on its own. You can compare it with a UART that has a startbit and from that moment on an exact timing (baudrate) to read the value of a bit. The timing is done separately on the sender and receiver side and therefore must be exact allowing only for small deviations. With a uart the most you send are 8 bits of data and each is synchronised with a startbit. A VGA sugnal is synchronised with a HSYNC but then 800 RGB values have to be transfered in a very small timeframe. Being out of sync a few nanoseconds can already wreak havoc. A TFT is like VGA but then with an extra dotclock to synchronise the datatransfer and internal memory to keep all the screen data. So no more electron beam (or a simulated one) that can only 'remember' 1 pixel and with super critical timing. This is just theory, so treat it as that. 
Some more theory when using the RGB interface of a TFT is that it might be possible to transfer the whole screen to the TFT and then only update it when changes happen. With TFT screens that have more then one interface this is already possible when using an SPI, parallel, UART or I2C interface. Microblocks. Build with logic. |
||||
| Page 2 of 2 |
|||||
 Print this page |
