I'm running a Raspberry PI 4B Buster environment with all recommended OpenVino dependencies.
I'm trying to put together an object detection pipeline, with multiple object detectors, and multiple inference requests per object detector.
The problem occurs after some time, 10m to 10h, the program doesn't crash, but I can see on the pipeline, that inference stops to happen. Running lsusb the Myriad device is missing.
First thought was temperature issues, but the device doesn't reach above 42.5 °C.
In dmesg output there's no sign of undervoltage issue.
I'd need your help to investigate the problem, the things I've tried so far are:
Different Python version (3.6, 3.7, 3.8)
Different OpenVINO version (2021/3, 2021/4)
Different Raspberry Device.
The environment contains of:
|||
|-|-|
| OS | Raspbian Buster 10 |
| Python | 3.7.3 |
| OpenVINO | 2021.4.2-3974-e2a469a3450-releases/2021/4 |
The OpenVINO Action Recognition Python Demo is the best reference for you since it uses multiple models and the inference uses input video.
Each step in this demo implements PipelineSteps interface by creating a class derived from PipelineSteps base class. It has been designed to properly function with the supported hardware (CPU,GPU, HDDL or MYRIAD).
Your issue could be caused by your modified code (maybe some error handler is required, some sequence of processes is improper, etc) or caused by the NCS2 device itself.
Try to confirm the device availability:
NCS2 was detected after rebooting and running lsusb - the NCS2 is in a good condition. It's just that sometimes, there are some underneath services halted/incomplete, which results in this issue.
NCS2 was not detected after rebooting and running lsusb - it could be a device issue/malfunction and if still within the warranty period, you may ask for a replacement.
I have a Micro bit v1. Days before, I was unable to search the Bluetooth signal of it, so I followed the instruction on microbit.org to upgrade its firmware. But after I copied the firmware file into it, a FAIL.TXT file showed up in the disk MAINTENANCE. What's more, since then on, every time I connect the Micro bit to my computer, it enters this MAINTENANCE disk, no matter I press the Reset or not during the connection. I've tried different versions of firmwares of the Micro bit v1, but none of them succeed.
The details about this Micro bit are shown as below.
# DAPLink Firmware - see https://mbed.com/daplink
Unique ID: 00000000066aff565357825187123855a5a5a5a597969908
HIC ID: 97969908
Auto Reset: 0
Automation allowed: 1
Overflow detection: 0
Daplink Mode: Bootloader
Bootloader Version: 0254
Git SHA: db711ec68a861b9d9b0d7a7a82071796ec117687
Local Mods: 1
USB Interfaces: MSD
Bootloader CRC: 0x0697f838
Interface CRC: 0x4915d882
Remount count: 1
URL: https://mbed.com/daplink
The contents of FAIL.TXT are shown as below.
error: In application programming aborted due to an out of bounds address.
type: interface
So, I am wondering that, what possibly has occured this upgrade failure ? And how can I fix my Micro bit ?
I am 7 months late, I know, and I made an account just ot answer here. I see some strange things I haven't seen before in your details;
You're missing the part of the UID that specifies the version of the
Micro:Bit (4 first numbers are supposed to be 9900 for 1.3 and 9901
for 1.5, not sure if it's different if you have 1.0).
Interface version is missing from the details.
Local mods being set to 1 means you have unsaved local changes to the Micro:Bit.
Remount count being set to 1 means it has failed to flash the previous hex you tried to flash to it. Not a good sign, but it means you only tried (or it only counted) once to reflash the firmware.
Try flashing an erase hex to the Micro:Bit, then an up-to-date firmware hex, and lastly the OOB hex. This worked for me when I experienced a similar issue.
I hope any of this can help you, or any others that stumble upon this post in the future.
Please reach out if you still need help!
This micro:bit has wrong HIC ID (97969908 instead of 97969901). It doesn't have original bootloader that's why you are not able to flash original interface firmware. According to DAPLink 97969908 is STM32F103XB bootloader. I think there are 2 possible solutions: 1st is to flash original bootloader and original interface firmware then, 2nd is to make some with DAPLink source files to compile a new interface firmware that would work with 97969908 bootloader.
See here https://github.com/ARMmbed/DAPLink/discussions/956
1. The problem explained
I'm trying to use OpenOCD for something uncommon. Instead of connecting to the chip, I'd like to merely detect the chip.
The procedure I have in mind would look like this:
Start OpenOCD with the probe config file (eg. stlink.cfg ) given as -f parameter. So OpenOCD knows what probe to use, but doesn't know what chip it will find.
OpenOCD detects a chip and reports this somehow (eg. write something to stdout). If possible, this action should not be intrusive to the chip (like resetting it).
OpenOCD shuts down.
Here are some more notes about the procedure:
Note 1: It would be nice if OpenOCD doesn't reach the server state where I need to setup a Telnet or GDB client to interact with it. I'd be happy to get the chip detection reported in a more convenient way, like getting the chip info on the stdout channel.
Note 2: The detection should be non-intrusive to the chip. However, if OpenOCD doesn't find anything, I'd like to have a backup method where OpenOCD tries to find a chip more aggressively (like holding down the nRST pin). I can invoke this other approach myself if needed (so there's no need for OpenOCD to do that automatically).
Note 3: At first, I'll just apply this "chip detection" only on STM32 chips with an STLinkV2 or STLinkV3 probe, later on other probes and chips as well.
Note 4: Some boards only have an SWD connection (no JTAG).
Note 5: I'm working on a Windows 10 computer, and got a very recent OpenOCD build (version 0.10.0_dev00921, built on 06 July 2019) downloaded from https://www.playembedded.org/blog/download/
2. What I've tried so far
Mr. Tommy Murphy referred me to Section 10.7 in the OpenOCD reference manual (see http://openocd.org/doc/pdf/openocd.pdf). I've read the section and observed the following example:
# openocd.cfg file
# -----------------
source [find interface/olimex-arm-usb-tiny-h.cfg]
reset_config trst_and_srst
jtag_rclk 8
Because my chip connects through the STLink probe and uses SWD transport protocol (instead of JTAG), I made a few modifications to the example:
# openocd.cfg file
# -----------------
source [find interface/stlink.cfg]
transport select hla_swd
reset_config srst_only
adapter_khz 480
I connect a NUCLEO_F303K8 board to my PC for this test. Then I issue the following command in my console:
> openocd -s "C:\...\scripts" -f "C:\...\openocd.cfg"
OpenOCD outputs the following and then terminates:
Open On-Chip Debugger 0.10.0+dev-00921-gef8c69ff9 (2019-07-06-01:00)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
adapter speed: 480 kHz
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : clock speed 480 kHz
Error: BUG: current_target out of bounds
So I end up with a few questions concerning autoprobing.
3. My questions
Question 1:
Is "Autoprobing" (as described in Section 10.7) really what I need here? If the answer is No, please ignore the next questions.
Question 2:
I've tried to imitate the example given in Section 10.7, with some minor modifications to make the example suitable for my Nucleo board. Unfortunately the Autoprobing fails. Is this because OpenOCD doesn't support autoprobing with the SWD protocol? Or am I simply making a mistake in my .cfg file?
Question 3:
I noticed that the Autoprobing example from Section 10.7 configures the reset behaviour of OpenOCD. Does this mean that Autoprobing will always be "intrusive" in the sense that it resets the chip?
Question 4:
The Autoprobing example from Section 10.7 seems to bring OpenOCD into the server state anyhow. Is it possible to avoid that? I want to keep this "chip detection" thing simple, without the need for a Telnet or GDB client.
EDITS
Thank you #nattgris for your remarkable answer. I've got a few more practical questions though.
1. With ST-Link
Suppose we're using the ST-Link, despite its sub-optimal cooperation with OpenOCD. You said:
.. if all you need is to know is whether a chip is there at all, in some configurations the ST-Link can probably be persuaded to give you that info.
How do I practically persuade the ST-Link to do that? In other words, what should I put in my openocd.cfg file to achieve this?
2. With SWD-probe (but not ST-Link)
Suppose we're using a true SWD-probe. You said:
Autoprobing, as described in Section 10.7, is only relevant for JTAG [...]. Simply connecting via SWD prints the corresponding information (the DPIDR register instead of the TAP IDCODE). So either way, you can get similar info about the chip over both protocols. [...] For all Cortex-chips, you will basically get "ARM" instead of the actual manufacturer of the chip (e.g. "ST"). Though ST (and perhaps other manufacturers) chips have a separate boundary scan TAP (i.e. JTAG only) that provides an actual ST IDCODE that can be used for chip identification.
From this, I conclude that:
Autoprobing as described in Section 10.7 is only applicable on JTAG, not on SWD.
As Autoprobing is not available for SWD, the alternative approach is to simply connect to the chip, after which OpenOCD automatically prints the DPIDR register. This DPIDR register is the SWD-equivalent of the JTAG TAP IDCODE, so to speak, and can identify the chip to some extent.
But how does one simply connect to the chip, if one doesn't know what chip is attached to the PC in the first place? If I'm not mistaken, OpenOCD always needs the specific config file, like stm32f7x.cfg, stm32f4x.cfg, stm32l0.cfg, ... to connect to the chip.
Apparently, the JTAG IDCODE and the SWD-equivalent DPIDR register provide the chip designer, which would always be "ARM" for the ARM-Cortex chips. This is not enough for complete chip identification. However, you say that ARM-chips have separate boundary scan TAPs providing further IDCODE registers for more complete identification. Unfortunately, these are JTAG-only. This means that SWD is on a dead-end here in terms of chip identification?
Autoprobing with JTAG (and therefore reading the IDCODE reg) can be completely non-intrusive. Therefore, one can make the system reset signal unavailable:reset_config noneYou say that reading the DPIDR over SWD (which I consider to be the SWD-equivalent of JTAG autoprobing) is also non-intrusive. Could I also enforce that "non-intrusiveness" by making the reset signal unavailable?
3. With JTAG-probe (but not ST-Link)
The JTAG protocol seems to provide the best support for chip identification (using Autoprobing). My conclusions:
The Autoprobing described in Section 10.7 would print the TAP IDCODE from the chip. For ARM-chips that would simply print "ARM", not the actual manufacturer (like "ST") and the chip name (like "STM32F767ZI").
How do I practically make sure that the procedure also prints these further info's, more in particular the actual chip name? In other words, what should I put in my openocd.cfg file (and possibly the openocd startup command) to achieve this?
Thank you very much :-)
Question 1:
Is this what you need? Depends. Autoprobing, as described in section 10.7, is only relevant for JTAG. So by itself, it won't cover your needs. But simply connecting via SWD prints the corresponding information (the DPIDR register instead of the TAP IDCODE) so either way, you can get similar info about the chip over both protocols.
However, I'm not sure if that's enough for you. If you only want to detect that a chip (any chip) responds, this is probably enough. If you also need to identify the chip in detail, further examination will in general be necessary, since the ID codes you get through both methods identifies the designer of the chip. So for all Cortex-chips, you will basically get "ARM" instead of the actual manufacturer of the chip (e.g. "ST"). Though ST (and perhaps other manufacturers) chips have a separate boundary scan TAP (i.e. JTAG only) that provides an actual ST IDCODE that can be used for chip identification.
However, since SWD is relevant only for ARM Cortex-type (or rather ADI v5) targets, if you can use SWD you can also read the ROM Table of the debug components, which provide among other things the manufacturer of the chip:
# Your JTAG adapter config
script interface.cfg
transport select swd
adapter_khz 100
swd newdap chip cpu -enable
dap create chip.dap -chain-position chip.cpu
target create chip.cpu cortex_m -dap chip.dap
init
dap info
shutdown
Output for an STM32F103:
Info : SWD DPIDR 0x1ba01477
Info : chip.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : gdb port disabled
AP ID register 0x14770011
Type is MEM-AP AHB
MEM-AP BASE 0xe00ff003
Valid ROM table present
Component base address 0xe00ff000
Peripheral ID 0x00000a0410
Designer is 0x0a0, STMicroelectronics
Part is 0x410, Unrecognized
Component class is 0x1, ROM table
MEMTYPE system memory present on bus
ROMTABLE[0x0] = 0xfff0f003
Component base address 0xe000e000
Peripheral ID 0x04001bb000
Designer is 0x4bb, ARM Ltd.
Part is 0x0, Cortex-M3 SCS (System Control Space)
Component class is 0xe, Generic IP component
ROMTABLE[0x4] = 0xfff02003
Component base address 0xe0001000
Peripheral ID 0x04001bb002
Designer is 0x4bb, ARM Ltd.
Part is 0x2, Cortex-M3 DWT (Data Watchpoint and Trace)
Component class is 0xe, Generic IP component
ROMTABLE[0x8] = 0xfff03003
Component base address 0xe0002000
Peripheral ID 0x04000bb003
Designer is 0x4bb, ARM Ltd.
Part is 0x3, Cortex-M3 FPB (Flash Patch and Breakpoint)
Component class is 0xe, Generic IP component
ROMTABLE[0xc] = 0xfff01003
Component base address 0xe0000000
Peripheral ID 0x04001bb001
Designer is 0x4bb, ARM Ltd.
Part is 0x1, Cortex-M3 ITM (Instrumentation Trace Module)
Component class is 0xe, Generic IP component
ROMTABLE[0x10] = 0xfff41003
Component base address 0xe0040000
Peripheral ID 0x04001bb923
Designer is 0x4bb, ARM Ltd.
Part is 0x923, Cortex-M3 TPIU (Trace Port Interface Unit)
Component class is 0x9, CoreSight component
Type is 0x11, Trace Sink, Port
ROMTABLE[0x14] = 0xfff42002
Component not present
ROMTABLE[0x18] = 0x0
End of ROM table
For non-Cortex chips, you will get good identification using the JTAG TAP IDCODE from autoprobing alone, like in this example with an old STR750:
# Your JTAG adapter config
script interface.cfg
transport select jtag
adapter_khz 100
init
shutdown
Info : JTAG tap: auto0.tap tap/device found: 0x4f1f0041 (mfg: 0x020 (STMicroelectronics), part: 0xf1f0, ver: 0x4)
Question 2:
As described above, "autoprobing" is only relevant for JTAG, but you get the same functionality (reading an ID code) over SWD as well. Unfortunately, that doesn't help you because you don't have access to either protocol!
The problem is that you use the ST-Link. Despite what people tend to think, this is NOT a true JTAG/SWD adapter. Yes, it speaks both JTAG and SWD, but it completely hides the protocol inside the adapter firmware. It only provides a high-level command set to the host (OpenOCD), of the type "Reset the target", "Step the target", "Read this memory" etc. As a consequence, the OpenOCD support of the ST-Link is an ugly hack, where it sits at the target layer instead of the adapter layer. So most adapter-, transport- or DAP-level features of OpenOCD simply does not exist and autoprobing in the OpenOCD sense is completely irrelevant for your setup.
For simple flashing and very basic GDB debugging, the ST-Link works. But for anything more low-level, just stay away from the ST-Link. It's not a good match at all for OpenOCD.
That said, if all you need is to know is whether a chip is there at all, in some configurations the ST-Link can probably be persuaded to give you that info, for example with the following configuration file:
script interface/stlink.cfg
transport select hla_swd
adapter_khz 100
hla newtap chip cpu -enable
dap create chip.dap -chain-position chip.cpu
target create chip.cpu cortex_m -dap chip.dap
You will get either
Warn : UNEXPECTED idcode: 0x2ba01477
or
Error: init mode failed (unable to connect to the target)
The rest of the questions are irrelevant together with an ST-Link, so I will assume that you switch to a real JTAG/SWD adapter.
Question 3:
JTAG autoprobing, as well as reading the DPIDR over SWD, is completely non-intrusive. For Cortex-M targets in general, most debug accesses to the target are non-intrusive so you can read/write memory etc. while the target is running hardly without affecting it.
JTAG does not define or require a system reset signal to be available at all. Autoprobing works fine without it, you should be able to use
reset_config none
Question 4:
Do you want to avoid starting a gdb server/telnet server at all? Then you can disable them with the following configuration:
gdb_port disabled
telnet_port disabled
tcl_port disabled
However if you just start OpenOCD to detect a chip and then shut it down, temporarily starting these services may not be a problem anyway.
Moreover, at least the GDB server is started only after creating a target, which isn't necessary to perform a JTAG autoprobe.
Summary
Yes you should be able to do what you want, but perhaps not with the ST-Link. With a real adapter you can do JTAG autoprobing to print detected TAPs on the scan chain. For SWD, OpenOCD always prints the detected DPIDR register (and generally breaks if no target is found; output will be different at least).
Connection/detection can be completely non-intrusive, if the target itself supports it, as most Cortex-M ones do. If target firmware have disabled debug pins, or powered down debug logic, you may need to hold or pulse reset, depending on the target.
With the mainline OpenOCD code you can access memory of the target easily. You can read some identification data from the target decode it and detect the chip.
BTW, this will probably not work with high level adapters such as STLink. Please use generic adapters (J-Link, FTDI-based adapters, CMSIS-DAP, etc).
source [find interface/jlink.cfg]
transport select swd
adapter_khz 1000
set _CHIPNAME generic_dap_access
# 1. DECLARE A DAP
# -----------------
# Declare a single DAP (a DAP is the SWD counterpart for a JTAG TAP)
# for the chip's cpu. The command `swd newdap` has the same parameters
# as `jtag newtap`.
# param one: Name of the module in the JTAG scan chain (usually a chip).
# param two: Tapname, reflects the role of the TAP (bs, cpu, flash, ...).
# -irlen 4: Instruction register length is 4 bits
# -ircapture 0x1: The bit pattern loaded by the TAP into the JTAG shift register on entry
# to the ircapture state. Default is 0x01.
# -irmask 0xf: A mask used with-ircaptureto verify that instruction scans work correctly.
swd newdap $_CHIPNAME cpu -irlen 4 -ircapture 0x1 -irmask 0xf
# 2. CREATE (?) A DAP AND LINK TO JTAG TAP
# -----------------------------------------
# Since OpenOCD version 0.11.0, the Debug Access Port (DAP) is no longer implicitely
# created together with the target. It must be explicitely declared.
# Declare a DAP instance named $_CHIPNAME.dap linked to the JTAG tap $_CHIPNAME.cpu.
dap create $_CHIPNAME.dap -chain-position $_CHIPNAME.cpu
# Note: Observe important note in manual
# for ARMv6-M, ARMv7 and ARMv8 targets.
# 3. DECLARE SOME PROCEDURES
# ---------------------------
# 3.1 Writes 'val' to address 'addr' via AP 'ap'
proc mww_ll { ap addr val } {
global _CHIPNAME
# I'm a bit confused how the following commands achieve just that.
$_CHIPNAME.dap apreg $ap 0x04 $addr
$_CHIPNAME.dap apreg $ap 0x0C $val
}
# 3.2 Reads and displays data from address 'addr' via AP 'ap'
proc mdw_ll { ap addr } {
global _CHIPNAME
$_CHIPNAME.dap apreg $ap 0x04 $addr
$_CHIPNAME.dap apreg $ap 0x0C
}
# 3.3 Reads data from address 'addr' via AP 'ap' and returns it
# Can be used to read data and pass it to other commands
proc mrw_ll { ap addr } {
global _CHIPNAME
$_CHIPNAME.dap apreg $ap 0x04 $addr
set ap [ocd_$_CHIPNAME.dap apreg $ap 0x0C]
regsub -all {(\s*\n)+} $ap "" ap
return $ap
}
# 4. INITIALIZE
# --------------
init # <- What does this actually do? I'm used to see `reset-init`
# everywhere in OpenOCD, but I don't know what simple `init` does.
# 5. READ VALUE AT 0x10000000
# ----------------------------
# Reads and displays value at 0x10000000 <- Why? What's special about
mdw_ll 0 0x10000000 # this memory location?
# 6. MODIFY RAM DATA
# -------------------
# Modify some data in RAM <- Why?
mdw_ll 0 0x08000000
mww_ll 0 0x08000000 0xdeadbeef
mdw_ll 0 0x08000000
exit
OpenOCD output:
Open On-Chip Debugger 0.10.0+dev-01116-gfc2e5110d-dirty (2019-07-11-16:04)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
adapter speed: 1000 kHz
Info : J-Link Ultra V4 compiled May 27 2019 15:49:24
Info : Hardware version: 4.00
Info : VTarget = 4.850 V
Info : clock speed 1000 kHz
Info : SWD DPIDR 0x6ba02477
Warn : gdb services need one or more targets defined
0x976562e5
0x20004602
0xdeadbeef
I have a Lindy IRDA USB bridge attached to my Xperia Neo (Cyanogen Mod 9). I have changed the features to support host mode etc. All is looking fine in the code. I detect the device. I can see the interface and the two endpoints (one in, one out), however as soon as I try to claimInterface it fails, regardless of whether I atempt a force claim or not.
There appears to be no simple way to find out why the claim fails. Though strace gives me a clue as the ioctl call for claim interface fails with a device not found error.
Ignoring the failure gets me only as far as the request which then fails to queue or send.
The questions I have are (I think):-
What exactly is missing that is resulting in the claim failing?
Is there a way around this that ideally would not require root?
Is there a way to override the claim somehow?
OK, so I appear to have fallen into answering my own question here, but I see that a number of people are getting confused over the apparent support for USB Host and the "odd" behaviours that can be observed so hopefully this answer may help some of you out.
I posed 3 questions, I have a definitive answer for 1 & 3 but I am less certain about the other at this stage.
1) What exactly is missing, and why does this result in a bad claim?
The problem is that the device, a lindy IRDA dongle is being detected by the host (my Xperia Neo handset) but that the only configuration that it supports is demanding too much power for the handset to support.
Oddly, this does not prevent either a) the device from being detected and enumerated by the Android libraries or b) from it appearing to be powered (red LED glowing)
There is no report at the time of the failing claimInterface() call from any system libraries, however a dmesg|tail running when the device is attached gave the necessary insight.
dmesg | tail
<3>usb 1-1: device v066f p4200 is not supported
<6>usb 1-1: New USB device found, idVendor=066f, idProduct=4200
<6>usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
<6>usb 1-1: Product: IrDA/USB Bridge
<6>usb 1-1: Manufacturer: Sigmatel Inc
<6>usb 1-1: rejected 1 configuration due to insufficient available bus power
<4>usb 1-1: no configuration chosen from 1 choice
Further investigation showed that this little device was claiming a requirement for 440mA which seems rather a lot but there seems little that can be done about it.
Questions 2 Can anything that does not require root be done to work around this?
It seems not. In theory I could provide external power to the device through the use of a USB Y cable or similar hackery but I don't believe that that would change the underlying problem that the handset refuses the demand. Even with root it is not clear that anything can be done to override the power profile.
Question 3, is there a way to override the claimInterface() failure and force the communications?
This is a blunt no. The device has simply not been created by the kernel so there is nothing there to override in the first place. Which does make it somewhat puzzling as to why the Android libraries still offer it up.
As to Question 2 and power demands...
Most android devices that support Host/OTG that I have run across, will only support a maximum current draw of around 100 mA. Could you force it to work via some kernel source hackery? Likely, but you would run a very real risk of burning up the USB support circuitry in your android device. This is because the Boost converter that such devices use to power the external usb device only physically support that maximum 100 mA current draw.
Could you use a Y-Cable to supply the needed current externally? Yes, I have done this before on a device that had no boost converter, but you would then need to have a workaround in the kernel to tell it that you had such external power, and that it was now okay to power the device up.
I've got quite a fun challenge / work assignment. I'm to monitor a couple of 5V light bulbs (warning lights) on a machine standing far out in no man's land. I'm looking for an affordable device with an input which allows me to hook into the light bulb circuit to tell whether it's lit or not.
Requirements:
GPRS
Inputs for at least two light bulbs
Programmable in C or something similar.
Bonus (not required, but it would be kind a nice):
Waterproof casing / chassis (I could make this my self, but it would be nice if I didn't have to)
Option to add other sensors like humidity, temperature and gps.
Any tips?
I'd recommend an arduino
Arduino is an open-source electronics prototyping platform based on flexible, easy-to-use hardware and software. It's intended for artists, designers, hobbyists, and anyone interested in creating interactive objects or environments.
Arduino can sense the environment by receiving input from a variety of sensors and can affect its surroundings by controlling lights, motors, and other actuators. The microcontroller on the board is programmed using the Arduino programming language (based on Wiring) and the Arduino development environment (based on Processing). Arduino projects can be stand-alone or they can communicate with software on running on a computer (e.g. Flash, Processing, MaxMSP).
there's an article here on hooking one up with gps
http://www.arduino.cc/playground/Tutorials/GPS
and for more information on the arduino platform in general, and where to buy
http://www.arduino.cc/
Edit: just noticed you were looking mainly for GPRS and not GPS - doh, however, quick look on google brings up this: http://www.libelium.com/squidbee/index.php?title=New_GPRS_module_for_Arduino_%28Hilo_-_Sagem%29 which is a GPRS module for the arduino :]
Have you looked at Arduino?
in fact, what you are asking already exists: many companies which produces electrical component for the industry provides a rail-mounted GPRS modem for remote signaling.
here is one example, made by phoenix contact
another one from another company
the tele-control range of product from wago
telit is well-known for its GSM chips, and provides a complete module with GPRS and programmable in python.
you can find some fancier systems including GPS and linux-based, here for example
there are countless other solutions...
I would buy the Terminus from Janus RC it is based on a telit module. It is a cell modem with 9 GPIO and you can program it using python.
Interface
9 Bi-directional CMOS I/Os
Power Monitor
1 ADC
ITU-T V.24 serial link through UART
Python Script Support
Integrated Python script interpreter (V1.5.2+)
2 MB of non-volatile memory
1.2 MB of RAM reserved for Python engine usage
Powerful built-in libraries makes accessing hardware easy