 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 : Beta Testers Wanted
  Page 7 of 26   |
|||||
| Author | Message | ||||
elproducts Senior Member  Joined: 19/06/2011 Location: United StatesPosts: 282 |
The schematic is in the documentation Geoff sent you. It's clear and complete in my opinion. Just follow that. It's only a few connections. www.elproducts.com |
||||
| plasma Guru  Joined: 08/04/2012 Location: GermanyPosts: 437 |
thx , cant remember this |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3198 |
I thought about that but the I2C in the 然ite can be a slave and a master at the same time, so I could not see the need for a second I2C bus. Geoff Geoff Graham - http://geoffg.net |
||||
| Frank N. Furter Guru Joined: 28/05/2012 Location: GermanyPosts: 831 |
Hi Geoff, thats not completely correct! If you have I2C-devices with a fixed adress (not jumperable)on the bus (like some EEproms, temperature sensors or realtime-clocks), then you can use only one on the bus. But when the 然ite has it's own I2C-bus you can use the same devices additional on the 然ite at the same time! 
I have very often this problem at work! The additional benefit is that you can drive more devices (bus capacity) with a longer wire! Frank |
||||
MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
I would also really welcome a second I2C. The possibilities to use the uMite would increase a lot. Not only you have the benefit of a master and slave at the same time, but also different speeds, like on a long wire you would choose the slow devices and on the short wire high speed devices. Both need different pullups to work the best in combination with power consumption. Less bus collisions (when using slow and fast devices). The situation Frank subscribes is a very desirable one and because not many other chips/mcu platforms offer it unfortunately not a common one, or difficult to achieve. Microblocks. Build with logic. |
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3198 |
OK, I will have a look to see if it can be implemented simply. The real issue is the amount of flash left, I am down to the last few hundreds of bytes. So it could be a case of deciding what to dump. Geoff Geoff Graham - http://geoffg.net |
||||
Grogster Admin Group  Joined: 31/12/2012 Location: New ZealandPosts: 9310 |
I thought you were reserving the last few hundred bytes for bug fixes, not new features? ...if I may paraphrase you for a moment...   Smoke makes things work. When the smoke gets out, it stops! |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2350 |
can you not simply sacrifice a little bit of program memory for expanded functions and any bug fixes? my understanding was that of the 32k of ram, 12 was used by the interpreter and the remaining 20k was available for basic variables. of the 128k of flash, 108k contained the interpreter and the remaining 20k was available for lines of basic code. this being the case, there seems to be no solid boundaries, beyond a (quite sensible) desire to not "nibble away at" the quoted 20k/20k of space available to the user. btw, in theory i have three 32mx150 chips on the was as samples from microchip. rob :-) |
||||
| MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
I think that having a full screen editor is a luxury in an embedded controller. Unlike the color maximite this uMite needs a computer connected to be able to program it anyway. If you need to install TeraTerm, you can also opt to install MMEdit. Or if just using a terminal, even notepad is a handy full screen editor. In my case once i used MMedit, i never used the builtin editor anymore. I think a console is good and a great way to communicate with the device. If it were up to me, i would drop the full screen editor and use that space for other (future) features, bug fixes or storage space for programs. Microblocks. Build with logic. |
||||
| elproducts Senior Member Joined: 19/06/2011 Location: United StatesPosts: 282 |
I don't understand since the 24LC01 has three address pins so you can set a unique address for up to 8 EEPROMs on the same bus. www.elproducts.com |
||||
| Frank N. Furter Guru Joined: 28/05/2012 Location: GermanyPosts: 831 |
Hi, thats the reason why this chip was in my last company on the blacklist! Take a look on the datasheet "http://ww1.microchip.com/downloads/en/DeviceDoc/21711J.pdf" , page 5, chapter 2.1: "The A0, A1 and A2 pins are not used by the 24XX01." YOU CAN ONLY USE ONE CHIP ON THE SAME BUS, NOT EIGHT! ...many developers stumbled over this point in our company, many designs doesn't worked therefore... Frank |
||||
| MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
@Frank, I found that out a little to late too. It would have been better if those pins were labeled NC. The functionality that Geoff added to the I2c that it now can be a master and slave is already a big improvement. I think this uMite will be used often as the heart of a intelligent 'module'. That is certainly the way i would use it. Many sensors are I2C and if you can have a uMite take out all the details of controlling a specific sensor and just report for instance a temperature to the I2C 'slave'* it would make programming the 'Main' program so much simpler and smaller (also an important factor). A 'module' could sample data at a really fast rate and average them. The fast rate would overwhelm an I2C bus if it is shared. Only the averaged results need then to be send over the shared I2C bus. Having those I2C busses separate really helps in those scenarios. *The 'slave' would be the 'Master control unit running the main program'. Microblocks. Build with logic. |
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3198 |
This illustrates the problem... it is all a matter of priorities. I would guess that 99.9% of people are happy with a single I2C bus and it is pretty drastic to remove something useful like the editor for something marginal like a second I2C bus. The editor is important as it means that someone does not need specialised software (like MMEdit) to change a program. Also, it will work with another project of mine that is in the pipeline (a VT100 terminal based on the PIC32MX250). I guess that I could cut down on the program memory but I think that 20K for the program is already quite tight and where will it end? The next person will want to reduce the program space even further for their special requirement. I was thinking of cutting the search function in 1-Wire. Does anyone use that? Yes, you are right. So much for good intentions. Geoff P.S Note that I said that I would just investigate a second I2C port - no guarantees. Geoff Graham - http://geoffg.net |
||||
vasi Guru Joined: 23/03/2007 Location: RomaniaPosts: 1697 |
Go for it! A good practice for a new project is to connect the temperature sensors one by one as single and unique sensor on a bus to find out it's ID. Then you can remove it from the bus and label the sensor and connect the next one, and so on. Then, you can know which sensor is in which place. Let the search function for the aliens of the future, when they will try to activate some old terran tech buried into ruins... 
Mikroelektronika provides only three functions in their One_Wire library for all their compilers (mikroC, mikroPascal, mikroBasic), no matter the target (PIC, dsPIC, PIC32, AVR, ARM, etc.). I would expected much more from them. 
And a piece of their code sample (sorry, I don't have mikroBasic installed): [code]begin text := '000.0000 C'; Init(); DrawFrame(); TFT_Set_Font(@HandelGothic_BT21x22_Regular, CL_BLACK, FO_HORIZONTAL); TFT_Write_Text('Temperature: ', 75, 65); // Main loop while (TRUE) do begin // Perform temperature reading Ow_Reset(PORTA, 0); // Onewire reset signal Ow_Write(PORTA, 0, 0xCC); // Issue command SKIP_ROM Ow_Write(PORTA, 0, 0x44); // Issue command CONVERT_T Delay_us(120); Ow_Reset(PORTA, 0); // Ow_Write(PORTA, 0, 0xCC); // Issue command SKIP_ROM Ow_Write(PORTA, 0, 0xBE); // Issue command READ_SCRATCHPAD temp := Ow_Read(PORTA, 0); temp := (Ow_Read(PORTA, 0) shl 8) + temp; //Format and display result on TFT Display_Temperature(temp); Delay_ms(1000); end; end.[/code] Hobbit name: Togo Toadfoot of Frogmorton Elvish name: Mablung Miriel Beyound Arduino Lang |
||||
| MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
Never had the need for a 1-wire search. I also like to use one of these: http://www.maximintegrated.com/datasheet/index.mvp/id/4382 They clean up the signals pretty good and i get more reliable results. Also no more time critical bitbanging timings as described here in the host microcontroller, just some commands over i2c or even over RS-232 with this version. Or get even more sensors with a 8 port one wire like this one where every one-wire is independently controlled. Microblocks. Build with logic. |
||||
jman Guru Joined: 12/06/2011 Location: New ZealandPosts: 711 |
My 2 cents worth I have used the 1-wire search but would not miss it John |
||||
| elproducts Senior Member Joined: 19/06/2011 Location: United StatesPosts: 282 |
I think that is a great addition to the MicroMite and look forward to beta testing that. I would guess that all these requests for changes/additions are a pain to Geoff and I'm just as guilty asking for USB support, but it also shows there is a lot of interest in this smaller version of Maximite. If nobody was responding then the product would probably not go anywhere. I don't recall seeing this much interest is the Maximite Mini. So despite the constant requests, I'm encouraged by the interest in MicroMite and look forward to what people create with it. So far, I haven't needed to use 1-wire at all. www.elproducts.com |
||||
| vasi Guru Joined: 23/03/2007 Location: RomaniaPosts: 1697 |
After Geoff are done presenting the Micromite in that publication (can't remember), maybe he can provide also a version without the full screen editor, packing inside useful stuff as much as possible, as there is not much space anyway for user's programs. I bet that here the majority are "microcontroller-guy"'s ... If someone pays attention, will see that PICAXE are more useful for all sorts of projects, where you can't afford to "mount and forget" a full Maximite. So. people around here are returning to PICAXE for home/farm appliances ... unless they have a competitive microcontroller. Geoff, please see how easy people [offered to buy] sorry, bought already a Pickit3. I would have never convinced them to do the same to learn PIC18F programming using an excellent and free compiler, JALv2 which resembles Ada or Pascal. Meantime, the posting frequency is on a down trend regarding Maximite (compared to the beginning). Hobbit name: Togo Toadfoot of Frogmorton Elvish name: Mablung Miriel Beyound Arduino Lang |
||||
| JohnL Senior Member Joined: 10/01/2014 Location: SeychellesPosts: 128 |
This is exactly how I use 1-wire 18S20 temp sensors on a long 1-wire network. I would fully support dumping 1-wire ROM search for a second I2C bus if memory space is an issue. |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9310 |
I also use MMedit for all my development now, and don't use the built-in editor anymore, just cos MMedit has full point-and-click/scroll editing etc, and colour syntax. As I have said before, that is not to speak ill of the built-in editor, this is just my choice, and I fully understand that you can't have a full-blown built-in editor, or there would be 2K left for the program!  Smoke makes things work. When the smoke gets out, it stops! |
||||
| Page 7 of 26 |
|||||
 Print this page |
