 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 Beta 6
  Page 8 of 9   |
|||||
| Author | Message | ||||
vasi Guru  Joined: 23/03/2007 Location: RomaniaPosts: 1697 |
you can put the ultrasonic together with the servo and... those are great for little robots so you can't dismiss the ultrasonic just because you are not into robotics... Hobbit name: Togo Toadfoot of Frogmorton Elvish name: Mablung Miriel Beyound Arduino Lang |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3282 |
I have thought of that but it would upset Mick. Grogster, peek/poke use very little flash (less than 70 bytes) - so I have left them in on the basis that they may come in useful. Geoff Geoff Graham - http://geoffg.net |
||||
bigmik Guru Joined: 20/06/2011 Location: AustraliaPosts: 2949 |
Now Geoff, You should have put a little Smiley there... 
I DO like the line numbers but I will learn to live without them `IF I had to'... If it meant more features in what should be called the MEGAmite as opposed to MicroMite then maybe its worth it ... You are probably the best judge of what to add and what not to. My personal feelings are that if a device is fairly straight forward to program with MMBASIC then maybe a dedicated command isn't needed, just add to the sub routine libraries, but if it gets complex to support in MMBASIC then they have more merit as new commands... Regards, Mick PS. Thank you for thinking of Me... 
Mick's uMite Stuff can be found >>> HERE (Kindly hosted by Dontronics) <<< |
||||
| MOBI Guru Joined: 02/12/2012 Location: AustraliaPosts: 819 |
I keep wondering if the RTC command is really necessary. To a degree, it tends to lock one into a specific RTC chip. The RTC still has to be connected to the i2c bus. It is not as though the RTC is internal to the pic32 and the i2c commands to read and set the RTC are little more onerous than the uMite commands and less restrictive. For some time I have been using the DS3231 on a cheap little Chinese board with battery backup, pad for i2c EEPROM and "in-chip" temperature sensor read directly from the RTC registers. Ok, the temperature resolution is (I think) 0.25 DegC but as previously stated is more than adequate for the average project. I'd be more receptive if all RTC chips have the same register structure but although some come close, they don't all. I think all RTC chips also have a common i2c address but I haven't confirmed that. What do you think (collectively) David M. |
||||
MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
I agree with leaving out the RTC commands. It is pretty easy to do with a few lines of basic code and leaves the choice for an RTC to the user. The same is actually valid for a keypad and LCD. Really difficult which things you bake into the firmware. It sure saves code and thus memory. Personally i remember very well that getting an LCD to work with your own code is very satisfying. It is part of the joy of learning and using micro controllers. Making everything too easy can have opposite effects. Really depends on which type of people are targeted. The RF and IR however is not so easy from basic and seems a good candidate for support in firmware. (A bit the same as having support for an PS/2 keyboard for instance). Microblocks. Build with logic. |
||||
atmega8 Guru Joined: 19/11/2013 Location: GermanyPosts: 724 |
I also agree with it. There are so many different RTC's around, with so different Parameters and features. Would be better to provide as many sample code as possible and integrate it in a mmite sample code library. Dietmar |
||||
| vasi Guru Joined: 23/03/2007 Location: RomaniaPosts: 1697 |
Guys, take it easy with removing things, the user space is not so big. Is not about just making the RTC working from the user space... Is about how much space you have for the serious (read, programs really complex) things. Hobbit name: Togo Toadfoot of Frogmorton Elvish name: Mablung Miriel Beyound Arduino Lang |
||||
| MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
In this case the flash is shared betwen firmware and 'userspace'. It might be a good criteria if something needs to be in the firmware instead of programming it in MMBasic. The smallest footprint wins. Microblocks. Build with logic. |
||||
jman Guru Joined: 12/06/2011 Location: New ZealandPosts: 711 |
I think having these built into the firmware is a great idea It makes it quick and easy to use these types of peripherals and gives those who are just starting out a method of using these peripherals. Sure some of us can write the required code of these peripherals but I am sure there are a few out there you are still learning. You are not locked into a particular version of RTC. Should you wish to use a different version then just code your own Maybe the solution is to have two versions one without the peripherals and one with them Regards Jman |
||||
| vasi Guru Joined: 23/03/2007 Location: RomaniaPosts: 1697 |
Micromite can't use SD-Card so, we depend on a PC/Tablet to log the data and in this case, the host software can pick the time from the PC/Tablet. One reason less for using a RTC... But others may use it for other kind of automations where you don't need to abuse the microcontroller's internal timers - less code, I guess. Well, you can't say I didn't tried to support the removal of RTC code ... Hobbit name: Togo Toadfoot of Frogmorton Elvish name: Mablung Miriel Beyound Arduino Lang |
||||
| MOBI Guru Joined: 02/12/2012 Location: AustraliaPosts: 819 |
A bit like PICAXE in a way except that the user can choose which .HEX file to install. Ok, I know not everyone can programme the firmware but then again, just how many people are likely to purchase just a pre-programmed PIC rather than a populated proto board? As to the RTC, if the user can wire up an external clock chip/module, I feel sure they can handle a one or two line of i2c. In any case, a firmware library could provide the example code then it is just a case of cut and paste. Either way, the user still has to write code - all part of the learning experience. David M. |
||||
| plasma Guru Joined: 08/04/2012 Location: GermanyPosts: 437 |
i've testet the time from the Micromite. i get a difference from 19 minutes per week. to put the right time on the micromite you need to connect one or two times per day. no way ... i really think we needs "libs" for the basic code for the most extra hardware , same as arduino. such like jmans nokia source . this expand the users experience and we can learn from as learning by doing . the inbuild firmware commands are usefull for rapid development . the basic sources ar for programmer which will learn , i think booth are great and usefull. thx |
||||
| vasi Guru Joined: 23/03/2007 Location: RomaniaPosts: 1697 |
He he, guys, some how you are right (a firmware for every need) but you forget that Geoff said that he won't maintain more than one firmware (well, sort of). Anyway, the chip can be in one of the two forms: before the firmware, and ... after the firmware  . I guess Geoff is laughing at us...
This code for PCF8583 using I2C Software, displaying on LCD and written in mikroBasic occupy around 5Kb of flash and can be compiled with the free version (where you can have 8Kb of maximum code for free): [code]program RTC_Read dim seconds, minutes, hours, day, month_, year as byte ' Global date/time variables ' Software I2C connections dim Soft_I2C_Scl as sbit at RF3_bit Soft_I2C_Sda as sbit at RF4_bit Soft_I2C_Scl_Direction as sbit at TRISF3_bit Soft_I2C_Sda_Direction as sbit at TRISF4_bit ' End Software I2C connections ' LCD module connections dim LCD_RS as sbit at LATB2_bit dim LCD_EN as sbit at LATB3_bit dim LCD_D4 as sbit at LATB4_bit dim LCD_D5 as sbit at LATB5_bit dim LCD_D6 as sbit at LATB6_bit dim LCD_D7 as sbit at LATB7_bit dim LCD_RS_Direction as sbit at TRISB2_bit dim LCD_EN_Direction as sbit at TRISB3_bit dim LCD_D4_Direction as sbit at TRISB4_bit dim LCD_D5_Direction as sbit at TRISB5_bit dim LCD_D6_Direction as sbit at TRISB6_bit dim LCD_D7_Direction as sbit at TRISB7_bit ' End LCD module connections '--------------------- Reads time and date information from RTC (PCF8583) sub procedure Read_Time() Soft_I2C_Start() ' Issue start signal Soft_I2C_Write(0xA0) ' Address PCF8583, see PCF8583 datasheet Soft_I2C_Write(2) ' Start from address 2 Soft_I2C_Start() ' Issue repeated start signal Soft_I2C_Write(0xA1) ' Address PCF8583 for reading R/W=1 seconds = Soft_I2C_Read(1) ' Read seconds byte minutes = Soft_I2C_Read(1) ' Read minutes byte hours = Soft_I2C_Read(1) ' Read hours byte day = Soft_I2C_Read(1) ' Read year/day byte month_ = Soft_I2C_Read(0) ' Read weekday/month byte} Soft_I2C_Stop() ' Issue stop signal} end sub '-------------------- Formats date and time sub procedure Transform_Time() seconds = ((seconds and 0xF0) >> 4)*10 + (seconds and 0x0F) ' Transform seconds minutes = ((minutes and 0xF0) >> 4)*10 + (minutes and 0x0F) ' Transform months hours = ((hours and 0xF0) >> 4)*10 + (hours and 0x0F) ' Transform hours year = (day and 0xC0) >> 6 ' Transform year day = ((day and 0x30) >> 4)*10 + (day and 0x0F) ' Transform day month_ = ((month_ and 0x10) >> 4)*10 + (month_ and 0x0F) ' Transform month end sub '-------------------- Output values to LCD sub procedure Display_Time() Lcd_Chr(1, 6, (day / 10) + 48) ' Print tens digit of day variable Lcd_Chr(1, 7, (day mod 10) + 48) ' Print oness digit of day variable Lcd_Chr(1, 9, (month_ / 10) + 48) Lcd_Chr(1,10, (month_ mod 10) + 48) Lcd_Chr(1,15, year + 49) ' Print year vaiable + 1 (start from year 2011) Lcd_Chr(2, 6, (hours / 10) + 48) Lcd_Chr(2, 7, (hours mod 10) + 48) Lcd_Chr(2, 9, (minutes / 10) + 48) Lcd_Chr(2,10, (minutes mod 10) + 48) Lcd_Chr(2,12, (seconds / 10) + 48) Lcd_Chr(2,13, (seconds mod 10) + 48) end sub '------------------ Performs project-wide init sub procedure Init_Main() AD1PCFG = 0xFFFF ' Initialize AN pins as digital Soft_I2C_Init() ' Initialize Soft I2C communication Lcd_Init() ' Initialize LCD Lcd_Cmd(_LCD_CLEAR) ' Clear LCD display Lcd_Cmd(_LCD_CURSOR_OFF) ' Turn cursor off Lcd_Out(1,1,"Date:") ' Prepare and output static text on LCD Lcd_Chr(1,8,":") Lcd_Chr(1,11,":") Lcd_Out(2,1,"Time:") Lcd_Chr(2,8,":") Lcd_Chr(2,11,":") Lcd_Out(1,12,"201") end sub '----------------- Main procedure main: Delay_ms(1000) Init_Main() ' Perform initialization while TRUE ' Endless loop Read_Time() ' Read time from RTC(PCF8583) Transform_Time() ' Format date and time Display_Time() ' Prepare and display on LCD wend end.[/code] Of course, the rest of the useful part of your application (this is just a simple example) must fit into the remaining 3Kb, or you have to buy the full license. The good part is that the code generated by the mikroe compilers can be burn with the Pickit2 programmer (they write something in the boot zone, something which the Pickit3 software knows how to add it, and the C32 compilers knows not, I guess). ______________ Edit: using I2C hardware, the code is even smaller (as expected), around 3.7Kb but still bigger than the text BASIC source code where I stripped the comments and the empty lines (still searching for the reasons to remove RTC). Of course, the compiled code contains also the initialization code required by the microcontroller, which is quite big. So, the stripped BASIC code is now 2.3Kb (reported by the file manager) but it can be this small because I didn't needed to write code for LCD and I2C (those are inside libraries - or firmware, in Micromite's case). It could have been even smaller if I had also some libraries for PCF8583 (code written in firmware). So, more space for our programs if the required routines are in firmware. Now, for exactly which peripherals? Hobbit name: Togo Toadfoot of Frogmorton Elvish name: Mablung Miriel Beyound Arduino Lang |
||||
Grogster Admin Group  Joined: 31/12/2012 Location: New ZealandPosts: 9590 |
Understood. EDIT: Adding to the RTC thing, I also think it is better to use an external RTC module, if you need it, rather then bothering with an RTC on the uM chip, but AGAIN - this is only MY 2c.... Smoke makes things work. When the smoke gets out, it stops! |
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3282 |
Gosh, I go away for half a day and there is so much activity. Firstly Mick, I did mean it as a joke - sorry, I was in a rush and should have used a smiley .
On the subject of putting features in or removing them from the firmware. Everyone should remember that this forum is not my only audience. I do put in sophisticated features (such as I2C, RS485, etc) for you fellows but I also want to attract the typical reader of Silicon Chip. This is typically someone who has built a few kits and would like to move up to using a microcontroller for something like a home brew controller but does not want to become a pro programmer in C. That is why I spent the time drawing circuit diagrams in the Special Devices section of the manual - to make it easy for the less technically adept. Putting in support for special devices like RTCs and IR was an experiment. I knew that people would then want support for their favourite variant (eg, a Philips remote control or a different RTC) but I figured that the typical Silicon Chip reader would not have a favourite device and would be happy to get support for whatever function that they needed. For example, to build a reticulation controller you could just attach a RTC, keypad and LCD module and with a few lines of code have a working solution. This type of constructor would just buy whatever it was that they needed to suit the Micromite rather than look in their parts box and wish that the Micromite supported whatever was in there. When I selected devices to support I looked for a mixture of popularity with potential non-technical constructors, easy availability, cost and performance. These tradeoffs are for the most part subjective and others might have their favourites but those were the parameters that I used. So yes, I could remove the RTC and save some bytes but then the builder of a reticulation controller (for example) would have to find some code to communicate with a RTC, gain some understanding of I2C, and so on. If you are more expert and have your favourite device you can ignore the built in support and write your own code. BTW the RTC command uses a total of 456 bytes so it is not huge amount of wasted flash if you did not want to use it. So, to my way of thinking, everyone gets what they need, both the beginner and the expert. Changing to the other topics that have been raised: - The idea of dynamically loading/unloading device handlers (as does Windows) will not work because the PIC32 does not have gigabytes of memory as does Windows based PCs. - I don't want to have multiple versions of the firmware supporting multiple devices because it is a nightmare to maintain. Already with the MM/CMM/DM/DOS, etc it takes me a full day to build all the various versions, test them, make sure the right documentation is with the right device and so on. Even then I make some mistakes. - Using both the keypad and LCD does take up most of the pins on a 28-pin device but in the Silicon Chip article I plan to publish the 20 lines or so of BASIC code that will move these two functions to a second Micromite communicating via I2C. This is a simple solution and, because the PIC32 is so cheap, it is also low cost. I know that this involves dealing with I2C but then there is no perfect solution for everything. - Doing something about line numbers has been on my list for a long time. The simple solution is to treat a line number exactly the same as a label within MMBasic. The problem is that the concept of line numbers is embedded in most areas of MMBasic and it will take a lot of care and testing to make sure that I don't break something in the change. Phew, that must be enough for one post. Geoff Geoff Graham - http://geoffg.net |
||||
| MOBI Guru Joined: 02/12/2012 Location: AustraliaPosts: 819 |
Offloading LCD, Keypad etc to another uMite sounds promising although I still can't see why not just hang i2c devices to the one unit. There are plenty of i2c based devices "out there" and even building a "purpose built" i2c device is not that difficult. I can't understand why i2c seems to be looked on as a "black art" or "white man's magic". If the average user (from tyro to maestro) can understand and use MM Basic, then surely i2c protocol is within their capabilities. I'm not growling and I'm not advocating that RTC, Keypad and LCD be removed, its just that I've been using i2c modules now for so long that I find it so easy to plug the devices I want into a 4 (or 5) pin i2c header on a bus, cut and paste a few lines of library code and Bob's you uncle. David M. |
||||
| bigmik Guru Joined: 20/06/2011 Location: AustraliaPosts: 2949 |
I DID read it that way.. 
Mik Mick's uMite Stuff can be found >>> HERE (Kindly hosted by Dontronics) <<< |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2431 |
i do fear that we have all (myself included) started to step over the line, telling geoff how to run what is, in reality, his project. for that, we all perhaps owe him an apology. i do see the greatest strength of the micromite being that a single 28-pin DIP chip (plus a capacitor) can do everything. there are a great many people out there today whose soldering skills are very limited, and who struggle to follow a schematic. these are people who are not stupid, and indeed as a kid could have put together a crystal set using a chunk of wood with screws as terminal posts - a project built from almost nothing that can sometimes provide the initial 'spark' for a lifetime of wonder and achievement. the micromite represents the modern crystal set. while one can certainly network two together, add on peripheral i/o expanders, such an approach quickly goes beyond the 'crystal set' stage. you quickly end up at the point of designing a transistor radio. as such, the micromite strengths lie with projects that can be put together on a piece of plug-in prototype board and left in that state permanently. the 'bread and butter' routines for this are the DS18S20, LCD, keypad, and IR functions, all interfacing with peripherals that can attach with minimal electronic nouse. all just my opinion, mind you. rob :-) |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4036 |
I'd never even heard of reticulation controller!! I'm busy wondering about the PIC32MZ version... I hope the chips will be cheap. John |
||||
BobD Guru Joined: 07/12/2011 Location: AustraliaPosts: 935 |
Rob, you've been reading my mail. Seriously, IMHO, a very good opinion. However, Geoff did invite suggestions and he is and has been strong enough to ignore us with very polite replies as needed. |
||||
| Page 8 of 9 |
|||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
