 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 MMBasic V5.3b3
  Page 2 of 2 |
|||||
| Author | Message | ||||
| matherp Guru  Joined: 11/12/2012 Location: United KingdomPosts: 8592 |
Great news: but please don't spend too much time until my Snadpic arrives and I have chance to properly sort out the pinout SSD connections should be: D0 91 D1 94 D2 98 D3 99 D4 100 D5 3 D6 4 D7 5 RS 18 WR 19 RESET 41 GND and CS LOW 3.3V, RD and CS high LED unconnected if you have the backlight control on 1963_PWM Touch connections T_DO 72 T-DIN 11 T_CLK 10 T_IRQ and T_CS whatever you want |
||||
| isochronic Guru Joined: 21/01/2012 Location: AustraliaPosts: 689 |
Just a thought for the 100 pin version before it is set in stone- it may be worth conserving pins 57 & 58 for serial I/O use, they can be used with software and a single uart2 via RF2 and RF8 (and also a combo rx/tx via uart1 and uart4, from memory?). I have a board which has uses such 57/58/uart2 and is working well so far, there is also a Digilent WiFire EF MZ board likewise |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8592 |
Can you confirm you want RX on 57 and TX on 58? |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2290 |
correct me if i am wrong, but while the USB is on a fixed set of pins, the hardware uarts on the MZ can be configured to several different pins each - and there are several uarts, yes? it may be worth considering, in consultation with geoff, having an extension to the OPTION command for configuring all this. something like: OPTION UARTn RxD TxD COMx where n is the uart number from the MZ processor's perspective, RxD and TxD are the data pins you want to use, and COMx is the port name from mmbasic's perspective - COM0 corresponding to the serial console. with the looming increased hardware configurability and complexity of the micromites (especially MZ-based), along with a variety of differing development boards each containing different attached interface hardware, this sort of flexibility may become very necessary. already we are seeing this with SD card and colour LCD wiring. any given micromite board would then have a configuration file (supplied by the designer) to type in at the USB console before first use, containing option lines for SD, LCD, TOUCH, and UART configuration. worth considering? cheers, rob :-) |
||||
| WhiteWizzard Guru Joined: 05/04/2013 Location: United KingdomPosts: 2794 |
Rob, Not sure the purpose of COMx in your example above. Please 'expand' on an example if possible. I do like the idea of being able to configure' which UART the console uses though!  Currently I have external hardware in my 'TermMite' switching various inputs to the MM's console pins (to allow different connectivity methods); but with your idea this external hardware could be eliminated and everything controlled by software  WW For everything Micromite visit micromite.org Direct Email: whitewizzard@micromite.o |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2290 |
the MZ hardware (and also the MX) knows about some number of hardware uarts. these are referred to as UART1, UART2, etc. these numbers have no relationship to the COMx numbering used within mmbasic. for instance, geoff might configure a version of mmbasic with UART2 as the console, UART1 as COM2 and a software uart as COM1. so the link between UARTn and COMx is defined within the mmbasic interpreter. for each UART (UART1, UART2, etc) the RxD, TxD, and other control pins are selectable amongst several sets of pins. for instance, it may be possible for UART2 to use any of pins 5, 9 or 23 for RxD. these numbers are just made up as an example. so the link between each UART and the pins it uses for communications are defined within the mmbasic interpreter as well. currently, the mmbasic interpreter has hard-coded the connection between port name (console, COM1, COM2, etc) and the UART used (UART1, UART2, etc), as well as hard-coding the pin numbers to use for RxD, TxD, etc. btw, with the maximite (using an MX695 or MX795 processor) each UART is wired up permanently to a fixed set of pins, that can not be changed by the mmbasic interpreter. this is a limitation of the MX695/795. does this all make sense? cheers, rob :-) |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8592 |
Unfortunately the choice of pins is limited and is different for each function (as well as by number of pins). I thought about this but there would need to be a lot of code and it would massively increase the chance of users locking up the chip |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2290 |
it would certainly be complex to manage, but may turn out to be a necessity in order to avoid having many different variants of mmbasic for all the different hardware setups. what i am proposing is a set of OPTION commands that can only be set from the console (like the current colour LCD and touch configuration), not from within a user program. by my reckoning, it would be necessary to maintain a list of UART to COM associations, and for each entry that is a hardware UART a set of configuration register values and pins used. there would also need to be a separate table of 'pin blocks' maintained - one bit per physical pin. whenever a UART configuration is changed: 1. the old pins would be marked as free in this table, 2. the UART to COM association table updated, then 3. the pin block table updated with the new pins in use. the pin block table would then be used to lock out mmbasic commands from trying to use any pin that is in use by a UART. while it may take a bit of flash space to implement, there is 2 megs available in the MZ. i would not suggest porting this idea back to the MX micromites. cheers, rob :-) |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8592 |
Here is my proposed pinout for the 100-pin MZ for comment This is significantly different from the MX470 because of one main driving influence. All PIC32 chips have just one I/O port (PORT_B) with all 16 pins available. In order to get the highest possible speed when driving things like displays the best approach is to use a 16-bit parallel port. By re-organising the pinout as I have it will be possible to to connect to displays either with a 8 or 16-pin connection and it will be possible to include drivers into the firmware for displays like the SSD1289, ILI9325 and parallel ILI9341. As there are no PCBs yet developed for the MZ this major re-organisation won't impact existing designs. There are no changes to the 64-pin pin usage except that pin 38 is no longer available as an I/O pin. This pin is specified in the datasheet as specifically for USB use if USB is enabled so shouldn't be used for general purpose I/O. My development board for the 100-pin MZ is the Snadpic so the list includes the connections for the on-board SDcard (SPI4 + CS + CD) 1 G15 Analog 2 A5 Analog 3 E5 Analog 4 E6 Analog 5 E7 Analog 6 C1 Analog COUNT 7 C2 Analog COUNT 8 C3 Analog COUNT 9 C4 Analog COUNT/IR 10 G6 Analog SPI2-CLK 11 G7 Analog I2C-SDA 12 G8 Analog I2C-CLK 13 VSS 14 VDD 15 MCLR 16 G9 Analog PWM1C 17 A0 Analog 18 E8 Analog 19 E9 Analog 20 B5 Analog SSD1963-D5 21 B4 Analog SSD1963-D4 22 B3 Analog SSD1963-D3 23 B2 Analog SSD1963-D2 24 B1 Analog SSD1963-D1 25 B0 Analog SSD1963-D0 26 B6 Analog SSD1963-D6 27 B7 Analog SSD1963-D7 28 A9 Analog 29 A10 Analog 30 AVDD 31 AVSS 32 B8 Analog B8 33 B9 Analog B9 34 B10 B10 35 B11 Analog B11 36 VSS 37 VDD 38 A1 Analog 39 F13 Analog COM1-EN/SPI3-CLK 40 F12 Analog PWM2B 41 B12 Analog B12 42 B13 Analog B13 43 B14 Analog B14 44 B15 Analog B15 45 VSS 46 VDD 47 D14 Analog COM1-RX 48 D15 Analog COM1-TX 49 Oscillator 50 C15 51 VBUS 52 VDD 53 VSS 54 D- 55 D+ 56 F3 USBID 57 F2 COM3-RX 58 F8 COM3-TX 59 A2 Snadpic-SD-CD 60 A3 61 A4 62 VDD 63 VSS 64 F4 SPI3-IN 65 F5 SPI3-OUT 66 A14 SPI2-OUT 67 A15 SPI4-OUT 68 D9 69 D10 SPI4-CLK 70 D11 SPI4-IN 71 D0 PWM1B 72 C13 SPI2-IN 73 C14 PWM1A 74 VDD 75 VSS 76 D1 SPI-CLK 77 D2 SPI-IN 78 D3 SPI-OUT 79 D12 80 D13 81 D4 Snadpic-SD-CS 82 D5 PWM2A 83 VDD 84 VSS 85 F0 COM4-TX 86 F1 COM4-RX 87 G1 COM2-TX 88 G0 COM2-RX 89 A6 KBD-CLK 90 A7 KBD-DAT 91 E0 92 VSS 93 VDD 94 E1 95 G14 SSD1963-RESET 96 G12 SSD1963-RS 97 G13 SSD1963-WR 98 E2 99 E3 100 E4 Analog |
||||
| WhiteWizzard Guru Joined: 05/04/2013 Location: United KingdomPosts: 2794 |
I like the way you have 'grouped' the pins for specific functions - should make PCB design 'cleaner'. Out of interest, which COM pins for console? For everything Micromite visit micromite.org Direct Email: whitewizzard@micromite.o |
||||
| isochronic Guru Joined: 21/01/2012 Location: AustraliaPosts: 689 |
Uh, TX (outbound from pic32) on 57 and RX (inbound to pic32) on 58 please |
||||
MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
These guys have video running on a PIC32MZ using the EBI interface. Pretty cool. https://www.youtube.com/watch?v=HwbVMnCwKCs Microblocks. Build with logic. |
||||
| isochronic Guru Joined: 21/01/2012 Location: AustraliaPosts: 689 |
(BTW) To test the USB wiring on my sn-7x board, I tried the 24M MM version software above, and was rewarded with the chevron prompt OK. Nice  It is running despite the pic being the EFG version instead of EFH - no crypto or CAN modules. (!) (ed) I replaced the 24 M crystal with a external clock (silicon resonator), it seems to be the usual method used in other MZ EF boards. |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8592 |
Chip versions A1 have an errata for using a crystal, A3 can use a crystal if, depending on speed, a very specific ressitor is used in one of the lines from the crystal. The oscillator has the advantage that it frees up a pin and works without issue. Oscillators are available cheap in 8-pin DIP packages (middle 4 pins not present) so easy to solder. the code should run fine on EFG, EFH, or EFM |
||||
| isochronic Guru Joined: 21/01/2012 Location: AustraliaPosts: 689 |
Yes there is a history of crystal problems. I saw a query asking a Microchip contact why they had used a silicon resonator on their boards instead of a crystal, and the gist of the reply was that while the crystal oscillator worked ok with high quality premium crystals, often the more ordinary 24 MHz crystals did not work reliably in practice and testing each crystals parameters was not really an option practically. Most of the available boards use the silicon resonators. I recycled one from a Microchip EC pim...size 2.5 x 2.0 mm !. Draws ca 5 mA but works much better. |
||||
| Page 2 of 2 |
|||||
 Print this page |
