Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. Other Discussions
  3. IT & Infrastructure
  4. Intel Atom, is it a poor platform for an undemanding VC6.0 application ?

Intel Atom, is it a poor platform for an undemanding VC6.0 application ?

Scheduled Pinned Locked Moved IT & Infrastructure
c++comsysadminhardwarehelp
8 Posts 4 Posters 11 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • N Offline
    N Offline
    Neil Urquhart
    wrote on last edited by
    #1

    I have a comand and control application which I have developed using VC6.0. Basicaly it works fine on all the PC's I have kicking around barr two. Namely the intended traget hardware (would'nt you know it :doh: ) and one other desktop machine. The commonality between the two machines which fail to run the app correctly is that they both use Intel Atom processors. The target hardware is an Asus EEE Box which has a 1.6Ghz Intel Atom with 1GB RAM and XP Home. The other machine that fails to run is a Compaq mimi desktop PC with an Intel Atom 230 and 1GB RAM and Xp Home. Other machines I have which do run the app correctly are my Desktop PC (Intel Pentium III Xeon, 267Ghz, 4GB RAM), my IBM X31 Laptop (Intel Pentium(R) @ 1.7Ghz & 1GB RAM, XP Prof), old desktop PC (1.3Ghz Intel Celleron) and another old IBM X30 Laptop (1.4Ghz I think). The application is undemanding in that it just has to accept commands from a radio modem conntected to a COM port (9600 Baud) and then issue commands to a bunch of 54 lighing faders on another COM port (Baud 19.2k). It has a GUI status/control page constructed with MFC controls. The application runs two worker threads below the MFC front end, one low level task to send/recieve and CRC check the serial I/O packets and another task to act as a server to the commands from the command from either the GUI or Radio Link. Does the Intel Atom have some fundemtal problems :confused:

    T L G 3 Replies Last reply
    0
    • N Neil Urquhart

      I have a comand and control application which I have developed using VC6.0. Basicaly it works fine on all the PC's I have kicking around barr two. Namely the intended traget hardware (would'nt you know it :doh: ) and one other desktop machine. The commonality between the two machines which fail to run the app correctly is that they both use Intel Atom processors. The target hardware is an Asus EEE Box which has a 1.6Ghz Intel Atom with 1GB RAM and XP Home. The other machine that fails to run is a Compaq mimi desktop PC with an Intel Atom 230 and 1GB RAM and Xp Home. Other machines I have which do run the app correctly are my Desktop PC (Intel Pentium III Xeon, 267Ghz, 4GB RAM), my IBM X31 Laptop (Intel Pentium(R) @ 1.7Ghz & 1GB RAM, XP Prof), old desktop PC (1.3Ghz Intel Celleron) and another old IBM X30 Laptop (1.4Ghz I think). The application is undemanding in that it just has to accept commands from a radio modem conntected to a COM port (9600 Baud) and then issue commands to a bunch of 54 lighing faders on another COM port (Baud 19.2k). It has a GUI status/control page constructed with MFC controls. The application runs two worker threads below the MFC front end, one low level task to send/recieve and CRC check the serial I/O packets and another task to act as a server to the commands from the command from either the GUI or Radio Link. Does the Intel Atom have some fundemtal problems :confused:

      T Offline
      T Offline
      Tony Richards
      wrote on last edited by
      #2

      How precisely does it fail?  I don't think there are any problems with the Atom processors, I for one run Visual Studio 2008 on my netbook which is Atom powered.

      N 1 Reply Last reply
      0
      • T Tony Richards

        How precisely does it fail?  I don't think there are any problems with the Atom processors, I for one run Visual Studio 2008 on my netbook which is Atom powered.

        N Offline
        N Offline
        Neil Urquhart
        wrote on last edited by
        #3

        One of the applications tasks seems to lock up and stops responding to commands via the USB serial ports. This could be down to some poor coding on my behalf that gets exposed too some sort of timing issue. ie. The Atom can't do something as quickly as other Non-Atom PC's do. As I said in my previous post I had tried the code on various low spec machines which were not Atom based in an attempt to replicate the problem, but it always ran fine. Exactly the same .exe just fails on the Atom PC's. I am planning on installing my VC6 compiler/debugger on a new Asus EEE Box (Atom PC) when it arrives today (snow permitting) and try and track down the exact place it goes wrong. I don't know anything about what the difference is as to what goes on in an Intel Atom as compared to say a Celeron. As a dumb programmer I just expected the same code to do the same thing on all compatible processors. Just as a cross fertilised thought, is it possible that VC6 can generate code which contains illegal opcodes as far as the Atom is concerned ?:confused:

        T 1 Reply Last reply
        0
        • N Neil Urquhart

          One of the applications tasks seems to lock up and stops responding to commands via the USB serial ports. This could be down to some poor coding on my behalf that gets exposed too some sort of timing issue. ie. The Atom can't do something as quickly as other Non-Atom PC's do. As I said in my previous post I had tried the code on various low spec machines which were not Atom based in an attempt to replicate the problem, but it always ran fine. Exactly the same .exe just fails on the Atom PC's. I am planning on installing my VC6 compiler/debugger on a new Asus EEE Box (Atom PC) when it arrives today (snow permitting) and try and track down the exact place it goes wrong. I don't know anything about what the difference is as to what goes on in an Intel Atom as compared to say a Celeron. As a dumb programmer I just expected the same code to do the same thing on all compatible processors. Just as a cross fertilised thought, is it possible that VC6 can generate code which contains illegal opcodes as far as the Atom is concerned ?:confused:

          T Offline
          T Offline
          Tony Richards
          wrote on last edited by
          #4

          While I don't claim to be an expert on the Atom, as far as I'm aware it's just a low-powered x86 processor.  Anything that runs on a 32bit Celeron should work on the Atom, just perhaps slower (after all, 32-bit Windows runs on the Atom fine).  That said, it could be another peice of hardware on teh system, as I doubt the motherboards are identical ;) As you say it could be a timing problem.  Also, I have had a problem where the chipset of the motherboard of an Atom powered embedded PC has been configured 'wierdly', causing things not to work.  However, at the time I was working with memory reads to IO ports across a PCI to ISA bridge (not something I plan to do again...) Have you tried producing a trivial program that does just one thing, perhaps with the USB, and see if that works.  Also, are the USB chipsets on the two computers the same?  Depending on what you are doing, this could cause a problem.

          1 Reply Last reply
          0
          • N Neil Urquhart

            I have a comand and control application which I have developed using VC6.0. Basicaly it works fine on all the PC's I have kicking around barr two. Namely the intended traget hardware (would'nt you know it :doh: ) and one other desktop machine. The commonality between the two machines which fail to run the app correctly is that they both use Intel Atom processors. The target hardware is an Asus EEE Box which has a 1.6Ghz Intel Atom with 1GB RAM and XP Home. The other machine that fails to run is a Compaq mimi desktop PC with an Intel Atom 230 and 1GB RAM and Xp Home. Other machines I have which do run the app correctly are my Desktop PC (Intel Pentium III Xeon, 267Ghz, 4GB RAM), my IBM X31 Laptop (Intel Pentium(R) @ 1.7Ghz & 1GB RAM, XP Prof), old desktop PC (1.3Ghz Intel Celleron) and another old IBM X30 Laptop (1.4Ghz I think). The application is undemanding in that it just has to accept commands from a radio modem conntected to a COM port (9600 Baud) and then issue commands to a bunch of 54 lighing faders on another COM port (Baud 19.2k). It has a GUI status/control page constructed with MFC controls. The application runs two worker threads below the MFC front end, one low level task to send/recieve and CRC check the serial I/O packets and another task to act as a server to the commands from the command from either the GUI or Radio Link. Does the Intel Atom have some fundemtal problems :confused:

            L Offline
            L Offline
            Luc Pattyn
            wrote on last edited by
            #5

            the Atom is the lowest member of the recent Intel processors; it is single-core, and power-efficient, but not anything fast. I run Visual Studio on one, works OK, not great. Your app probably has timing issues, most serial communications have some, and the weaker the processor, the more likely they are to surface. I would suggest you provide logging, and optionally log all communication activity. BTW: You do have full exception catching and handling, do you? :)

            Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]


            Happy New Year to all.
            We hope 2010 soon brings us automatic PRE tags!
            Until then, please insert them manually.


            N 1 Reply Last reply
            0
            • L Luc Pattyn

              the Atom is the lowest member of the recent Intel processors; it is single-core, and power-efficient, but not anything fast. I run Visual Studio on one, works OK, not great. Your app probably has timing issues, most serial communications have some, and the weaker the processor, the more likely they are to surface. I would suggest you provide logging, and optionally log all communication activity. BTW: You do have full exception catching and handling, do you? :)

              Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]


              Happy New Year to all.
              We hope 2010 soon brings us automatic PRE tags!
              Until then, please insert them manually.


              N Offline
              N Offline
              Neil Urquhart
              wrote on last edited by
              #6

              What exactly do you mean by full exception catching ? Could you reference some examples ?

              L 1 Reply Last reply
              0
              • N Neil Urquhart

                What exactly do you mean by full exception catching ? Could you reference some examples ?

                L Offline
                L Offline
                Luc Pattyn
                wrote on last edited by
                #7

                Every app should have sufficient exception handling, which includes: 1. local try-catch blocks to catch exceptions where you can handle them, i.e. remedy the problem, and/or can log them; 2. an overall try-catch block to cope with the ones you missed to handle in (1) 3. special provisions for special cases, Application.ThreadException is relevant here. I don't have an example handy at this moment. :)

                Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]


                Happy New Year to all.
                We hope 2010 soon brings us automatic PRE tags!
                Until then, please insert them manually.


                1 Reply Last reply
                0
                • N Neil Urquhart

                  I have a comand and control application which I have developed using VC6.0. Basicaly it works fine on all the PC's I have kicking around barr two. Namely the intended traget hardware (would'nt you know it :doh: ) and one other desktop machine. The commonality between the two machines which fail to run the app correctly is that they both use Intel Atom processors. The target hardware is an Asus EEE Box which has a 1.6Ghz Intel Atom with 1GB RAM and XP Home. The other machine that fails to run is a Compaq mimi desktop PC with an Intel Atom 230 and 1GB RAM and Xp Home. Other machines I have which do run the app correctly are my Desktop PC (Intel Pentium III Xeon, 267Ghz, 4GB RAM), my IBM X31 Laptop (Intel Pentium(R) @ 1.7Ghz & 1GB RAM, XP Prof), old desktop PC (1.3Ghz Intel Celleron) and another old IBM X30 Laptop (1.4Ghz I think). The application is undemanding in that it just has to accept commands from a radio modem conntected to a COM port (9600 Baud) and then issue commands to a bunch of 54 lighing faders on another COM port (Baud 19.2k). It has a GUI status/control page constructed with MFC controls. The application runs two worker threads below the MFC front end, one low level task to send/recieve and CRC check the serial I/O packets and another task to act as a server to the commands from the command from either the GUI or Radio Link. Does the Intel Atom have some fundemtal problems :confused:

                  G Offline
                  G Offline
                  gagnerargent
                  wrote on last edited by
                  #8

                  I don't think that the problem is due to the Atom processors.

                  1 Reply Last reply
                  0
                  Reply
                  • Reply as topic
                  Log in to reply
                  • Oldest to Newest
                  • Newest to Oldest
                  • Most Votes


                  • Login

                  • Don't have an account? Register

                  • Login or register to search.
                  • First post
                    Last post
                  0
                  • Categories
                  • Recent
                  • Tags
                  • Popular
                  • World
                  • Users
                  • Groups