BLIPS 2.8 (26 Nov 06) Bootloader - via serial and IP

Go To Last Post
100 posts / 0 new

Pages

Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

26 Nov 06: uploaded BLIPS 2.8 to BLIPS in project section. See revision history there.

Nov 10, 2006: mega168 was tested OK, no changes to assembly language code was needed. This fact isn't yet reflected in the comments in the source code uploaded here.
=========================================

I'm looking for someone to help test the following.

I have implemented an AVR bootloader, PC side, called
"BLIPS" - meaning: Bootstrap Loader for Internet Protocol and Serial (communications)

This PC program is Windows GUI/mouse based, rather than strictly command line based.

BLIPS enables loading and verifying FLASH and EEPROM files in AVR chips that have a bootloader in place in flash. That AVR side follows Atmel's application note 109 protocol.

BLIPS communicates with the AVR chip in the following manners:

1. AVR connected to serial port on same PC as BLIPS runs on.

2. AVR connected to a serial port on a distant PC which has LAN or Internet connectivity to the PC running BLIPS. The freeware called Proxy Serial is used on the distant PC. BLIPS connects to Proxy Serial and the remote AVR using BLIPS' TCP/IP connection option.

3. AVR connected to a distant device rather than a PC, where the device converts ethernet or WiFi to serial. Example devices include Lantronix XPort, Lantronix WiPort (WiFi), Moxa NPort W2150 (WiFi), Digi, and many others. BLIPS uses either UDP or TCP (user's choice) to connect to these kinds of devices.

The testing I've done has used two AVR-side bootloaders. One is in assembly language, fits in 512 bytes; the other is in GCC/C, requires 1024 bytes. The concept is that BLIPS triggers the AVR remotely to go to bootstrap mode by sending two characters to the running application which in turn jumps to the bootloader and talks to BLIPS. The application would use a watchdog timer as well, with a timeout triggering BLIPS to run. The two bootloaders each wait for a couple of seconds for to come in and if not, the user application is run. Thus, it should be rare that a person has to be there to push a reset button.

BLIPS was compiled for Windows 98 and later compatibility. A different version with the WIndows XP look and feel and use of .NET 2.0 is what I'd like to see tested - with chips and flash/eeprom files that try out test cases I cannot do.

Thanks in advance.

Last Edited: Sun. Nov 26, 2006 - 01:51 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

screen grab from BLIPS is enclosed here.

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

I'm interested in it. I need something similiar but instead of using IP I need to update throught bluetooth (serial) because the AVR in not accesible and any body can acess the reset button. I've see the MegaLoad that supports ATmega48 (that I use) but it needs ICCV7 and I'm working with WinAVR. Why you use .NET framework? This is a simple app and this adds heady load! Your bootloader supports ATmega48?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I wrote this using VB6 which yields a leaner executable.
I then ran the source through Microsoft's VB6 to .NET converter for VB Express 2005 (free from Microsoft).
I made a few changes and that's the look and feel, above. I could revert. It seems like everyone's being pushed to .NET by Microsoft.

As to ATmega48, If the on-chip bootloader you choose supports Atmel's 109 protocol and runs on the mega48, my program shouldn't know. It gets the chip ID from the bootloader code on the chip and looks up the chip info in Atmel's XML files. As I discussed in the top of this thread, I have two such AVR-side bootloaders in source from the public domain ( freeware). You could tweak one for the mega48.

Bluetooth serial - should show up as a COM port, right?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

re BLIPS/GUI shown above, anyone wish to help test it?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

BLIPS - I added AVR-side support for high speed block mode write and verify for flash.
the AVR side code I'm using still fits in 512 bytes and still conforms to Atmel's AVR109 protocol.
All the other bootloaders for AVRs I found were much larger (like 2KBytes) if fast block mode was supported.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes, it can be used (programmed) as an standard COM.

If you send me the app and bootloader code, I can tweak it for ATmega48 and test your app.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello Steve,
I would like to help in testing your bootloader. I sounds that is will do exactly what I need for my work. Please can you send me the program.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

audiotools wrote:
Hello Steve,
I would like to help in testing your bootloader. I sounds that is will do exactly what I need for my work. Please can you send me the program.

I'm hung up trying to fit in support for the mega128 on the AVR side. Since I don't HAVE a mega128, it's guesswork. Maybe I should post what I have - just tested with the mega8.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have a JEDMicro ATmega32 dev kit if you want verification on that device. I currently run a modified version of MegaLoad on it for ISProgramming.

I am rather new to the whole botloader scene so "handholding" might be required!

Cheers

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I ordered a mega128 stamp (ETT) via FutureLec.

Thanks for the mega32 offer - will do. I have a mega32 board too (PRRLC) - its ISP connector is non-standard and I've never bought/made an adaptor for the Atmel ISP that I have.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Re other people testing BLIPS (see graphic above)...
I have the AVR side code jammed into 512 bytes now, supposedly will support mega128.
the mega128 I ordered won't arrive for a week.
Should I post BLIPS and the AVR assembly code now or wait until I test the mega128? The mega8 is tested, and it's pretty much identical to the '16 and '32, I suppose.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Update -- The AVR side is coded/tested - but I'm waiting to test on a mega128 to make sure I got the RAMPZ code right.

The PC side- BLIPS (its UI is shown above). I coded this in VB6 then auto-migrated it to VB 2005 (the free version that's out now). Runs fine. Has the nice look of XP buttons and styles versus standard VB6 programs. HOWEVER, when I took BLIPS to other PCs using the "publish" tool in VB2005, it was ridiculous. The target PC would crash, even if I suffered thorough the agony of downloading the 20MB .NET2 framework. And VB2005's IDE, on my AMD1800 PC, is a joke, in terms of bloatedness. Microsoft needs to see the real world.

So I moved BLIPS back to VB6. It now supports the XP look and even though it's VB6. I like that. This trick was discovered by VBers and it's nice.

So, it's about ready to go - should get the mega128 any day.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Anyone want to give this a try?
Beta versions

1 BLIPS (PC side software). Won't run on windows 98. Should "talk to" any bootloader than conforms to Atmel App note 109, including...
2 AVR chip bootloader - 512 bytes, supports Atmel standard with high speed block mode. I spent a lot of time trying to make this easy to configure for any AVR. Test with mega128 and big flash file not done yet- code is there though.

See the Readme on what's been tested so far.

When these are tested well, I'll put it the pair of programs in the Academy.

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Anyone have time to test these yet?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

After a lot more work, code changes to support mega128 large flash, bug fixes, BLIPS 2.0 PC-side, and newer AVR-side code, is in the academy files
https://www.avrfreaks.net/index.p...

Bug reports welcome.

steve

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

First i would like to thank you for your effort in writing a small but powerful bootloader and a smart pc software.

I tried to work with your BLIPS code downloaded from your academy project on an ATmega168. Unfortunatly i ran into several problems, from wich i could not resolve everyone. Any help is appreciated.

BLIPS 2.0 PC program:
I tried to run it on the german Windows 2000 version. It crashes during startup with the following message(translated from german): "Runtime error '9', index outside of valid area."

provided Mega8 bootloader:
I could not assemble it for ATmega168 because of several reasons (using AVR Studio 4.11 SP3):
1. Some register names are different. I was able to adjust this:
;changed register names
.set SPMEN =SELFPRGEN ;SPMEN to SELFPRGEN
.set EEMWE =EEMPE ;EEMWE to EEMPE
.set EEWE =EEPE ;EEWE to EEPE

2. in and out doesn't work with memory mapped (high) i/o registers. Unfortunatly many UART related registers for the ATmega168 are memory mapped registers.
I changed all of these into lds and sts. I hope this is correct.

3. The same problem arise for the sbis and sbi instructions.
I'm no expert AVR assembler programmer (to be true it was several years ago that i programmed the last time using assembler - an AD DSP device... :oops: ).
So i gave up for today hoping that someone can help me here.

4. The comment table for the configuration seems to be not alinged correctly - at least for me the column heads and rows don't fit together.

I attached the changed asm file i have now.

cheers
Holger

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

as to BLIPS on windows 2000 - This could well be, I tested it only on Windows XP. Can you try it on XP SP1 or SP2? It uses the newer common controls library and this may be the problem. Otherwise, it could be a bug in my program's dealing with the regiistry. I'd like to work with you on this, though if it's a Windows 2000 specific problem, I can't do much as I don't have that OS.

As to the mega168 changes to the ASM code, for the memory mapped registers - yes, I'd like feedback from people tweaking the code for all the processor variants. If you'll send me the changes, I can sustain a new baseline. From this, It would be great if we/I could add the conditional code changes for the 168 and others. My goal was to wind up with a bootloader that uses only ASM, stays 512Bytes for the sake of the mega8, and is kept in synch with BLIPS.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

as to BLIPS on windows 2000 - This could well be, I tested it only on Windows XP. Can you try it on XP SP1 or SP2? It uses the newer common controls library and this may be the problem. Otherwise, it could be a bug in my program's dealing with the regiistry. I'd like to work with you on this, though if it's a Windows 2000 specific problem, I can't do much as I don't have that OS.

As to the mega168 changes to the ASM code, for the memory mapped registers - yes, I'd like feedback from people tweaking the code for all the processor variants. I'll take the changes and sustain a new baseline. From this, It would be great if we/I could add the conditional code changes for the 168 and others. My goal was to wind up with a bootloader that uses only ASM, stays 512Bytes for the sake of the mega8, and is kept in synch with BLIPS.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Steve,
BLIPS does not run for me on an XP SP2. Shows a runtime error 339, saying something that it misses MSWINSCK.OCX, which I actually do not have on this XP installation (I have found it on my Win98 system, though).

Jörg.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That's the socket driver for the TCP and UDP connections. I thought MSWINSCK.OCX was part of XP SP1.
It is also part of the visual basic 6 run-time support that's free from Microsoft. Maybe I can legally include MSWINSCK.OCX in my distribution or at least refer to where to get it.

Did BLIPS run OK after getting the OCX?

I'm recoding the AVR side code to deal with the mega168 and others that have memory mapped UART registers. Later today I'll upload. I don't have a mega168 though, so can't test.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Version 2.1 of the PC side BLIPS and the AVR side - I just uploaded these to the academy projects. Changes discussed in the PDF file.

There's a new BLIPS and new AVR-side, rewritten to support mega168 et al with memory mapped I/O registers. Tested on mega8 and mega128 but I need someone to test on mega168, and others

MSWINSCK.ocx is widely available but of course, get it from microsoft.com if you can to minimize security risks..

steve

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Did BLIPS run OK after getting the OCX?

I will give that a try this evening.

For the moment I tried BLIPS2.1 on a german Win2000 (at work) and it shows the same behaviour that Holger reported ( ~ Run time error 9. Index outside valid area). :(

Any idea?

Jörg.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

does the window open before the error?
If you have VB6 for Win2K I can send sources and you can run in debug mode to trap the error.

Try removing the manifest file that came with the exe. that file may be ignored by Win2K, but on XP it causes the new XP styles in the user interface to be used.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Steve,
thanks for adapting the asm file so quick. It now assembles without problems. It seems to wait as expected but since the pc side does not work i do not know if it works.

Quote:
does the window open before the error?

No, this error message comes from windows before any window is opened.

I think there are some dlls missing. I tried installing every VB6 runtime file i found on MS website (SP3, 5 and 6) but it did not work. None of them include the mswinsck.ocx mentioned above.

Removing the manifest file does not help too.

Does your VB studio include the depends.exe tool? It can show you all the dlls your program needs. Maybe this will lead to the information wich one is missing.

I will try and check BLIPS on XP tomorrow.

Holger

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

OK - I have no way to try BLIPS on Win2K - just XP.
So I hope your XP runs is OK tomorrow.

mswinsck.ocx - google for it - it's easy to find - just be sure to get it from a safe and trusted source.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok, i think i've got it.(Regarding the PC software)

It's an problem with international windows versions(or at least with the german windows version).
After searching and copying MSCOMM32.OCX, MSWINSCK.OCX and MSCOMCTL.OCX into BLIPS' directory it runs on XP _and_ W2K english version. It does not run on XP german version.

I tried the dependency walker but i can't find the problem. If started on german XP it looks for some more DLLs than on english XP. I think these are language specific DLLs but judging from our software in my company (i don't write it but i install and work with it a lot) these language specific DLLs aren't that important. It should also complain when they are missing and not crash with a runtime error.

Maybe you can find any language-specific setting in your project? Or a function or API call that does not work on other language versions? Unfortunatly i don't have VB so i can't help here. Or is it free for download now?

I need this to run on german windows too, i have english versions only at work.

Holger

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JBecker wrote:
Quote:
Did BLIPS run OK after getting the OCX?

For the moment I tried BLIPS2.1 on a german Win2000 (at work) and it shows the same behaviour that Holger reported ( ~ Run time error 9. Index outside valid area). :(

Jörg.


Same run time error 9 to me.
I have Win XP Greek version and had to manually install the MSWINSCK.OCX file to get this error.

Steve, if you fix this, I could test it on mega8515 and mega16 AVRProg compatible bootloaders. :cry:

Practice Safe hex.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello Steve,

I have tried Blips on a Hungarian XP. Got the freshest MSWINSCK.OCX MSCOM32.OCX and MSCOMCTL.OCX. I tried both registering them and copying to Blips directory. Unfortunately I got the same run time error 9 before the program starts like others. The OCX files are english versions which can be a problem? I have no Visual basic so I can not debug the problem, but if you have new versions I pleased to test it.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Steve,

I also have the problem with run time error 9 (XPSP2). Can you send me the source, then I will try to debug it. ??

Can't wait to see it running :wink:

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Using an extra PC that I have, which has a recently loaded Win XP with SP2, I downloaded BLIPS 2.1 from the avrfreaks.net academy files. I ran it and it errored saying that the following two Windows files are missing
MSWINSCK.OCX
MSCOMM32.OCX

For each of those two files, I copied the matching OCX, OCA and DEP files from another computer to my 2nd computer to the same directory (c:\windows\system32).
I then ran regsvr32 for the two OCXs.

Now BLIPS 2.1 runs and displays its normal window.

I didn't distribute those OCXes because I'm not sure if it's a violation of Microsoft's copyrights. I think I've seen many shareware program include those with an installer as if it's legal to copy them. I don't know -anyone know?

So I didn't see the error you guys are seeing.

andniels1 - if you have VB6 installed let me know and I'll email or PM the source and you can run and see what's failing.

Steve

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm currently working on getting the AVR code on a Mega8 and Mega88. Just by chance, I have a blinking LED on a Mega8. I will post details later.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Steve,

I have did about the same you suggested, but I still have problem.

I don't have VB and I know only the basics of it, so I hunted up this stuff from the net. You are right MSCOMM32.OCX licenced, MSWINSCK.OCX aviable from microsoft. During the test I was also asked for MSCOMCTL.OCX, I found it on the net, I dont remember where.

I also found on the net how to register this files, but I also copied to PLIPS folder, you know just to make sure. Unfortunatly, I got this error message. I have XPSP2 with Hungarian language.

I am not a windows hacker I don't know what could be the problem. Maybe the source of the OCX was not reliable and they have different versions? It can also be a language problem and simple some settings on windows?

I would be glad to read some more experiense, I may got the idea how to solve the problems.

Laszlo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

holgerd wrote:
Ok, i think i've got it.(Regarding the PC software)

It's an problem with international windows versions(or at least with the german windows version).
After searching and copying MSCOMM32.OCX, MSWINSCK.OCX and MSCOMCTL.OCX into BLIPS' directory it runs on XP _and_ W2K english version. It does not run on XP german version.

I tried the dependency walker but i can't find the problem. If started on german XP it looks for some more DLLs than on english XP. I think these are language specific DLLs but judging from our software in my company (i don't write it but i install and work with it a lot) these language specific DLLs aren't that important. It should also complain when they are missing and not crash with a runtime error.

Maybe you can find any language-specific setting in your project? Or a function or API call that does not work on other language versions? Unfortunatly i don't have VB so i can't help here. Or is it free for download now?

I need this to run on german windows too, i have english versions only at work.

Holger

I am very sorry but as a typical dumb American, I have no experience in using VB6 for foreign languages. I know nothing about what can go wrong. I just use VB6 out of the box as it comes and I always assumed that MS Windows takes care of localization transparently to me. Maybe I need to Google around on this topic.

Those OCXes normally go in the windows directory, but maybe putting them into BLIPS' directory makes them override the German versions in the system directory. I'm guessing.

I need a trip to Heidelberg to debug this.
------------------

Just to be sure you all noticed, BIPS v2.1 is uploaded.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I just uploaded a microsoft SETUP.EXE with CAB file style of BLIPS 2.1.
I see that they bundle the OCXes.
No doubt this doesn't cure the internationalization problem (won't run on German XP SP2).

But it's something I could whip up quickly.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Steve,
post the sources to the academy , i'll spend some time and help you fix any problems
that crop up , i think you will find a few more hands might help

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I managed to program a Mega8 with the bootloader on a STK-500 @ 3.6864mHZ. I could not get AVRprog, v1.4 to recognize anything hooked up to the serial port. After downloading the three .OCX files everyone is talking about, and putting them into the BLIPS directory, I was able to communicate with the chip. I changed the "Mega8" bootstring ID to "MegaZ" and read it back, so I know communication is going on.

Time for work. Perhaps a LED will blink tonight.

BTW. English XP home, SP2

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

so Someguy22 got BLIPS running OK on an English XP system. It's the German (or other) versions that don't work.

da21: do you have VB6? I would like to send the sources to someone with VB6 for German (or ?) XP SP2 and have them tell me what needs changing. Then I'll put a new version in the academy. I don't want sources for the version that doesn't work to spread around.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have sucessfully used BLIPS to assemble a bootloader and program it to a Mega8, then compile a "blinky" program with the ImageCraft eval compiler, then download and run the program.

Windows XP, Home, US edition, SP2
BLIPS 2.1

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

regarding finding the bug in the German language (and other non-English?) versions of XP with BLIPS 2.1, I'm waiting to hear back from a user in Germany.

Steve

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

stevech wrote:
regarding finding the bug in the German language (and other non-English?) versions of XP with BLIPS 2.1, I'm waiting to hear back from a user in Germany.

Steve

Hi Steve,

i'm the german user that found out that BLIPS2.1 has this runtime error bug with german windows versions, XP and W2K. If i understand it correctly other users like garoca (hungarian) and kkontak (greek) have the same error on their XP systems so it's no german-version only problem but a common problem with international windows versions.

Unfortunatly i don't have VB6 and i don't think microsoft offers it for free. Will your source compile with the free .NET studio express? If yes, i would offer to give it a try though i'm no VB programmer. If not, i don't see how i can help you in the moment.

I read somewhere after googling a bit that there is an extra chapter in the VB help about programming for international versions. Maybe this is helpful here?

If you have anything new to test i'm the first to give it a new try; i would really love to see it running.

Cheers
Holger

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Eventually i can get access to VB6 at work. I will give it a try if you send me the sources to hdpub _At_ gmx _Dot_ de

Holger

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I haven't heard back from the person with a German XP on which the the error occurs. I sent the stuff to trap the error since I cannot. Maybe that person is on holiday.

I did a version of BLIPS for VB2005 express. I abandoned that version and went back to VB6 because the time needed to launch the program was absurd with the huge overhead of .NET2. Microsoft doesn't get it. Who wants to sit for 30 or more seconds with the hard disk thrashing away before the program's window opens (on an AMD1800)?

So I'll take a pass on VB2005 and .NET2 for me. The software bloat and overhead for object oriented abstractions has gotten much too far ahead of the hardware state of the art. Microsoft's developers and testers need slower PCs.

end of rant.

Last Edited: Thu. Jul 20, 2006 - 03:40 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Some people are reporting Run Time Error 9 when BLIPS 2.1 runs. With the help of user Anders N. I found that this happens when the serial port enumeration yields no ports named COM1 and up. Since every PC I've seen has a COM1, what else could be going on? Does a foreign language XP call COM1 something else? Does the string compare of "COM" fail in BLIPS due to unicode text rather than 8 bit ASCII?

Anyone have a guess?

Here's what BLIPS uses to enumerate the ports

Public Declare Function EnumPorts Lib "winspool.drv" _
Alias "EnumPortsA" _
(ByVal pName As String, _
ByVal nLevel As Long, _
lpbPorts As Any, _
ByVal cbBuf As Long, _
pcbNeeded As Long, _
pcReturned As Long) As Long

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

BLIPS 2.2 is in Academy projects files area.
It copes with the COM port enumeration problem (see discussion above).

If you need the DLL/OCXes for BLIPS, use version 2.1 which has a setup.exe, then replace the exe with version 2.2.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

BLIPS 2.2 solved the problems with international windows versions! (At least for me, tested with W2K german until now). No runtime error now.

After startup there's a message saying "NO COM PORTS found by enumaration..." but if i select the correct COM Port in the serial settings it works. Maybe this is because my laptop only has COM4, so there's no COM1?

Testing with ATmega168:
I can read the chip ID, do a flash erase but if i try to write the flash memory i get a message "Error in response to an "A" 0 command. Incorrect (or no) response from bootloader."
Maybe a problem with the mega168 bootloader AVR code?

stevech wrote:
I haven't heard back from the person with a German XP on which the the error occurs. I sent the stuff to trap the error since I cannot. Maybe that person is on holiday.

If you meant me with this i havn't got anything until now. Maybe an email address typo?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

On the COM ports, this must be some quirk in that laptop and COM4. The BLIPS use of the MS Windows enumerate ports system call looks for "local" ports. Maybe that COM4 isn't "local". That system call says it returns whatever COM ports exist, no matter how they're numbered. I have more to learn on this, I guess. So for now, BLIPS 2.2 just blindly creates COM1-8 for its choices, if enumeration yields no ports at all.

On the other issue: with the mega168 - sounds like the chip signature is read OK. And if the erease command works, then the basics are working. The 'A" command just sets the address, in this case, to zero, to start the flash loading. The AVR side gets the 'A' and then the two bytes of address 0 and 0 and stores them then sends back a CR to the PC. The error you're seeing is BLIPS timing out getting the CR. If you look at the ASM code, this is at label "L12". It's pretty simple code. Let's see what we can diagnose here. Take a look at the list file from AVRStudio's assembly of the bootloader asm code. There's a conditional assembly on the RAMPZ register. Since the mega168 has no RAMPZ, and you have, we assume, changed the include file to be the mega168, then the RAMPZ "out" instruction would be omitted in the listing. Other than this, let me know what you might suspect.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

stevech wrote:
I.So I'll take a pass on VB2005 and .NET2 for me. The software bloat and overhead for object oriented abstractions has gotten much too far ahead of the hardware state of the art. Microsoft's developers and testers need slower PCs.

One of the main reasons I'm not rich right now is that in 1987 I decided not to dump 10k in Microsoft because I thought Microsoft wasn't going anywhere because the code they were introducing would barely run on the machines of the day. what I didn't realize is that Bill Gates real genuis was having his people use the fastest machines they could get their hands on to develop code that would barely run, because he knew that in a year or so the machines would catch up. Folks who wrote for the average machines of the day wound up with code that seemed slow and archaic compared to the matured Windows code and the rest is history.

Also, my .NET code comes right up with not delay whatever, so I'm not sure what you are doing that makes it take 30 seconds. I use C# Express, but VB Express and C# Express both are translated to the CLR before being run and I can't see how that process could be causing a difference. Anyway I like the Express stuff because it works well for me, has improved my efficiency by a factor or 10 over C++ and MFC, and it is FREE.

end of rant.

Smiley

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

the problem with the failure to enumerate com ports was found by Anders N.
He points out my naieve error in comparing the string "local" in the enumeration procedure. This can be "lokal" in other languages. Gee, Microsoft, the system call can return either "lokal" or "local". I will have to figure out how to cope. Meanwhile, BLIPS 2.1 defaults to COM1-8.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

smileymicros wrote:
stevech wrote:

Also, my .NET code comes right up with not delay whatever, so I'm not sure what you are doing that makes it take 30 seconds

end of rant.

Smiley

Maybe the 30 seconds is because my PC is just an AMD1800. But moreover, if the .NET2 version of BLIPS is the FIRST program that runs that uses the .NET2 libraries, this long delay happens. After the 10's of megabytes of bloated libraries are loaded and linked at run time, the next launch is faster. I still take the position that I'll avoid the bloat and stick with VB6 and no .NET for the time being.

On philosophy: I remember years and years ago a study that IBM did on their VM operating sytem and applications. That concluded that about 80% of the machine cycles were spent MOVING data rather than calculating anything. I think Microsoft has taken that to 99.99%, with all the abstraction layers.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'd add that 99.99% of computer time in general is used to coddle the user and has nothing whatever to do with 'computing'. It's almost all about the user experience. Also, I'm not sure that is such a bad thing - I'd much rather labor the processor than my brain. I use the Windows Calculator program and you just know that thing is 99.99% dedicated to look and feel and 0.001% to actual calculation. What percent of the activity we have here on AVRFreaks does any computing and what precent is just moving data around? Again, I'd bet that it is 99.99% and I think it is a good thing. I'm probably using more computational power right now writing this dumb missive than was available on the entire planet 25 years ago.

What you are calling bloat could also be looked at as appropriate application of resources for the intended use.

Funny though, I don't mean to start an argument or hijack the thread, it's just that I really like .NET and I really hated the C++/MFC that preceeded it. MFC was a real step up from the Windows API for making GUI's for use with microcontrollers, but C# .NET is a quantum leap in ease of use for me.

And finally, Microsoft has decided to let non-.NET coding become obsolete, note that there is no non .NET VB7, so we might as well realize that 'resistence is futile' and just Borg on.

Smiley

Pages