 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]PIC32MX170F256B Support
| Author | Message | ||||
G8JCF Guru  Joined: 15/05/2014 Location: United KingdomPosts: 676 |
Does anybody know if/when Micromite support might be extended to the PIC32MX170F256B chip ? The PIC32MX170F256B seems to be identical to the PIC32MX150F128B but with twice the Program Memory at 256+3K and twice the Data Memory at 64K. This part would make for a really nice uMite. From Microchip direct, it looks like this part will start shipping 05-Sep-2014 with a one off price of around GBP 2.34 or about US$4.00 which seems very reasonable to me and almost nothing more than the '150F part, although I guess Microchip will drop the prices on the '150F once '170F parts start shipping. Peter The only Konstant is Change |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 3678 |
At a guess it won't be something Geoff rushes to do as there are more important things like taking a break and PIC32MZ, so why not ask for the sources and rebuild it? Are you hitting the limits because if not, and it doesn't seem people are, why ask? Have you tried to see if it already works, though without the extra flash & RAM being visible? If it works, you can fit the part and wait for extra support or take your time in DIY. John |
||||
| G8JCF Guru Joined: 15/05/2014 Location: United KingdomPosts: 676 |
Hi John I was curious. Yes I've starting hitting the limits with the current uMite. Each time I get close to the limits, I adjust my code to be less structured but more compact which means that it becomes harder to maintain and more error prone. In my particular case I need extended precision integer arithmetic, ie at least 10 significant digits, and so I have implemented a BCD arithmetic library which is quite big ! I think that I had hoped that I wouldn't have to do the usual cramming-in, tricks and so on with the uMite which I've always had to do with 8 & 16 bit MCUs. TassyJim's work with MMEDIT to add the AutoCrunch option has really helped, but I've only gotten about 20% of my project coded so far and already it's beginning to feel a little cramped :( The Project BTW is an Antenna Analyser and LC component analyser using a DDS. The 170F part is not available yet, so I can't load up MMBasic and see what happens. In my experience, one can never have enough memory to work with - just quite how we managed with 4K EPROMs and 256 bytes of RAM back in 1974 and yet got so much done still surprises many people - mind you I wouldn't want to have to maintain the assembler we wrote in those days 25 years later - structured assembler !!! Things really improved when we moved to 68000's and at last had room to play in. Peter The only Konstant is Change |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3167 |
That is impressive, I thought that it would be a long time before people started doing that. I have a couple of early samples of the MX170/270 but I have not figured out what to do with them. If people are hitting the memory limits of the MX150 I could then simply adjust a few constants and recompile the source for the MX170 - which would raise the program space to about 54KB (plus 54KB RAM) and still leave about 30KB of flash free for other uses. As a longer term goal I would like to use some of the extra flash to add USB console support to the Micromite (so a USB-serial converter would not be required) but that would require the MX270 and the loss of four I/O pins compared to the current Micromite (two for the crystal plus four for USB minus two for the console). So, does anyone think that would be worth it? Another thing that we can do with the extra flash is compile the firmware for speed rather than compactness. That might add 10 to 20% to the speed of the interpreter. This will not happen tomorrow, Microchip have a habit of announcing chips well before they can make them - for example we are still waiting for the final silicon for the MZ series twelve months after we first heard about it. Geoff Geoff Graham - http://geoffg.net |
||||
| G8JCF Guru Joined: 15/05/2014 Location: United KingdomPosts: 676 |
Hi Geoff Very many thanks for responding, much appreciated. 1000 lines of Basic is not difficult !! I wrote a VB6 program which implements a Software Defined Radio, "SDR", which must comprise of over 300,000 lines of source (including comments) over the course of 18 months including a vector arithmetic/FFT library in x86 assembler. If you are into HF SDR radio then take a look at http://www.g8jcf.dyndns.org/index.htm Anyway, back to the uMite. 1) For an embedded controller supporting USB is the least of concerns, USB<->TTL Serial adaptors are so cheap and only required during development, so I would NOT bother implementing it IMHO 2) Losing 2 pins for the USB out of 20, ie 10%, is again (for an embedded controller) much too expensive, again USB<->TTL serial adaptors are just so cheap it's just not worth it. 3) As for the crystal, that's an interesting conundrum, for applications such as frequency counters, precision timing, a crystal controlled clock is essential, but losing 2 I/O pins is a serious I/O budget hit when you only have 20 to start with. Because I'm into Amateur Radio and hence accurate/precise frequency measurement is of major concern I would be prepared to sacrifice 2 x I/O lines in pursuit of precision and accuracy. 4) Given the doubling of Flash & RAM with the 170F's I would probably favour Speed over compactness, although of course that would depend on just how much "inflation" the "speed" option gave rise to. Whilst I've got your attention, I would really like a VARPTR keyword so that I could pass the address of a variable to a function/sub, eg Dim Addr Dim A(4) Dim Result Addr = Varptr(A(0)) Result = Function1(Addr) This way I could get round the problem of not being able to pass arrays to SUBs/FUNCTIONs. I'm suggesting this because it seems to me that with the 4.5 PEEK/POKE syntax, ie "POKE VAR var, ħoffset, val" and "PEEK(VAR var, ħoffset)", implementing VARPTR could be really simple since "VAR var" must evaluate to a 32 bit address. Finally, I've never had so much fun programming an MCU as I have had with the uMite. I am amazed at just how easy/quick it is to program in MMBasic - so thank you :) Take care and thank you Peter - GM8JCF The only Konstant is Change |
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3167 |
With USB you will lose four pins because you must use a crystal to stay within the USB timing specs. In the Micromite I originally tried to make it so that you could optionally use a crystal but a bug in the silicon (errata #2) stopped that from working. Perhaps the MX170/270 will be different. I can see why VARPTR would be handy but perhaps I should look at passing arrays to a sub/function first. That would be more suited to BASIC rather than a C orientated function. I also need to look at implementing 32 or 64 bit integers (that will use some of the extra flash). Geoff Geoff Graham - http://geoffg.net |
||||
| G8JCF Guru Joined: 15/05/2014 Location: United KingdomPosts: 676 |
Hi Geoff Ah Ah !! :) 33/64 Bit integers ! Absolutely, Please, eg a Var% option as in Dim A% . For an embedded MCU controller, handling UNSIGNED 32 bit INTs, UINT32, would seem to be natural. Passing arrays to FUNCTIONs and SUBs would be really useful, eg A=Function( Array() ) The VARPTR route is a bit of a bodge (even if it would work) Here's how I use PEEK '==================================== 'V4.5 Only 'Function Retrieves the 8 Hex digits stored in a Single 'by HexBin function using PEEK ' 'Returns 8 Hex Digits prepended with &H, eg &H12345678 ' Function Bin2Hex$(D) Local A1$(1) Length 10,B1$(1) Length 2,I For I=3 to 0 step -1 B1$(1)=Hex$(peek(Var D,I)) B1$(1)=String$(2-Len(B1$(1)),"0") + B1$(1) A1$(1)=A1$(1)+B1$(1) Next I Bin2Hex$="&H"+A1$(1) End Function Take care Peter - GM8JCF - http://www.g8jcf.dyndns.org/index.htm The only Konstant is Change |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2294 |
i agree that USB support is not paramount in the sorts of applications the micromite is likely to be used for. my preference would be for compiling for speed (perhaps allowing for compilation with a free compiler), a bootloader, 32-bit maths, and extending the space allocated for saving variables. one other thing (applying to the 32MX150 too), how practical would it be to enable the 32kHz crystal portion of the onboard RTC, not for use as a battery-backed RTC, but simply to trigger a precise timing interrupt every (say) 1/8th of a second via a dedicated interrupt name. this could be done in much the same as with the proposal to enable use of the 2v bandgap reference: a "CONFIG TIMING INT|32KHZ [, int_name, divider]" command that defaults to RC on reset. the 32KHz could then be used for all the pin functions (FIN, PIN, etc), but NOT the date/time, TIMER, PAUSE, etc commands that would still run on the internal RC. rob :-) |
||||
MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
I would favor unsigned integers too. It is the thing i miss most. Would a 32MX795 uMite version not be a solution, instead of waiting for the 170 series. (A Maxi/Minimite without the video capabilities, to have maximum use of internal peripherals and memory) If people are able to choose between a 150,250,170,270,695,795 chip and run the same basic code. Then when you run into capacity problems, pins, coms, timers etc then you just move up to a bigger version. I could even imagine a 795 64 pin chip on a small pcb (with caps and crystal) that plugs into a 28 pin dip socket to make the upgrade even easier. Sure you not use all the available pins, but if it is memory you need then that would be a solution. Microblocks. Build with logic. |
||||
| G8JCF Guru Joined: 15/05/2014 Location: United KingdomPosts: 676 |
@TZAdvantage I came across the mini Maximite which is I think more or less what you've suggested, but at AU$45 a time, it's somewhat less cost-effective than a uMite unfortunately - mini Maximite from Jaycar and geoffg mini Maximite . Perhaps Phil from Micromite.org might be in a position to offer a '795+xtal+C on a 28 pin dil pcb for something closer to the cost of a uMite ? The '795s seem to be in US$10 range compared to the US$3~4 for the '150s (and '170s when they finally ship). Anyway, it's still great fun working with the uMite. 73 Peter - GM8JCF The only Konstant is Change |
||||
| MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
I have got one in the works. :) It will be the 64 pin version of a 695/795, Still have to figure out some pinouts so that it can be a replacement for a uMite 28 pin dip. My wish is to have a microcontroller that functions as a uMite but has lots more memory. a 695/795 seems to fit the bill. As Geoff has made the functions from the micromite available from the Mini/Maximite it should be possible. Microblocks. Build with logic. |
||||
| G8JCF Guru Joined: 15/05/2014 Location: United KingdomPosts: 676 |
Yes Indeed ! The only Konstant is Change |
||||
 Print this page |
