 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 : Micromite EXTREME b5v6, VGA
  Page 4 of 4 |
|||||
| Author | Message | ||||
| matherp Guru  Joined: 11/12/2012 Location: United KingdomPosts: 8592 |
This appears to be a disagreement you have with Geoff. He introduced the console and PS2 functionality on the MM+. I just included a VGA driver and extended the console to optionally use it. I don't understand why you think it is so bad for both capabilities to exist in the same firmware as long as neither compromises the other. Certainly neither PS2 nor console functionality impact the Micromite at all if not enabled. Why not also make them available on the Micromite? What is the downside? One issue with sprites is that Geoff isn't happy with the Maximite solution. If anyone wants to write a proper specification for a MMBasic I/F to Sprites then I'm happy to look at it. Remember though that without high-speed external memory we can't have a frame buffer separate from the display for the bigger TFT displays so there are limitations on what can be achieved. In answer to one of your later points, I have no intention of supporting EBI. This completely moves away from the single chip solution that is the essence of both the Micromite and Maximite There seems to be almost no use of CAN on the Maximite. Is the Maximite code interface what is needed? The problem with implementing CAN is finding a way to test it. I don't have any CAN devices lying around also it needs external tranceivers so moves away from the single chip solution. If anyone wants to implement a CAN solution then I'm happy to try and integrate it. This seems to be a specific requirement of yours but is in any case trivial to implement as a CFunction - why not write one and make it available? Most of these ideas relate to core MMBasic which is an area for Geoff rather than a thread about a port to a new chip This is a mixed bag of requirements PID is just a code loop run on a time scheduled basis - easy to do in Basic. Or if it needs to be very fast in a CFunction (I've already posted a PID CFunction) RF24L01 meets my criteria for inclusion, difficult to interface at the signal level, but there are so many different RF modules out there why chose the RF24L01. The RF guru is srnet and he doesn't use the RF24L01 There is certainly a need for a library of MMBasic support routines for all sorts of devices but there is very little out there in Arduino world that hasn't been developed for MMBasic the issue is access to the code that has been written. i.e. a librarian is needed - volunteers? Still unsure what is needed. IMHO it would be pointless to support say the BME280 as it is just an I2C device and just needs a MMBasic subroutine to talk to it. My point as above is that firmware support should be for devices that can't be interfaced in Basic (so WS2812 - possibly, BME280 - no) One problem with USB is that the PIcs only have a single USB port. This means you need an external OTG transceiver to have optional host/client capability and AFAIK these are all impossible to hand-solder. So, to be clear, whether rightly or wrongly, My port to the MZ is intended to stay directly in-line with Geoff's vision for the Micromite and will stay in lock-step with the MM+ releases and capability. I'm happy to consider implementing additional functionality where that relates to devices that will be generally useful and can't be interfaced in Basic. I have now proved that CFunctions on the MZ can directly use normal floating point. so double main(double *xx, double *yy, double *tt){ return (FPow((*xx + *yy) , *tt)) * 2.0; } works on the extreme. This, with the HW floating point, opens the way for advanced signal processing many times faster than the MM+ |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2290 |
the discussion seems to have become quite heated! from my own view of the 'mite ecosystem, the MZ2048 seems to be a worthy successor to the colour maximite MX695/795: 1. having basic code run directly from flash addresses the maximite's problem of graphics chewing up RAM (when driving a vga monitor). 2. we now have the micromite's excellent 64-bit integer support. 3. VGA output is there, something the MX processors lacked the resources to fully implement. 4. micromite C-functions are available for esoteric device support. 5. SD support is available. 6. the elegance of a single-chip design is retained. from what people have said the only two things lacking is CAN and sprites, and peter puts good arguments for both remaining absent until someone else comes up with a good solution. regarding CAN: would anyone care to produce a specification of a generic CAN implementation? my understanding is that one problem with CAN is that there are as many flavours of the protocol as there are devices that use it. can any CAN experts comment? regarding sprites: again, someone needs to produce a good specification. something that will operate both with and without an internal frame buffer. or provide a means of gracefully degrading sprite performance if there is no frame buffer. or put an argument for having sprites only available with VGA output. with 2mb of flash, many restraints have been lifted. in particular, the need to be ruthlessly selective about what features to include. and run-from-flash means there is plenty of RAM remaining free at 640x480 resolutions. peter: how practical would it be to have the number of VGA bit planes runtime selectable, ie: 2-colour mode, 4-colour mode, 8-colour mode? would an intensity plane (16-colour mode) be feasable? microblocks: if you want CAN, put forward a specification. whitewizzard: i can't comment about outside of nz, but over here 4:3 LCD monitors are cheap as chips and readily available 2nd hand at next to no cost. for a retro-80's computer a 15" 4:3 monitor is the obvious choice. even better if you could source a 13" one. rather than complaining about missing features, perhaps some of the members other than peter and geoff could sit down and start writing some code - or produce some specifications. geoff has put in many thousands of hours work coding, and peter is doing his best to catch up! it may be time for some others to also lend a hand. the source code licencing does not in any way prevent anyone from creating changes to the core code and submitting them to geoff for consideration. as always, just my own personal opinion. cheers, rob :-) |
||||
MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
In my view anything called embedded is not having a VGA monitor. A small LCD (or even larger) sure. Embedded also not really need PS/2 keyboard. Support for many kind of keypads or even arrays of switches is more likely to be useful. I, like anyone else just express a viewpoint. Mine is based on working with lots (100's) of beginners. The micromite is fantastic for that. Still it is not beating arduino for some reason. One of the reason is the library and endless examples. Hosting a library should be trivial but somehow it always ends up in some unknown corner. Geoff already has a site for his projects and even one for MMBasic. Seems like the best place. This forum also has facilities for that but understandably not front and center because the mites are just a part of the community. A CAN bus specification? The Arduino world already has it. Even sources available on github. The specs are sufficient for most cases and can be a template for more difficult uses. Github CAN Bus Arduino (This allows for example monitoring messages fom your car). With the library, breakout board it works (basic functions) within a few minutes. If that was possible with the mites, would that not be great? CAN bus is also good to use for communication between mites. My feeling is that every peripheral that is available in the chip should be available from BASIC. The whole discussion about what is used most is i think irrelevant as most projects are first defined what it should do and then suitable parts are sourced. Especially in the PIC world selecting a particular chip is done by searching on things like memory and needed peripherals. Sorry for the rambling. :) Microblocks. Build with logic. |
||||
| IanT Regular Member  Joined: 29/11/2016 Location: United KingdomPosts: 84 |
"Still it is not beating Arduino for some reason." I'm not in a position to comment (at all) on any of the technical stuff here but I used to earn my living selling large ticket items (S/W) for a well known IT company, so perhaps I can help a little from that perspective. My first comment would be that it is hard to 'sell' anything to anyone if they've never heard of you or your product. I've been aware of the Maximite for several years now but only because I 'found' it searching for another (PIC32 related) product. As far as I am aware, the Maximite & Micromite are virtually unknown here in UK (outside perhaps of a small group of 'retro' enthusiasts). I was therefore pleased to see MM mentioned in a recent Microchip newsletter but in many ways this is hitting the completely wrong audience (presumably 'professional' developers). Which brings me to my second point. When entering any market (but especially several years after your main rival) you really do need to understand your key product differentiators (or unique selling points if you wish) and to whom these USPs might be of value to (e.g. your potential core marketplace - Buyers & Users). At this point I will also add that there is obviously a large difference between a commercial product with funds and organisation behind it - and something like MM, which is more Geoffs "love-child" (please take that as a compliment Geoff) growing up in the company of some (shall we say) very fond Uncles. It seems to me that the current growth of MM (in Australia & NZ) owes quite a lot to the publicity provided by Silicon Chip. Unfortunately, SC magazine is not (as far as I'm aware) widely distributed in either the US, Canada or UK, the other major English speaking marketplaces. 'English' being important in this context because good quality documentation is crucial (and was something that helped attract me to the MM). To succeed, any product also has to find 'routes to market' and to do this, it is very useful to understand what & where those markets are. Reading this thread, I'm still not clear that anyone is thinking along these lines (except for Phil and his 'Education' focus) and it may well be that many here don't really care either. After all it's not a commercial project per-se and you probably just enjoy the technical challenges. Fine, nothing wrong with that - except that my impression is that most of you would like to see the further uptake and spread of MM. Sometimes these things happen under their own steam but usually they need a bit of help. Two thoughts for you. 1) The cheapest form of traditional publicity are articles published/placed in specialist publications (in fact they usually pay the contributor to do so) and this is a cost effective way to gain access to vertical markets. However, the best publicity of all, is Word of Mouth (one Happy User to a Friend or Colleague) - these days often involving Social Media & Special Interest Forums (such as this one). 2) Not every product can appeal to everyone across a wide base. Niche markets are usually easier to understand (and therefore address & penetrate). Phils' desire to have an even better 'Educational' solution would be a good example of market focus. He clearly needs to keep costs low, whilst offering an attractive 'learning' solution. But sometimes you can just stumble over opportunities (e.g. someone finds a good application for your product and word spreads). As an aside - I build large scale railway models (13.5mm = 1 foot) and have recently joined MERG (the Club I mentioned in a previous last post). I presented MM to the Thames Valley Area Group last Tuesday (I have therefore become what my former employer would call an "Evangelist"!). I joined MERG mainly to gain access to their CBus kits (and expertise). CBus uses CAN technology to communicate between the growing number of CBus boards now available. I wasn't aware that there were different 'flavours' of CAN but if a 'Super' Maximite/Micromite (with CAN drivers) was available, I would probably buy one just to see what I could do with it.... http://www.merg.org.uk/merg_resources/cbus.php Whereas, whilst I've seen (say) the 'Clock' projects, I wouldn't bother building one (I have lots of usable clocks around already). I'm not disparaging the clock projects at all but they are not offering me a 'solution' I need, although I understand that they do demonstrate the MM technology well. This month in MEW (Model Engineers Workshop) two Arduino projects were published. One was for an automated rotary table and ME folk who've never before considered an 'embedded' solution, will look at this and think "I might be able to do that". Arduino wins some more users because a) it's delivered a 'solution' some will need and b) people have been made aware that a solution exists. You need both solutions and awareness. OK, that's my two pennies worth - I'll shut up now and let you carry on the technical debate... Regards, IanT |
||||
| MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
Thanks for mentioning MERG and their CBus. Very interesting. I particularly like CAN for its solid messaging over simple cable. Should be able to use it for about 500 meters. With Arduinos i tested it over a total length of about 240 meters. It allows lots of nodes, can be repeated for larger distances and is pretty reliable. I am only aware of two flavors of CAN, and the difference is mainly speed. (i just checked and it is described in ISO 11898) A pretty good description can be found here: https://www.kvaser.com/can-protocol-tutorial/ Using CAN directly from Basic is impossible, the reason i would appreciate a port from the maximite to the micromite. Microblocks. Build with logic. |
||||
| WhiteWizzard Guru Joined: 05/04/2013 Location: United KingdomPosts: 2794 |
All Can we please keep to topic on this thread! For new feature suggestions then these need to be suggested to Geoff. Thanks For everything Micromite visit micromite.org Direct Email: whitewizzard@micromite.o |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 3661 |
Why is it impossible? The Arduino examples use the MCP2515 which is SPI. As SPI is available from MMBasic, then why won't it work? John |
||||
CircuitGizmos Guru Joined: 08/09/2011 Location: United StatesPosts: 1421 |
I'm willing to do that. To do that, though, I need people to send sample code. The last library grew because people were willing to send their samples. I'll start a library. Please send sample code. Email to: code@circuitgizmos.com Micromites and Maximites! - Beginning Maximite |
||||
CaptainBoing Guru Joined: 07/09/2016 Location: United KingdomPosts: 1985 |
I have only just last night launched such a library: http://www.fruitoftheshed.com/ It is free, ad' free and with a robust open licence. It's wiki based; lets not go back to a set of static pages or a zip file that someone has to maintain - historically, people have got enthusiastic in the beginning but then their interest moved on to other areas and they let it run down. The original ZIP library is currently undergoing conversion to this new platform. Wikis score over a single file for, at least, the following reasons: * No single "keeper" - Everyone can add articles at any time. * Everyone can police/correct/modify articles at any time. * Rich articles with pix & graphics to support the thinking behind. * Focused discussion. * Article history with roll-back. * Searchable within the wiki. * Searchable on the web (Bing, Google etc... ) hth |
||||
2001cpx Regular Member Joined: 03/10/2013 Location: CanadaPosts: 59 |
Hi, on MZ100,which pin is VGA-GRN-OUT ? (35?) Thanks! "Color Maximite,(Duinomite-Mega,Mini),CGmmStick,GCmicroboard2b,Micromite + explore 64,100,LCD backpack,Lcd Backpack V2,TFT Backpack,Micromite Extreme,Armmite L,F,H,CMM2" |
||||
| WhiteWizzard Guru Joined: 05/04/2013 Location: United KingdomPosts: 2794 |
Sorry - I can't confirm this as only used 64pinner MZs. Just checked other paperwork I have been sent from Peter but this pin seems to not be labelled. No doubt Peter will confirm pin number as soon as he reads this . . . . WW For everything Micromite visit micromite.org Direct Email: whitewizzard@micromite.o |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8592 |
On my current development environment it is pin 32 (RB8). I don't think this has changed since I last posted a version but ...... |
||||
| WhiteWizzard Guru Joined: 05/04/2013 Location: United KingdomPosts: 2794 |
Hi Peter, Just had it happen again with v15. Tried the above. PEEK returned 8A8. POKE did not recover red. WW For everything Micromite visit micromite.org Direct Email: whitewizzard@micromite.o |
||||
Grogster Admin Group  Joined: 31/12/2012 Location: New ZealandPosts: 9066 |
Probably a silly suggestion, but I guess you have tried another VGA screen and lead? My guess would be that you have......  Smoke makes things work. When the smoke gets out, it stops! |
||||
| WhiteWizzard Guru Joined: 05/04/2013 Location: United KingdomPosts: 2794 |
Hi G, It's an 'issue' that Peter is aware about and is something to do with an 'upset' SPI channel driving the red signal. As soon as the MZ is reset, the red signal is back!. We are stress testing the MZ to thrash things out, and this is just one of those annoying things that appears very infrequently; and seemingly at random. First time it happened I did suspect my soldering, then the lead. All those were initial thoughts, but this is an SPI issue; but just can't recreate for Peter to track down.  For everything Micromite visit micromite.org Direct Email: whitewizzard@micromite.o |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9066 |
Okey dokey. Smoke makes things work. When the smoke gets out, it stops! |
||||
| 2001cpx Regular Member Joined: 03/10/2013 Location: CanadaPosts: 59 |
Thanks!!!!,but in your post with pinout list,it s not in (GOOD JOB!) "Color Maximite,(Duinomite-Mega,Mini),CGmmStick,GCmicroboard2b,Micromite + explore 64,100,LCD backpack,Lcd Backpack V2,TFT Backpack,Micromite Extreme,Armmite L,F,H,CMM2" |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8592 |
Here is the latest pinout for the 100-pin 1 G15 Analog / Digital 2 A5 Analog / Digital 3 E5 Analog / Digital /PWM2C / TONE_L 4 E6 Analog / Digital 5 E7 Analog / Digital 6 C1 Analog / Digital / COUNT / PWM2A 7 C2 Analog / Digital / COUNT 8 C3 Analog / Digital / COUNT 9 C4 Analog / Digital / COUNT/ IR 10 G6 Analog / Digital / SPI2-CLK 11 G7 Analog / Digital / I2C-SDA 12 G8 Analog / Digital / I2C-CLK 13 VSS 14 VDD 15 MCLR 16 G9 Analog / Digital / PWM1C 17 A0 Analog / Digital 18 E8 Analog / Digital / TONE_R 19 E9 Analog / Digital / VGA-BLU-SS 20 B5 Analog / Digital / SSD1963-D5 21 B4 Analog / Digital / SSD1963-D4 / VGA-VSYNC 22 B3 Analog / Digital / SSD1963-D3 23 B2 Analog / Digital / SSD1963-D2 24 B1 Analog / Digital / SSD1963-D1 25 B0 Analog / Digital / SSD1963-D0 26 B6 Analog / Digital / SSD1963-D6 27 B7 Analog / Digital / SSD1963-D7 28 A9 Analog / Digital 29 A10 Analog / Digital 30 AVDD 31 AVSS 32 B8 Analog / Digital / SSD1963-D8 / VGA-GRN-OUT 33 B9 Analog / Digital / SSD1963-D9 / VGA-BLU-OUT 34 B10 Analog / Digital / SSD1963-D10 / VGA-RED-OUT 35 B11 Analog / Digital / SSD1963-D11 36 VSS 37 VDD 38 A1 Analog / Digital 39 F13 Analog / Digital / COM1-EN / VGA-BLU-CLK 40 F12 Analog / Digital / PWM2B 41 B12 Analog / Digital / SSD1963-D12 42 B13 Analog / Digital / SSD1963-D13 43 B14 Analog / Digital / SSD1963-D14 / VGA-RED-CLK 44 B15 Analog / Digital / SSD1963-D15 / VGA-RED-SS 45 VSS 46 VDD 47 D14 Analog / Digital / COM1-RX 48 D15 Analog / Digital / VGA-GRN-CLK 49 Oscillator 50 XTAL - unused 51 VBUS 52 VDD 53 VSS 54 D- D- 55 D+ D+ 56 USBID 57 F2 Digital / COM3-TX 58 F8 Digital / COM3-RX 59 A2 Digital / Snadpic-SD-CD /I2C2-CLK* 60 A3 Digital /I2C2-SDA* 61 A4 Digital 62 VDD 63 VSS 64 F4 Digital / VGA-GRN-SS 65 F5 Digital / COM1-TX 66 A14 Digital / SPI2-OUT 67 A15 Digital / SPI3-OUT 68 D9 Digital 69 D10 Digital / SPI3-CLK 70 D11 Digital / SPI3-IN 71 D0 Digital / PWM1B 72 C13 Digital / SPI2-IN 73 C14 Digital / PWM1A 74 VDD 75 VSS 76 D1 Digital / SPI-CLK 77 D2 Digital / SPI-IN 78 D3 Digital / SPI-OUT 79 D1 Digital / VGA_HSYNC 80 D13 81 D4 Digital / Snadpic-SD-CS 82 D5 Digital / PWM1A 83 VDD 84 VSS 85 F0 Digital / COM4-TX /CONSOLE-TX 86 F1 Digital / COM4-RX /CONSOLE-RX 87 G1 Digital / COM2-TX 88 G0 Digital / COM2-RX 89 A6 Digital / KBD-CLK 90 A7 Digital / KBD-DAT 91 E0 Digital 92 VSS 93 VDD 94 E1 95 G14 Digital / SSD1963-RESET 96 G12 Digital / SSD1963-RS 97 G13 Digital / SSD1963-WR 98 E2 Digital 99 E3 Digital 100 E4 Digital / Analog * Not yet implemented New hex to include BLIT and overlay text (VGA, SSD1963, ILI9341) and TONE coming soon |
||||
| MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
BLIT is interesting. In my VB 6.0 days i made a lot of use of the win32 BitBlt function. Especially the SRCINVERT (XOR) was interesting as it allowed to restore the background by writing the same graphic twice. A mouse pointer would then be easy to make. Microblocks. Build with logic. |
||||
| Page 4 of 4 |
|||||
 Print this page |
